DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Application
This action is in reply to the reply received January 22, 2026 (hereinafter “Reply”).
Claims 1, 4, 12-15, 17, and 19 are amended.
Claims 2, 3, and 16 are cancelled.
Claims 1, 4-15, and 17-20 are pending.
Claim Rejections - 35 U.S.C. § 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, 4-15, and 17-20 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter. Claims 1, 4-15, and 17-20 are directed to an abstract idea without significantly more as required by the Alice test as discussed below.
Step 1
Claims 1, 4-15, and 17-20 are directed to a process, machine, manufacture, or composition of matter.
Step 2A
Claims 1, 4-15, and 17-20 are directed to abstract ideas, as explained below.
Prong one of the Step 2A analysis requires identifying the specific limitation(s) in the claim under examination that the examiner believes recites an abstract idea; and determining whether the identified limitation(s) falls within at least one of the groupings of abstract ideas of mathematical concepts, mental processes, and certain methods of organizing human activity.
The claims recite the following limitations that are directed to abstract ideas. Claim 1 recites a method for selecting a plurality of medical supplies from a plurality of suppliers for a patient, based on medical condition and measurements of the patient, the method comprising: receiving heterogenous data relating to medical supplies from a plurality of third-party medical suppliers; converting the third-party suppliers heterogenous data into a predetermined data format by mapping a plurality of attributes of third-party medical supplies heterogeneous data to a respective attribute of the predetermined format; storing the converted data in a data source combining the medical supplies of the third-party medical suppliers; inputting patient data, the patient data comprising prescription data associated with the medical condition of the patient and anatomical data in relation with one or more body portion relating to the prescription data; generating a patient filter object comprising rules for selecting a plurality of medical supplies from the data source of medical supplies fitting the medical condition of the patient associated with the inputted prescription data of the patient; storing the patient filter object; generating a list of a plurality of medical supplies stored in the data source which only match all of the rules of the generated patient filter object; and communicating the medical supplies associated with the filter upon receiving a request. Claim 12 recites similar features as claim 1. Claims 4-11, 13-15, and 17-20 further specify features of the abstract ideas or characteristics of the data used thereby.
These limitations describe abstract ideas that correspond to concepts identified as abstract ideas by the courts as mental processes—such as concepts performed in the human mind (including an observation, evaluation, judgment, or opinion)—because the claimed features identified above (besides the communicating step) are concepts performed in the human mind (including an observation, evaluation, judgment, or opinion).
These limitations describe abstract ideas that correspond to concepts identified as abstract ideas by the courts as certain methods of organizing human activity—such as fundamental economic principles or practices (including hedging, insurance, mitigating risk), commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions)—because the claim features identified above a (1) commercial or legal interactions including advertising, marketing or sales activities or behaviors and (2) manage personal behavior or relationships or interactions between people including following rules or instructions.
Thus, the concepts set forth in claims 1, 4-15, and 17-20 recite abstract ideas.
Prong two of the Step 2A requires identifying whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluating those additional elements to determine whether they integrate the exception into a practical application of the exception. “Integration into a practical application” requires an additional element or a combination of additional elements in the claim to apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. Further, “integration into a practical application” uses the considerations laid out by the Supreme Court and the Federal Circuit to evaluate whether the judicial exception is integrated into a practical application, such as considerations discussed in M.P.E.P. § 2106.05(a)-(h).
The claims recite the following additional elements beyond those identified above as being directed to an abstract idea. Claim 1 recites that its method is computer-implemented, a server, third-party medical suppliers, a computerized device, and communicating data between the devices. Claim 12 recites similar features as claim 1 and further recites a system, several software modules and other software implementors (e.g., handlers), a browser configured to display information, and interfaces that receive inputs or data. Claim 13 recites a browser simulator. Several of the dependent claims also recite communicating data between the devices (e.g., by receiving data from third-party systems).
The identified judicial exception(s) are not integrated into a practical application for the following reasons.
First, evaluated individually, the additional elements do not integrate the identified abstract ideas into a practical application. The additional computer elements identified above—the computer, system, server, computerized device, simulator, browser, third-party medical suppliers/systems, software/software modules, interfaces, and simulator—are recited at a high level of generality. Inclusion of these elements amounts to mere instructions to implement the identified abstract ideas on a computer. See M.P.E.P. § 2106.05(f). The use of conventional computer elements to communicate data between the devices (e.g., by displaying information or receiving inputs) is the insignificant, extra-solution activity of mere data gathering or outputting in conjunction with a law of nature or abstract idea. See M.P.E.P. § 2106.05(g). To the extent that the claims transform data (e.g., converting or transforming data according to rules or mappings), the mere manipulation of data is not a transformation. See M.P.E.P. § 2106.05(c). Inclusion of computing system in the claims amounts to generally linking the use of the judicial exception to a particular technological environment or field of use. See M.P.E.P. § 2106.05(h). Thus, taken alone, the additional elements do not amount to significantly more than a judicial exception.
Second, evaluating the claim 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. See M.P.E.P. § 2106.05(a). Their collective functions merely provide an implementation of the identified abstract ideas on a computer system in the general field of use of online medical supply management. See M.P.E.P. § 2106.05(h).
Thus, claims 1, 4-15, and 17-20 recite mathematical concepts, mental processes, or certain methods of organizing human activity without including additional elements that integrate the exception into a practical application of the exception.
Accordingly, claims 1, 4-15, and 17-20 are directed to abstract ideas.
Step 2B
Claims 1, 4-15, and 17-20 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements, when considered both individually and as an ordered combination, do not amount to significantly more than the abstract idea.
The analysis above describes how the claims recite the additional elements beyond those identified above as being directed to an abstract idea, as well as why identified judicial exception(s) are not integrated into a practical application. These findings are hereby incorporated into the analysis of the additional elements when considered both individually and in combination. Additional features of these analyses are discussed below.
Evaluated individually, the additional elements do not amount to significantly more than a judicial exception. In addition to the factors discussed regarding Step 2A, prong two, these additional computer elements also provide conventional computer functions that do not add meaningful limits to practicing the abstract idea. Generic computer components recited as performing generic computer functions that are well-understood, routine and conventional activities amount to no more than implementing the abstract idea with a computerized system. The use of generic computer components to communicate data between the devices (e.g., by displaying information or receiving inputs) is the well-understood, routine, and conventional computer functions of receiving or transmitting data over a network, e.g., the Internet, and does not impose any meaningful limit on the computer implementation of the identified abstract ideas. See M.P.E.P. § 2106.05(d)(II). Thus, taken alone, the additional elements do not amount to significantly more than a judicial exception.
Evaluating the claim limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. In addition to the factors discussed regarding Step 2A, prong two, there is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely amount to mere instructions to implement the identified abstract ideas on a computer.
Thus, claims 1, 4-15, and 17-20, taken individually and as an ordered combination of elements, are not directed to eligible subject matter since they are directed to an abstract idea without significantly more.
Claim Rejections - 35 U.S.C. § 102
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.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 4, 5 and 8-10 are rejected under 35 U.S.C. § 102(a)(2) as being anticipated by Roh et al. (U.S. Pub. No. 2023/0104580 A1) (hereinafter “Roh”).
Claim 1: Roh, as shown, discloses the following limitations:
A computer-implemented method for selecting a plurality of medical supplies from a plurality of suppliers for a patient, the selected medical supplies being based on medical condition and measurements of the patient (see at least ¶ [0131]: FIG. 6 is a block diagram illustrating an example robotic surgical system for customized kit assembly for surgical implants, in accordance with one or more embodiments. The implantation of surgical implants or surgical implant components is sometimes referred to as “insertion” or “installation.” Surgical implants are sometimes referred to as “implants.” Surgical implant components are sometimes referred to as “implant components.” The system of FIG. 6 includes at least one surgical robot 602 a, databases and modules that can be implemented in the cloud 620, and at least one surgical implant 616. The surgical robot 602 is the same as or similar to the surgical robot 440 illustrated and described in more detail with reference to FIG. 4A. The system is implemented using the components of the example computer system 300 illustrated and described in more detail with reference to FIG. 3. Likewise, embodiments of the system can include different and/or additional components or can be connected in different ways; see also at least ¶ [0138]: the implant components 618 a are generic, off-the-shelf implant components while the implant components 618 b are implant components that can be or have been modified or customized for a particular patient using the embodiment described herein. The surgical implant 616 can be a single piece or can include multiple surgical implant components 618. Surgical implants that include multiple implant components 618 can alternatively be referred to as assemblies. The implants 616 can be customized to fit a particular patient or a specific application that the implant 616 is intended for. For example, the implant 616 can include biological donor tissues or biosynthetic tissues such as can be used in operations such as organ transplant, skin graft, or other tissue installation or replacement. In other examples, the implant 616 can be any of multiple implantable medical devices, e.g., cardiac pacemakers, electric neurological stimulation devices such as vagus nerve stimulators or deep brain stimulators, blood glucose monitors, insulin pumps, etc.; see also at least ¶¶ [0091]-[0098] and [0172]; see also at least ¶ [0142]: the inventory database 630 can additionally include data on third party vendors including manufacturing capabilities and information necessary to order a custom implant component 618 b. The inventory database 630 can include information about tools, instruments, and other equipment associated with surgical procedures), the method comprising:
a server receiving heterogenous data relating to medical supplies from a plurality of third-party medical suppliers (see at least ¶ [0142]: the inventory database 630 can additionally include data on third party vendors including manufacturing capabilities and information necessary to order a custom implant component 618 b. The inventory database 630 can include information about tools, instruments, and other equipment associated with surgical procedures; see also at least ¶ [0153]: the inventory database 630 can also contain the manufacturing capabilities and order information for third party vendors in order to enable ordering of custom implant components 618 b from third party sources; see also at least ¶ [0158]: the assembly module 624 orders a compatible generic component 618 a that is not immediately available according to the inventory database 630. For example, the implant component 618 b is a screw requiring a casting of titanium and such capabilities are unavailable on site. Thus, the assembly module 624 orders the screw from a third-party vendor; see also at least ¶ [0159]);
the server automatically converting the third-party medical suppliers heterogeneous data into a predetermined electronic data format by mapping a plurality of attributes of third-party medical supplies heterogeneous data to a respective attribute of the predetermined electronic format (see at least ¶¶ [0142], [0153], and [0158]-[0159] and the analysis above. The data is heterogenous because it corresponds to inventory or capabilities not available locally; see also at least ¶¶ [0155] and [0165]);
storing the converted data in a data source combining the medical supplies of the third-party medical suppliers (see at least ¶¶ [0142], [0153], [0155], [0158]-[0159], and [0165] and the analysis above);
inputting patient data into the server, the patient data comprising prescription data associated with the medical condition of the patient and anatomical data in relation with one or more body portion relating to the prescription data (see at least ¶ [0141]: one or more processors generate an implantation plan comprising implantation parameters for controlling insertion of the customized version of the surgical implant 616 into a particular patient's body by the surgical robot 602 of the surgical system of FIG. 6 . For example, the planning module 626 images the patient using at least one imaging device 614 and generates the implantation plan. The implantation plan includes a design of the implant 616 and implant placement within a virtual model of a portion of a patient's anatomy or body generated from the images acquired of the patient. The planning module 626 further generates tool paths and implantation parameters to be used during insertion of the implant 616. The optimization module 628 receives information describing an initial implant component 618 a from the assembly module 624. The information can be generated by the planning module 622; see also at least ¶ [0144]: the data includes the designs and placement of previous implants, previous tool paths used during implantation procedures, and previous patient information such as gender, age, height, weight, medical conditions, patient medical history, patient family medical history, allergies, or vital information such as baseline measurements of heart rage, blood pressure, blood oxygen saturation, or respiration rate; see also at least ¶¶ [0131], [0138], [0145], [0152], and [0173]; see also at least ¶ [0122]: the display module 522 can be configured to convert and transmit processing parameters, sensor readings 526, output signals 528, input data, treatment profiles and prescribed operational parameters);
the server generating a patient filter object comprising rules for selecting a plurality of medical supplies from a data source of medical supplies fitting the medical condition of the patient associated with the inputted prescription data of the patient (see at least ¶ [0142]: one or more processors of the surgical system of FIG. 6 design a customized version of the surgical implant 616 using patient data describing a particular patient's anatomy or body, a treatment or particular medical application, and the implant database 622. The customized version of the surgical implant 616 comprises at least the generic surgical implant component 618 a and the customized surgical implant component 618 b. The customized surgical implant component 618 b is for the particular patient and the treatment or particular medical application. For example, the optimization module 628 uses data from the implant database 622 to customize the implant component 618 b to the patient. An inventory database 630 stores data describing a stock of generic implant components 618 a. The implant components 618 a can include any of screws, rods, plates, or commercially available implant components. In some embodiments, one or more processors of the system of FIG. 6 determine absence of the customized surgical implant component 618 b in an inventory. The one or more processors cause manufacture of the customized surgical implant component 618 b in response to determining the absence in the inventory. For example, the inventory database 630 can additionally include manufacturing capabilities to determine whether an implant component 618 can be manufactured. The inventory database 630 can additionally include data on third party vendors including manufacturing capabilities and information necessary to order a custom implant component 618b. The inventory database 630 can include information about tools, instruments, and other equipment associated with surgical procedures; see also at least ¶ [0143]: a path is generated for a surgical tool 154 in a virtual model of the patient's anatomy or body to virtually insert the customized version of the surgical implant 616 in the virtual model. A virtual robotic surgical procedure is performed according to the implantation plan to virtually insert a model of the customized version of the surgical implant 616 at an implantation site. One or more surgical steps of the implantation plan are simulated using a three-dimensional (3D) model generated using real-time patient data; see also at least ¶ [0147]: the assembly module 624 receives patient data such as gender, age, height, weight, allergies, current or prior medical conditions, or any additional clinical information that can impact the outcome of the surgical procedure. The assembly module 624 further acquires vital information such as the patient's blood pressure, heart rate, blood oxygen saturation, respiration rate, etc. Baseline vital information can be accessed from the clinical information or measured directly; see also at least ¶¶ [0144]-[0145], [0165], and [0174]);
storing the patient filter object (see at least ¶ [0152]: assembly module 624 receives information describing a customized implant component 618 b from the optimization module 628. The implant component 618 b can be modified by the optimization module 628 using patient data and data from previously inserted implants 616 from the implant database 622 to better accommodate the patient’s physiology including allergies and medical conditions; see also at least ¶ [0153]: the assembly module 624 queries the inventory database 630 for a stock of generic or otherwise in-stock implant components 618 a. In an embodiment, the in-stock generic implant components 618 a include screws of various sizes ranging from 0.5 inches to 3 inches having a range of standard and metric threads with tulip heads and traditional rounded star heads. The screws can alternatively be comprised of proprietary designs. The inventory database 630 can additionally include an inventory of rods and plates. The rods can be available in a range of diameters and lengths and the plates can similarly be available in a range of dimensions and can have holes and other features to accept screws and other hardware. The implant components 618 a can additionally be available in a range of materials such as surgical stainless steel and titanium or alloys. The inventory database 630 can also contain the manufacturing capabilities and order information for third party vendors in order to enable ordering of custom implant components 618 b from third party sources; see also at least ¶ [0154]: in step 816, the assembly module 624 determines whether the customized implant component 618 b matches an implant component 618 a in stock according to the inventory database 630. A matching implant component 618 a can be an exact match or can match required design parameters while not necessarily matching optional design parameters; see also at least ¶¶ [0159]-[0161] and [0165]-[0166]);
the server automatically generating a list of a plurality of the medical supplies stored in the data source which only match all of the rules of the generated patient filter object (see at least ¶¶ [0152]-[0153] and the analysis above; see also at least ¶ [0154]: in step 816, the assembly module 624 determines whether the customized implant component 618 b matches an implant component 618 a in stock according to the inventory database 630. A matching implant component 618 a can be an exact match or can match required design parameters while not necessarily matching optional design parameters; see also at least ¶¶ [0159]-[0161] and [0165]-[0166]);
communicating to a computerized device of the patient the medical supplies of the generated list upon receiving a request from the said computerized device of the patient (see at least ¶ [0157]: The optimization module 628 can generate parameters, dimensions, and/or instructions or files for manufacturing items, such as customized implant components 618 b. In some embodiments, the optimization module 628 generates a three-dimensional model of the customized implant component 618 b that is transmitted to an onsite or offsite manufacturing system. Example manufacturing system can include, without limitation, one or more printers (e.g., additive manufacturing printers), milling machines, molding machines, lathes, extruders, and/or other manufacturing equipment disclosed herein. In some embodiments, the optimization module 628 generates three-dimensional CAD or CAM models that are transmitted to the manufacturing system. The manufacturing system can determine manufacturing instructions executable to manufacture the customized implant component 618 b. In some embodiments, the optimization module 628 generates and send machine executable instructions to instruct the manufacturing equipment to produce the customized implant component 618 b; see also at least ¶ [0171]: The system can receive data before and/or during the surgical procedure and can use received data to, for example, recommend, design (pre-operatively and/or intra-operatively design), and/or provide components, implants, instructions, and/or kit assemblies; see also at least ¶ [0112]: the user and surgical team can review the proposed surgical plans to select an appropriate surgical plan. The robotic surgical system 400 can modify a surgical plan with one or more corrective surgical steps based on identified surgical complications, sensor readings, or the like; see also at least ¶ [0117]: the physician can review the virtual simulations to accept or reject the recommended surgical plan. The physician can modify surgical plans pre-operatively or intraoperatively. Kits (e.g., pre-operative kits, intraoperative kits, etc.) can be modified or provided based on the modification; see also at least ¶ [0163]: the assembly module 624 terminates the kit assembly when all implant components 618 and tools in the implantation plan have been selected, customized, and added to the kit; see also at least ¶ [0170]).
Claim 4: Roh discloses the limitations as shown in the rejections above. Further, Roh, as shown, discloses the following limitations:
wherein inputting the prescription data comprising inputting a date of a prescription, a disease, an anatomical region or portions of the body being treated, dimensions of the anatomical region and treatment indications (see at least ¶ [0076]: the EHR database 106 includes a digital record of patients’ health information, collected and stored systematically over time. The EHR database 106 can include demographics, medical history, history of present illness (HPI), progress notes, problems, medications, vital signs, immunizations, laboratory data, or radiology reports. Software (in memory 164) operating on the console 108 or implemented on the example computer system 300 (e.g., the instructions 304, 308 illustrated and described in more detail with reference to FIG. 3 ) are used to capture, store, and share patient data in a structured way. The EHR database 106 can be created and managed by authorized providers and can make health information accessible to authorized providers across practices and health organizations, such as laboratories, specialists, medical imaging facilities, pharmacies, emergency facilities, etc. The timely availability of EHR data enables healthcare providers to make more accurate decisions and provide better care to the patients by effective diagnosis and reduced medical errors. Besides providing opportunities to enhance patient care, the EHR database 106 can also be used to facilitate clinical research by combining patients’ demographics into a large pool. For example, the EHR database 106 can support a wide range of epidemiological research on the natural history of disease, drug utilization, and safety, as well as health services research; see also at least ¶ [0109]: the robotic surgical system 400 can autonomously perform steps, the surgical team can provide information in real-time that is used to continue the surgical procedure. The information can include physician input, surgical team observations, and other data input; see also at least ¶ [0112]: the robotic surgical system 400 can monitor hospital or on-site inventory, available resources in the surgical room 402, time to acquire equipment (e.g., time to acquire replacement end effectors, surgical tools, or other equipment), and other information to determine how to proceed with surgery. The robotic surgical system 400 can generate multiple proposed surgical plans for continuing with the surgical procedure. The user and surgical team can review the proposed surgical plans to select an appropriate surgical plan. The robotic surgical system 400 can modify a surgical plan with one or more corrective surgical steps based on identified surgical complications, sensor readings, or the like; see also at least ¶¶ [0143] and [0171]).
Claim 5: Roh discloses the limitations as shown in the rejections above. Further, Roh, as shown, discloses the following limitations:
the input of the prescription data being performed by a healthcare professional (see at least ¶ [0171]: the healthcare provider schedules surgical procedures based on a manufacturing schedule for patient-sized components, the patient conditions, or other input parameters. Manufacturing schedules can be modified based on the priority of the conditions of the scheduled patients; see also at least ¶ [0109]: advantageously, complicated procedures can be autonomously performed without user intervention to enable the surgical team to focus and attend to other tasks. Although the robotic surgical system 400 can autonomously perform steps, the surgical team can provide information in real-time that is used to continue the surgical procedure. The information can include physician input, surgical team observations, and other data input.).
Claim 8: Roh discloses the limitations as shown in the rejections above. Further, Roh, as shown, discloses the following limitations:
a healthcare professional adding or removing one or more medical supplies to the generated filter associated with the patient data (see at least ¶ [0112]: the user and surgical team can review the proposed surgical plans to select an appropriate surgical plan. The robotic surgical system 400 can modify a surgical plan with one or more corrective surgical steps based on identified surgical complications, sensor readings, or the like; see also at least ¶ [0117]: the physician can review the virtual simulations to accept or reject the recommended surgical plan. The physician can modify surgical plans pre-operatively or intraoperatively. Kits (e.g., pre-operative kits, intraoperative kits, etc.) can be modified or provided based on the modification; see also at least ¶ [0163]: the assembly module 624 terminates the kit assembly when all implant components 618 and tools in the implantation plan have been selected, customized, and added to the kit; see also at least ¶ [0170]; see also at least ¶ [0109]).
Claim 9: Roh discloses the limitations as shown in the rejections above. Further, Roh, as shown, discloses the following limitations:
the automatic matching of a plurality of medical supplies from a data source of medical supplies further comprising matching medical supplies only fitting stored patient anatomical dimensions and fulfilling the prescription data of the patient (see at least ¶ [0142]: one or more processors of the surgical system of FIG. 6 design a customized version of the surgical implant 616 using patient data describing a particular patient's anatomy or body, a treatment or particular medical application, and the implant database 622. The customized version of the surgical implant 616 comprises at least the generic surgical implant component 618 a and the customized surgical implant component 618 b. The customized surgical implant component 618 b is for the particular patient and the treatment or particular medical application. For example, the optimization module 628 uses data from the implant database 622 to customize the implant component 618 b to the patient. An inventory database 630 stores data describing a stock of generic implant components 618 a. The implant components 618 a can include any of screws, rods, plates, or commercially available implant components. In some embodiments, one or more processors of the system of FIG. 6 determine absence of the customized surgical implant component 618 b in an inventory. The one or more processors cause manufacture of the customized surgical implant component 618 b in response to determining the absence in the inventory. For example, the inventory database 630 can additionally include manufacturing capabilities to determine whether an implant component 618 can be manufactured. The inventory database 630 can additionally include data on third party vendors including manufacturing capabilities and information necessary to order a custom implant component 618b. The inventory database 630 can include information about tools, instruments, and other equipment associated with surgical procedures; see also at least ¶ [0143]: a path is generated for a surgical tool 154 in a virtual model of the patient's anatomy or body to virtually insert the customized version of the surgical implant 616 in the virtual model. A virtual robotic surgical procedure is performed according to the implantation plan to virtually insert a model of the customized version of the surgical implant 616 at an implantation site. One or more surgical steps of the implantation plan are simulated using a three-dimensional (3D) model generated using real-time patient data; see also at least ¶ [0147]: the assembly module 624 receives patient data such as gender, age, height, weight, allergies, current or prior medical conditions, or any additional clinical information that can impact the outcome of the surgical procedure. The assembly module 624 further acquires vital information such as the patient's blood pressure, heart rate, blood oxygen saturation, respiration rate, etc. Baseline vital information can be accessed from the clinical information or measured directly; see also at least ¶¶ [0144]-[0145], [0165], and [0174]).
Claim 10: Roh discloses the limitations as shown in the rejections above. Further, Roh, as shown, discloses the following limitations:
sending an electronic message to a computerized device of the patient prior to a predetermined duration before the selected medical supply of the patient has to be renewed to ensure an adequate treatment (see at least ¶ [0139]: generate a voucher for the customer user within the user interface for the purchased service that can be utilized by the customer user to redeem the purchase and receive the service from the corresponding physician specified for each of the services of the bundled set of services (the providers of marketplace system 100 can have pre-arranged agreements with providers registered with the system that the providers will agree to honor such vouchers generated by purchasing server 126 for purchased services). An example of such a voucher for a bundled set of services is illustrated in FIG. 4B. As depicted in the example, example voucher 400 can be generated to include identifying information for the customer user 402, identifying and contact information for each physician specified for a service and any facility included in the offered service 404, a description of each service of the purchased service 406, a confirmation number 408 for the purchase, which may be generated by purchasing server 126 based on the unique transaction identifier that is included in the respective information record for the purchase that is maintained within transaction information database 114 k, and instructions for redeeming the voucher 410. The confirmation number (or any other suitable redemption information such as a one or two dimensional bar code, a QR code, or any other form of machine readable information) may also be provided in the electronic confirmation message to the customer user and electronic notifications to the physician user that will be performing the service and the provider user for the offered service sent by purchasing system 126 to the customer user. The voucher can be presented to the user within the user interface, for example, as printable and/or machine readable form; see also at least ¶¶ [0133], [0245], and [0261]).
Claim Rejections - 35 U.S.C. § 103
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 6, 7, 12-15, and 17-19 are rejected under AIA 35 U.S.C. § 103 as being unpatentable over Roh et al. (U.S. Pub. No. 2023/0104580 A1) (hereinafter “Roh”) in view of Ketchel et al. (U.S. Pub. No. 2021/0209664 A1) (hereinafter “Ketchel”).
Claim 6: Roh discloses the limitations as shown in the rejections above. Further, Roh, as shown, discloses the following limitations:
[…] selecting one or more of the communicated medical supplies of the filter and ordering the said selected medical supplies (see at least ¶ [0142]: the inventory database 630 can additionally include data on third party vendors including manufacturing capabilities and information necessary to order a custom implant component 618 b. The inventory database 630 can include information about tools, instruments, and other equipment associated with surgical procedures; see also at least ¶ [0158]: the assembly module 624 can order a custom implant component 618 b if the manufacturing capabilities required to manufacture the implant component 618 b do not exist on site. Similarly, the assembly module 624 orders the custom implant component 618 b if there is insufficient stock of raw materials on site. The assembly module 624 orders a compatible generic component 618 a that is not immediately available according to the inventory database 630. For example, the implant component 618 b is a screw requiring a casting of titanium and such capabilities are unavailable on site. Thus, the assembly module 624 orders the screw from a third-party vendor; see also at least ¶ [0153]).
Roh does not explicitly disclose that the patient selects and orders the medical supplies. However, Ketchel, as shown, discloses
the patient selecting one or more of the communicated medical supplies of the filter and ordering the said selected medical supplies (see at least ¶ [0121]: FIG. 3B is a screen shot illustrating an example of a GUI provided by a search result listing page 310 for customer portal 120 that presents a list of providers offering the service specified within search entry field 304 within a default search radius (for example, 50 miles) of the location specified within location entry field 306 returned in the search conducted by navigation and search service 124. In the illustrated example, search result listing page 310 includes a result listing section 311, a result filtering section 316, and a result sorting section 318. Result filtering section 316 provides various user interface controls for refining the results of the search presented within result listing section 311 by modifying the search criteria or inputting additional search criteria. In the illustrated example, result filtering section; see also at least ¶ [0122]: each entry for an offered product listed in the product search result listing page can include portions presenting information from the account information record of the pharmacy that is offering the product through the system (for example, pharmacy name, address, and contact information), cost information for purchasing the offered product through marketplace system 100 (for example, the discounted price for the product that is specified in the information record for the offered product within product offer database 114 j or, for prescription drugs, a price that is calculated based on the specified discounted price in relation to the quantity specified by the user) and a cost savings difference between the discounted price and the regular price for the product when the product is purchased outside of the system as specified in the information record for the offered product), and an option to select to purchase the offered product listed in the entry (for example, via an “Add to Cart” button). When a user selects the option to purchase an offered product listed in the product search result listing page, navigation and search service 124 can be configured to update the session data object for the session with application server 116 that is presently being maintained for the user to include an indication that the user has selected the offered product for purchasing (for example, by including the product offer identifier that is maintained within product offer database 114 j to uniquely identify the offering of the particular product by the pharmacy) in association with any other required information (for example, in the case of a prescription drug, the quantity that is specified by the user and the price that is calculated based on the discounted price for the product that is specified in the information record for the offered product within product offer database 114 j in relation to the quantity specified by the user). Upon selecting one or more services and/or products for purchase in association with a session with application server 116, the user may then have an option to navigate to a customer purchase page (for example, a “Check-Out” page) to proceed with purchasing the selected item(s) with respect to an account information record maintained within customer profile database 114 a for a registered customer user; see also at least ¶¶ [0123]-[0124]).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the techniques involved in providing a medical storefront taught by Ketchel with the medical supply ordering and management systems disclosed by Roh, because Ketchel teaches several benefits for using its techniques, including teaching at ¶ [0039] that its techniques can “reduce the effort required by a medical practice to offer medically relevant or beneficial services to a patient” and at ¶ [0040] that its techniques “improve a patient’s ease of access to medical services. This facilitation may be a result of reducing the patient’s effort selecting, scheduling, and paying for medical services.” See M.P.E.P. § 2143(I)(G).
Moreover, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the techniques involved in providing a medical storefront taught by Ketchel with the medical supply ordering and management systems disclosed by Roh, because the claimed invention is merely a combination of old elements (the techniques involved in providing a medical storefront taught by Ketchel and the medical supply ordering and management systems disclosed by Roh), in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. See M.P.E.P. § 2143(I)(A).
Claim 7: The combination of Roh and Ketchel teaches the limitations as shown in the rejections above. Further, Roh, as shown, discloses the following limitations:
linking the medical data of a plurality of patients in relation to medical supplies […] (see at least ¶ [0076]: besides providing opportunities to enhance patient care, the EHR database 106 can also be used to facilitate clinical research by combining patients' demographics into a large pool. For example, the EHR database 106 can support a wide range of epidemiological research on the natural history of disease, drug utilization, and safety, as well as health services research; see also at least ¶ [0167]: the computing system can analyze scheduled procedures for other patients to identify one or more of the scheduled procedures in which the patient-sized components are suitable. The computing system can prioritize and assign the available patient-sized components to the appropriate patients. The computing system can then cause additional patient-sized components (e.g., standard or patient-specific components) to be ordered or manufactured for other patients. This allows for flexibility when scheduling procedures and selecting suitable components of kits; see also at least ¶¶ [0168], [0174], and [0186]).
Roh does not explicitly disclose that the medical supplies are ordered by the said patients. However, Ketchel, as shown, teaches
medical supplies ordered by the said patients (see at least ¶ [0122]: each entry for an offered product listed in the product search result listing page can include portions presenting information from the account information record of the pharmacy that is offering the product through the system (for example, pharmacy name, address, and contact information), cost information for purchasing the offered product through marketplace system 100 (for example, the discounted price for the product that is specified in the information record for the offered product within product offer database 114 j or, for prescription drugs, a price that is calculated based on the specified discounted price in relation to the quantity specified by the user) and a cost savings difference between the discounted price and the regular price for the product when the product is purchased outside of the system as specified in the information record for the offered product), and an option to select to purchase the offered product listed in the entry (for example, via an “Add to Cart” button). When a user selects the option to purchase an offered product listed in the product search result listing page, navigation and search service 124 can be configured to update the session data object for the session with application server 116 that is presently being maintained for the user to include an indication that the user has selected the offered product for purchasing (for example, by including the product offer identifier that is maintained within product offer database 114 j to uniquely identify the offering of the particular product by the pharmacy) in association with any other required information (for example, in the case of a prescription drug, the quantity that is specified by the user and the price that is calculated based on the discounted price for the product that is specified in the information record for the offered product within product offer database 114 j in relation to the quantity specified by the user). Upon selecting one or more services and/or products for purchase in association with a session with application server 116, the user may then have an option to navigate to a customer purchase page (for example, a “Check-Out” page) to proceed with purchasing the selected item(s) with respect to an account information record maintained within customer profile database 114 a for a registered customer user; see also at least ¶¶ [0121] and [0123]-[0124]).
The rationales to modify/combine the teachings of Roh to include the teachings of Ketchel are presented above regarding claim 6 and incorporated herein.
Claim 12: Roh, as shown, discloses the following limitations:
A system for selecting a plurality of medical supplies from a plurality of suppliers for a patient based on medical condition and measurements of the patient (see at least ¶ [0131]: FIG. 6 is a block diagram illustrating an example robotic surgical system for customized kit assembly for surgical implants, in accordance with one or more embodiments. The implantation of surgical implants or surgical implant components is sometimes referred to as “insertion” or “installation.” Surgical implants are sometimes referred to as “implants.” Surgical implant components are sometimes referred to as “implant components.” The system of FIG. 6 includes at least one surgical robot 602 a, databases and modules that can be implemented in the cloud 620, and at least one surgical implant 616. The surgical robot 602 is the same as or similar to the surgical robot 440 illustrated and described in more detail with reference to FIG. 4A. The system is implemented using the components of the example computer system 300 illustrated and described in more detail with reference to FIG. 3. Likewise, embodiments of the system can include different and/or additional components or can be connected in different ways; see also at least ¶ [0138]: the implant components 618 a are generic, off-the-shelf implant components while the implant components 618 b are implant components that can be or have been modified or customized for a particular patient using the embodiment described herein. The surgical implant 616 can be a single piece or can include multiple surgical implant components 618. Surgical implants that include multiple implant components 618 can alternatively be referred to as assemblies. The implants 616 can be customized to fit a particular patient or a specific application that the implant 616 is intended for. For example, the implant 616 can include biological donor tissues or biosynthetic tissues such as can be used in operations such as organ transplant, skin graft, or other tissue installation or replacement. In other examples, the implant 616 can be any of multiple implantable medical devices, e.g., cardiac pacemakers, electric neurological stimulation devices such as vagus nerve stimulators or deep brain stimulators, blood glucose monitors, insulin pumps, etc.; see also at least ¶¶ [0091]-[0098] and [0172]), the system comprising:
a third-party medical supplies data source configured to store data relating to a plurality of medical supplies from a plurality of third-parties suppliers into a predetermined format (see at least ¶ [0142]: one or more processors of the surgical system of FIG. 6 design a customized version of the surgical implant 616 using patient data describing a particular patient's anatomy or body, a treatment or particular medical application, and the implant database 622. The customized version of the surgical implant 616 comprises at least the generic surgical implant component 618 a and the customized surgical implant component 618 b. The customized surgical implant component 618 b is for the particular patient and the treatment or particular medical application. For example, the optimization module 628 uses data from the implant database 622 to customize the implant component 618 b to the patient. An inventory database 630 stores data describing a stock of generic implant components 618 a. The implant components 618 a can include any of screws, rods, plates, or commercially available implant components. In some embodiments, one or more processors of the system of FIG. 6 determine absence of the customized surgical implant component 618 b in an inventory. The one or more processors cause manufacture of the customized surgical implant component 618 b in response to determining the absence in the inventory. For example, the inventory database 630 can additionally include manufacturing capabilities to determine whether an implant component 618 can be manufactured. The inventory database 630 can additionally include data on third party vendors including manufacturing capabilities and information necessary to order a custom implant component 618b. The inventory database 630 can include information about tools, instruments, and other equipment associated with surgical procedures; see also at least ¶ [0143]: a path is generated for a surgical tool 154 in a virtual model of the patient's anatomy or body to virtually insert the customized version of the surgical implant 616 in the virtual model. A virtual robotic surgical procedure is performed according to the implantation plan to virtually insert a model of the customized version of the surgical implant 616 at an implantation site. One or more surgical steps of the implantation plan are simulated using a three-dimensional (3D) model generated using real-time patient data; see also at least ¶ [0147]: the assembly module 624 receives patient data such as gender, age, height, weight, allergies, current or prior medical conditions, or any additional clinical information that can impact the outcome of the surgical procedure. The assembly module 624 further acquires vital information such as the patient’s blood pressure, heart rate, blood oxygen saturation, respiration rate, etc. Baseline vital information can be accessed from the clinical information or measured directly; see also at least ¶¶ [0144]-[0145], [0165], and [0174]);
a plurality of medical supplier data converters, each data converter being configured to transform received third-party medical supplies data form a third-party specific format into a predetermined format usable by the system (see at least ¶ [0142]: the inventory database 630 can additionally include data on third party vendors including manufacturing capabilities and information necessary to order a custom implant component 618 b. The inventory database 630 can include information about tools, instruments, and other equipment associated with surgical procedures; see also at least ¶ [0153]: the inventory database 630 can also contain the manufacturing capabilities and order information for third party vendors in order to enable ordering of custom implant components 618 b from third party sources; see also at least ¶ [0158]: the assembly module 624 orders a compatible generic component 618 a that is not immediately available according to the inventory database 630. For example, the implant component 618 b is a screw requiring a casting of titanium and such capabilities are unavailable on site. Thus, the assembly module 624 orders the screw from a third-party vendor; see also at least ¶ [0139], [0155], [0159], and [0165]-[0166]);
a patient software module comprising:
a data store comprising data relating to patients, the data comprising anatomical data of the patient and prescription data (see at least ¶ [0141]: one or more processors generate an implantation plan comprising implantation parameters for controlling insertion of the customized version of the surgical implant 616 into a particular patient's body by the surgical robot 602 of the surgical system of FIG. 6 . For example, the planning module 626 images the patient using at least one imaging device 614 and generates the implantation plan. The implantation plan includes a design of the implant 616 and implant placement within a virtual model of a portion of a patient's anatomy or body generated from the images acquired of the patient. The planning module 626 further generates tool paths and implantation parameters to be used during insertion of the implant 616. The optimization module 628 receives information describing an initial implant component 618 a from the assembly module 624. The information can be generated by the planning module 622; see also at least ¶ [0144]: the data includes the designs and placement of previous implants, previous tool paths used during implantation procedures, and previous patient information such as gender, age, height, weight, medical conditions, patient medical history, patient family medical history, allergies, or vital information such as baseline measurements of heart rage, blood pressure, blood oxygen saturation, or respiration rate; see also at least ¶¶ [0074]-[0075], [0131], [0138], [0145], [0152], and [0173]; see also at least ¶ [0122]: the display module 522 can be configured to convert and transmit processing parameters, sensor readings 526, output signals 528, input data, treatment profiles and prescribed operational parameters);
a patient filter object comprising rules for selecting a plurality of medical supplies from the data source of medical supplies fitting the medical condition of the patient associated with the inputted prescription data of the patient (see at least ¶ [0142]: one or more processors of the surgical system of FIG. 6 design a customized version of the surgical implant 616 using patient data describing a particular patient's anatomy or body, a treatment or particular medical application, and the implant database 622. The customized version of the surgical implant 616 comprises at least the generic surgical implant component 618 a and the customized surgical implant component 618 b. The customized surgical implant component 618 b is for the particular patient and the treatment or particular medical application. For example, the optimization module 628 uses data from the implant database 622 to customize the implant component 618 b to the patient. An inventory database 630 stores data describing a stock of generic implant components 618 a. The implant components 618 a can include any of screws, rods, plates, or commercially available implant components. In some embodiments, one or more processors of the system of FIG. 6 determine absence of the customized surgical implant component 618 b in an inventory. The one or more processors cause manufacture of the customized surgical implant component 618 b in response to determining the absence in the inventory. For example, the inventory database 630 can additionally include manufacturing capabilities to determine whether an implant component 618 can be manufactured. The inventory database 630 can additionally include data on third party vendors including manufacturing capabilities and information necessary to order a custom implant component 618b. The inventory database 630 can include information about tools, instruments, and other equipment associated with surgical procedures; see also at least ¶ [0143]: a path is generated for a surgical tool 154 in a virtual model of the patient's anatomy or body to virtually insert the customized version of the surgical implant 616 in the virtual model. A virtual robotic surgical procedure is performed according to the implantation plan to virtually insert a model of the customized version of the surgical implant 616 at an implantation site. One or more surgical steps of the implantation plan are simulated using a three-dimensional (3D) model generated using real-time patient data; see also at least ¶ [0147]: the assembly module 624 receives patient data such as gender, age, height, weight, allergies, current or prior medical conditions, or any additional clinical information that can impact the outcome of the surgical procedure. The assembly module 624 further acquires vital information such as the patient's blood pressure, heart rate, blood oxygen saturation, respiration rate, etc. Baseline vital information can be accessed from the clinical information or measured directly; see also at least ¶¶ [0144]-[0145], [0165], and [0174]);
a medical supplies matcher configured to:
automatically match a plurality of medical supplies of the third-party medical supplies data source which only match all of the rules of the generated patient filter object (see at least ¶ [0142]: one or more processors of the surgical system of FIG. 6 design a customized version of the surgical implant 616 using patient data describing a particular patient's anatomy or body, a treatment or particular medical application, and the implant database 622. The customized version of the surgical implant 616 comprises at least the generic surgical implant component 618 a and the customized surgical implant component 618 b; see also at least ¶ [0143]: a path is generated for a surgical tool 154 in a virtual model of the patient's anatomy or body to virtually insert the customized version of the surgical implant 616 in the virtual model. A virtual robotic surgical procedure is performed according to the implantation plan to virtually insert a model of the customized version of the surgical implant 616 at an implantation site. One or more surgical steps of the implantation plan are simulated using a three-dimensional (3D) model generated using real-time patient data; see also at least ¶ [0147]: the assembly module 624 receives patient data such as gender, age, height, weight, allergies, current or prior medical conditions, or any additional clinical information that can impact the outcome of the surgical procedure. The assembly module 624 further acquires vital information such as the patient's blood pressure, heart rate, blood oxygen saturation, respiration rate, etc. Baseline vital information can be accessed from the clinical information or measured directly; see also at least ¶¶ [0144]-[0145], [0165], and [0174]);
generate and store the patient filter object (see at least ¶ [0152]: assembly module 624 receives information describing a customized implant component 618 b from the optimization module 628. The implant component 618 b can be modified by the optimization module 628 using patient data and data from previously inserted implants 616 from the implant database 622 to better accommodate the patient’s physiology including allergies and medical conditions; see also at least ¶ [0153]: the assembly module 624 queries the inventory database 630 for a stock of generic or otherwise in-stock implant components 618 a. In an embodiment, the in-stock generic implant components 618 a include screws of various sizes ranging from 0.5 inches to 3 inches having a range of standard and metric threads with tulip heads and traditional rounded star heads. The screws can alternatively be comprised of proprietary designs. The inventory database 630 can additionally include an inventory of rods and plates. The rods can be available in a range of diameters and lengths and the plates can similarly be available in a range of dimensions and can have holes and other features to accept screws and other hardware. The implant components 618 a can additionally be available in a range of materials such as surgical stainless steel and titanium or alloys. The inventory database 630 can also contain the manufacturing capabilities and order information for third party vendors in order to enable ordering of custom implant components 618 b from third party sources; see also at least ¶ [0154]: in step 816, the assembly module 624 determines whether the customized implant component 618 b matches an implant component 618 a in stock according to the inventory database 630. A matching implant component 618 a can be an exact match or can match required design parameters while not necessarily matching optional design parameters; see also at least ¶¶ [0159]-[0161] and [0165]-[0166]);
a catalogue browser configured to display only the matching medical supplies (see at least ¶ [0171]: the system can receive data before and/or during the surgical procedure and can use received data to, for example, recommend, design (pre-operatively and/or intra-operatively design), and/or provide components, implants, instructions, and/or kit assemblies; see also at least ¶ [0112]: the user and surgical team can review the proposed surgical plans to select an appropriate surgical plan. The robotic surgical system 400 can modify a surgical plan with one or more corrective surgical steps based on identified surgical complications, sensor readings, or the like; see also at least ¶ [0117]: the physician can review the virtual simulations to accept or reject the recommended surgical plan. The physician can modify surgical plans pre-operatively or intraoperatively. Kits (e.g., pre-operative kits, intraoperative kits, etc.) can be modified or provided based on the modification; see also at least ¶ [0163]: the assembly module 624 terminates the kit assembly when all implant components 618 and tools in the implantation plan have been selected, customized, and added to the kit; see also at least ¶¶ [0153] and [0170]);
an order handler for a user to select and add to a list of desired products only the one or more products associated with one of the generated filters associated with the patient data and displayed by the catalogue browser (see at least ¶ [0171]: the system can receive data before and/or during the surgical procedure and can use received data to, for example, recommend, design (pre-operatively and/or intra-operatively design), and/or provide components, implants, instructions, and/or kit assemblies; see also at least ¶ [0112]: the user and surgical team can review the proposed surgical plans to select an appropriate surgical plan. The robotic surgical system 400 can modify a surgical plan with one or more corrective surgical steps based on identified surgical complications, sensor readings, or the like; see also at least ¶ [0117]: the physician can review the virtual simulations to accept or reject the recommended surgical plan. The physician can modify surgical plans pre-operatively or intraoperatively. Kits (e.g., pre-operative kits, intraoperative kits, etc.) can be modified or provided based on the modification; see also at least ¶ [0163]: the assembly module 624 terminates the kit assembly when all implant components 618 and tools in the implantation plan have been selected, customized, and added to the kit; see also at least ¶¶ [0153] and [0170]);
a healthcare professional software module comprising:
a data store comprising a list of patients associated with a healthcare professional (see at least ¶ [0075]: the system 100 includes an electronic health records (EHR) database 106 that contains patient records. The EHR are a digital version of patients' paper charts. The EHR database 106 can contain more information than a traditional patient chart, including, but not limited to, a patients' medical history, diagnoses, medications, treatment plans, allergies, diagnostic imaging, lab results, etc. In some embodiments, the steps for each procedure disclosed herein are stored in the EHR database 106. Electronic health records can also include data collected from the monitors 112 from historical procedures. The EHR database 106 is implemented using components of the example computer system 300 illustrated and described in more detail with reference to FIG. 3; see also at least ¶ [0076]: the EHR database 106 can be created and managed by authorized providers and can make health information accessible to authorized providers across practices and health organizations, such as laboratories, specialists, medical imaging facilities, pharmacies, emergency facilities, etc. The timely availability of EHR data enables healthcare providers to make more accurate decisions and provide better care to the patients by effective diagnosis and reduced medical errors. Besides providing opportunities to enhance patient care, the EHR database 106 can also be used to facilitate clinical research by combining patients' demographics into a large pool. For example, the EHR database 106 can support a wide range of epidemiological research on the natural history of disease, drug utilization, and safety, as well as health services research; see also at least ¶¶ [0098] and [0128]);
an interface to input prescription data associated to one or more of the patients of the list (see at least ¶ [0141]: one or more processors generate an implantation plan comprising implantation parameters for controlling insertion of the customized version of the surgical implant 616 into a particular patient's body by the surgical robot 602 of the surgical system of FIG. 6 . For example, the planning module 626 images the patient using at least one imaging device 614 and generates the implantation plan. The implantation plan includes a design of the implant 616 and implant placement within a virtual model of a portion of a patient’s anatomy or body generated from the images acquired of the patient. The planning module 626 further generates tool paths and implantation parameters to be used during insertion of the implant 616. The optimization module 628 receives information describing an initial implant component 618 a from the assembly module 624. The information can be generated by the planning module 622; see also at least ¶ [0144]: the data includes the designs and placement of previous implants, previous tool paths used during implantation procedures, and previous patient information such as gender, age, height, weight, medical conditions, patient medical history, patient family medical history, allergies, or vital information such as baseline measurements of heart rage, blood pressure, blood oxygen saturation, or respiration rate; see also at least ¶¶ [0131], [0138], [0145], [0152], and [0173]; see also at least ¶ [0122]: the display module 522 can be configured to convert and transmit processing parameters, sensor readings 526, output signals 528, input data, treatment profiles and prescribed operational parameters); and
an interface to input or capture measurements of anatomical regions of one or more of the patients of the list (see at least ¶¶ [0122], [0131], [0138], [0141], [0144]-[0145], [0152], and [0173] and the analysis above).
Roh does not explicitly disclose, but Ketchel, as shown, teaches the following limitations:
a login software module to authenticate a user to the system (see at least ¶ [0134]: upon a user registering a customer account with server system 110 to establish an account information record within customer profile database 114 a and logging into his or her customer account (for example, by accessing a login user interface element or a login screen within the user interface implemented by customer portal 120 to provide the user name and password associated with the account), the user then proceeds with purchasing any offered service or product for which the session data object for the session with application server 116 that is being maintained for the user includes an indication that the user has selected for purchasing. For example, upon the user selecting an option within the user interface implemented by navigation and search services 124 to navigate to a customer purchase page and initiate a purchasing session with purchasing service 126 to purchase one or more of the offered items indicated as having been selected by the user in the session data object in association with the registered customer account for the user; see also at least ¶¶ [0279]-[0280]).
The rationales to modify/combine the teachings of Roh to include the teachings of Ketchel are presented above regarding claim 6 and incorporated herein.
Claim 13: The combination of Roh and Ketchel teaches the limitations as shown in the rejections above. Further, Roh, as shown, discloses the following limitations:
the healthcare professional software module further comprising a catalogue browser simulator for simulating the catalogue browser of the patient software module of one of the patients of the list (see at least ¶ [0171]: the system can receive data before and/or during the surgical procedure and can use received data to, for example, recommend, design (pre-operatively and/or intra-operatively design), and/or provide components, implants, instructions, and/or kit assemblies; see also at least ¶ [0112]: the user and surgical team can review the proposed surgical plans to select an appropriate surgical plan. The robotic surgical system 400 can modify a surgical plan with one or more corrective surgical steps based on identified surgical complications, sensor readings, or the like; see also at least ¶ [0117]: the physician can review the virtual simulations to accept or reject the recommended surgical plan. The physician can modify surgical plans pre-operatively or intraoperatively. Kits (e.g., pre-operative kits, intraoperative kits, etc.) can be modified or provided based on the modification; see also at least ¶ [0163]: the assembly module 624 terminates the kit assembly when all implant components 618 and tools in the implantation plan have been selected, customized, and added to the kit; see also at least ¶¶ [0153] and [0170]).
Claim 14: The combination of Roh and Ketchel teaches the limitations as shown in the rejections above. Further, Roh, as shown, discloses the following limitations:
an importation software module for automatically retrieving and storing third-party medical supplies data from a plurality of third-party systems into the third-party medical supplies data source (see at least ¶ [0142]: the optimization module 628 uses data from the implant database 622 to customize the implant component 618 b to the patient. An inventory database 630 stores data describing a stock of generic implant components 618 a. The implant components 618 a can include any of screws, rods, plates, or commercially available implant components. In some embodiments, one or more processors of the system of FIG. 6 determine absence of the customized surgical implant component 618 b in an inventory. The one or more processors cause manufacture of the customized surgical implant component 618 b in response to determining the absence in the inventory. For example, the inventory database 630 can additionally include manufacturing capabilities to determine whether an implant component 618 can be manufactured. The inventory database 630 can additionally include data on third party vendors including manufacturing capabilities and information necessary to order a custom implant component 618 b. The inventory database 630 can include information about tools, instruments, and other equipment associated with surgical procedures; see also at least ¶ [0153]: the inventory database 630 can also contain the manufacturing capabilities and order information for third party vendors in order to enable ordering of custom implant components 618 b from third party sources; see also at least ¶ [0158]: the assembly module 624 orders a compatible generic component 618 a that is not immediately available according to the inventory database 630. For example, the implant component 618 b is a screw requiring a casting of titanium and such capabilities are unavailable on site. Thus, the assembly module 624 orders the screw from a third-party vendor; see also at least ¶ [0159]; see also at least ¶ [0113]: databases can be updated with data (e.g., intraoperative data collected during the surgical procedure, simulation data, etc.) to intraoperatively adjust surgical plans, collect data for ML/AI training sets, or the like. Data from on-site and off-site simulations (e.g., pre- or post-operative virtual simulations, simulations using models, etc.) can be generated and collected).
Claim 15: The combination of Roh and Ketchel teaches the limitations as shown in the rejections above. Further, Roh, as shown, discloses the following limitations:
the importation software module further comprising a plurality of data connectors, each data connector being configured to establish communication with a third-party system and to transfer data from the said third-party system (see at least ¶¶ [0113], [0142], [0153], [0158]-[0159] and the analysis above; see also at least ¶ [0135]: communications interface 612 allows the surgical robot 602 to communicate with external devices and can include a wireless antenna and transceiver or a port for receiving a cable to facilitate a wired connection. Examples of a wired connection include ethernet, universal serial bus (USB) or a proprietary connection. A wireless communications interface can include any of WiFi, Bluetooth, near field communications (NFC) or a cellular communications interface such as 3G, 4G, LTE, or 5G. The communications interface 612 can connect a user interface to the surgical robot 602 or can facilitate access to a local network or the cloud 620's network to access a remote server and/or database; see also at least ¶ [0025]).
Claim 17: The combination of Roh and Ketchel teaches the limitations as shown in the rejections above. Further, Roh, as shown, discloses the following limitations:
the converters being configured to map a plurality of attributes of the third-party medical supplies to a respective attribute of the predetermined format (see at least ¶¶ [0113], [0142], [0153], [0158]-[0159] and the analysis above. The received data is stored in—i.e., mapped to—the format of the inventory database 630).
Claim 18: The combination of Roh and Ketchel teaches the limitations as shown in the rejections above. Further, Roh, as shown, discloses the following limitations:
a crawler for analyzing potential relationships between characteristics of patient users and medical supplies that are ordered by such patients (see at least ¶ [0142]: one or more processors of the surgical system of FIG. 6 design a customized version of the surgical implant 616 using patient data describing a particular patient's anatomy or body, a treatment or particular medical application, and the implant database 622. The customized version of the surgical implant 616 comprises at least the generic surgical implant component 618 a and the customized surgical implant component 618 b. The customized surgical implant component 618 b is for the particular patient and the treatment or particular medical application. For example, the optimization module 628 uses data from the implant database 622 to customize the implant component 618 b to the patient. An inventory database 630 stores data describing a stock of generic implant components 618 a. The implant components 618 a can include any of screws, rods, plates, or commercially available implant components. In some embodiments, one or more processors of the system of FIG. 6 determine absence of the customized surgical implant component 618 b in an inventory. The one or more processors cause manufacture of the customized surgical implant component 618 b in response to determining the absence in the inventory. For example, the inventory database 630 can additionally include manufacturing capabilities to determine whether an implant component 618 can be manufactured. The inventory database 630 can additionally include data on third party vendors including manufacturing capabilities and information necessary to order a custom implant component 618b. The inventory database 630 can include information about tools, instruments, and other equipment associated with surgical procedures; see also at least ¶ [0143]: a path is generated for a surgical tool 154 in a virtual model of the patient's anatomy or body to virtually insert the customized version of the surgical implant 616 in the virtual model. A virtual robotic surgical procedure is performed according to the implantation plan to virtually insert a model of the customized version of the surgical implant 616 at an implantation site. One or more surgical steps of the implantation plan are simulated using a three-dimensional (3D) model generated using real-time patient data; see also at least ¶ [0147]: the assembly module 624 receives patient data such as gender, age, height, weight, allergies, current or prior medical conditions, or any additional clinical information that can impact the outcome of the surgical procedure. The assembly module 624 further acquires vital information such as the patient's blood pressure, heart rate, blood oxygen saturation, respiration rate, etc. Baseline vital information can be accessed from the clinical information or measured directly; see also at least ¶¶ [0144]-[0145], [0165], and [0174]).
Claim 19: The combination of Roh and Ketchel teaches the limitations as shown in the rejections above. Further, Roh, as shown, discloses the following limitations:
the crawler using a trained artificial intelligence algorithm to perform the analysis (see at least ¶ [0084]: in alternative example embodiments, the ML model 216, e.g., in the form of a CNN generates the output 224, without the need for feature extraction, directly from the input data 204. The output 224 is provided to the computer device 228 or the console 108 illustrated and described in more detail with reference to FIG. 1 . The computer device 228 is a server, computer, tablet, smartphone, smart speaker, etc., implemented using components of the example computer system 300 illustrated and described in more detail with reference to FIG. 3 . In some embodiments, the steps performed by the ML system 200 are stored in memory on the computer device 228 for execution. In other embodiments, the output 224 is displayed on the high-definition monitors 124 illustrated and described in more detail with reference to FIG. 1; see also at least ¶¶ [0087]: the ML system 200 trains the ML model 216, based on the training data 220, to correlate the feature vector 212 to expected outputs in the training data 220. As part of the training of the ML model 216, the ML system 200 forms a training set of features and training labels by identifying a positive training set of features that have been determined to have a desired property in question, and, in some embodiments, forms a negative training set of features that lack the property in question; see also at least ¶¶ [0089]. [0118], and [0130]).
Claim 11 is rejected under AIA 35 U.S.C. § 103 as being unpatentable over Roh et al. (U.S. Pub. No. 2023/0104580 A1) (hereinafter “Roh”) in view of Weiler et al. (U.S. Pub. No. 2018/0168261 A1) (hereinafter “Weiler”).
Claim 11: Roh discloses the limitations as shown in the rejections above.
Roh does not explicitly disclose, but Weiler, as shown, teaches the following limitations:
the medical supplies being compression socks (see at least ¶ [0073]: beyond the specific subset of patients having complex surface morphologies, the inventors herein have determined that measurement of body parts or body areas using the standard tape measure technique or prior art imaging methodology cannot suitably generate a compression garment fit that substantially conforms to the shape of the patient's body part that is in need of compression treatment as is indicated by a compression prescription generated by a provider or as needed by an athlete for post-exercise recovery. In this regard, it has been determined that circumference measurements taken by the tape measurement technique do not provide accurate information about the shape of the parts, and subparts, of the body regions being measured for fitting with compression garments. Moreover, prior art imaging techniques are configured to extract the circumferences of the body parts or body areas of interest. When a body part or body area are assumed to be a circle, which is the case with measurements of body parts or body areas taken according to these prior art methods, a circle, an ellipse, and a square may each demonstrate the same “circumference,” but, as would be recognized, would present markedly different shapes; see also at least ¶¶ [0072], [0082], and [0085]).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the techniques for providing prescription compression garments taught by Weiler with the medical supply ordering and management systems disclosed by Roh, because Weiler teaches at ¶ [0072] that “the ability to generate well-fitting compression garments or to enhance the selection of pre-fabricated garments that are intended to deliver a prescribed one or more compression values to a patient having complex surface morphologies is greatly enhanced, at least because the provided garment is custom generated for or selected to fit the specific body part or body area of that patient, even in view of her non-uniform skin surface configuration.” See M.P.E.P. § 2143(I)(G).
Moreover, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to combine the techniques for providing prescription compression garments taught by Weiler with the medical supply ordering and management systems disclosed by Roh, because the claimed invention is merely a combination of old elements (the techniques for providing prescription compression garments taught by Weiler and the medical supply ordering and management systems disclosed by Roh), in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. See M.P.E.P. § 2143(I)(A).
Claim 20 is rejected under AIA 35 U.S.C. § 103 as being unpatentable over Roh et al. (U.S. Pub. No. 2023/0104580 A1) (hereinafter “Roh”) in view of Ketchel et al. (U.S. Pub. No. 2021/0209664 A1) (hereinafter “Ketchel”) and further in view of Weiler et al. (U.S. Pub. No. 2018/0168261 A1) (hereinafter “Weiler”).
Claim 20: The combination of Roh and Ketchel teaches the limitations as shown in the rejections above.
Roh does not explicitly disclose, but Weiler, as shown, teaches the following limitations:
the medical supplies being compression socks (see at least ¶ [0073]: beyond the specific subset of patients having complex surface morphologies, the inventors herein have determined that measurement of body parts or body areas using the standard tape measure technique or prior art imaging methodology cannot suitably generate a compression garment fit that substantially conforms to the shape of the patient's body part that is in need of compression treatment as is indicated by a compression prescription generated by a provider or as needed by an athlete for post-exercise recovery. In this regard, it has been determined that circumference measurements taken by the tape measurement technique do not provide accurate information about the shape of the parts, and subparts, of the body regions being measured for fitting with compression garments. Moreover, prior art imaging techniques are configured to extract the circumferences of the body parts or body areas of interest. When a body part or body area are assumed to be a circle, which is the case with measurements of body parts or body areas taken according to these prior art methods, a circle, an ellipse, and a square may each demonstrate the same “circumference,” but, as would be recognized, would present markedly different shapes; see also at least ¶¶ [0072], [0082], and [0085]).
The rationales to modify/combine the teachings of Roh (as modified by Ketchel) to include the teachings of Weiler are presented above regarding claim 11 and incorporated herein.
Response to Arguments
The arguments submitted with the Reply have been fully considered. The amendments obviate the rejections under § 112. The remaining arguments are not persuasive.
Applicant argues that several of the added claim features cannot be performed by the human mind. Reply, p. 4. The revised rejections indicate which of the amended features are directed to abstract ideas and which recite additional elements. The rejections also indicate why the additional elements are, individually or in combination with claim features, insufficient to demonstrate subject matter eligibility under the Alice test.
Applicant argues that “‘mapping’ and ‘conversion’ mechanism are not ‘mental process’.” Reply, p. 4. Examiner disagrees, because a person can mentally map and convert one type of data (e.g., “one widget”) into another type of data format (e.g., “1 widget”).
Applicant argues that the applied references do not disclose the features added via amendment to the independent claims. Examiner disagrees for the reasons provided in the rejections above, which map the added claim features to specific features of the applied art.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. The following references have been cited to further show the state of the art with respect to medical supply ordering and management.
Mahinda (U.S. Pub. No. 2009/0083064 A1) (competitive online prescription pricing system);
Kahn et al. (“Development of web based online medicine delivery system for COVID-19 pandemic.” Journal of Software Engineering and Applications 14.01 (2021): 26).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Christopher Tokarczyk, whose telephone number is 571-272-9594. The examiner can normally be reached Monday-Thursday between 6:00 AM and 4:00 PM Eastern.
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.
/CHRISTOPHER B TOKARCZYK/ Primary Examiner, Art Unit 3687
Prosecution Insights