DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
Claims 1-20 were previously pending in this application. The amendment filed 19 March 2026 has been entered and the following has occurred: Claims 1, 2, 8-10, & 16 have been amended. No claims have been cancelled.
Claims 1-20 remain pending in the application.
Affidavits/Declarations
The declarations under 37 CFR 1.132 filed 04 August 2025 are insufficient to overcome the rejections of claims 1-20 based upon the claims being directed towards patent-ineligible subject matter under 35 U.S.C. 101 as set forth in the last Office action because: The prior art, i.e. several references, generally point towards efforts of automatically converting electronic transmissions according to certain accessed parameters and rules/regulations, including geographic location in particular, as set forth in the ‘Claim Rejections - 35 USC § 101’ section found below. Therefore, while Applicant generally declares several points regarding the automated conversion of data into a standardized format cutting down on network traffic, computation/processing efforts, and/or transmission delays amounting to a technical improvement over prior art systems, it is understood by Examiner that any such prior art systems that disclose the same or similar efforts would also achieve said results described in the filed declarations, and therefore the claims would not amount to a technical improvement over prior art systems, because prior art systems already substantially describe Applicant’s purported improvements.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
The claims recite subject matter within a statutory category as a process (claims 1-20), which recite steps of:
receiving an electronic prescription from a prescriber device for a patient inputted by the prescriber;
looking-up regional rules in a rules database that comprises a plurality of rules for electronic prescribing, and converting the electronic prescription to a standardized format based on the regional prescription rules;
correlating the electronic prescription to a patient wallet associated with the patient and storing the electronic prescription in association with the patient wallet, the patient wallet being stored in an electronic prescription wallet database;
automatically transmitting a prescription fill request to a blockchain and a pharmacy system comprising at least one pharmacy;
creating a ledger that records prescription transactions on the blockchain automatically via the central server, wherein
each of the prescription transactions recorded in the digital ledger on the blockchain are automatically generated by the central server to include a cryptographic hash of a previous block, a timestamp, and transaction data related to the electronic prescription;
notifying one or more of the patient or the prescriber the prescription is ready for pick-up at a pharmacy of the pharmacy system; and
cancelling the prescription at the pharmacy and sending the prescription to a different pharmacy based on an input provided by the patient, wherein the patient device sends a request to access a patient profile associated with the patient wallet to fill the prescription at the different pharmacy; and
sending a receipt in response to the prescription being filled and retrieved at the different pharmacy.
These steps of receiving an electronic prescription, correlating said electronic prescription to a patient wallet, storing the electronic prescription, transmitting a prescription fill request, generating a prescription fill request, transmitting the prescription fill request to a pharmacy system, creating a ledger that records prescription transactions, notifying the patient regarding the prescription, cancelling the prescription at the pharmacy and sending it to a different pharmacy based on input provided by the patient, and sending a receipt in response to the prescription being filled, as drafted, under the broadest reasonable interpretation (BRI), includes Methods of Organizing Human Activity. MPEP 2106.04(a)(2) describes varying Methods of Organizing Human Activity specifically relating to commercial or legal interactions and/or managing personal behavior or interactions between people. For instance, correlating the electronic prescription to a patient wallet associated with a patient, presumably for managing payments for the prescription by the patient, falls under Methods of Organizing Human Activity as it relates to commercial or legal interactions, because the system manages sales activities or behaviors between the patient and the entities of the pharmacy where the prescription is being filled. Additionally, by the system performing the recited steps, the system is managing personal behavior or relationships or interactions between the patient and the entities of the pharmacy where the prescription is being filled. That is, the typical interaction or behavior between the patient and the entities of the pharmacy regarding the filling of the patient’s prescriptions, (e.g. the generation of the prescription refill in response to the patient requesting said refill, payment or financial interaction for the prescription, etc.) would be different without the performance of the enumerated steps by the instantly claimed system. Furthermore, interactions and/or transactions regarding prescription refills, cost estimation/adjudication, and/or payment for said refills, are effectively managed by the steps recited. Therefore, under the BRI, the Claims recite varying Methods of Organizing Human Activity, specifically relating to commercial or legal interactions and/or managing personal behavior or interactions between people.
Dependent claims recite additional subject matter which further narrows or defines the abstract idea embodied in the claims (such as claims 2-8, 10-15, & 17-20, reciting particular aspects of how processing a prescription, adjudicating a prescription, authenticating user data and determining user preferences may be performed in the mind but for recitation of generic computer components).
This judicial exception is not integrated into a practical application. In particular, the additional elements do not integrate the abstract idea into a practical application, other than the abstract idea per se, because the additional elements amount to no more than limitations which:
amount to mere instructions to apply an exception (such as recitation of a central server, a prescriber device, an electronic patient wallet, a database (e.g. electronic prescription wallet database), a communication interface, a blockchain, a pharmacy system, a digital ledger, a patient device, and a cryptographic hash, amounts to invoking computers as a tool to perform the abstract idea, see Applicant’s specification [0108] for a central server; [0028] for a prescriber device; [0023] for an electronic patient wallet; [0035] for a database; [0028] for a communication interface/network; [0098] for a blockchain; [0045] for a pharmacy system; [0098] for a digital ledger; and [0028] for a patient device; and [0098] for a cryptographic hash, see MPEP 2106.05(f));
add insignificant extra-solution activity to the abstract idea (such as recitation of receiving an electronic prescription from a prescriber device for a patient inputted by the prescriber, transmitting a prescription fill request to a blockchain and pharmacy system, notifying (i.e. sending a notification) the patient or prescriber the prescription is ready for pick-up, receiving an input provided by the patient, sending a request to access a patient profile to fill the prescription at a different pharmacy, and sending a receipt in response to the prescription being filled and retrieved at the different pharmacy, a transaction recorded in the digital ledger including a cryptographic hash of a previous block, a timestamp, and transaction data related to the electronic prescription amounts to mere data gathering; recitation of correlating the electronic prescription to a patient wallet associated with the patient, creating a ledger that records prescription transactions, cancelling the prescription at initial pharmacy and refilling the prescription at a different pharmacy based on an input provided by the patient, recording prescription transactions in a digital ledger, looking-up regional rules in a rules database that comprises a plurality of rules for electronic prescribing amounts to selecting a particular data source or type of data to be manipulated; recitation of storing the electronic prescription and the patient wallet in an electronic prescription wallet database and converting the electronic prescription to a standardized format based on the regional rules amounts to insignificant application, see MPEP 2106.05(g));
generally link the abstract idea to a particular technological environment or field of use (such as recitation of a blockchain and/or digital ledger being generically applied to the field of prescriptions or recording prescription transactions in said blockchain/digital ledger, see MPEP 2106.05(h)).
Dependent claims recite additional subject matter which amount to limitations consistent with the additional elements in the independent claims (such as claims 2-8, 10-15, & 17-20, which recite limitations relating to generic computer components, e.g. a controller, a memory, electronic patient wallet, a patient device, a central service/server, a patient database, a communication interface, additional limitations which amount to invoking computers as a tool to perform the abstract idea; claims 3-6, 11, 14-15, & 17-20, which recite limitations relating to transmitting a prescription fill request from a patient device or central service, notifying the prescriber of tasks included in the insurance policy associated with the patient profile, notifying one or more of the patient or prescriber, monitoring, i.e. receiving, pharmacy behavior, receiving cost estimates from one or more pharmacies and/or non-affiliated entities, specifying types of data, prescriptions, and/or patient profiles being received, relaying to the central server that only a portion of the prescription was filled, receiving geographic regional rules regarding a secondary prescriber being able to alter, modify, and/or assign changes to a prescription, receiving bids or pricing estimates responsive to a patient request, obtaining pharmacy wait times in real-time, additional limitations which add insignificant extra-solution activity to the abstract idea which amounts to mere data gathering; claims 2-7, 10, & 12-13, which recite limitations relating to updating one or more prescription fills/refills, wherein data relating to the prescription is distributed but not copied, correlating the prescription fill request to the patient profile associated with the patient wallet, once tasks are performed, cross-referencing prescription fill request to data corresponding to patient profile data, increasing financial coverage of the prescription, cancelling a prescription at an initial pharmacy by determining if a different pharmacy is selected or a threshold condition is met, determining if a patient received a partial fill of the prescription from a different pharmacy and flagging the different pharmacy if a second patient, different that the first patient, received a partial fill or a complete fill of the prescription from the different pharmacy, updating the patient wallet to include cost estimates associated with the prescription, advancing a refill of the prescription, in response to the patient receiving only a portion of the prescription from a different pharmacy, updating the blockchain to record the prescription refill, perform ad hoc requests responsive to a patient request to a particular prescription, additional limitations which add insignificant extra-solution activity to the abstract idea by selecting a particular data source or type of data to be manipulated; claims 2-8, 10-15, & 17-20, additional limitations which generally link the abstract idea to a particular technological environment or field of use such as use in remote fulfillment of prescription requests and/or electronic wallets for prescription adjudication). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation and do not impose a meaningful limit to integrate the abstract idea into a practical application.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to discussion of integration of the abstract idea into a practical application, the additional elements amount to no more than mere instructions to apply an exception, add insignificant extra-solution activity to the abstract idea, and generally link the abstract idea to a particular technological environment or field of use. Additionally, the additional limitations, other than the abstract idea per se, amount to no more than limitations which:
amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields (such as receiving an electronic prescription from a prescriber device for a patient inputted by the prescriber, transmitting a prescription fill request to a blockchain and pharmacy system, notifying (i.e. sending a notification) the patient or prescriber the prescription is ready for pick-up, receiving an input provided by the patient, sending a request to access a patient profile to fill the prescription at a different pharmacy, and sending a receipt in response to the prescription being filled and retrieved at the different pharmacy, a transaction recorded in the digital ledger including a cryptographic hash of a previous block, a timestamp, and transaction data related to the electronic prescription, looking-up regional rules in a rules database that comprises a plurality of rules for electronic prescribing, e.g., receiving or transmitting data over a network, Symantec, MPEP 2106.05(d)(II)(i); correlating the electronic prescription to a patient wallet associated with the patient, creating a ledger that records prescription transactions, cancelling the prescription at initial pharmacy and refilling the prescription at a different pharmacy based on an input provided by the patient, recording prescription transactions in a digital ledger, converting the electronic prescription to a standardized format based on the regional rules, e.g., performing repetitive calculations, Flook, MPEP 2106.05(d)(II)(ii); creating a ledger that records prescription transactions on the blockchain, the prescription transactions recorded in the digital ledger including a cryptographic hash of a previous block, a timestamp, and transaction data related to the electronic prescription, e.g., electronic recordkeeping, Alice Corp., MPEP 2106.05(d)(II)(iii); storing the electronic prescription and the patient wallet in an electronic prescription wallet database, storing or recording prescription transactions in a ledger/blockchain, storing computerized instructions such as in a memory, for performance of the methods recited, e.g., storing and retrieving information in memory, Versata Dev. Group, MPEP 2106.05(d)(II)(iv); receiving user input, such as at a user interface or web page interface, e.g., a web browser’s back and forward button functionality, Internet Patent Corp., MPEP 2106.05(d)(II)(ii); converting the electronic prescription to a standardized format based on the regional rules, see Livesay Par [0026] and Livesay Claim 1 which generally disclose the well-known nature of an electronic query corresponding to a request for health information of a patient being formatted according to at least one request parameter, including geographical location of the patient, a list of medications prescribed to the patient, and a time period, see Strong Par [0020] & [0026] which generally disclose considering medical and personal data including location of the patient when auto-formatting requests for medication refill, see Ishmael Par [0033] which discloses one or more encrypted codes associated with one or more events, including location information and formatting guidelines for data associated with the event being based on one or more parameters, including said location data).
Dependent claims recite additional subject matter which, as discussed above with respect to integration of the abstract idea into a practical application, amount to invoking computers as a tool to perform the abstract idea. Dependent claims recite additional subject matter which amount to limitations consistent with the additional elements in the independent claims (such as claims 2-8, 10-15 & 17-20, additional limitations which amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields, claims 3-6, 11, 14-15, & 17-20, which recite limitations relating to transmitting a prescription fill request from a patient device or central service, notifying the prescriber of tasks included in the insurance policy associated with the patient profile, notifying one or more of the patient or prescriber, monitoring, i.e. receiving, pharmacy behavior, receiving cost estimates from one or more pharmacies and/or non-affiliated entities, specifying types of data, prescriptions, and/or patient profiles being received, relaying to the central server that only a portion of the prescription was filled, receiving geographic regional rules regarding a secondary prescriber being able to alter, modify, and/or assign changes to a prescription, receiving bids or pricing estimates responsive to a patient request, obtaining pharmacy wait times in real-time, e.g., receiving or transmitting data over a network, Symantec, MPEP 2106.05(d)(II)(i); claims 2-7, 10, & 12-13, which recite limitations relating to updating one or more prescription fills/refills, correlating the prescription fill request to the patient profile associated with the patient wallet, once tasks are performed, cross-referencing prescription fill request to data corresponding to patient profile data, increasing financial coverage of the prescription, cancelling a prescription at an initial pharmacy by determining if a different pharmacy is selected or a threshold condition is met, determining if a patient received a partial fill of the prescription from a different pharmacy and flagging the different pharmacy if a second patient, different that the first patient, received a partial fill or a complete fill of the prescription from the different pharmacy, updating the patient wallet to include cost estimates associated with the prescription, advancing a refill of the prescription, in response to the patient receiving only a portion of the prescription from a different pharmacy, updating the blockchain to record the prescription refill, perform ad hoc requests responsive to a patient request to a particular prescription, e.g., performing repetitive calculations, Flook, MPEP 2106.05(d)(II)(ii); claims 3-5, 14-15, & 18-19, which recite limitations relating to maintaining one or more prescription/insurance records, pickup records, execution of a prescription, and/or patient profile preferences, updating blockchain to record prescription refill upon refill taking place, updating the patient wallet, i.e. financial records, to include cost estimates, e.g., electronic recordkeeping, Alice Corp., MPEP 2106.05(d)(II)(iii); claims 2-8, 10-15, & 17-20, which recite limitations relating to storing computerized instructions to perform the steps recited, storing prescription data, a patient profile, a digital patient wallet, and/or prescription transactions, such as in a blockchain or digital ledger, storing real-time pharmacy wait times, storing bids or pricing estimates for particular prescription(s), e.g., storing and retrieving information in memory, Versata Dev. Group, MPEP 2106.05(d)(II)(iv); claims 6 & 7, which recite limitations relating to selecting a pharmacy such as in a user interface via a button or element, e.g., a web browser’s back and forward button functionality, Internet Patent Corp., MPEP 2106.05(d)(II)(ii)). 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.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-7 & 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Doherty et al. (U.S. Patent Publication No. 2018/0240539), hereinafter “Doherty”, in view of Blackley et al. (U.S. Patent Publication No. 2019/0198144), hereinafter “Blackley”, further in view of Livesay et al. (U.S. Patent Publication No. 2019/0198181), hereinafter “Livesay”.
Claim 1 –
Regarding Claim 1, Doherty discloses a method for tracking execution of a prescription prescribed by a prescriber, the method comprising:
receiving, at a central server, an electronic prescription from a prescriber device for a patient inputted by the prescriber (See Doherty Par [0028] which discloses a central prescription handling engine receiving prescription data from a prescribing entity, such as a clinic or hospital that is associated with at least one prescriber (e.g., a doctor, a nurse practitioner, or other individual authorized by a recognized health care licensing entity to prescribe medications) (via a computing device or interface of the prescribing entity); See Doherty Par [0030]-[0033] which discloses a centralized prescription handling engine (CPHE) for filling a medical prescription listing of one or more prescribed medications and/or treatments at one or more affiliated pharmacies in response to receiving prescription data from the prescribing entity);
correlating, with a controller of the central server, the electronic prescription to a patient wallet associated with the patient and storing the electronic prescription in association with the patient wallet (While not “patient wallet” per se, but see Doherty Par [0031] which discloses the CPHE providing a central hub for integrating insurance and payment engines; See Doherty Par [0072]-[0074] which discloses receiving prescription cost information which can then be sent to a payment engine, which may be in communication with a third-party payment processing system, such as a credit card company, and/or may communicate the prescription cost information directly to a given user, wherein the user can pay via a web account of mobile device account/application, effectively constituting an electronic patient wallet),
the patient wallet being stored in an electronic prescription wallet database (While not “electronic wallet” per se, see Doherty Par [0072]-[0074] which discloses receiving prescription cost information which can then be sent to a payment engine, which may be in communication with a third-party payment processing system, such as a credit card company, and/or may communicate the prescription cost information directly to a given user, wherein the user can pay via a web account of mobile device account/application and even mentions the use of PayPal™, effectively constituting an electronic patient wallet; See Doherty Par [0031] & [0082] which discloses a central hub, interpreted as “ wallet database” under BRI, for integrating insurance engine and prescription engine, such that a third-party payment processing system, such as a credit card company, may communicate the prescription cost information directly to a given user, wherein the user can pay via a web account of mobile device account/application; See further Doherty Par [0071] which discloses a pharmacy insurance database such that the patient or user can receive an insurance policy acceptability indication, such that adjudication/payment can be processed after said indication is determined and transmitted to the patient/user);
automatically transmitting, via a communication interface of the central server, a prescription fill request to a blockchain and a pharmacy system comprising at least one pharmacy (See Doherty Par [0058]-[0059] which discloses generating a prescription refill request and transmitting via a mobile device or terminal at a GPI to submit such as refill request to the CPHE for fulfillment; See Doherty Par [0085] which discloses the plurality of prescribing entity computing devices being accessible by a prescriber, such as for purposes of submitting/filing a medical prescription; See Doherty Par [0031] & [0082] which discloses storing and tracking communications between user and pharmacy to facilitate continuing and actively-monitored care, but does not explicitly mention use of a blockchain per se; See Doherty Par [0039] which discloses the prescription data, i.e. fill request, can be sent via link to CPHE, such that the CPHE can be configured to selectively, i.e. automatically, route the prescription data to various pharmacy interfaces associated with one or more pharmacies, sch as based on automated user preferences stored by the user, characteristics of each pharmacy corresponding to each pharmacy interface, etc.);
notifying one or more of the patient or the prescriber, via the communication interface of the central server, the prescription is ready for pick-up at a pharmacy of the pharmacy system (See Doherty Par [0029] for communicating scheduling data related to the filling of the prescription being communicated to the user; See Doherty Par [0047] which discloses a notification being sent regarding the start date and time from which the prescribed medication will be available, i.e. ready for pick-up); and
cancelling the prescription at the pharmacy and sending the prescription to a different pharmacy based on an input provided by the patient via a patient device (See Doherty Par [0066] which discloses a selection of a given pharmacy based on available pharmacy information being made by the user though a mobile device or terminal, i.e. the patient selects a particular pharmacy; See Doherty Par [0079] which discloses that a user, i.e. patient or prescriber, can confirm an alternate delivery date/time for pickup of a medicine at an alternate pharmacy that has stock of that particular medicine, the confirmation effectively constituting input by the patient), wherein the patient device sends a request to access a patient profile associated with the patient wallet to fill the prescription at the different pharmacy (See Doherty Par [0073]-[0076] which discloses communicating prescription cost information to a given user associated with patient web account such that the prescription cost information can be adjusted to reflect taxes, insurance coverage, and/or shipping and handling costs where applicable; See Doherty Par [0079] which discloses that a user, i.e. patient or prescriber, can confirm an alternate delivery date/time for pickup of a medicine at an alternate pharmacy that has stock of that particular medicine, the confirmation effectively constituting input by the patient); and
sending a receipt from the pharmacy system to the central server in response to the prescription being filled and retrieved at the different pharmacy (See Doherty Par [0073]-[0076] which discloses communicating prescription cost information to a given user associated with patient web account such that the prescription cost information can be adjusted to reflect taxes, insurance coverage, and/or shipping and handling costs where applicable, and further discloses sending a payment confirmation, constituting a receipt under BRI).
As shown above, Doherty effectively discloses storing and tracking communications, i.e. transactions, between user and pharmacy to facilitate continuing and actively-monitored care, but does not explicitly mention use of a blockchain per se, and therefore does not explicitly disclose the following limitations:
automatically transmitting, via a communication interface of the central server, a prescription fill request to a blockchain;
creating a digital ledger that records prescription transactions on the blockchain automatically via the central server, wherein
each of the prescription transactions recorded in the digital ledger on the blockchain are automatically generated by the central server to include a cryptographic hash of a previous block, a time stamp, and transaction data related to the electronic prescription.
However, Blackley discloses automatically transmitting, via a communication interface of the central server, a prescription fill request to a blockchain (See Blackley Par [0024 & [0036] which discloses when a prescriber (e.g., physician) writes a prescription for a patient, the prescriber may have the prescription entered, i.e. transmitted, into an existing prescription system that may be augmented to interface with the blockchain prescription management (BCPM) system and further describes the BCPM system automatically coordinating/managing the recording of transactions in the blockchain; See Blackley Par [0026] which discloses the BCPM system sending submission information (that specifies the submission information and directly or indirectly references the prescription transaction) to the BCPM application on a device of the patient; See Blackley Par [0042] which discloses the BCPM being hosted on a cloud system that interfaces with a variety of client devices, such that the BCPM application accesses the blockchain and receives and sends information via varying means and includes interfaces to retrieve health information from various applications that of the client devices); creating a digital ledger that records prescription transactions on the blockchain automatically via the central server (See Blackley Par [0024], [0036], [0049], [0064] which discloses recording transactions that relate to prescribing, dispensing, and taking of medicine in a blockchain or in the form of a generalized distributed ledger and the BCPM system automatically coordinating/managing the recording of transactions in the blockchain in Blackley Par [0036], in particular; See Blackley Par [0051] which discloses said system or computing device can include a central processing unit and/or server implementation) wherein each of the prescription transactions recorded in the digital ledger on the blockchain are automatically generated by the central server (See Blackley Par [0024], [0036], [0049], [0064] which discloses recording transactions that relate to prescribing, dispensing, and taking of medicine in a blockchain or in the form of a generalized distributed ledger and the BCPM system automatically coordinating/managing the recording of transactions in the blockchain in Blackley Par [0036], in particular) to include a cryptographic hash of a previous block, a time stamp, and transaction data related to the electronic prescription (See Blackley Par [0001] which discloses once a block is full, the block is “capped” with a block header including a hash digest of all transaction identifiers within the block, and the block header is recorded as the first transaction in the next block in the chain, i.e. each subsequent hash contains a previously capped block; See Blackley Par [0003] which discloses the use of a cryptographic one-way hash of information that uniquely identifies the asset; See Blackley Par [0005] which further discloses possible use of a smart contract system that records the contract as a transaction in the blockchain using an identity token that is a hash of the computer code; See Blackley Par [0036] which discloses the BCPM system records in the blockchain a prescription transaction that specifies details of a prescription such as the medicine, dosage patient, and so on, i.e. transaction data related to the electronic prescription; See Blackley Par [0044] which discloses that when a transaction is recorded, details regarding the transaction, such as the date, i.e. timestamp, of the transaction is also included/recorded). The disclosure of Blackley is directly applicable to the disclosure of Doherty because the disclosures share limitations and capabilities, such as being directed towards management and fulfillment of prescription requests.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Doherty which already discloses storing and tracking communications, i.e. transactions, between user and pharmacy to facilitate continuing and actively-monitored care, to further specifically include the use and tracking of transmitted information via a digital ledger and/or blockchain, as disclosed by Blackley, because by using a blockchain or distributed ledger, the system can effectively record in the blockchain a submission transaction for each pharmacy that has provided a submission for dispensing the prescription, and effectively track the fulfillment process of the prescription fulfillment, i.e. the purpose of transferring the ownership is to ensure that the submission token has not been spent by a pharmacy and is available to be transferred to the BCPM service if that pharmacy is selected (See Blackley Par [0036]).
While Doherty and Blackley generally disclose the automatic transmission of one or more prescription fill requests to a blockchain and a pharmacy system, Doherty and Blackley are generally silent on accessing a rules database for purposes of accessing a standardized format according to geographical rules as given by the following limitation:
via the central server, looking-up regional prescription rules in a rules database that comprises a plurality of rules for electronic prescribing, and converting the electronic prescription to a standardized format based on the regional prescription rules.
However, Livesay discloses via the central server, looking-up regional prescription rules in a rules database that comprises a plurality of rules for electronic prescribing, and converting the electronic prescription to a standardized format based on the regional prescription rules (See Livesay Par [0018] which discloses storing data relating to a patient’s prescribed medication in a health information system; See Livesay Par [0026] which discloses a query corresponding to a list of medications that have been prescribed for a particular patient and further contains one or more request parameters that manages the formatting of said query; See Livesay Par [0030] which discloses a communication protocol list being stored in a database and a translation module allowing for retrieval of the list from the database, such that communication protocols, i.e. rules, are maintained that are compatible with each of the endpoint computing devices; See Livesay Claim 1 which discloses an electronic query corresponding to a request for health information of a patient being formatted according to at least one request parameter, including geographical location of the patient, a list of medications prescribed to the patient, and a time period, such that it is understood by Examiner that the electronic prescription format is thereby based on the geographical location parameter, i.e. that manages the formatting of said query as per Livesay Par [0026]). The disclosure of Livesay is directly applicable to the disclosure of combined disclosure of Doherty and Blackley because the disclosures share limitations and capabilities, such as being directed towards transmission and/or maintaining of one or more prescription fill requests for a patient.
It would have been obvious to one of ordinary skill in the art before the effective filing date do the claimed invention to modify the combined disclosure of Doherty and Blackley, which already discloses the automatic transmission of one or more prescription fill requests to a blockchain and a pharmacy system to further include looking-up regional rules in a rules database that comprises a plurality of rules for electronic prescribing, and converting the electronic prescription transmission to a standardized format based on the regional rules, as disclosed by Livesay, because this allows for communications that are compatible with each endpoint computing device in varying geographic locations (See Livesay Par [0030]).
Claim 2 –
Regarding Claim 2, Doherty, Blackley, and Livesay disclose the method of Claim 1 in its entirety. Doherty & Blackley further disclose a method, further comprising:
updating, with the controller and based on computer-readable instructions stored on memory thereof, a number of prescription fills and refills associated with the prescription and correlated to the patient wallet in response to the prescription being filled and retrieved, wherein data relating to the electronic prescription is distributed but not copied (See Doherty Par [0055]-[0056] which discloses prescription information database including tracking confirmation information such as pharmacy location, staff identifier, retrieval timestamp, medication quantity, and verification method of given user; See Doherty Par [0058]-[0059] which describes receiving and storing one or more fill requests associated with one or more refill information and prescription data; See Doherty Par [0037] which discloses patient web accounts recording and being able to view medical information such as current and past medications, such that the web accounts are also correlated with payment engine and payment methods such as described in Doherty Par [0072]-[0074]; In view of Applicant’s Specification Par [0098] which discloses that a blockchain may be used to allow the data relating to prescriptions to be distributed but not copied, and therefore, see Blackley Par [0036] which discloses the BCPM system records in the blockchain a submission transaction for each pharmacy that has provided a submission for dispensing the prescription, but not the prescription information itself and therefore substantially relates to the descripted aspects of “not copying” said prescription data), and
in response to the indication that the prescription refill has been filled, the central system updates the blockchain to record the prescription refill (See Blackley Par [0036]; See Blackley Par [0047] which discloses the pharmacy system may allow a pharmacy to record blockchain transactions relating to refills, renewals, changes, and so on; See Blackley Par [0027] & [0036] which discloses when a prescription that includes a dose is dispensed to the patient, i.e. refilled under BRI, the dispense transaction is recorded in the blockchain by the BCPM system, i.e. the blockchain is updated; See Blackley Par [0051] which discloses said system or computing device can include a central processing unit and/or server implementation such as for managing BCPM system).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined disclosure of Doherty, Blackley, and Livesay, which already discloses the recording of prescription transactions, to further specifically include updating the blockchain to record the prescription refill transaction, in particular, upon the prescription refill being refilled, as disclosed by Blackley, because by recording each prescription refill transaction, the system can effectively record/manage each associated transaction of the prescription fulfillment process, e.g. refills, for both the patient and pharmacy (See Blackley Par [0036]).
Claim 3 –
Regarding Claim 3, Doherty, Blackley, and Livesay disclose the method of Claim 1 in its entirety. Doherty further discloses a method, further comprising:
generating, with the controller, the prescription fill request, sent from a patient device or a central service, the prescription fill request correlated to the patient profile associated with the patient wallet and stored in the electronic prescription wallet database (See Doherty Par [0058]-[0059] which describes receiving and storing one or more fill requests associated with one or more refill information and prescription data; See Doherty Par [0037] which discloses patient web accounts recording and being able to view medical information such as current and past medications, such that the web accounts are also correlated with payment engine and payment methods such as described in Doherty Par [0072]-[0074]), the correlation including matching patient data transmitted with the electronic prescription to data stored in a patient database of the electronic prescription wallet database (See Doherty Par [0055]-[0056] which discloses prescription information database including tracking confirmation information such as pharmacy location, staff identifier, retrieval timestamp, medication quantity, and verification method of given user; See Doherty Par [0058]-[0059] which describes receiving and storing one or more fill requests associated with one or more refill information and prescription data; See Doherty Par [0037] which discloses patient web accounts recording and being able to view medical information such as current and past medications, such that the web accounts are also correlated with payment engine and payment methods such as described in Doherty Par [0072]-[0074]).
Claim 4 –
Regarding Claim 4, Doherty, Blackley, and Livesay disclose the method of Claim 1 in its entirety. Doherty further discloses a method, further comprising:
cross-referencing, with the controller, the prescription fill request to data corresponding to the patient profile, the data comprising an insurance policy associated with the patient profile (See Doherty Par [0082] which discloses cross-checking previously filled prescriptions and information associated with said prescribing such as patient information, the integrated insurance engine and/or payment engine which as described in Par [0067]-[0069] effectively identifies and references insurance coverage details, thereby effectively constituting cross-referencing insurance policy associated with patient profile).
Claim 5 –
Regarding Claim 5, Doherty, Blackley, and Livesay disclose the method of Claim 4 in its entirety. Doherty does not effectively disclose, but Blackley further discloses a method, further comprising:
notifying the prescriber, via the communication interface of the central server, tasks included in the insurance policy associated with the patient profile that once performed, increase financial coverage of the prescription (See Blackley Par [0026] which discloses notifying a prescriber that alternative medicines or pharmacies are available such that the prescriber and patient can discuss options in real time to identify an appropriate medicine, dosage, pharmacy, and so on that will increase the chances of having a prescription dispensed and reduce the chances of an abandonment, i.e. by decreasing price and/or increasing financial coverage of the prescription; See Blackley Par [0031] which discloses an incentive token for incentivizing patients to take certain actions such that when making an in-store purchase, the BCPM application may display a Quick Response (“QR”) code that identifies the incentive token, such that a POS system may scan the QR code, adjust a purchase price based on the incentive, and coordinate the recording of an incentive token transaction that inputs the incentive token that is owned by the patient and outputs an incentive token that is owned by the pharmacy, effectively increasing financial coverage; [0033] which discloses a pharmacy specifying rules to be used for generating submissions, such that one rule for a pharmacy may be that when dispensing a prescription for 30 doses of a certain medicine for a certain sponsor, the copayment amount should be $10 and the incentive should be a 25% off coupon, i.e. that opting for a certain medicine increases financial coverage of the prescription via a 25% off coupon).
It would have been obvious to one of ordinary skill in the effective filing date of the claimed invention to modify the combined disclosure of Doherty, Blackley, and Livesay, to further include notifying the prescriber, via the communication interface of the central server, tasks included in the insurance policy associated with the patient profile that once performed, increase financial coverage of the prescription, as disclosed by Blackley because this effectively increases the chances of having a prescription dispensed and reduce the chances of an abandonment, i.e. by decreasing price and/or increasing financial coverage of the prescription (See Blackley Par [0026]).
Claim 6 –
Regarding Claim 6, Doherty, Blackley, and Livesay disclose the method of Claim 1 in its entirety. Doherty further discloses a method, further comprising:
notifying one or more of the patient or the prescriber and prior to cancelling the prescription at the pharmacy, determining if the different pharmacy is selected, and if the different pharmacy is not selected, reminding the patient the prescription is ready for pick-up within a threshold duration (See MPEP 2111.04(II) for contingent limitations in a method claim, such that the BRI of contingent limitations in a method claim require only those steps that must be performed and does not include steps that are not required to be performed because the conditions precedent are not met, therefore this claim is effectively met if a reference discloses notifying one or more of the patient or the prescriber and prior to cancelling the prescription at the pharmacy and determining if a different pharmacy is selected, therefore see Doherty Par [0066] which discloses a selection of a given pharmacy based on available pharmacy information being made by the user though a mobile device or terminal, i.e. the patient selects a particular pharmacy; See Doherty Par [0079] which discloses that a user, i.e. patient or prescriber, can confirm, i.e. after notification by the system, an alternate delivery date/time for pickup of a medicine at an alternate pharmacy that has stock of that particular medicine, the confirmation effectively constituting input by the patient of choosing a different pharmacy).
Claim 7 –
Regarding Claim 7, Doherty, Blackley, and Livesay disclose the method of Claim 6 in its entirety. Doherty further discloses a method, further comprising:
cancelling the prescription following the threshold duration and instructing the patient to select a new pharmacy to fill the prescription (Because this claim is dependent from claim 6 and the limitation recited for claim 7 is a result of the contingent limitation in claim 6, this claim is not required to be performed because the conditions precedent is not required to be met under BRI, however, it should be noted that Doherty Par [0079] effectively discloses that a user, i.e. patient or prescriber, can confirm, i.e. after notification by the system, an alternate delivery date/time for pickup of a medicine at an alternate pharmacy that has stock of that particular medicine, the confirmation effectively constituting input by the patient of choosing a different pharmacy, and thereby cancelling said prescription at the initial pharmacy).
Claim 16 –
Regarding Claim 16, Doherty discloses a method comprising:
receiving, at a central server, an electronic prescription from a prescriber device for a patient inputted by a prescriber, wherein a controller of the central server correlates authenticating data to a prescriber profile stored in an electronic prescription wallet database (See Doherty Par [0028] which discloses a central prescription handling engine receiving prescription data from a prescribing entity, such as a clinic or hospital that is associated with at least one prescriber (e.g., a doctor, a nurse practitioner, or other individual authorized by a recognized health care licensing entity to prescribe medications) (via a computing device or interface of the prescribing entity); See Doherty Par [0030]-[0033] which discloses a centralized prescription handling engine (CPHE) for filling a medical prescription listing of one or more prescribed medications and/or treatments at one or more affiliated pharmacies in response to receiving prescription data from the prescribing entity);
correlating, with the controller of the central server, the electronic prescription to a patient wallet associated with the patient and storing the electronic prescription in association with the patient wallet (While not “patient wallet” per se, but see Doherty Par [0031] which discloses the CPHE providing a central hub for integrating insurance and payment engines; See Doherty Par [0072]-[0074] which discloses receiving prescription cost information which can then be sent to a payment engine, which may be in communication with a third-party payment processing system, such as a credit card company, and/or may communicate the prescription cost information directly to a given user, wherein the user can pay via a web account of mobile device account/application, effectively constituting an electronic patient wallet), the patient wallet being stored in the electronic prescription wallet database (While not “electronic wallet” per se, see Doherty Par [0072]-[0074] which discloses receiving prescription cost information which can then be sent to a payment engine, which may be in communication with a third-party payment processing system, such as a credit card company, and/or may communicate the prescription cost information directly to a given user, wherein the user can pay via a web account of mobile device account/application and even mentions the use of PayPal™, effectively constituting an electronic patient wallet; See Doherty Par [0031] & [0082] which discloses a central hub, interpreted as “ wallet database” under BRI, for integrating insurance engine and prescription engine, such that a third-party payment processing system, such as a credit card company, may communicate the prescription cost information directly to a given user, wherein the user can pay via a web account of mobile device account/application; See further Doherty Par [0071] which discloses a pharmacy insurance database such that the patient or user can receive an insurance policy acceptability indication, such that adjudication/payment can be processed after said indication is determined and transmitted to the patient/user);
distributing the electronic prescription across multiple systems without copying of the prescription data via the central server (See Doherty Par [0058]-[0059] which discloses generating a prescription refill request and transmitting via a mobile device or terminal at a GPI to submit such as refill request to the CPHE for fulfillment; See Doherty Par [0085] which discloses the plurality of prescribing entity computing devices being accessible by a prescriber, such as for purposes of submitting/filing a medical prescription; See Doherty Par [0039] which discloses the prescription data, i.e. fill request, can be sent via link to CPHE, such that the CPHE can be configured to selectively, i.e. automatically, route the prescription data to various pharmacy interfaces associated with one or more pharmacies, such as based on automated user preferences stored by the user, characteristics of each pharmacy corresponding to each pharmacy interface, etc.), wherein the electronic prescription comprises:
automatically transmitting, via a communication interface of the central server, a prescription fill request to a plurality of pharmacies and a blockchain (See Doherty Par [0058]-[0059] which discloses generating a prescription refill request and transmitting via a mobile device or terminal at a GPI to submit such as refill request to the CPHE for fulfillment; See Doherty Par [0085] which discloses the plurality of prescribing entity computing devices being accessible by a prescriber, such as for purposes of submitting/filing a medical prescription; See Doherty Par [0031] & [0082] which discloses storing and tracking communications between user and pharmacy to facilitate continuing and actively-monitored care, but does not explicitly mention use of a blockchain per se; See Doherty Par [0039] which discloses the prescription data, i.e. fill request, can be sent via link to CPHE, such that the CPHE can be configured to selectively, i.e. automatically, route the prescription data to various pharmacy interfaces associated with one or more pharmacies, such as based on automated user preferences stored by the user, characteristics of each pharmacy corresponding to each pharmacy interface, etc.);
adjusting a display of a patient profile associated with the patient wallet (See Doherty Par [0039] which discloses selective routing, i.e. selection of one or more pharmacies being based on user choice such that insurance coverage, i.e. cost estimates, can be a preference for said selection by the user, such that the display of a patient profile, i.e. web account of mobile device account/application and candidate pharmacies is adjusted according to user preference and/or selection);
transmitting, via the communication interface of the central server, a prescription fill request corresponding to the prescription to at least one pharmacy of the plurality of pharmacies (See Doherty Par [0058]-[0059] which discloses generating a prescription refill request and transmitting via a mobile device or terminal at a GPI to submit such as refill request to the CPHE for fulfillment; See Doherty Par [0085] which discloses the plurality of prescribing entity computing devices being accessible by a prescriber, such as for purposes of submitting/filing a medical prescription; See Doherty Par [0031] & [0082] which discloses storing and tracking communications between user and pharmacy to facilitate continuing and actively-monitored care, but does not explicitly mention use of a blockchain per se; See Doherty Par [0039] which discloses the prescription data, i.e. fill request, can be sent via link to CPHE, such that the CPHE can be configured to selectively, i.e. automatically, route the prescription data to various pharmacy interfaces associated with one or more pharmacies, sch as based on automated user preferences stored by the user, characteristics of each pharmacy corresponding to each pharmacy interface, etc.); and
receiving feedback from the at least one pharmacy regarding a status of the prescription (See Doherty Par [0029] for communicating scheduling data related to the filling of the prescription being communicated to the user; See Doherty Par [0047] which discloses a notification being sent regarding the start date and time from which the prescribed medication will be available, i.e. ready for pick-up).
As shown above, Doherty effectively discloses storing and tracking communications, i.e. transactions, between user and pharmacy to facilitate continuing and actively-monitored care, and further discloses transmission of prescription cost information to CPHE for a selected/given pharmacy, but does not explicitly mention use of a blockchain per se and/or receiving bids/cost estimates from a plurality of pharmacies, and therefore does not explicitly disclose the following limitations:
based on geographic information included in the electronic prescription, via the central server, looking-up regional prescription rules in a rules database that comprises a plurality of rules for electronic prescribing, and converting the electronic prescription to a standardized format based on the regional prescription rules;
notifying the prescriber, via a communication interface of the central server, tasks demanded by an insurance policy associated with the patient wallet to meet financial coverage of the electronic prescription;
automatically transmitting, via the communication interface of the central server, a prescription fill request to a blockchain;
creating a digital ledger that records prescription transactions on a blockchain, wherein
each of the prescription transactions recorded in the digital ledger on the blockchain are automatically generated by the central server to include a cryptographic hash of a previous block, a timestamp, and transaction data related to the electronic prescription;
receiving a plurality of bids or cost estimates from the plurality of pharmacies; and
automatically sending a request for a bid or a cost estimate to fill the prescription to the plurality of pharmacies.
However, Blackley discloses notifying the prescriber, via a communication interface of the central server, tasks demanded by an insurance policy associated with the patient wallet to meet financial coverage of the electronic prescription (See Blackley Par [0026] which discloses notifying a prescriber that alternative medicines or pharmacies are available such that the prescriber and patient can discuss options in real time to identify an appropriate medicine, dosage, pharmacy, and so on that will increase the chances of having a prescription dispensed and reduce the chances of an abandonment, i.e. by decreasing price and/or increasing financial coverage of the prescription; See Blackley Par [0031] which discloses an incentive token for incentivizing patients to take certain actions such that when making an in-store purchase, the BCPM application may display a Quick Response (“QR”) code that identifies the incentive token, such that a POS system may scan the QR code, adjust a purchase price based on the incentive, and coordinate the recording of an incentive token transaction that inputs the incentive token that is owned by the patient and outputs an incentive token that is owned by the pharmacy, effectively increasing financial coverage; [0033] which discloses a pharmacy specifying rules to be used for generating submissions, such that one rule for a pharmacy may be that when dispensing a prescription for 30 doses of a certain medicine for a certain sponsor, the copayment amount should be $10 and the incentive should be a 25% off coupon, i.e. that opting for a certain medicine increases financial coverage of the prescription via a 25% off coupon); automatically transmitting, via a communication interface of the central server, a prescription fill request to a blockchain (See Blackley Par [0024 & [0036] which discloses when a prescriber (e.g., physician) writes a prescription for a patient, the prescriber may have the prescription entered, i.e. transmitted, into an existing prescription system that may be augmented to interface with the blockchain prescription management (BCPM) system and further describes the BCPM system automatically coordinating/managing the recording of transactions in the blockchain; See Blackley Par [0026] which discloses the BCPM system sending submission information (that specifies the submission information and directly or indirectly references the prescription transaction) to the BCPM application on a device of the patient; See Blackley Par [0042] which discloses the BCPM being hosted on a cloud system that interfaces with a variety of client devices, such that the BCPM application accesses the blockchain and receives and sends information via varying means and includes interfaces to retrieve health information from various applications that of the client devices); creating a digital ledger that records prescription transactions on a blockchain (See Blackley Par [0024], [0036], [0049], [0064] which discloses recording transactions that relate to prescribing, dispensing, and taking of medicine in a blockchain or in the form of a generalized distributed ledger and the BCPM system automatically coordinating/managing the recording of transactions in the blockchain in Blackley Par [0036], in particular; See Blackley Par [0051] which discloses said system or computing device can include a central processing unit and/or server implementation), wherein each of the prescription transactions recorded in the digital ledger on the blockchain are automatically generated by the central server (See Blackley Par [0024], [0036], [0049], [0064] which discloses recording transactions that relate to prescribing, dispensing, and taking of medicine in a blockchain or in the form of a generalized distributed ledger and the BCPM system automatically coordinating/managing the recording of transactions in the blockchain in Blackley Par [0036], in particular) to include a cryptographic hash of a previous block, a timestamp, and transaction data related to the electronic prescription (See Blackley Par [0001] which discloses once a block is full, the block is “capped” with a block header including a hash digest of all transaction identifiers within the block, and the block header is recorded as the first transaction in the next block in the chain, i.e. each subsequent hash contains a previously capped block; See Blackley Par [0003] which discloses the use of a cryptographic one-way hash of information that uniquely identifies the asset; See Blackley Par [0005] which further discloses possible use of a smart contract system that records the contract as a transaction in the blockchain using an identity token that is a hash of the computer code; See Blackley Par [0036] which discloses the BCPM system records in the blockchain a prescription transaction that specifies details of a prescription such as the medicine, dosage patient, and so on, i.e. transaction data related to the electronic prescription; See Blackley Par [0044] which discloses that when a transaction is recorded, details regarding the transaction, such as the date, i.e. timestamp, of the transaction is also included/recorded); receiving a plurality of bids or cost estimates from the plurality of pharmacies (See Blackley Par [0026] which discloses the system identifying pharmacies that are available to dispense the prescription to the patient based on terms defined by the patient, such as being approved by a sponsor of the insurance for the patient, and further discloses the system recording in the blockchain a submission transaction for each pharmacy that specifies the submission information and directly or indirectly references the prescription transaction, and thereby prices associated with said submission; See Blackley Par [0050] which discloses pricing service may allow sponsors and pharmacies to interact to establish a price at which each pharmacy is to provide a medicine to patients of the sponsors, such that the pricing service may allow a sponsor to elicit pricing proposals from the pharmacies and to send counterproposals, and the proposals and counterproposals may specify prices, volume discounts, incentives, and so on, and once an agreement is reached, the pricing service may support the generating of rules (to be approved by the parties) that implement the agreement, such that the prices are understood to be a continuous cost estimate/pricing based on prices, volume discounts, incentives, and so on); and automatically sending a request for a bid or a cost estimate to fill the prescription to the plurality of pharmacies (See Blackley Par [0026] which discloses the system identifying pharmacies that are available to dispense the prescription to the patient based on terms defined by the patient, such as being approved by a sponsor of the insurance for the patient, and further discloses the system recording in the blockchain a submission transaction for each pharmacy that specifies the submission information and directly or indirectly references the prescription transaction, and thereby prices associated with said submission).
It would have been obvious to one of ordinary skill in the effective filing date of the claimed invention to modify the combined disclosure of Doherty and Blackley, to further include notifying the prescriber, via the communication interface of the central server, tasks included in the insurance policy associated with the patient profile that once performed, increase financial coverage of the prescription, as disclosed by Blackley because this effectively increases the chances of having a prescription dispensed and reduce the chances of an abandonment, i.e. by decreasing price and/or increasing financial coverage of the prescription (See Blackley Par [0026]). It would have been also obvious to include the use and tracking of transmitted information, such as prescription transactions and associated information with prescription transactions, via a digital ledger and/or blockchain, as disclosed by Blackley, because by using a blockchain or distributed ledger, the system can effectively record in the blockchain a submission transaction for each pharmacy that has provided a submission for dispensing the prescription, and effectively track the fulfillment process of the prescription fulfillment, i.e. the purpose of transferring the ownership is to ensure that the submission token has not been spent by a pharmacy and is available to be transferred to the BCPM service if that pharmacy is selected (See Blackley Par [0036]). Lastly, it would have been also obvious to one of ordinary skill in the effective filing date of the claimed invention to modify the combined disclosure of Doherty and Blackley, to further include continuous updates to pricing estimates provided by the plurality of pharmacies, as disclosed by Blackley, because this allows a sponsor to elicit pricing proposals from the pharmacies and to send counterproposals, and the proposals and counterproposals may specify prices, volume discounts, incentives, and so on, and once an agreement is reached, the pricing service may support the generating of rules (to be approved by the parties) that implement the agreement, and thereby implement smart contracts based on said continuous pricings/agreements (See Blackley Par [0050]).
However, Livesay discloses based on geographic information included in the electronic prescription, via the central server, looking-up regional prescription rules in a rules database that comprises a plurality of rules for electronic prescribing, and converting the electronic prescription to a standardized format based on the regional prescription rules (See Livesay Par [0018] which discloses storing data relating to a patient’s prescribed medication in a health information system; See Livesay Par [0026] which discloses a query corresponding to a list of medications that have been prescribed for a particular patient and further contains one or more request parameters that manages the formatting of said query; See Livesay Par [0030] which discloses a communication protocol list being stored in a database and a translation module allowing for retrieval of the list from the database, such that communication protocols, i.e. rules, are maintained that are compatible with each of the endpoint computing devices; See Livesay Claim 1 which discloses an electronic query corresponding to a request for health information of a patient being formatted according to at least one request parameter, including geographical location of the patient, a list of medications prescribed to the patient, and a time period, such that it is understood by Examiner that the electronic prescription format is thereby based on the geographical location parameter, i.e. that manages the formatting of said query as per Livesay Par [0026]). The disclosure of Livesay is directly applicable to the disclosure of combined disclosure of Doherty and Blackley because the disclosures share limitations and capabilities, such as being directed towards transmission and/or maintaining of one or more prescription fill requests for a patient.
It would have been obvious to one of ordinary skill in the art before the effective filing date do the claimed invention to modify the combined disclosure of Doherty and Blackley, which already discloses the automatic transmission of one or more prescription fill requests to a blockchain and a pharmacy system to further include looking-up regional rules in a rules database that comprises a plurality of rules for electronic prescribing, and converting the electronic prescription transmission to a standardized format based on the regional rules, as disclosed by Livesay, because this allows for communications that are compatible with each endpoint computing device in varying geographic locations (See Livesay Par [0030]).
Claim 17 –
Regarding Claim 17, Doherty, Blackley, and Livesay disclose the method of Claim 16 in its entirety. Doherty does not disclose, but Blackley further discloses a method, further comprising:
receiving a plurality of bids from a centralized database in communication with the central server, the plurality of bids based on continuous updates to pricing estimates provided by the plurality of pharmacies (See Blackley Par [0026] which discloses the system identifying pharmacies that are available to dispense the prescription to the patient based on terms defined by the patient, such as being approved by a sponsor of the insurance for the patient, and further discloses the system recording in the blockchain a submission transaction for each pharmacy that specifies the submission information and directly or indirectly references the prescription transaction, and thereby prices associated with said submission; See Blackley Par [0050] which discloses pricing service may allow sponsors and pharmacies to interact to establish a price at which each pharmacy is to provide a medicine to patients of the sponsors, such that the pricing service may allow a sponsor to elicit pricing proposals from the pharmacies and to send counterproposals, and the proposals and counterproposals may specify prices, volume discounts, incentives, and so on, and once an agreement is reached, the pricing service may support the generating of rules (to be approved by the parties) that implement the agreement, such that the prices are understood to be a continuous cost estimate/pricing based on prices, volume discounts, incentives, and so on).
It would have been obvious to one of ordinary skill in the effective filing date of the claimed invention to modify the combined disclosure of Doherty and Blackley, to further include continuous updates to pricing estimates provided by the plurality of pharmacies, as disclosed by Blackley, because this allows a sponsor to elicit pricing proposals from the pharmacies and to send counterproposals, and the proposals and counterproposals may specify prices, volume discounts, incentives, and so on, and once an agreement is reached, the pricing service may support the generating of rules (to be approved by the parties) that implement the agreement, and thereby implement smart contracts based on said continuous pricings/agreements (See Blackley Par [0050]).
Claim 18 –
Regarding Claim 18, Doherty and Blackley disclose the method of Claim 16 in its entirety. Doherty and Blackley further disclose a method, wherein:
the patient profile is one of a plurality of patient profiles associated with the patient wallet via the insurance policy (“patient profile” under BRI could simply include any information or details regarding a patient, therefore See Doherty Par [0036] which discloses web accounts, terminals, and terminal-to-CPHE links can be similar for the other users, such that user can have a web account accessible through terminal in communication with CPHE via link, and additional users can have a web account accessible through terminal in communication with CPHE 105 via same or similar links; See Doherty Par [0037] which discloses the patient being able to access insurance coverage information, and is understood by Examiner to further include covered entities and insurance coverage information associated therewith, constituting accessing other patient profiles), and wherein
the cost estimates are from data sources that are not directly affiliated with the pharmacy (See Blackley Par [0050] which discloses pricing service may allow sponsors and pharmacies to interact to establish a price at which each pharmacy is to provide a medicine to patients of the sponsors, such that the pricing service may allow a sponsor to elicit pricing proposals from the pharmacies and to send counterproposals, and the proposals and counterproposals may specify prices, volume discounts, incentives, and so on, and once an agreement is reached, the pricing service may support the generating of rules (to be approved by the parties) that implement the agreement, such that the prices are understood to be a continuous cost estimate/pricing based on prices, volume discounts, incentives, and so on, such that the sponsors are “not directly affiliated” because they are a third party that does not represent the pharmacy or the user, and are instead negotiating against the pharmacy to elicit pricing proposals, and as such, the sponsors providing the cost estimates and/or negotiations for cost estimates are indeed from data sources that are not affiliated with the pharmacy, as this claim limitation sets forth; however, it is understood by Examiner that if Applicant intended for this limitation to be interpreted as the cost estimates not being directly affiliated with the pharmacy, i.e. pharmacy having no influence or say in the cost estimates provided to the user, then the limitation would most likely need different verbiage to specify that interpretation, but would most likely overcome Blackley if appropriate verbiage was provided, because Blackley’s negotiation by a sponsor does involve the pharmacy).
It would have been obvious to one of ordinary skill in the effective filing date of the claimed invention to modify the combined disclosure of Doherty, Blackley, and Livesay, to further include cost estimates are from data sources that are not directly affiliated with the pharmacy, as disclosed by Blackley, because this allows a sponsor to elicit pricing proposals from the pharmacies and to send counterproposals, and the proposals and counterproposals may specify prices, volume discounts, incentives, and so on, and once an agreement is reached, the pricing service may support the generating of rules (to be approved by the parties) that implement the agreement, and thereby implement smart contracts based on said continuous pricings/agreements (See Blackley Par [0050]).
Claim 19 –
Regarding Claim 19, Doherty, Blackley, and Livesay disclose the method of Claim 18 in its entirety. Doherty and Blackley further disclose a method, wherein:
at least one of the plurality of patient profiles is associated with a primary user authorized to execute changes to settings of the plurality of patient profiles (“patient profile” under BRI could simply include any information or details regarding a patient, therefore See Doherty Par [0036] which discloses web accounts, terminals, and terminal-to-CPHE links can be similar for the other users, such that user can have a web account accessible through terminal in communication with CPHE via link, and additional users can have a web account accessible through terminal in communication with CPHE 105 via same or similar links; See Doherty Par [0037] which discloses the patient being able to access insurance coverage information, and is understood by Examiner to further include covered entities and insurance coverage information associated therewith, constituting accessing other patient profiles, and the patient can also record, i.e. change/select and view personal preferences, such as insurance coverage, preferred pharmacy locations, preferred pick-up times, and would therefore constitute a primary user authorized to change settings/preferences), and wherein
the central server automatically performs ad hoc requests to pharmacies to receive the bids or the pricing estimates responsive to a patient request for a particular prescription (See Blackley Par [0050] which discloses pricing service may allow sponsors and pharmacies to interact to establish a price at which each pharmacy is to provide a medicine to patients of the sponsors, such that the pricing service may allow a sponsor to elicit pricing proposals from the pharmacies and to send counterproposals, and the proposals and counterproposals may specify prices, volume discounts, incentives, and so on, and once an agreement is reached, the pricing service may support the generating of rules (to be approved by the parties) that implement the agreement, such that the prices are understood to be a continuous cost estimate/pricing based on prices, volume discounts, incentives, and so on, and upon said agreement being reached, the system automatically applies the agreed pricing rules to the smart contract, i.e. the prescription transaction and details thereof, to present, i.e. select, the negotiated prices of each pharmacy to the user as seen in Blackley Par [0054])
It would have been obvious to one of ordinary skill in the effective filing date of the claimed invention to modify the combined disclosure of Doherty, Blackley, and Livesay, to further include the system performing ad hoc requests to pharmacies to receive the bids or the pricing estimates responsive to a patient request for a particular prescription, as disclosed by Blackley, because this allows the system to create favorability criterion/criteria for selection of a particular pharmacy by the user or the system based on said ad hoc requests, i.e. the system may select one or more pharmacies that are deemed to be most favorable to the patient based on one or more criterion, including the negotiated prices (See Blackley Par [0050] & [0054]).
Claim 20 –
Regarding Claim 20, Doherty, Blackley, and Livesay disclose the method of Claim 16 in its entirety. Doherty further discloses a method, wherein:
the patient wallet comprises adjustable preferences, the preferences comprising ranking priorities for filling prescriptions prescribed to the patient, wherein the priorities comprise price, proximity, availability, and wait times (While not “patient wallet” per se, see Doherty Par [0072]-[0074] which discloses receiving prescription cost information which can then be sent to a payment engine, which may be in communication with a third-party payment processing system, such as a credit card company, and/or may communicate the prescription cost information directly to a given user, wherein the user can pay via a web account of mobile device account/application and even mentions the use of PayPal™, effectively constituting an electronic patient wallet; See Doherty Par [0031] & [0082] which discloses a central hub, interpreted as “ wallet database” under BRI, for integrating insurance engine and prescription engine, such that a third-party payment processing system, such as a credit card company, may communicate the prescription cost information directly to a given user, wherein the user can pay via a web account of mobile device account/application; See further Doherty Par [0071] which discloses a pharmacy insurance database such that the patient or user can receive an insurance policy acceptability indication, such that adjudication/payment can be processed after said indication is determined and transmitted to the patient/user; See Doherty Par [0028] & [0063] which discloses list of pharmacies being based/generated on preferences such as physical proximity to the user, the ability of the candidate pharmacies to refill the prescription and inventory criteria, i.e. availability; See Doherty Par [0042] which also discloses selective routing based on pharmacy location/chain, medication availability, prescription queue length, i.e. wait time, and insurance coverage, constituting price), and wherein
pharmacy wait times are obtained based on real-time monitoring of the pharmacies (See Doherty Par [0045] which discloses a prescription filling capacity of a given pharmacy may be based on staffing levels, number of prescriptions that have to be filled, and the complexity of prescriptions being filled, and the system automatically generating optimal appointment times, i.e. pharmacy pick-up/wait times, based on staffing, which may increase and/or decrease in response to a change in demand, i.e. real-time, for the given pharmacy's services, or other services; additionally, see Doherty Par [0051] which discloses an indication of position change in a virtual queue for a patient regarding pharmacy wait position/time may be able to receive queue position notifications, to alert him/her of the change in his/her position in the virtual queue and/or a change in the estimated queue time, thereby constituting real-time monitoring of the wait times associated with the pharmacy).
Claims 8-15 are rejected under 35 U.S.C. 103 as being unpatentable over Doherty, in view of Blackley, in view of Livesay, further in view of Chen et al. (U.S. Patent Publication No. 2013/0191139), hereinafter “Chen”.
Claim 8 –
Regarding Claim 8, Doherty, Blackley, and Livesay disclose the method of Claim 1 in its entirety. Doherty further discloses a method, further comprising:
the prescription is available to pick-up from only one pharmacy (See Doherty Par [0089] which discloses selectively routing prescription data to a particular (singular) pharmacy, i.e. pharmacy interface, based on user choice, or could be automated using preferences stored by user (pharmacy location/chain, day/time for pick-up/delivery, pharmacy operating hours, insurance coverage, language spoken, medication availability, prescription queue length, pharmacy staff availability, etc.), and wherein
the regional prescription rules include electronic prescription regulations for both a geographic region of the pharmacy and a facility type of the pharmacy (See Livesay Par [0018] which discloses storing data relating to a patient’s prescribed medication in a health information system; See Livesay Par [0026] which discloses a query corresponding to a list of medications that have been prescribed for a particular patient and further contains one or more request parameters that manages the formatting of said query; See Livesay Par [0030] which discloses a communication protocol list being stored in a database and a translation module allowing for retrieval of the list from the database, such that communication protocols, i.e. rules, are maintained that are compatible with each of the endpoint computing devices; See Livesay Claim 1 which discloses an electronic query corresponding to a request for health information of a patient being formatted according to at least one request parameter, including geographical location of the patient, a list of medications prescribed to the patient, and a time period, such that it is understood by Examiner that the electronic prescription format is thereby based on the geographical location parameter, i.e. that manages the formatting of said query as per Livesay Par [0026]).
It would have been obvious to one of ordinary skill in the art before the effective filing date do the claimed invention to modify the combined disclosure of Doherty and Blackley, which already discloses the automatic transmission of one or more prescription fill requests to a blockchain and a pharmacy system to further include looking-up regional rules in a rules database that comprises a plurality of rules for electronic prescribing, and converting the electronic prescription transmission to a standardized format based on the regional rules, as disclosed by Livesay, because this allows for communications that are compatible with each endpoint computing device in varying geographic locations (See Livesay Par [0030]).
While Livesay generally discloses converting the electronic prescription transmission to a standardized format based on the regional rules, Doherty, Blackley, and Livesay do not explicitly disclose the regional prescription rules include electronic prescription regulations for a facility type of the pharmacy.
However, Chen discloses the regional prescription rules include electronic prescription regulations for a facility type of the pharmacy (See Chen Par [0133] which discloses that revocation of access may be required if the provider is no longer in good standing with the DEA, or determining that a certain facility/location at which the provider is no longer authorized to prescribe controlled substances, i.e. regulations for a facility type, i.e. the type of facility is an unauthorized facility; See Chen Par [0135] which discloses generating and presenting locations where the provider practices, the state license number and the associated state, such that the ACM presents the "Access Status" of each provider, along with an option to alter/change the access status depending on various factors of said providers/provider locations). The disclosure of Chen is directly applicable to the combined disclosure of Doherty, Blackley, and Livesay, because the disclosures share limitations and capabilities, such as being directed towards transmission and/or maintaining of one or more prescription fill requests for a patient.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Doherty, Blackley, and Livesay, which already discloses the electronic prescription transmission to a standardized format based on the regional rules, to further include the regional prescription rules include electronic prescription regulations for a facility type of the pharmacy, as disclosed by Chen, because
Claim 9 –
Regarding Claim 9, Doherty discloses a method for tracking execution of a prescription prescribed by a prescriber, the method comprising:
receiving, at a central server, an electronic prescription from a prescriber device for a patient inputted by the prescriber, wherein a controller of the central server correlates authenticating data to a prescriber profile stored in an electronic prescription wallet database (See Doherty Par [0028] which discloses a central prescription handling engine receiving prescription data from a prescribing entity, such as a clinic or hospital that is associated with at least one prescriber (e.g., a doctor, a nurse practitioner, or other individual authorized by a recognized health care licensing entity to prescribe medications) (via a computing device or interface of the prescribing entity); See Doherty Par [0030]-[0033] which discloses a centralized prescription handling engine (CPHE) for filling a medical prescription listing of one or more prescribed medications and/or treatments at one or more affiliated pharmacies in response to receiving prescription data from the prescribing entity);
looking-up, with the central server, regional rules in a rules database that comprises a plurality of prescription rules, the regional rules associated with one or more of a residence of the patient and/or a location of the prescriber (See Doherty Par [0053] which discloses an external database being referenced, such as government regulatory, i.e. rules/laws, database, and as further described in Doherty Par [0092] defines a geographical area defined by a municipality, territory, state, province or country) and each prescription rule may include data indicating the particular laws and/or regulations for electronic prescribing for a particular geographic region in a format that may be read by the controller so that one or more operations based on the retrieved prescription rules for a particular geographic region are performed (See Doherty Par [0053] which discloses an external database being referenced, such as government regulatory, i.e. rules/laws, database, and as further described in Doherty Par [0092] defines a geographical area defined by a municipality, territory, state, province or country);
correlating, with the controller of the central server, the electronic prescription to a patient wallet associated with the patient and storing the electronic prescription in association with the patient wallet (While not “patient wallet” per se, but see Doherty Par [0031] which discloses the CPHE providing a central hub for integrating insurance and payment engines; See Doherty Par [0072]-[0074] which discloses receiving prescription cost information which can then be sent to a payment engine, which may be in communication with a third-party payment processing system, such as a credit card company, and/or may communicate the prescription cost information directly to a given user, wherein the user can pay via a web account of mobile device account/application, effectively constituting an electronic patient wallet), the patient wallet being stored in the electronic prescription wallet database (While not “electronic wallet” per se, see Doherty Par [0072]-[0074] which discloses receiving prescription cost information which can then be sent to a payment engine, which may be in communication with a third-party payment processing system, such as a credit card company, and/or may communicate the prescription cost information directly to a given user, wherein the user can pay via a web account of mobile device account/application and even mentions the use of PayPal™, effectively constituting an electronic patient wallet; See Doherty Par [0031] & [0082] which discloses a central hub, interpreted as “ wallet database” under BRI, for integrating insurance engine and prescription engine, such that a third-party payment processing system, such as a credit card company, may communicate the prescription cost information directly to a given user, wherein the user can pay via a web account of mobile device account/application; See further Doherty Par [0071] which discloses a pharmacy insurance database such that the patient or user can receive an insurance policy acceptability indication, such that adjudication/payment can be processed after said indication is determined and transmitted to the patient/user);
generating, with the controller and based on computer-readable instructions stored on memory thereof, a prescription fill request, sent from a patient device via the patient to the prescriber device, including a single instance of the electronic prescription correlated to a patient profile associated with the patient wallet and stored in the electronic prescription wallet database (See Doherty Par [0058]-[0059] which discloses generating a prescription refill request and transmitting via a mobile device or terminal at a GPI to submit such as refill request to the CPHE for fulfillment; See Doherty Par [0085] which discloses the plurality of prescribing entity computing devices being accessible by a prescriber, such as for purposes of submitting/filing a medical prescription; See Doherty Par [0031] & [0082] which discloses storing and tracking communications between user and pharmacy to facilitate continuing and actively-monitored care), the correlation including matching patient data transmitted with the electronic prescription to data stored in a patient database of the electronic prescription wallet database (While not “electronic wallet” per se, see Doherty Par [0072]-[0074] which discloses receiving prescription cost information which can then be sent to a payment engine, which may be in communication with a third-party payment processing system, such as a credit card company, and/or may communicate the prescription cost information directly to a given user, wherein the user can pay via a web account of mobile device account/application and even mentions the use of PayPal™, effectively constituting an electronic patient wallet; See Doherty Par [0031] & [0082] which discloses a central hub, interpreted as “ wallet database” under BRI, for integrating insurance engine and prescription engine, such that a third-party payment processing system, such as a credit card company, may communicate the prescription cost information directly to a given user, wherein the user can pay via a web account of mobile device account/application; See further Doherty Par [0071] which discloses a pharmacy insurance database such that the patient or user can receive an insurance policy acceptability indication, such that adjudication/payment can be processed after said indication is determined and transmitted to the patient/user; See Doherty Par [0055]-[0056] which discloses prescription information database including tracking confirmation information such as pharmacy location, staff identifier, retrieval timestamp, medication quantity, and verification method of given user; See Doherty Par [0058]-[0059] which describes receiving and storing one or more fill requests associated with one or more refill information and prescription data; See Doherty Par [0037] which discloses patient web accounts recording and being able to view medical information such as current and past medications, such that the web accounts are also correlated with payment engine and payment methods such as described in Doherty Par [0072]-[0074]);
automatically transmitting, via a communication interface of the central server, the prescription fill request a pharmacy system and blockchain (See Doherty Par [0058]-[0059] which discloses generating a prescription refill request and transmitting via a mobile device or terminal at a GPI to submit such as refill request to the CPHE for fulfillment; See Doherty Par [0085] which discloses the plurality of prescribing entity computing devices being accessible by a prescriber, such as for purposes of submitting/filing a medical prescription; See Doherty Par [0031] & [0082] which discloses storing and tracking communications between user and pharmacy to facilitate continuing and actively-monitored care, but does not explicitly mention use of a blockchain per se; See Doherty Par [0039] which discloses the prescription data, i.e. fill request, can be sent via link to CPHE, such that the CPHE can be configured to selectively, i.e. automatically, route the prescription data to various pharmacy interfaces associated with one or more pharmacies, sch as based on automated user preferences stored by the user, characteristics of each pharmacy corresponding to each pharmacy interface, etc.), wherein the central server employs one or more suitable communication protocols defining rules and data formats for exchanging information and communicating over a network between the central server, the prescriber device, the patient device, and the pharmacy system (See Doherty Par [0036] which discloses communication links in the form of a network, such that communication between CPHE 105 and the mobile devices can be through links which can comprise any wired and/or wireless network including, but not limited to, a wide-area network, such as network, and a cellular network, and any suitable combination thereof, and does not necessarily imply that the “suitable” communication protocols defining rules and data formats be suitable with the geographic laws/regulations)
notifying one or more of the patient or the prescriber, via the communication interface of the central server, the prescription is ready for pick-up at a pharmacy (See Doherty Par [0029] for communicating scheduling data related to the filling of the prescription being communicated to the user; See Doherty Par [0047] which discloses a notification being sent regarding the start date and time from which the prescribed medication will be available, i.e. ready for pick-up);
cancelling the prescription at the pharmacy and sending the prescription to a different pharmacy based on an input provided by the patient via the patient device or a threshold duration elapsing, wherein the patient device sends a request to access the patient profile to fill the prescription at the different pharmacy (See Doherty Par [0066] which discloses a selection of a given pharmacy based on available pharmacy information being made by the user though a mobile device or terminal, i.e. the patient selects a particular pharmacy; See Doherty Par [0079] which discloses that a user, i.e. patient or prescriber, can confirm an alternate delivery date/time for pickup of a medicine at an alternate pharmacy that has stock of that particular medicine, the confirmation effectively constituting input by the patient), wherein the patient device sends a request to access a patient profile associated with the patient wallet to fill the prescription at the different pharmacy (See Doherty Par [0073]-[0076] which discloses communicating prescription cost information to a given user associated with patient web account such that the prescription cost information can be adjusted to reflect taxes, insurance coverage, and/or shipping and handling costs where applicable; See Doherty Par [0079] which discloses that a user, i.e. patient or prescriber, can confirm an alternate delivery date/time for pickup of a medicine at an alternate pharmacy that has stock of that particular medicine, the confirmation effectively constituting input by the patient); and
sending a receipt from the pharmacy system to the central server in response to the prescription being filled and ready for pick-up at the different pharmacy (See Doherty Par [0073]-[0076] which discloses communicating prescription cost information to a given user associated with patient web account such that the prescription cost information can be adjusted to reflect taxes, insurance coverage, and/or shipping and handling costs where applicable, and further discloses sending a payment confirmation, constituting a receipt under BRI).
As shown above, Doherty effectively discloses storing and tracking communications, i.e. transactions, between user and pharmacy to facilitate continuing and actively-monitored care, but does not explicitly mention use of a blockchain per se, and therefore does not explicitly disclose the following limitations:
automatically transmitting, via a communication interface of the central server, a prescription fill request to a blockchain;
creating a digital ledger that records prescription transactions on a blockchain, and wherein
each of the prescription transactions recorded in the digital ledger on the blockchain are automatically generated by the central server to include a cryptographic hash of a previous block, a timestamp, and transaction data related to the electronic prescription;
However, Blackley discloses automatically transmitting, via a communication interface of the central server, a prescription fill request to a blockchain (See Blackley Par [0024 & [0036] which discloses when a prescriber (e.g., physician) writes a prescription for a patient, the prescriber may have the prescription entered, i.e. transmitted, into an existing prescription system that may be augmented to interface with the blockchain prescription management (BCPM) system and further describes the BCPM system automatically coordinating/managing the recording of transactions in the blockchain; See Blackley Par [0026] which discloses the BCPM system sending submission information (that specifies the submission information and directly or indirectly references the prescription transaction) to the BCPM application on a device of the patient; See Blackley Par [0042] which discloses the BCPM being hosted on a cloud system that interfaces with a variety of client devices, such that the BCPM application accesses the blockchain and receives and sends information via varying means and includes interfaces to retrieve health information from various applications that of the client devices); creating a digital ledger that records prescription transactions on the blockchain automatically via the central server (See Blackley Par [0024], [0036], [0049], [0064] which discloses recording transactions that relate to prescribing, dispensing, and taking of medicine in a blockchain or in the form of a generalized distributed ledger and the BCPM system automatically coordinating/managing the recording of transactions in the blockchain in Blackley Par [0036], in particular; See Blackley Par [0051] which discloses said system or computing device can include a central processing unit and/or server implementation), wherein each of the prescription transactions recorded in the digital ledger on the blockchain are automatically generated by the central server (See Blackley Par [0024], [0036], [0049], [0064] which discloses recording transactions that relate to prescribing, dispensing, and taking of medicine in a blockchain or in the form of a generalized distributed ledger and the BCPM system automatically coordinating/managing the recording of transactions in the blockchain in Blackley Par [0036], in particular) to include a cryptographic hash of a previous block, a time stamp, and transaction data related to the electronic prescription (See Blackley Par [0001] which discloses once a block is full, the block is “capped” with a block header including a hash digest of all transaction identifiers within the block, and the block header is recorded as the first transaction in the next block in the chain, i.e. each subsequent hash contains a previously capped block; See Blackley Par [0003] which discloses the use of a cryptographic one-way hash of information that uniquely identifies the asset; See Blackley Par [0005] which further discloses possible use of a smart contract system that records the contract as a transaction in the blockchain using an identity token that is a hash of the computer code; See Blackley Par [0036] which discloses the BCPM system records in the blockchain a prescription transaction that specifies details of a prescription such as the medicine, dosage patient, and so on, i.e. transaction data related to the electronic prescription; See Blackley Par [0044] which discloses that when a transaction is recorded, details regarding the transaction, such as the date, i.e. timestamp, of the transaction is also included/recorded).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the disclosure of Doherty which already discloses storing and tracking communications, i.e. transactions, between user and pharmacy to facilitate continuing and actively-monitored care, to further specifically include the use and tracking of transmitted information via a digital ledger and/or blockchain, as disclosed by Blackley, because by using a blockchain or distributed ledger, the system can effectively record in the blockchain a submission transaction for each pharmacy that has provided a submission for dispensing the prescription, and effectively track the fulfillment process of the prescription fulfillment, i.e. the purpose of transferring the ownership is to ensure that the submission token has not been spent by a pharmacy and is available to be transferred to the BCPM service if that pharmacy is selected (See Blackley Par [0036]).
While Doherty and Blackley generally disclose the automatic transmission of one or more prescription fill requests to a blockchain and a pharmacy system, Doherty and Blackley are generally silent on accessing a rules database for purposes of accessing a standardized format according to geographical rules as given by the following limitation:
converting prescription data of the electronic prescription into a standardized format based on the regional rules;
However, Livesay discloses converting prescription data of the electronic prescription into a standardized format based on the regional rules (See Livesay Par [0018] which discloses storing data relating to a patient’s prescribed medication in a health information system; See Livesay Par [0026] which discloses a query corresponding to a list of medications that have been prescribed for a particular patient and further contains one or more request parameters that manages the formatting of said query; See Livesay Par [0030] which discloses a communication protocol list being stored in a database and a translation module allowing for retrieval of the list from the database, such that communication protocols, i.e. rules, are maintained that are compatible with each of the endpoint computing devices; See Livesay Claim 1 which discloses an electronic query corresponding to a request for health information of a patient being formatted according to at least one request parameter, including geographical location of the patient, a list of medications prescribed to the patient, and a time period, such that it is understood by Examiner that the electronic prescription format is thereby based on the geographical location parameter, i.e. that manages the formatting of said query as per Livesay Par [0026]).
It would have been obvious to one of ordinary skill in the art before the effective filing date do the claimed invention to modify the combined disclosure of Doherty and Blackley, which already discloses the automatic transmission of one or more prescription fill requests to a blockchain and a pharmacy system to further include looking-up regional rules in a rules database that comprises a plurality of rules for electronic prescribing, and converting the electronic prescription transmission to a standardized format based on the regional rules, as disclosed by Livesay, because this allows for communications that are compatible with each endpoint computing device in varying geographic locations (See Livesay Par [0030]).
While Doherty, Blackley, and Livesay do not disclose, Chen discloses:
via the central server, detecting one or more violations of the regional rules in the electronic prescription (See Chen Par [0135] which discloses making determinations of access status to alter/change access status for a provider based on where the provider practices, their associated DEA number, the State of the DEA number, the State license number and the associated state, i.e. regional rules; See Chen Par [0159] which discloses the pharmacy system 500 will also confirm that the details of the electronic prescription are valid and do not exceed or conflict with any state laws relating to the electronic prescription of controlled substances using the controlled substance database, and if the electronic prescription does exceed or conflict with state or federal government laws, then an error message is presented to the provider), and
flagging the electronic prescription via the central server responsive to detecting the one or more violations of the regional rules (“flagging” is understood to merely constitute identifying or indicating, therefore see Chen Par [0159]-[0160] which discloses the pharmacy system will also confirm that the details of the electronic prescription are valid and do not exceed or conflict with any state laws relating to the electronic prescription of controlled substances using the controlled substance database, and if the electronic prescription does exceed or conflict with state or federal government laws, then an error message is presented to the provider);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined disclosure of Doherty, Blackley, and Livesay to further include detecting one or more violations of the regional rules in the electronic prescription and flagging the electronic prescription via the central server responsive to detecting the one or more violations of the regional rules, as disclosed by Chen, because this allows for automatically checking prescription requests as regulated by federal or state government for appropriately dispensing prescriptions (See Chen Par [0159]-[0160]).
Claim 10 –
Regarding Claim 10, Doherty, Blackley, Livesay, and Chen disclose the method of Claim 9 in its entirety. Doherty does not disclose, but Blackley and Chen further disclose a method, further comprising:
via the central server, sending a message to the prescribed device indicating the violation has occurred (Chen Par [0159] which discloses the pharmacy system 500 will also confirm that the details of the electronic prescription are valid and do not exceed or conflict with any state laws relating to the electronic prescription of controlled substances using the controlled substance database, and if the electronic prescription does exceed or conflict with state or federal government laws, then an error message is presented to the provider, i.e. a message indicating the violation has occurred is generated); and
the patient is a first patient, further comprising detecting if the first patient received a partial fill of the prescription from the different pharmacy and flagging the different pharmacy if a second patient, different than the first patient, received a partial fill or a complete fill of the prescription from the different pharmacy (See MPEP 2111.04(II) for contingent limitations in a method claim, such that the BRI of contingent limitations in a method claim require only those steps that must be performed and does not include steps that are not required to be performed because the conditions precedent are not met, therefore this claim is effectively met if a reference discloses detecting if the first patient received a partial fill of the prescription from the different pharmacy, therefore see Blackley Par [0036] which discloses the BCPM system recording in the blockchain for each dose of a prescription, a dose token that creates and outputs a dose token with the dispense transaction as the owner, such that it is understood by Examiner if a partial dispensation occurs then the system effectively detects this partial dispensation and accordingly assigns a dose token for each dose of the partially filled prescription, such as seen in Blackley Par [0059] where a next dose for the prescription is required to be dispensed and is thereby selected and recorded as a dose transaction that is owned by the dispense transaction).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined disclosure of Doherty, Blackley, and Livesay, to further disclose detecting if the first patient received a partial fill of the prescription from the different pharmacy, as disclosed by Blackley, because this allows for monitoring of fraudulent prescriptions detects this partial dispensation and accordingly assigns a dose token for each dose of the partially filled prescription and the system automatically determining when where a next dose for the prescription is required to be dispensed and is thereby selected and recorded as a dose transaction that is owned by the dispense transaction (See Blackley Par [0059]).
It would have been further obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined disclosure of Doherty, Blackley, Livesay, and Chen, to further disclose via the central server, sending a message to the prescribed device indicating the violation has occurred, as disclosed by Chen, because this allows for confirming that the details of the electronic prescription are valid and do not exceed or conflict with any state laws relating to the electronic prescription of controlled substances using the controlled substance database, and if they do, presenting said information when needed (See Chen Par [0159]-[0160])
Claim 11 –
Regarding Claim 11, Doherty, Blackley, Livesay, and Chen disclose the method of Claim 10 in its entirety. Doherty further discloses a method, further comprising:
monitoring a behavior of the different pharmacy over time to detect fraud (“to detect fraud” is considered a “whereby” clause in a method claim, wherein it simply expresses the intended result of a process step positively recited (See MPEP 2111.04(I)) and therefore does not seem to add patentable weight beyond the actual process step occurring (i.e. monitoring a behavior of the different pharmacy over time). therefore see Doherty Par [0055] which discloses monitoring of IT, sales, or inventory tracking systems of a given pharmacy which could effectively be applied for the purposes or intended result of detecting fraud), and wherein
the rule(s) for the particular geographic region include an option for a secondary prescriber to alter, modify, and/or assign changes to the prescription (See Doherty Par [0053] which discloses an external database being referenced, such as government regulatory, i.e. rules/laws, database, and as further described in Doherty Par [0092] defines a geographical area defined by a municipality, territory, state, province or country; See Doherty Par [0085] which discloses each one of the prescribing entity interfaces can represent one or more prescribing entities, such that each one of the plurality of prescribing entity computing devices is accessible by a prescriber who is an individual that is authorized by the relevant licensing and/or governmental authority to prescribe medications, such as a physician and a nurse practitioner, and may be suitable for transmitting and receiving data to and from the CPHE regarding the user’s prescription).
Claim 12 –
Regarding Claim 12, Doherty, Blackley, Livesay, and Chen disclose the method of Claim 9 in its entirety. Doherty further discloses a method, further comprising:
receiving cost estimates from one or more pharmacies in the pharmacy system and updating the patient wallet to include the cost estimates associated with the prescription (See Doherty Par [0073]-[0076] which discloses communicating prescription cost information to a given user associated with patient web account such that the prescription cost information can be adjusted, i.e. estimated, to reflect taxes, insurance coverage, and/or shipping and handling costs where applicable, and further discloses sending a payment confirmation; While not “electronic wallet” per se, see Doherty Par [0072]-[0074] which discloses receiving prescription cost information which can then be sent to a payment engine, which may be in communication with a third-party payment processing system, such as a credit card company, and/or may communicate the prescription cost information directly to a given user, wherein the user can pay via a web account of mobile device account/application and even mentions the use of PayPal™, effectively constituting an electronic patient wallet; See Doherty Par [0031] & [0082] which discloses a central hub, interpreted as “ wallet database” under BRI, for integrating insurance engine and prescription engine, such that a third-party payment processing system, such as a credit card company, may communicate the prescription cost information directly to a given user, wherein the user can pay via a web account of mobile device account/application; See further Doherty Par [0071] which discloses a pharmacy insurance database such that the patient or user can receive an insurance policy acceptability indication, such that adjudication/payment can be processed after said indication is determined and transmitted to the patient/user).
Claim 13 –
Regarding Claim 13, Doherty, Blackley, Livesay, and Chen disclose the method of Claim 9 in its entirety. Doherty does not disclose, but Blackley further discloses a method, further comprising:
automatically advancing a refill of the prescription, without instruction from the prescriber, in response to the patient receiving only a portion of the prescription from the different pharmacy (See Blackley Par [0036] which discloses the BCPM system recording in the blockchain for each dose of a prescription, a dose token that creates and outputs a dose token with the dispense transaction as the owner, such that it is understood by Examiner if a partial dispensation occurs then the system effectively detects this partial dispensation and accordingly assigns a dose token for each dose of the partially filled prescription, such as seen in Blackley Par [0059] where a next dose for the prescription is required to be dispensed and is thereby selected and recorded as a dose transaction that is owned by the dispense transaction), wherein the different pharmacy relays to the central server that only a portion of the prescription was filled (See Blackley Par [0036] which discloses the BCPM system recording in the blockchain for each dose of a prescription, a dose token that creates and outputs a dose token with the dispense transaction as the owner, such that it is understood by Examiner if a partial dispensation occurs then the system effectively detects this partial dispensation and accordingly assigns a dose token for each dose of the partially filled prescription, such as seen in Blackley Par [0059] where a next dose for the prescription is required to be dispensed and is thereby selected and recorded as a dose transaction that is owned by the dispense transaction, and such that this information is relayed or transmitted over server implementation to be recorded in the BCPM system/blockchain).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combined disclosure of Doherty, Blackley, and Livesay, to further disclose detecting if the first patient received a partial fill of the prescription from the different pharmacy, as disclosed by Blackley, because this allows for monitoring of fraudulent prescriptions detects this partial dispensation and accordingly assigns a dose token for each dose of the partially filled prescription and the system automatically determining when where a next dose for the prescription is required to be dispensed and is thereby selected and recorded as a dose transaction that is owned by the dispense transaction (See Blackley Par [0059]).
Claim 14 –
Regarding Claim 14, Doherty, Blackley, Livesay, and Chen disclose the method of Claim 9 in its entirety. Doherty and Blackley further disclose a method, further comprising:
storing insurance data in the patient wallet associated with an insurance policy purchased by the patient, wherein the insurance data comprises in-network pharmacies, in-network prescribers, and tasks requested to provide financial coverage for the prescription (See Doherty Par [0055]-[0056] which discloses prescription information database including tracking confirmation information such as pharmacy location, staff identifier, retrieval timestamp, medication quantity, and verification method of given user; See Doherty Par [0058]-[0059] which describes receiving and storing one or more fill requests associated with one or more refill information and prescription data; See Doherty Par [0037] which discloses patient web accounts recording and being able to view medical information such as current and past medications, such that the web accounts are also correlated with payment engine and payment methods such as described in Doherty Par [0072]-[0074]; See Doherty Par [0082] which discloses cross-checking previously filled prescriptions and information associated with said prescribing such as patient information, the integrated insurance engine and/or payment engine which as described in Par [0067]-[0069] effectively identifies and references insurance coverage details, thereby effectively constituting cross-referencing insurance policy associated with patient profile, and further determines if the pharmacy accepts said coverage, i.e. effectively constituting an in-network pharmacy; See Blackley Par [0026] which discloses notifying a prescriber that alternative medicines or pharmacies are available such that the prescriber and patient can discuss options in real time to identify an appropriate medicine, dosage, pharmacy, and so on that will increase the chances of having a prescription dispensed and reduce the chances of an abandonment, i.e. by decreasing price and/or increasing financial coverage of the prescription; See Blackley Par [0031] which discloses an incentive token for incentivizing patients to take certain actions, i.e. tasks, such that when making an in-store purchase, the BCPM application may display a Quick Response (“QR”) code that identifies the incentive token, such that a POS system may scan the QR code, adjust a purchase price based on the incentive, and coordinate the recording of an incentive token transaction that inputs the incentive token that is owned by the patient and outputs an incentive token that is owned by the pharmacy, effectively increasing financial coverage; [0033] which discloses a pharmacy specifying rules to be used for generating submissions, such that one rule for a pharmacy may be that when dispensing a prescription for 30 doses of a certain medicine for a certain sponsor, the copayment amount should be $10 and the incentive should be a 25% off coupon, i.e. that opting for a certain medicine increases financial coverage of the prescription via a 25% off coupon).
It would have been obvious to one of ordinary skill in the effective filing date of the claimed invention to modify the combined disclosure of Doherty, Blackley, and Livesay, to further include notifying the prescriber, via the communication interface of the central server, tasks included in the insurance policy associated with the patient profile that once performed, increase financial coverage of the prescription, as disclosed by Blackley because this effectively increases the chances of having a prescription dispensed and reduce the chances of an abandonment, i.e. by decreasing price and/or increasing financial coverage of the prescription (See Blackley Par [0026]).
Claim 15 –
Regarding Claim 15, Doherty, Blackley, Livesay, and Chen discloses the method of Claim 14 in its entirety. Doherty further discloses a method, further comprising:
the patient accesses other patient profiles associated with the insurance policy purchased by the patient (“patient profile” under BRI could simply include any information or details regarding a patient, therefore See Doherty Par [0036] which discloses web accounts, terminals, and terminal-to-CPHE links can be similar for the other users, such that user can have a web account accessible through terminal in communication with CPHE via link, and additional users can have a web account accessible through terminal in communication with CPHE 105 via same or similar links; See Doherty Par [0037] which discloses the patient being able to access insurance coverage information, and is understood by Examiner to further include covered entities and insurance coverage information associated therewith, constituting accessing other patient profiles).
Response to Arguments
Applicant's arguments filed 19 March 2026 have been fully considered but they are not persuasive:
Regarding 35 U.S.C. 101 rejections of claims 1-20, Applicant argues on p. 13-16 of Arguments/Remarks in view of Declarations filed on 04 August 2025. In particular, Applicant argues in view of several points (points 4 to 11) that generally purport technical advantages and/or improvements over prior art systems regarding conversion of an electronic prescription into a standardized format based on regional rules, and therefore point to patent-eligible subject matter. Examiner respectfully disagrees with Applicant’s arguments. The embodiments argued by Applicant seem to amount to mere efforts to mere data manipulation and/or insignificant application, as shown above in the ‘Claim Rejections - 35 U.S.C. 101’ section of this Office Action. For instance, merely accessing a database of rules and applying said rules amounts to mere data gathering and/or data manipulation efforts of gathered data. While said rules may be specific and/or particular to certain laws or regulations of a particular geographic region, this merely limits the data being gathered rather than amounting to improvements. In terms of the latter portion of the limitation being argued by Applicant, converting an electronic prescription into a standardized format based on regional rules, amounts to insignificant application and/or well-understood, routine, and/or conventional activity found in prior art systems. That is, while Applicant declares that this amounts to a technical improvement over prior art systems, numerous references point towards efforts of converting electronic transmissions according to certain parameters and rules, including geographic location in particular. Therefore, while Applicant generally argues several points regarding conversion of data into a standardized format cutting down on network traffic, computation/processing efforts, and/or transmission delays, it is understood by Examiner that any such system that discloses the same or similar efforts would also achieve said results described in the filed Declarations. Furthermore, while Applicant argues in view of the benefits of mere automation of the manual effort of converting prescription data into a standardized format, MPEP 2106.0(a)(I)(iii) states that mere automation of manual processes, such as using a generic computer to achieve a result, amounts to insignificant, extra-solution activity and does not amount to a technical improvement. As such, independent claims 1, 9, & 16 and claims dependent therefrom remain rejected under 35 U.S.C. 101.
Regarding 35 U.S.C. 101 rejections of claims 1-20, Applicant argues on p. 16-17 in view of Example 42, stating that the claims and Example 42 both relate to a method for transmission of medical data and even if claim 1 recites an abstract idea, amended claim 1 further recites additional elements including converting updated information provided by a user and/or a pharmacy into a format used by the central server or into a format used by different pharmacies and/or users, including accounting for regional differences, thereby integrating the alleged abstract idea into a practical application. Examiner respectfully disagrees with Applicant’s arguments. The inventive concept of the application is not directed towards accounting for regional differences in formatting of prescriptions. Rather, the efforts regarding said formattings are needed in order to achieve the actual inventive concept of managing a patient’s prescription requests electronically. While the system may improve upon a prescriber’s awareness of drugs and dosages thereof prescribed in different states or from different providers, this is not a technical problem, i.e. a problem associated with the technology or technological components performing the abstract idea. Instead, this is a problem with the abstraction of awareness of drugs and dosages thereof prescribed in different states or from different providers. That is, depending on location of the patient, varying rules or regulations are needed. That is, this is not necessarily a disparity/shortcoming in the prior art. Rather, this represents mere necessary steps that occur as a result of the actual inventive concept. Therefore, the claims are not substantially similar to or the same as Example 42, because Example 42 specifically laid out and was directed towards shortcomings in prior art systems regarding formattings and disparate medical system when transmitting medical data. However, it is understood by Examiner and further pointed out by the prior art that conversion of these formattings are typical and well-understood aspects of modern prior art systems. Furthermore, as an additional aside, converting or transforming of data does not satisfy the requirements of the transformation prong for determining a particular transformation or machine when considering whether a claim amounts to significantly more than the recited abstract idea. As such, independent claims 1, 9, & 16 and claims dependent therefrom remain rejected under 35 U.S.C. 101.
Regarding 35 U.S.C. 101 rejections of claims 1-20, Applicant argues on p. 17-19 of Arguments/Remarks that claims 9 & 16 have been amended to include similar subject matter as claim 1, and therefore, claims 9 &16 are patent-eligible for the same or substantially similar reasons as argued for claim 1. Examiner respectfully disagrees with Applicant’s arguments. As presented above, claim 1 remains rejected under 35 U.S.C. 101, therefore rendering Applicant’s arguments regarding claims 9 & 16 moot, since claim 1 has been determined to not be patent-eligible. As such, independent claims 1, 9, & 16 and claims dependent therefrom remain rejected under 35 U.S.C. 101.
Regarding 35 U.S.C. 103 rejections of claims 1-20, Applicant argues on p. 22-23 of Arguments/Remarks that previously cited portions of Doherty, Blackley, and Livesay do not read on the newly-recited limitations found in amended, independent claim 9, and therefore these claims overcome previous 35 U.S.C. 103 rejections. More specifically, Applicant argues that Doherty, Blackley, and Livesay do not disclose “… detecting one or more violations of the regional rules in the electronic prescription, and flagging the electronic prescription via the central server responsive to detecting the one or more violations of the regional rules”. Examiner agrees with Applicant’s arguments. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection has been made under 35 U.S.C. 103 over Doherty, in view of Blackley, in view of Livesay, further in view of Chen to read on the newly-recited limitations regarding “… detecting one or more violations of the regional rules in the electronic prescription, and flagging the electronic prescription via the central server responsive to detecting the one or more violations of the regional rules”. Therefore, the newly-recited limitations found in amended, independent claim 9 are effectively met by Doherty, Blackley, Livesay, and Chen. As such, independent claim 9 and claims dependent therefrom (claims 10-15), remain rejected under 35 U.S.C. 103 over Doherty in view of Blackley, in view of Livesay, further in view of Chen.
Regarding 35 U.S.C. 103 rejections of claims 1-20, Applicant argues on p. 19-21 of Arguments/Remarks that Doherty, Blackley, and Livesay fail to disclose “looking-up regional prescription rules in a rules database that comprises a plurality of rules for electronic prescribing, and converting the electronic prescription to a standardized format based on the regional prescription rules” as found in independent claims 1, 9, & 16. Examiner respectfully disagrees with Applicant’s arguments. Livesay effectively disclosed “looking-up regional prescription rules in a rules database that comprises a plurality of rules for electronic prescribing, and converting the electronic prescription to a standardized format based on the regional prescription rules” at least by Livesay Par [0030] which discloses a communication protocol list being stored in a database and a translation module allowing for retrieval of the list from the database, such that communication protocols, i.e. rules, are maintained that are compatible with each of the endpoint computing devices and Livesay Claim 1 which discloses an electronic query corresponding to a request for health information of a patient being formatted according to at least one request parameter, including geographical location of the patient, a list of medications prescribed to the patient, and a time period, such that it is understood by Examiner that the electronic prescription format is thereby based on the geographical location parameter, i.e. that manages the formatting of said query as per Livesay Par [0026]. While Applicant argues against Livesay disclosing said aspects because Livesay does not suggest looking-up “regional prescription rules”, Examiner argue that an electronic query corresponding to a request for health information of a patient being formatted according to at least one request parameter, including geographical location of the patient, and communication protocols, i.e. rules being established for said health information, and the health information can be one or more prescriptions or refill queries reads on the limitations therein. Therefore, the claims found in amended, independent claims 1, 9, & 16 are effectively met by Doherty, Blackley, and Livesay. As such, independent claims 1 & 16 and claims dependent therefrom, remain rejected under 35 U.S.C. 103 over Doherty in view of Blackley, further in view of Livesay.
Regarding 35 U.S.C. 103 rejections of claims 1-20, Applicant argues on p. 23 of Arguments/Remarks that claims 9 & 16 have been amended to include similar subject matter as claim 1, and therefore, claims 9 & 16 and claims dependent from claim 1 are allowable over the prior art for the same or substantially similar reasons as argued for claim 1. Examiner respectfully disagrees with Applicant’s arguments. As presented above, a new ground or rejection has been issued for independent claim 1 under 35 U.S.C. 103 over Doherty in view of Blackley, further in view of Livesay, rendering Applicant’s arguments moot, since claim 1 has been determined to not be allowable over the prior art. As such, independent claims 1, 9, & 16 and claims dependent therefrom, remain rejected under 35 U.S.C. 103 over Doherty in view of Blackley, further in view of Livesay. Dependent claim 8 remains rejected under 35 U.S.C. 103 over Doherty in view of Blackley, in view of Livesay, further in view of Chen.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant's disclosure:
Wallace et al. (U.S. Patent Publication No. 2004/0210341) discloses utilizes a network to provide for the secure delivery of confidential patient information and the sending of dispense instructions to a remote dispensing station;
Sepe et al. (U.S. Patent No. 10,621,687) discloses automatically tracking, ordering, and replenishing prescription item stock and fulfillment of prescription orders, such that rule parameters may also provide for exceptions that may apply to specific pharmacy locations, regions, countries, specific dates, etc., to provide additional flexibility and to ensure that the appropriate amount of prescription items are ordered at the right time and in the right amounts based on regional rules.
Applicant's amendment necessitated the new ground of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUNTER J RASNIC whose telephone number is (571)270-5801. The examiner can normally be reached M-F 8am-5:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shahid Merchant can be reached on (571) 270-1360. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/H.R./Examiner, Art Unit 3684
/Shahid Merchant/Supervisory Patent Examiner, Art Unit 3684
Prosecution Insights