DETAILED ACTION
This action is in reference to the communication filed on 8 JAN 2025.
Claims 1-20 are present and have been examined.
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 rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. As explained below, the claim(s) are directed to an abstract idea without significantly more.
Step One: Is the Claim directed to a process, machine, manufacture or composition of matter? YES
With respect to claims 1-20 the independent claims (1, 18, 20) recite a server, non-transitory computer readable medium, and method, each which falls in a statutory category of invention.
Step 2A – Prong One: Is the claim directed to a law of nature, a natural phenomenon (product of nature) or an abstract idea? YES
With respect to claims 1-20 the independent claims (1, 18, 20) are directed, in part, to:
(claim 1)
receive an outbound patient notification from an enterprise pharmacy system, wherein the outbound patient notification is indicative of a prescription status change;
apply one or more predetermined rules to the outbound patient; and
update a dispensing history collection to incorporate the prescription status change in response to application of the one or more predetermined rules.
These claim elements are considered to be abstract ideas because they are directed to mental processes, including concepts performed in the mind such as observation, evaluation, judgment, opinion, etc. Receiving a notification, and applying rules to subsequently update a record to incorporate the changes are examples of evaluation and judgement at lease. The claims are further directed to certain methods of organizing human activities, including managing personal behaviors such as following rules or instructions – applying predetermined rules and storing an updated entry as per the rules is also an example of following instructions in the sequencing and the application thereof of the rules themselves.
If a claim limitation, under its broadest reasonable interpretation, covers concepts such as evaluation, judgement and opinion, then it falls within the mental process grouping of abstract ideas. If a claim covers rules and instructions, then it falls within the “method of organizing human activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A – Prong Two: Does the claim recite additional elements that integrate the judicial exception into a practical application? NO.
This judicial exception is not integrated into a practical application. In particular, the claims recite additional element: Claim 1 recites a “cloud server” comprising a processor and a memory having instructions thereon executable by the processor; claim 18 recites a non-transitory machine readable storage media comprising a plurality of instructions executed by a processor, while claim 20 recites only a cloud server. Each of claims 1, 18, 20 appears to require sending and receiving of data between computing elements. Examiner finds that the cloud servers in claims 1, 20, as well as the processor/memory elements in claims 1, 18, are recited at a high level of generality and as such amount to no more than adding the words “apply it” to the judicial exception, or mere instructions to implement the abstract idea on a computer, or merely uses the computer as a tool to perform the abstract idea (see MPEP 2106.05f), or generally links the use of the judicial exception to a particular technological field of use/computing environment (see MPEP 2106.05h). The claims as written appear to rely on the existing computing infrastructure and the inherent capabilities therein.
Examiner finds no improvement to the functioning of the computer or any other technology or technical field in the cloud servers in claims 1, 20, as well as the processor/memory elements in claims 1, 18, (see MPEP 2106.05a), nor any other application or use of the judicial exception in some meaningful way beyond a general like between the use of the judicial exception to a particular technological environment (see MPEP 2106.05e). Examiner further finds that the sending/receiving of any data between computing elements/environments in the claims is found to be the equivalent of adding insignificant extra solution activity to the judicial exception(s) identified (see MPEP 2106.05g).
Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception? NO.
The independent claims are additionally directed to claim elements such as: Claim 1 recites a “cloud server” comprising a processor and a memory having instructions thereon executable by the processor; claim 18 recites a non-transitory machine readable storage media comprising a plurality of instructions executed by a processor, while claim 20 recites only a cloud server. When considered individually, the identified claim elements only contribute generic recitations of technical elements to the claims. It is readily apparent, for example, that the claim is not directed to any specific improvements of these elements. Examiner looks to Applicant’s specification in:
[0068] The processor 34 of the local hub server 32.sub.1 may be embodied as any type of processor capable of executing software/firmware, such as a microprocessor, digital signal processor, microcontroller, or the like. The processor 34 may be a single processor or include multiple processors. The I/O subsystem 32 of the local hub server 32.sub.1 may be embodied as circuitry and/or components to facilitate input/output operations with the processor 34 and/or other components of the local hub server 32.sub.1. The processor 34 is communicatively coupled to the I/O subsystem 36.
[0069] The memory 38 of the user local hub server 104 may be embodied as or otherwise include one or more conventional volatile and/or non-volatile memory devices. The memory 38 is communicatively coupled to the I/O subsystem 36 via a number of signal paths. Although only a single memory device 38 is illustrated in FIG. 1, the local hub server 32.sub.1 may include additional memory devices in other embodiments. Various data and software may be stored in the memory 38.
[077] As illustrated in FIG. 1, in some embodiments the cloud server 58 may also access the private network 30, for example via one or more virtual private network connections or other private network connections. The cloud server 58 may be embodied as, without limitation, any server or other computing device capable of performing the functions described herein, and thus generally includes the same components as the local hub server 32.sub.1 and/or the main server 14. For example, a processor 60 is coupled to an I/O subsystem 62, and the I/O subsystem 62 is coupled to a memory 64, a data storage unit 66, communication circuitry 68, and one or more peripheral devices 70. In some embodiments, each of the foregoing components may be identical to corresponding components of the local hub server 32.sub.1 described above, and a detailed explanation of such components will not be repeated here for brevity.
[0096] Another portion of the process 500, i.e., the portion between the left-most vertical line and the right-most vertical line in FIG. 5, and centered under the heading “Cloud Server,” illustratively represents one or more software applications executed by a processor 60 of the cloud server 58. In one embodiment, this portion of the process 500 is or includes the communication engine module 322 and the PWA module 324 stored in the memory 64 (and/or data storage 66) of the cloud server 58 in the form of instructions executable by the processor 60 of the cloud server 58 (see FIG. 3). The process steps of this portion of the process 500 will be described below for purposes of this disclosure as being executed by the processor 60 of the cloud server 58.
These passages, as well as others, makes it clear that the invention is not directed to a technical improvement. Further, per the specification, these elements are defined and described in capabilities only – i.e. any device capable of performing the claimed function is suitable. When the claims are considered individually and as a whole, the additional elements noted above, appear to merely apply the abstract concept to a technical environment in a very general sense – i.e. a generic computer receives information from another generic computer, processes the information and then sends information back. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified as an abstract idea. The fact that the generic computing devices are facilitating the abstract concept is not enough to confer statutory subject matter eligibility.
As per dependent claims 2-17, 19:
Dependent claims 2-4 are not directed any additional abstract ideas and are also not directed to any additional non-abstract claim elements. Rather, these claims offer further descriptive limitations of elements found in the independent claims and addressed above – such as matching patient information and making initial contact. While these descriptive elements may provide further helpful context for the claimed invention these elements do not serve to confer subject matter eligibility to the invention since their individual and combined significance is still not heavier than the abstract concepts at the core of the claimed invention.
Dependent claims 5-17, 19 are not directed to any additional abstract ideas beyond those identified above. However, these claims either recite or depend on a claim that recites the use of a “progressive web application” to communicate within the system, including a “mobile device.” These elements are not found to recite a practical application, as they are recited at a high level of generality and as such amount to no more than adding the words “apply it” to the judicial exception, or mere instructions to implement the abstract idea on a computer, or merely uses the computer as a tool to perform the abstract idea (see MPEP 2106.05f), or generally links the use of the judicial exception to a particular technological field of use/computing environment (see MPEP 2106.05h). The data sending/receiving is analogous to adding insignificant extra solution activity to the judicial exception(s) identified (see MPEP 2106.05g). Examiner finds no improvement to the functioning of the computer or any other technology or technical field in the “web application” nor the mobile device as claimed (see MPEP 2106.05a), nor any other application or use of the judicial exception in some meaningful way beyond a general like between the use of the judicial exception to a particular technological environment (see MPEP 2106.05e).
These elements further do not amount to significantly more. Turning to the specification:
[0074] The mobile communication devices 18.sub.1-18.sub.1 illustrated in FIG. 1 are intended to depict mobile communication devices that are each separately owned and/or operated by a different patient and/or other shopper. No limit on the total number of such mobile communication devices 18.sub.1-18.sub.J that may be owned and operated by any one shopper, or on the total number of such mobile communication devices 18.sub.1-18.sub.J that may communicate with the main server 14, is intended or should be inferred. The mobile communication devices 18.sub.1-18.sub.1 may be or include any mobile electronic device capable of executing one or more software application programs as described herein and of communicating with the main server 14 via the public network 16. Examples of the mobile communication devices 18.sub.1-18.sub.J include, but should not be limited to, mobile telephones, smart phones, tablet computers, personal data assistants (PDAs), and the like.
[0075] The user computing devices 20.sub.1-20.sub.K illustrated in FIG. 1 are intended to include any of privately owned and accessed computers, such as those residing in customer's residences, to include semi-privately owned and accessed computers, such as those residing at multiple-employee business enterprises, and publicly accessible computers, such as those available at internet cafés and kiosks. The user computing devices 20.sub.1-20.sub.K may be or include any computer capable of executing one or more software programs and of communicating with the main server 14 via the public network 16 for various purposes including, for example, accessing by customers of their EMS web page(s). Examples of the user computing devices 20.sub.1-20.sub.K include, but should not be limited to, personal computers (PCs), laptop computers, notebook computers and the like, whether or not networked with one or more other computing devices.
[0262] The environment 1800 of the cloud server 58 further includes a progressive web application (PWA) module 1818, which is illustratively operable to provide one or more PWA interfaces to one or more mobile communications devices (MCDs) 18. The term “progressive web application” or “PWA” is to be understood in accordance with its ordinary meaning; that is, a progressive web application (PWA) is a website that looks and behaves, with respect to a mobile communication device such as an MCD 18, as if it is a native mobile application running on the mobile device. PWAs generally take advantage of native mobile device features, without requiring the mobile device user to download application software (i.e., an “app”) locally to the mobile device. Thus, each PWA described herein may be embodied as a web application or web page that is executable via the MCD 18.
Examiner finds it apparent that the invention as claimed relies on the existing elements as described therein in the specification. There is no indication of any improvement to these elements, nor to any other technology or technical field. As such there is nothing to support a finding of significantly more. The claims are directed to an abstract idea without significantly more.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-11, 13-20 is/are rejected under 35 U.S.C. 102a1 as anticipated by Marantette (US 20220254467 A1).
In reference to claim 1, 18, 20
Marantette teaches: A cloud server for prescription management for a retail pharmacy patient, the cloud server comprising a processor and a memory having instructions stored therein and executable by the processor to cause the processor (claim 1), a one or more non-transitory machine readable storage media comprising a plurality of instructions executable by at least one process or to cause the at least one processor to (claim 18), and a method for prescription management for a retail pharmacy patient, the method comprising: (at least [figs 1, 3 and related text] cloud server 58, has processor 58) to:
receive an outbound patient notification from an enterprise pharmacy system, wherein the outbound patient notification is indicative of a prescription status change (at least [fig 2 and related text] EPS access module 206 receives EOPN, at [fig 12 and related text] “In step 1222, the cloud server 58 provides prescription refill status information to the MCD 18. The status information may indicate whether or not each requested prescription refill was successfully submitted. The status information may be sent to the MCD 18 as a PWA, a web page, or other user interface. In step 1224, the MCD 18 displays the prescription status information received from the cloud server 58.”; alternatively see [fig 13 and related text] for discussion of a refill request process – i.e. the request is received and the “status” of the request is updated as shown, and [fig 10 and related text] where the status at 1002 is “The process 1000 illustrated in FIG. 10 starts in step 1002, in which the cloud server 58 (e.g., the processor 46 of the main server 14) is operable to determine whether the status of a prescription transaction is “ready after time” or otherwise eligible to be updated by the patient.”));
apply one or more predetermined rules to the outbound patient notification (at least [figs 12 and related text] “In step 1204, the cloud server 58 (e.g., the processor 60 of the cloud server 58) processes the batch load prescription refill information and sends an enhanced message including a link to a prescription refill progressive web application (PWA) to the MCD 18 associated with the patient. The cloud server 58 may send the enhanced message in response to a data payload in the batch outreach collection 308 matching one or more rules, such as rules determining that a patient is associated with prescriptions that are expected to be refilled.” At [fig 17 and related text] “ step 1706, the cloud server 58 (e.g., the processor 60 of the cloud server 58) matches the EPS 202 payload against multiple communication rules. Each of the communication rules may be embodied as any conditions, database queries, or other computer code that may be evaluated against the EPS 202 payload to determine whether the EPS 202 payload matches the communication rule. In some embodiments, each communication rule and/or a rules engine may be embodied as a function, lambda, or other code executed by the cloud server 58 using a function as a service (FaaS) platform or other “serverless” architecture.”); and
update a dispensing history collection to incorporate the prescription status change in response to application of the one or more predetermined rules (at least [fig 5 and related text] at step 520, EPS record updated, at fig 6 and related text] “ The process 600 illustrated in FIG. 6 starts in step 602, in which the main server 14 (e.g., the processor 46 of the main server 14) is operable to create a prescription transaction record. The prescription transaction record may be embodied as any database record or other data describing a prescription transaction originated by a patient, prescriber, or other entity. Thus, the prescription transaction record may include data indicative of a patient as well as one or more prescriptions associated with the patient. The prescription transaction may be embodied as one or more records or other data maintained by an enterprise pharmacy system (EPS) 202 maintained by the main server 14…In step 622, the main server 14 updates the associated prescription transaction record in the EPS 202 with completed checkout information. The main server 14 and/or an associated local hub server 32 may provide the completed checkout information to the appropriate retail outlet 22.”).
In reference to claim 2, 19:
Marantette teaches: wherein the memory further comprises instructions stored therein and executable by the processor to cause the processor to:
select one or more prescription records from the dispensing history collection that match a predetermined smart refill criteria in response to an update of the dispensing history collection (at least [fig 12 and related text] “The process 1200 illustrated in FIG. 12 starts in step 1202, in which the main server 14 (e.g., the processor 46 of the main server 14) is operable to batch load prescription refill information. To load the refill information, the main server 14 may extract information from an enterprise pharmacy system (EPS) 202 for prescriptions that are overdue for refill or are likely to be refilled soon. For example, the main server 14 may identify prescription records that have a refill date (e.g., the date the prescription was picked up plus the days supply of that prescription) that is a predetermined amount of time in the future (e.g., four days in the future).”);
match each of the one or more prescription records with customer contact information from a customer collection (at least [fig 12 and related text] “In step 1204, the cloud server 58 (e.g., the processor 60 of the cloud server 58) processes the batch load prescription refill information and sends an enhanced message including a link to a prescription refill progressive web application (PWA) to the MCD 18 associated with the patient. The cloud server 58 may send the enhanced message in response to a data payload in the batch outreach collection 308 matching one or more rules, such as rules determining that a patient is associated with prescriptions that are expected to be refilled. As described above, the enhanced message may be sent via SMS or other messaging service to a phone number associated with the patient.”);
add the one or more prescription records to a retail outreach collection and to a refill collection (at least [fig 12 and related text] retail outlet 22 refills prescription at steps 1222-1226); and
send a retail outreach message for each of the matching customer contact information, wherein the retail outreach message is indicative of an identifier associated with one or more prescription records in the refill collection that match the corresponding customer contact information (at least [fig 12 and related text] “As described above, the enhanced message may be sent via SMS or other messaging service to a phone number associated with the patient. Also as indicated above, the enhanced message includes a link such as a URI or URL that identifies the refill reminder PWA provided by the cloud server 58. In some embodiments, the PWA link may also include a unique identifier generated by the cloud server 58 and associated with the particular recall reminder payload. As described further below, this unique identifier may be used by the cloud server 58 to associate PWA interactions with the MCD 18 with a particular recall reminder, for example by referencing one or more records in the batch outreach collection 308.”).
In reference to claim 3:
Marantette further teaches: wherein to select the one or more prescription records that match the predetermined smart refill criteria comprises to select the one or more prescription records having a refill date within a predetermined number of days in the future from a current date (at least [0152] “ For example, the main server 14 may identify prescription records that have a refill date (e.g., the date the prescription was picked up plus the days supply of that prescription) that is a predetermined amount of time in the future (e.g., four days in the future). The prescription refill information may be provided to the cloud server 58 in a batch process. The cloud server 58 may load the prescription refill information into the batch outreach collection 308 or other data store maintained by the cloud server 58.”)
In reference to claim 4:
Marantette further teaches: wherein the memory further comprises instructions stored therein and executable by the processor to cause the processor to:
match each of the selected one or more prescription records with patient preference information from the customer collection (at least [fig 3 and related text] patient preferences table is matched to the patient, “For example, the cloud server 58 may maintain the patient preference table 306 indicating whether a patient has opted in to view prescription details.”; at [fig 6 and related text] “step 602, in which the main server 14 (e.g., the processor 46 of the main server 14) is operable to create a prescription transaction record. The prescription transaction record may be embodied as any database record or other data describing a prescription transaction originated by a patient, prescriber, or other entity. Thus, the prescription transaction record may include data indicative of a patient as well as one or more prescriptions associated with the patient. The prescription transaction may be embodied as one or more records or other data maintained by an enterprise pharmacy system (EPS) 202 maintained by the main server 1”);
determine whether automatic refill preferences are enabled for each of the selected one or more prescription records based on the matching patient preference information (at least [0108, 090] each prescription may have different opt in preferences for the prescription details including any information about the refill status, at [fig. 6/8 and related text] the preferences are collected from preferences 306; at [0152] “For example, the main server 14 may identify prescription records that have a refill date (e.g., the date the prescription was picked up plus the days supply of that prescription)” – i.e. automatic refills); and
set each of the selected one or more prescription records for which automatic refill preferences are enabled to be in cart (at least [fig 6 and related text] express checkout process adds refilled prescriptions to the cart for checkout based on the preferences; “ In step 614, the cloud server 58 provides a prescription shopping cart interface to the MCD 18. The shopping cart interface may provide information regarding the prescription transaction, including drug information, prices, ready time, and other status information. That prescription transaction information may be stored in the express cart collection 304 or other data storage maintained by the cloud server 58. In some embodiments, when providing the shopping cart interface, the cloud server 58 may mask protected health information (PHI) according to one or more user communications preferences associated with the patient. “ at [0152] “For example, the main server 14 may identify prescription records that have a refill date (e.g., the date the prescription was picked up plus the days supply of that prescription)” – i.e. automatic refills)).
In reference to claim 5:
Marantette further teaches: wherein the memory further comprises instructions stored therein and executable by the processor to cause the processor to:
receive a response to a retail outreach message, wherein the response is indicative of a first identifier associated with a corresponding one or more prescription records of the refill collection (at least [fig 13 and related text] step 1302 – user responds to message);
generate a progressive web application interface indicative of the corresponding one or more prescription records (at least [fig 13 and related text] “In step 1304, the cloud server 58 (e.g., the processor 60 of the cloud server 58) receives the text message from the MCD 18 and initiates the refill request process. The cloud server 58 may record the phone number or other identifier associated with the text message. In step 1306 the cloud server 58 responds to the MCD 18 with an enhanced message including a link to a refill request progressive web application (PWA). “); and
transmit the progressive web application interface to the mobile computing device (at least [fig 13 and related text] “The enhanced message may be sent via SMS or other messaging service to the phone number associated with the text message received in step 1304. Also as indicated above, the enhanced message includes a link such as a URI or URL that identifies the refill request PWA provided by the cloud server 58.”).
In reference to claim 6:
Marantette further teaches: wherein the memory further comprises instructions stored therein and executable by the processor to cause the processor to:
receive, from the mobile computing device, a personal identification number provided by a user of the mobile computing device (at least [fig 14 and related text] “ In step 1436, the MCD 18 receives a user selection of the PIN from the user of the MCD 18. To receive the user selection, the MCD 18 may display the PWA, web page, or other challenge interface received from the cloud server 58. The challenge interface may include one or more numeric entry fields or other user interface elements configured to receive the PIN from the user.”); and
verify the personal identification number using the customer collection (at least [fig 14 and related text] “In step 1438, the cloud server 58 compares the PIN response received from the MCD 18 to the PIN previously associated with the patient as described above. In step 1440, the cloud server 58 determines whether the PIN supplied by the MCD 18 matches the previously stored PIN.“);
wherein to transmit the progressive web application interface comprises to transmit the progressive web application interface in response to verification of the personal identification number (at least [fig 14 and related text] “ Referring back to step 1440, if the PIN supplied by the MCD 18 matches the previously stored PIN, the process 1400 advances to step 1444, in which the patient is successfully verified. After successful verification, the system 10 may proceed with the pending PWA (“progressive web application”) process or other process. For example, as described above, after successful verification, the process 600 may continue executing in step 614 of the process 600, in step 914 of the process 900, in step 1120 of the process 1100, in step 1214 of the process 1200, or otherwise continue executing.”).
In reference to claim 7:
Marantette further teaches: wherein the memory further comprises instructions stored therein and executable by the processor to cause the processor to:
receive a first request from the mobile computing device in response to transmission of the progressive web application interface, wherein the first request is indicative of a first prescription record of the corresponding one or more prescription records (at least [fig 13 and related text] 1302: send text message requesting refill);
send a refill request to a refill request application programming interface established by the enterprise pharmacy system in response to receipt of the first request (at least [fig 13 and related text] “n step 1320, the main server 14 processes the prescription refill request. For example, the main server 14 may submit the prescription refill request through an enterprise pharmacy system (EPS) 202 or other prescription management system. The main server 14 returns status information to the cloud server 58 indicating whether the prescription refill request was successful.”); and
send a response to the mobile computing device in response to sending of the refill request, wherein the response is indicative of a status returned by the application programming interface (at least [fig 13 and related text] “In step 1322, the cloud server 58 provides prescription refill status information to the MCD 18. The status information may indicate whether or not each requested prescription refill was successfully submitted. The status information may be sent to the MCD 18 as a PWA, a web page, or other user interface. In step 1324, the MCD 18 displays the prescription status information received from the cloud server 58.”).
In reference to claim 8:
Marantette further teaches: wherein the memory further comprises instructions stored therein and executable by the processor to cause the processor to:
receive a second request from the mobile computing device in response to transmission of the progressive web application interface, wherein the second request is indicative of an autofill configuration for the first prescription record (at least [fig 12 and related text, including 0152] “For example, the main server 14 may identify prescription records that have a refill date (e.g., the date the prescription was picked up plus the days supply of that prescription)” – i.e. automatic refills; at [fig 10 and related text] “n step 1010, the MCD 18 displays the request new time/cancel interface received from the cloud server 58. The MCD 18 may display the interface using a native web browser of the MCD 18. The interface may allow the user to select a new ready time for one or more prescriptions (e.g., “today after 5:00 p.m.,” “tomorrow,” or another requested time), to cancel one or more prescriptions, or to otherwise modify one or more prescriptions. “ – i.e. change date); and
update the dispensing history collection with the autofill configuration for the first prescription record (at least [fig 10 and related text] “In step 1012, the cloud server 58 updates one or more prescription data entries based on the change request received from the MCD 18. The cloud server 58 may, for example, update corresponding entries in the express cart collection 304. The cloud server 58 may also send the change request to the main server 14, and in step 1016 the main server 14 may update one or more prescription transaction records based on the change request. “).
In reference to claim 9:
Marantette further teaches: wherein the memory further comprises instructions stored therein and executable by the processor to cause the processor to:
receive a second request from the mobile computing device in response to transmission of the progressive web application interface, wherein the second request is indicative of a refill date change for the first prescription record (at least [fig 10 and related text] “The interface may allow the user to select a new ready time for one or more prescriptions (e.g., “today after 5:00 p.m.,” “tomorrow,” or another requested time… In step 1012, the MCD 18 receives a user selection such as a requested time change or a cancellation. The MCD 18 provides a response including the user selection to the cloud server 58.); and
update the first prescription record in the refill collection based on the refill date change (at least [fig 10 and related text] “In step 1012, the cloud server 58 updates one or more prescription data entries based on the change request received from the MCD 18… The cloud server 58 may also send the change request to the main server 14, and in step 1016 the main server 14 may update one or more prescription transaction records based on the change request. For example, the main server 14 may update one or more records in the EPS 202 or other data system maintained by the main server 14. The main server 14 may send one or more notifications or other updates to the retail outlet 22 associated with the prescription transaction. After updating the main server 14, the process 1000 is completed.”).
In reference to claim 10:
Marantette further teaches: wherein the memory further comprises instructions stored therein and executable by the processor to cause the processor to:
receive a second request from the mobile computing device in response to transmission of the progressive web application interface, wherein the second request is indicative of a cancelation of the first prescription record (at least [fig 10 and related text] “In step 1008, the cloud server 58 provides a request new time/cancel interface to the MCD 18. The cloud server 58 may provide the request new time interface as a PWA, a web page, or other interface... In step 1010, the MCD 18 displays the request new time/cancel interface received from the cloud server 58. The MCD 18 may display the interface using a native web browser of the MCD 18. The interface may allow the user to select a new ready time for one or more prescriptions (e.g., “today after 5:00 p.m.,” “tomorrow,” or another requested time), to cancel one or more prescriptions, or to otherwise modify one or more prescriptions. In step 1012, the MCD 18 receives a user selection such as a requested time change or a cancellation. The MCD 18 provides a response including the user selection to the cloud server 58.”);
remove the first prescription record from the refill collection based on the cancelation of the first prescription record (at least [fig 10 and related text] at step 1014, “update prescription data based on change request”); and
update the first prescription record in the dispensing history collection based on the cancelation of the first prescription record (at least [fig 10 and related text] “ In step 1012, the cloud server 58 updates one or more prescription data entries based on the change request received from the MCD 18…The cloud server 58 may also send the change request to the main server 14, and in step 1016 the main server 14 may update one or more prescription transaction records based on the change request. For example, the main server 14 may update one or more records in the EPS 202 or other data system maintained by the main server 14. The main server 14 may send one or more notifications or other updates to the retail outlet 22 associated with the prescription transaction. After updating the main server 14, the process 1000 is completed.”).
In reference to claim 11:
Marantette further teaches: wherein the memory further comprises instructions stored therein and executable by the processor to cause the processor to:
receive a second request from the mobile computing device in response to transmission of the progressive web application interface, wherein the second request is indicative of an approval of clinical review for the first prescription record (at least [fig 12 and related text] “The refill failure status may also include user interface elements requesting authorization to allow the pharmacy to contact the associated prescriber to request additional refills. Additionally or alternatively, the refill failure status may indicate that the prescriber has requested the patient to contact the prescriber directly to obtain additional refills…In step 1232, the MCD 18 displays the failure status information received from the cloud server 58 and may receive a user selection indicating whether the patient authorizes the pharmacy to request additional refills from the prescriber. The MCD 18 sends a response to the cloud server 58 including the user selection. In step 1234, the cloud server 58 determines whether the user authorized requesting additional refills from the prescriber.”); and
update the first prescription record in the dispensing history collection based on the approval of clinical review (at least [fig 12 and related text] “ If the user authorizes additional refills, the process 1200 branches to step 1236, in which the main server 14 processes the prescription refill request with a parameter indicating that requesting additional refills is authorized. For example, the main server 14 may submit the prescription refill request through the EPS 202 or other prescription management system as described above. The main server 14 returns status information to the cloud server 58 indicating whether the prescription refill requests were successful, and the process loops back to step 1222 to provide refill status as described above.” See also update process at [fig 10 and related text]).
In reference to claim 13:
Marantette further teaches: wherein the memory further comprises instructions stored therein and executable by the processor to cause the processor to:
authenticate a patient using a mobile computing device based on authentication information associated with the patient in a patient data collection (at least [fig 15 and related text] “the process 1500 advances to step 1522, in which the cloud server 58 generates a two-factor authentication code. The two-factor authentication code may be embodied as a random numeric code or any other random code. The cloud server 58 sends the two-factor authentication code to a mobile phone number associated with the patient using a text messaging service….In step 1524, the MCD 18 associated with the patient receives and displays the message including the two-factor authentication code. The two-factor authentication code may be displayed, for example, using the native messaging application 406 provided by the MCD 18. In step 1526, the MCD 18 receives a user selection including the two-factor authentication code. The user selection may be received, for example, using a PWA received from the cloud server 58 and executed by the native web browser of the MCD 18…In step 1528, the cloud server 58 compares the user selection received from the MCD 18 to the two-factor authentication code determined as described above in connection with step 1522. In block 1530, the cloud server 58 determines whether the authentication codes match.”);
select one or more prescription records associated with the patient from the dispensing history in response to authenticating the patient (at least [fig 15 and related text] “In step 1534, the cloud server 58 provides an immunization appointment message to the MCD 18. Before sending the message, the cloud server 58 may update the immunization collection 316, the patient lookup table 318, and/or or other data tables to indicate that an immunization request has been processed. “);
generate a progressive web application interface indicative of the selected one or more prescription records (at least [fig 15 and related text] “The immunization appointment message may include a link to an immunization appointment PWA.” See also [fig 16 and related text for PWA/progressive web application discussion); and
transmit the progressive web application interface to the mobile computing device (at least [fig 15 and related text] “ In step 1534, the cloud server 58 provides an immunization appointment message to the MCD 18.”).
In reference to claim 14:
Marantette further teaches: wherein to generate the progressive web application interface comprises to:
determine whether the patient privacy protection is enabled for the patient based on the customer collection (at least [fig 3, 8 and related text] “ For example, the cloud server 58 may update the patient preferences table 306 with the user selection. The patient preference table 306 may indicate whether the user has affirmatively enrolled in receiving detailed prescription information or whether the user has affirmatively opted out. “ – at step 816-818, patient preferences including masking preferences); and
mask patient privacy information of the selected one or more prescription records in response to a determination that patient privacy protection is enabled (at least [fig 3, 8 and related text] “ In step 812, the cloud server 58 masks protected health information (PHI) based on patient communication preferences. For example, the cloud server 58 may maintain the patient preference table 306 indicating whether a patient has opted in to view prescription details. If the patient has not opted in to viewing prescription details (e.g., the user has not yet responded or has affirmatively declined viewing details), the cloud server 58 may hide or obfuscate prescription details such as drug name, prescription number, written date, last filled date, or other information that could include PHI. After retrieving and potentially masking the prescription details information, the cloud server 58 sends the prescription details to the MCD 18 as a PWA or web page. In step 814, the MCD 18 displays the prescription details received from the cloud server 58”).
In reference to claim 15:
Marantette further teaches: wherein the memory further comprises instructions stored therein and executable by the processor to cause the processor to: receive identification information from the mobile computing device (at least [fig 15 and related text] “In step 1518, the MCD 18 receives a user selection including patient identification information. The MCD 18 sends a response to the cloud server 58 including the user selection.” See also [fig 7 and related text] for discussion of verification) ; and
select the patient from the patient data collection with the identification information (at least [fig 15 and related text] “In step 1520, the cloud server 58 verifies the patient information provided by the MCD 18. The cloud server 58 may, for example, look up patient records in a patient lookup table 318 that match the identifying information provided by the MCD 18. The patient lookup table 318 may be initially populated with patient data provided by the main server 14 or otherwise extracted from the enterprise pharmacy system (EPS) 202.”);
wherein to authenticate the patient comprises to authenticate the patient in response to selection of the patient (at least [fig 15 and related text] step 1520 authenticates the user based on the lookup information – “Thus, the cloud server 58 may verify the identity of the patient without requiring the patient to create an online account. The cloud server 58 may also verify additional information associated with the patient, “).
In reference to claim 16:
Marantette further teaches: wherein the memory further comprises instructions stored therein and executable by the processor to cause the processor to:
generate a landing page web application based on a predetermined configuration, wherein the landing page is indicative of the progressive web application interface (at least [057] “The term “progressive web application” or “PWA” is to be understood in accordance with its ordinary meaning; that is, a progressive web application (PWA) is a website that looks and behaves, with respect to a mobile communication device such as an MCD 18, as if it is a native mobile application running on the mobile device…Thus, each PWA described herein may be embodied as a web application or web page that is executable via the MCD 18. Each PWA may appear to the user of the MCD 18 to look and operate similarly to a native application, but as a web application, the PWA does not need to be independently installed prior to execution. “) at [0231-0233] “Illustratively, the link may identify a landing page or other entry point associated with a two-way communication PWA.” PWA is configured based on configuration table 312); and
transmit the landing page web application to the mobile computing device (at least [057, 0231-0233 as noted above] “Illustratively, the link may identify a landing page or other entry point associated with a two-way communication PWA.”)
wherein to receive the identification information comprises to receive the identification information in response to transmission of the landing page web application (at least [0233] “Potential interaction flows may be configured for business processes including communication consent, add credit card, transfer follow-up, call back needed, PA submission, PA response, support program, service confirmation, welcome packet, privacy practice notice, transaction audit signature, HIPAA signature collect, Medicare open enrollment, or other processes. In particular, one or more of the processes described above, such as the immunization process 1600 shown in FIG. 16, may be implemented using dynamic two-way communication as described herein.”).
In reference to claim 17:
Marantette further teaches: wherein the predetermined configuration is indicative of a plurality of application entry points, wherein each application entry point comprises an application name, an address, and an interface configuration (at least [0231-235] configuration table 312 provides the types of applications and appropriate information for a given entry point).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Marantette.
In reference to claim 12:
Marantette further discloses wherein the memory further comprises instructions stored therein and executable by the processor to cause the processor to:
receive a second request from the mobile computing device in response to transmission of the progressive web application interface, wherein the second request is indicative of a change in refill [information] for the first prescription record (at least [fig 10 and related text] “In step 1008, the cloud server 58 provides a request new time/cancel interface to the MCD 18. The cloud server 58 may provide the request new time interface as a PWA, a web page, or other interface... In step 1010, the MCD 18 displays the request new time/cancel interface received from the cloud server 58. The MCD 18 may display the interface using a native web browser of the MCD 18. The interface may allow the user to select a new ready time for one or more prescriptions (e.g., “today after 5:00 p.m.,” “tomorrow,” or another requested time), to cancel one or more prescriptions, or to otherwise modify one or more prescriptions. In step 1012, the MCD 18 receives a user selection such as a requested time change or a cancellation. The MCD 18 provides a response including the user selection to the cloud server 58.”);
remove the first prescription record from the refill collection based on the change in refill [information] (at least [fig 10 and related text] at step 1014, “update prescription data based on change request”); and
initiate a transfer process with the enterprise pharmacy system based on the change in refill [information] (at least [fig 10 and related text] “ In step 1012, the cloud server 58 updates one or more prescription data entries based on the change request received from the MCD 18…The cloud server 58 may also send the change request to the main server 14, and in step 1016 the main server 14 may update one or more prescription transaction records based on the change request. For example, the main server 14 may update one or more records in the EPS 202 or other data system maintained by the main server 14. The main server 14 may send one or more notifications or other updates to the retail outlet 22 associated with the prescription transaction. After updating the main server 14, the process 1000 is completed.”).
Marantette further teaches wherein the location of a pharmacy pickup may be changed at [0170] “In some embodiments, the prescription refill interface may also include a store finder interface that may be used to identify a particular retail outlet 22, for example based on address or other geographic location. The cloud server 58 may provide the available prescription refill as part of a PWA, a web page, or other interface to the MCD 18.”, [0202] “In step 1512, the MCD 18 receives a user selection of a store location. The MCD 18 may receive the user selection in response to displaying a store finder interface received from the cloud server 58. The user may identify a particular retail outlet 22, for example using address or other geographic information. The MCD 18 sends a response including the user selection of the store location to the cloud server 58. In step 1514, the cloud server 58 looks up a store location based on the user selection. The cloud server 58 may, for example, look up a store number or other identification in a store lookup table.”
As a user in Marantette could themselves enter a modification for a prescription pickup, the system would then remove the prescription based on the user’s choices, and save/update the record internally, and as the same user in Marantette could also select the pickup location from among a plurality of locations, it would have been obvious to one of ordinary skill in the art that the user in Marantette could initiate a change in location pickup, and the system would perform in the same manner as far as removing a prescription and saving the changes internally.
Relevant Prior Art
The following prior art not relied upon is made of record:
US 20150058034, to Ayshford, discloses a means of bundling user preferences with prescription pickups.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KATHERINE KOLOSOWSKI-GAGER whose telephone number is (571)270-5920. The examiner can normally be reached Monday - Friday.
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, Mamon Obeid can be reached at 571-270-1813. 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.
/KATHERINE . KOLOSOWSKI-GAGER/
Primary Examiner
Art Unit 3687
/KATHERINE KOLOSOWSKI-GAGER/Primary Examiner, Art Unit 3687