Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Claims
The status of the claims as of the response filed 8/5/2025 is as follows: Claims 2-4, 11, 14-16, and 21-22 are cancelled, and all previously given rejections for these claims are considered moot. Claims 1, 13, and 20 are currently amended. Claims 5, 10, and 17-18 are as previously presented. Claims 6-9, 12, and 19 are original. Claims 1, 5-10, 12-13, and 17-20 are currently pending in the application and have been considered below.
Response to Amendment
Rejection Under 35 USC 101
The claims have been amended but the 35 USC 101 rejections are upheld.
Rejection Under 35 USC 102/103
The amendments made to the claims introduce limitations that are not fully addressed in combination in the previous Office action, and thus the corresponding 35 USC 102/103 rejections are withdrawn. However, Examiner will consider the amended claims in light of an updated prior art search and address their patentability with respect to prior art below.
Response to Arguments
Rejection Under 35 USC 101
On pages 1-2 of the response filed 8/5/2025 Applicant argues that “the claimed approach is not and could not be implemented an performed as a human activity or task,” further submitting that “the precise problem solved by the claimed approach is that the status quo is a human based system of manual recognition and reporting which is ineffective.” Applicant’s arguments are fully considered, but are not persuasive. Examiner maintains that the underlying functions of the computerized system (e.g. receiving an identifier of a medical device under consideration for deployment, storing the identifier in a repository comprising a set of entries with device IDs linked to device usage results, comparing the identifier to the stored entries to identify a match based on vendor and model number, lot number, or expiration date, ensuring that the matching entries are free of reported anomalies like recalls, product expiration, deaths, or serious injury, logging indications of safe operation of the device, generating reports about whether anomalies have been reported, updating entries in the repository, receiving a request for entries in the repository, identifying a vendor corresponding to a source of the request, and returning only entries corresponding to the identified vendor responsive to the request) describe the management of personal behavior and interactions between human actors for the commercial purpose of tracking medical device safety reporting and verification. The fact that such reporting functions occur digitally via computerized elements such as a mobile device application, an input device, a presumably electronic repository, a server, various computer logics, and a graphical user interface of a user device thus amounts to instructions to “apply” the exception in a manner that invokes these high-level computing elements as tools with which to digitize and/or automate the otherwise-abstract steps such that they occur in an electronic environment rather than manually among human actors in a commercial enterprise. Applicant’s arguments lend credence to this analysis, because they show that the invention merely seeks to automate a currently manual process (see bottom of page 1: “The precise problem solved by the claimed approach is that the status quo is a human based system of manual recognition and reporting”). Examiner notes that per MPEP 2106.05(f)(2), “‘claiming the improved speed or efficiency inherent with applying the abstract idea on a computer’ does not integrate a judicial exception into a practical application or provide an inventive concept.” Applicant has not provided any evidence that the implementation of the abstract idea with computing components provides any technical improvements beyond the improved speed or efficiency inherent with applying medical device anomaly reporting operations in a computing environment.
On page 2 of the response Applicant argues that “the scanned data and storage using a database removes the claimed approach from an abstract idea” because “the claims require an imaging device or medium for device recognition” and “the device ID needs to be stored in a database, and compared to corresponding fields in other device records.“ Applicant’s arguments are fully considered, but are not persuasive. Examiner maintains that the underlying functions of storing medical device entries in a repository and comparing a device ID to stored device entries could be achieved by a human actor managing their personal behavior to achieve a commercial medical device anomaly reporting operation. For example, an administrator could keep paper records of medical device IDs linked to any reported anomalies (e.g. malfunctions, recalls, expirations, deaths, etc.) and look through the records to find matches to a new medical device under consideration for deployment by a doctor to give the doctor the go-ahead or inform them of any known anomalies linked to that device type. Implementing such operations in a digitized environment amounts to instructions to “apply” the exception, as explained above. Examiner further notes that the claims as presently drafted do not appear to actually require an imaging device or medium for device recognition as Applicant asserts; rather, an identifier of a medical device is received “from an interface to a scan tool or input device,” which under the broadest reasonable interpretation in light of the specification could include receiving a device identifier in the form of an alphanumeric character simply typed to an input device (see specification at Pg9 L2-5: “The identifier 134 may be scanned 138 by a scanner device 136, retrieved from a photographic image taken via a camera 131 feature of the reporter’s device 130, or simply entered in alphanumeric characters” as well as Pg12 L6-11: “The app 132 receives the identifier of the medical device from one of an optical reader 136 scanning a bar code on the medical device, a photographic image of the medical device from the personal device 130 on which the app 132 resides, or alternatively, the 14-digit 10 device identifier 134 can be manually entered from an alphanumeric rendering on the medical device,” e.g. via a keyboard as in Fig. 7). Accordingly, receiving a device inquiry with an identifier represented as alphanumeric characters (e.g. from a doctor wishing to deploy a certain device) is considered part of the abstract idea, and the use of an input device such as a keyboard to provide the identifier digitally amounts to instructions to “apply” the abstract idea, because it is merely invoked as a tool with which to implement the otherwise-abstract function of communicating an alphanumeric device identifier between entities in an electronic environment.
For the reasons outlined above, the 35 USC 101 rejections are upheld.
Rejection Under 35 USC 102/103
Applicant’s arguments with respect to alleged deficiencies of the Reiner reference have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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, 5-10, 12-13, and 17-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
In the instant case, claims 1, 5-10, and 12 are directed to a method (i.e. a process), claims 13 and 17-19 are directed to a system (i.e. a machine), and claim 20 is directed to a computer program embodying program code on a non-transitory medium (i.e. a manufacture). Thus, each of the claims falls within one of the four statutory categories. Nevertheless, the claims fall within the judicial exception of an abstract idea.
Step 2A – Prong 1
Independent claims 1, 13, and 20 recite steps that, under their broadest reasonable interpretations, cover certain methods of organizing human activity, e.g. managing personal behavior, relationships, or interactions between people. Specifically, claim 13 (as representative) recites:
A system for gathering and tracking medical device reports for determining safe usage of medical devices, comprising:
a mobile device application for receiving an identifier of a medical device from an interface to a scan tool or input device, the medical device under consideration for deployment for a patient usage;
an interface to a repository for storing the identifier in a repository, further comprising generating a set of entries in the repository based on previous received identifiers, including, for each entry in the set of entries, an indication of either an adverse result or an acceptable result;
a server for comparing the identifier to the set of entries in the repository for identifying a match based on a vendor and at least one of a model number, lot number or expiration date; and
reporting logic for determining, based on an identity established by the identifier and the comparison, a database match based on receiving a report of an adverse event associated with the identity, the reporting logic further configured to reconcile safe medical device operation based on current and previous anomaly free operation by:
ensuring the set of entries in the repository is free from reported device anomalies corresponding to the identity of the medical device, the anomalies defined by recalls, product expiration, reported deaths, and reported serious injury; and
receiving an indication of safe operation of the medical device during the current usage attempt;
GUI logic configured to render on a graphical user interface of a user device, based on the comparison, whether the device has been the subject of a reported anomaly or recall indicative of unsafe usage;
the server further configured to:
receive an indication of whether an anomaly indicative of an adverse event was encountered during the current usage attempt, and if so, to report an adverse event resulting from the current usage to the repository via the graphical user interface; and
generate an entry in the repository indicative of the encountered anomaly, the generated entry available for subsequent comparisons;
receive a request to render one or more of the entries in the set of entries;
identify a vendor corresponding to a source of the request; and
render the entries from the set of entries corresponding only to the identified vendor.
But for the recitation of high-level computer components (underlined above), these italicized functions, when considered as a whole, describe a commercial medical device safety reporting and verification method that could be achieved by a human actor managing their personal behavior and/or interactions with colleagues. For example, an administrator or other human actor could receive a device identifier from a colleague wishing to use or deploy a medical device for a patient (e.g. verbally or via other communication means), compare the device ID with a repository of known device usage failures and successes (e.g. in the form of table, physical records, or other means of storing and tracking information) to identify matching devices based on vendor type, device model number, device lot number, and/or expiration date, and let their colleague know if the device type is associated with any known malfunctions, errors, recalls, or other anomalies that might preclude safe operation of the device. The administrator could render this information in a visual format such as a written report, visual warning, chart, etc. The administrator could further receive indications of successful or failed device usages from colleagues and continually update the repository with new reports, records, or other entries for future cross-checking comparisons. Finally, the administrator could communicate with a representative of a specific device vendor who has requested certain device type entries in the repository and provide that vendor representative information only about device types that they are authorized to view, e.g. entries associated with devices produced by that vendor. Accordingly, the steps recited in these claims describe various interactions that could occur by and among human actors and they are found to recite an abstract idea in the form of a certain method of organizing human activity.
Dependent claims 5-10, 12, and 17-19 inherit the limitations that recite an abstract idea from their dependence on claims 1 or 13, and thus these claims also recite an abstract idea under the Step 2A – Prong 1 analysis. In addition, claims 5-10 and 17-19 recite further limitations that merely further describe the abstract idea identified above.
Specifically, claims 5 and 17 describe how subsequent entries are generated and used as a reference for comparison to new device identifiers, which a human actor could achieve in the same manner as described for the independent claims.
Claim 6 recites that the anomalies are indicative of various types of harm, and a human actor would be capable of managing records denoting these types of harm.
Claim 7 recites accumulating the set of entries in the repository based on receiving a plurality of usage reports identifying a usage attempt, an identifier, and a usage outcome, which are types of data entries/records that a human actor would be capable of soliciting, aggregating, and managing for future comparisons.
Claim 8 specifies that the accumulated entries are arranged according to a vendor and a model, which a human actor would be capable of performing when managing or organizing data records.
Claim 9 specifies that the identifier is an industry recognized unique identifier for the medical device, which a human actor would be capable of receiving and cross-referencing in a repository.
Claim 10 recites identifying patient health records corresponding to usage of the medical device and storing generated entries in the patient records, which a human actor would be capable of performing by looking through patient records for indications of usage of a particular type of medical device (e.g. a certain model of implanted pacemaker) and writing a note or other indication in the patient record when that medical device has been reported to have malfunctions, errors, a recall, or other usage anomalies.
Claim 18 recites accessing the entries for identifying patients associated with the medical device, transmitting a proactive inquiry for identifying anomalies and receiving an indication of whether anomalies occurred post-us age or post-implantation. A human actor could achieve these features by looking through the usage reports for a patient associated with a given medical device, communicating with a colleague looking to proactively understand anomalies associated with usage of a given device, and provide the colleague an answer about post-usage or post-implantation anomalies they discovered in the reports.
Claim 19 recites identifying a report gathering authority including at least one of a manufacturer and a governmental entity, determining if the device related event is a serious adverse event, and if so, transmitting the event to the appropriate party, which could be achieved by an administrator identifying relevant governmental and/or manufacturing entities, determining that a serious event (e.g. a death) has occurred, and communicating with the entities to notify them of the event.
However, recitation of an abstract idea is not the end of the analysis. Each of the claims must be analyzed for additional elements that indicate the abstract idea is integrated into a practical application to determine whether the claim is considered to be “directed to” an abstract idea.
Step 2A – Prong 2
The judicial exception is not integrated into a practical application. In particular, independent claims 1, 13, and 20 do not include additional elements that integrate the abstract idea into a practical application. Claim 13 (as representative) recites the additional elements of a mobile device application that receives an identifier of a medical device from an interface to a scan tool or input device, an interface to a repository, a server, reporting logic, and GUI logic configured to render data on a graphical user interface of a user device. Claims 1 and 20 recite substantially similar additional elements. These additional elements, when considered in the context of each claim as a whole, merely serve to automate interactions that could occur by and among human actors (as described above), and thus amount to instructions to “apply” the abstract idea with generic computer components (see MPEP 2106.05(f)). That is, the mobile device application, input device, interface to a repository, server, various logics, and GUI of a user device merely digitize and/or automate the data sharing, management, and analysis steps that could otherwise be achieved as a certain method of organizing human activity. For example, the mobile application and interface to a scan tool or input device merely digitize the function of receiving a medical device identifier (e.g. an alphanumerically entered by a user); the interface to the repository, server, and reporting logic merely digitize/automate the data storage and record matching/analysis functions; and the GUI logic and GUI of a user interface merely digitize the output of identified anomaly reports such that all of these functions occur electronically in a computerized environment. Additionally, the use of an interface to a scan tool rather than an input device to provide the medical device identifier would amount to insignificant extra-solution activity in the form of data gathering (see MPEP 2106.05(g)) because it merely acts as a source for obtaining the device identifier data necessary for the rest of the comparison and analysis steps. Accordingly, independent claims 1, 13, and 20 as a whole are each directed to an abstract idea without integration into a practical application.
The judicial exception recited in dependent claims 5-10, 12, and 17-19 is also not integrated into a practical application under a similar analysis as above. Claims 5-9 and 17-18 do not introduce any new additional elements beyond the abstract idea itself, and thus these claims do not provide integration into a practical application. Claim 10 specifies that the identified and stored health records are electronic health records in an electronic health records system. The records being electronic again merely serves to digitize aspects that could otherwise be achieved as a certain method of organizing human activity, and thus does not provide integration into a practical application. Claim 12 recites various means of receiving the identifier, including from an optical reader scanning a bar code, a photographic image of the medical device from a personal device or a typed alphanumeric identifier from a label. These sources of the identifier are merely different means of gathering data necessary for the rest of the comparison and analysis steps, and thus amount to insignificant extra-solution activity in the form of data gathering (see MPEP 2106.05(g)) and do not provide integration into a practical application. Claim 19 recites identifying an interface and transmitting the event to the appropriate party via the identified interface. The use of an interface to transmit data to an appropriate entity again merely serves to digitize data sharing / communication steps that could otherwise be achieved as a certain method of organizing human activity, and thus does not provide integration into a practical application.
Accordingly, the additional elements of claims 1, 5-10, 12-13, and 17-20 do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Claims 1, 5-10, 12-13, and 17-20 are directed to an abstract idea.
Step 2B
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a mobile device application, an interface to a scan tool or input device, an interface to a repository, a server, a reporting logic, a GUI logic, a GUI of a user device, computer program code (as in claim 20), electronic health records (as in claim 10), and interfaces (as in claim 19) used for performing the receiving, storing, generating, comparing, identifying, determining, reconciling, ensuring, rendering, reporting, etc. steps of the invention amount to no more than mere instructions to apply the exception using generic computer components. As evidence of the generic nature of the above recited additional elements, Examiner notes that Applicant’s specification is silent to the particular architectures of the mobile device application, the interface to the repository, the server, the logics, and computer program code; Pg 19, L14-29 briefly note that those skilled in the art should readily understand that the methods of the invention “are deliverable to a user processing and rendering device in many forms” and provide various examples of known devices such as application specific integrated circuits, field programmable gate arrays, state machines, controllers, or other hardware components or devices. These disclosures do not indicate that the elements of the invention are particular machines, and instead provide generic examples of computer hardware, such that one of ordinary skill in the art would understand that any generic processing and rendering devices executing software could be used. Fig. 7 & Pg12 L9-16 provide an example of the input device as a keyboard, which is a generic input component for computing devices. Further, Pg8 L22-25 notes that “Any suitable computing device may host the app 132, such as a personal smartphone device, tablet, laptop or PC,” showing that the user device with a GUI is contemplated as including many types of known, generic computing devices with display capabilities. Further, the combination of these additional elements is not expanded upon in the specification as a unique arrangement and as such relies on the knowledge of one of ordinary skill in the art to understand the combination of components within a computer system as a well-known and generic combination for automating an abstract idea that could otherwise be performed as a certain method of organizing human activity and thus do not provide an inventive concept.
The receipt of identifier data from various sources (e.g. an interface of a scan tool as in the independent claims, or optical/photographic means as in claim 12) amounts to insignificant extra-solution activity in the form of mere data gathering, as explained above. Examiner further notes that the receipt or transmission of data over a network is also recognized as a well-understood, routine, and conventional activity in the art, as outlined in MPEP 2106.05(d)(II) and thus does not provide an inventive concept.
Analyzing these additional elements as an ordered combination adds nothing that is not already present when considering the elements individually; the overall effect of the server/computer/logic implementation and user devices with input/GUI/interface elements in combination is to digitize and/or automate a commercial medical device safety reporting and verification operation that could otherwise be achieved as a certain method of organizing human activity. Thus, when considered as a whole and in combination, claims 1, 5-10, 12-13, and 17-20 are not patent eligible.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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 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.
Claims 1, 5-9, 12-13, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Casady et al. (US 20150234995 A1) in view of Reiner (US 20170068792 A1).
Claims 1, 13, and 20
Casady teaches a system for gathering and tracking medical device reports for determining safe usage of medical devices (Casady abstract, Fig. 1, [0030], noting a system for gathering and managing recalls of medical devices to reduce instances of errors during a medical procedure), comprising:
a mobile device application for receiving an identifier of a medical device from an interface to a scan tool or input device, the medical device under consideration for deployment for a patient usage (Casady [0031], [0039], [0059]-[0060], [0064], noting a subscriber processing unit (e.g. a mobile device like a laptop, tablet, smartphone, etc. per [0059]) is integrated with a portable data collection unit (e.g. a bar code scanner, stand-alone camera, or other input device per [0059]) and used by a subscriber to collect product identifier data (e.g. an identifier of a medical device as in [0031]) prior to actual deployment/use of the medical device (e.g. at the site of a medical procedure like a surgery per [0060]));
an interface to a repository for storing the identifier in a repository, further comprising generating a set of entries in the repository based on previous received identifiers, including, for each entry in the set of entries, an indication of either an adverse result or an acceptable result (Casady [0034]-[0036], noting a database stores information including entries of recall information (i.e. an adverse result) associated with specific medical device identifiers like product codes, part numbers, catalog numbers, lot numbers, serial numbers, ID numbers, supplier, etc.);
a server for comparing the identifier to the set of entries in the repository for identifying a match based on a vendor and at least one of a model number, lot number or expiration date (Casady [0030], [0039], [0041], [0049]-[0051], noting a server of the system compares the device identifier to the recall entries stored in the database and identifies matches based on supplier (i.e. vendor) and other features like product code (i.e. model number), lot number, and/or expiration date); and
reporting logic for determining, based on an identity established by the identifier and the comparison, a database match based on receiving a report of an adverse event associated with the identity (Casady [0032], [0039], [0041], noting the system determines matches of the device identifier to recall entries (i.e. reports of an adverse event associated with the identity of the device) stored in the database), the reporting logic further configured to reconcile safe medical device operation based on current and previous anomaly free operation by:
ensuring the set of entries in the repository is free from reported device anomalies corresponding to the identity of the medical device, the anomalies defined by recalls, product expiration, (Casady [0051], [0060], [0064], noting that alerts are sent to a subscriber if the device identifier matches any recall entries or other relevant conditions (e.g. product expiration dates) in the database so that use of the device can be avoided or prevented; such a function indicates that no alert is sent if no matches are found, thereby ensuring that the set of entries in the repository is free from recall or expiration indications corresponding to that device identifier); and
;
GUI logic configured to render on a graphical user interface of a user device, based on the comparison, whether the device has been the subject of a reported anomaly or recall indicative of unsafe usage (Casady [0032], [0051], [0053], [0064], noting that alerts are sent to a subscriber for display at a user device, e.g. via email, text, or dashboard alert if the device identifier matches any recall entries);
the server further configured to:
receive an indication of whether an anomaly indicative of an adverse event was encountered (Casady [0052], noting new product recalls (i.e. indications of whether an anomaly indicative of an adverse event was encountered) can be added to the system at a user interface); and
generate an entry in the repository indicative of the encountered anomaly, the generated entry available for subsequent comparisons (Casady [0052], noting new product recalls can be added to the system for storage in the database and subsequent comparisons);
receive a request to render one or more of the entries in the set of entries; identify a vendor corresponding to a source of the request; and render the entries from the set of entries corresponding only to the identified vendor (Casady [0040], [0057], noting a supplier subscriber (i.e. a vendor) can enter search criteria about their products, and the system returns reports representing gathered information about that specific supplier’s products from the system (e.g. all recalls for a specific set of manufacturers/suppliers as in [0040]), considered equivalent to the system identifying a vendor corresponding to a source of the request (e.g. via supplier ID as in [0044] & [0049]) and rendering entries corresponding only to the identified vendor).
In summary, Casady teaches a medical device recall tracking, reporting, and notification system that allows users to inquire about particular device identifiers to be notified about current recalls, product expirations, etc. at the point of care, as well as create and update recall entries. This reference further contemplates the system aggregating post-operation patient outcomes for reporting purposes (Casady [0056]-[0057]). However, it fails to explicitly disclose that tracked device anomalies or patient outcomes include reported deaths and reported serious injury, that the system can receive an indication of safe operation of the medical device during the current usage attempt, and that received indications of whether an anomaly indicative of an adverse event was encountered represent anomalies encountered during the current usage attempt.
However, Reiner teaches an analogous medical device safety reporting system in which a user may record indications of safe operation as well as indications of adverse events like death and serious injury that are encountered during a current usage attempt (Reiner Fig. 3C, [0271]-[0272], [0291]-[0299], [0320]-[0321], noting entries in a database are accumulated from various reports of outcomes, including no complications or continuing functionality/safety (i.e. an indication of safe operation during the current usage attempt), or presence of complications, malfunctions, or other anomalies like patient death or chronic debilitation (i.e. serious injury) that took place during the current usage attempt; such entries are associated with a given medical device via a device identifier stored in the database as noted in [0128] & [0272]). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the recall reporting system of Casady to also include functionality for recording other types of medical device outcomes (e.g. safe operation or catastrophic events like serious injury or death) encountered during a current usage attempt as in Reiner in order to allow for expanded safety surveillance and warnings to be implemented based on more types of performance/quality indicators so that even early indicators of unsafe device operation (i.e. those recorded prior to an official recall) may be considered during device selection and treatment planning stages, thereby providing care providers with improved insights related to medical device safety and performance (as suggested by Reiner [0268]). The result of such a combination would include a computerized system via which users may submit device-specific entries of recalls (as in Casady) as well as other types of performance/quality outcomes like safe operation or adverse events (as in Reiner) so that new device identifier inquiries (as in Casady) would return alerts of expanded types of device anomalies (e.g. recalls and product expirations as in Casady, and serious injury and death as in Reiner).
Regarding claim 1, Casady in view of Reiner teaches a method for determining safe medical devices (Casady [0064], noting a method for medical device safety) including substantially similar limitations as explained for claim 13 above.
Regarding claim 20, Casady in view of Reiner teaches a computer program embodying program code on a non-transitory computer readable storage medium that, when executed by a processor, performs steps for implementing a method for determining safe medical devices (Casady [0030], [0034], noting the system is implemented by a server data processor performing computerized functions for medical device safety, i.e. a processor executing stored computer program code; see also Reiner [0060], [0080], noting a processor that executes instructions stored on a non-transitory medium such as a hard disk, floppy disk, CD-ROM, etc.), the method comprising substantially similar steps as claim 13, as explained above.
Claims 5 and 17
Casady in view of Reiner teaches the method of claim 1, and the combination further teaches:
generating the entry in the repository based on a first medical device in response to an anomaly encountered in the current usage attempt (Casady [0052], noting new product recalls (i.e. indications of whether an anomaly indicative of an adverse event was encountered) can be added to the database; see also Reiner [0271]-[0272], [0291]-[0299], [0320]-[0321], noting device outcome data such as device malfunctions or complications (i.e. anomalies) may be recorded in the database for cross-referencing to future devices of the same type);
receiving an identifier and a request for a second comparison of a second medical device, the second medical device being the same type as the first medical device (Casady [0039], [0059]-[0060], [0064], noting a subscriber collects product identifier data (e.g. an identifier of a new medical device under consideration for deployment (considered to encompass a second medical device of the same type as a previous device) so that it may be compared/matched to recall entries); and
rendering an indication for preventing usage of the second medical device based on the second comparison (Casady [0032], [0039], [0060], noting the system displays alerts indicating matches of an entered device identifier (e.g. a second medical device matching a previously stored recall of a device of the same type) so that use or implantation of the recalled device may be prevented).
Claim 17 recites substantially similar subject matter as claim 5, and is also rejected as above.
Claim 6
Casady in view of Reiner teaches the method of claim 1, and the combination further teaches wherein the anomalies are indicative of either minor harm, serious injury or a fatality resulting from a previous usage attempt (Reiner [0188], [0295]-[0298], [0320]-[0321], noting device malfunctions, complications, or other anomalies can be recorded at different levels of severity, including minor, major or severe, and catastrophic resulting in patient death).
Claim 7
Casady in view of Reiner teaches the method of claim 1, and the combination further teaches: accumulating the set of entries based on receiving a plurality of usage reports, each usage report of the plurality of usage reports based on a usage attempt and including an identifier indicative of the medical device and whether the usage attempt encountered normal operation or an anomaly (Casady [0052], noting new product recalls (i.e. indications of whether an anomaly indicative of an adverse event was encountered) can be added to the database; see also Reiner [0271]-[0272], [0291]-[0299], [0320]-[0321], noting device outcome data such as device malfunctions or complications (i.e. anomalies) or lack thereof (i.e. normal operation) may be recorded in the database for each utilized medical device).
Claim 8
Casady in view of Reiner teaches the method of claim 7, and the combination further teaches
arranging the set of entries according to a vendor and a model, the model designating a type of the medical device (Casady [0034], Table 1, noting recall entries include associated supplier information (i.e. vendor) and model information designating a type of device like device class, product code, part code, reference number, catalog number, etc.);
identifying, based on a received identifier, a model of the medical device (Casady [0050], Table 3, noting an input identifier for a device includes model information designating a type of the device like device identifier, product code, part code, reference number, catalog number, etc.); and
traversing entries in the set of entries corresponding to the model for determining anomalies encountered with the same model of the medical device (Casady [0049]-[0051], noting device matches are found based on matches in supplier and device identifier (e.g. model information like product code, part code, reference number, catalog number, etc.)).
Claim 9
Casady in view of Reiner teaches the method of claim 1, and the combination further teaches wherein the identifier is an industry recognized unique identifier for the medical device (Casady [0035], noting the device identifier can include a Unique Device identifier as established by the FDA).
Claim 12
Casady in view of Reiner teaches the method of claim 1, and the combination further teaches receiving the identifier of the medical device from one of an optical reader scanning a bar code on the medical device, or a typed alphanumeric identifier from a label on the medical device (Casady [0059]-[0060], noting the subscriber processing unit (e.g. a mobile device like a laptop, tablet, smartphone, etc.) is integrated with a portable data collection unit (e.g. a bar code scanner, stand-alone camera, or other input device) and used by a subscriber to collect the product identifier data).
Claim 18
Casady in view of Reiner teaches the system of claim 13, and the combination further teaches wherein the reporting logic is further configured to reconcile subsequent anomaly free operation by: accessing the set of entries in the repository for identifying patients associated with the medical device; transmitting a proactive inquiry for identifying anomalies presented subsequent to a usage of the medical device; and receiving an indication of whether anomalies occurred post-usage or post-implantation (Casady [0013], [0031]-[0032], noting the system can be utilized to inquire about medical devices that are currently in use in the patient population, such that returned alerts (e.g. indicative of recalls as in Casady as well as other types of anomalies or complications as in the combination with Reiner) notify a user of whether anomalies occurred post-usage or post-implantation of the device in question, e.g. for the purpose of identifying and alerting patients associated with that device who may be affected as in [0013]).
Claim 19
Casady in view of Reiner teaches the system of claim 13, and the combination further teaches wherein the reporting logic is configured to identify an interface to a report gathering authority including at least one of a manufacturer and a governmental entity; determine if the device related event is a serious adverse event; and if so, transmit the device related event to the appropriate party via the identified interface (Casady [0014], [0056]-[0057], noting many entities like global subscribers (e.g. “any person or group that is interested in compiling data of medical devices for studies and journal articles” per [0056], considered to include a manufacturer and/or a governmental entity) as well as device suppliers and manufacturers receive generated reports of recalls (i.e. serious adverse events), post-operation patient outcomes, supplier performance, etc. from the system, e.g. at respective user interface devices as in Fig. 1 & [0036]).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Casady and Reiner as applied to claim 1 above, and further in view of Halpern et al. (US 20160189321 A1).
Claim 10
Casady in view of Reiner teaches the method of claim 1, and the combination further teaches that patients affected by a device recall may be alerted (Casady [0013], [0032]). However, the present combination fails to explicitly disclose identifying an EHR (Electronic Health Records) system; identifying a patient record in the EHR corresponding to a usage of the medical device; and storing the generated entry in the patient record in the EHR. However, Halpern teaches an analogous medical device safety reporting system that includes integration with patient EHRs such that patient records associated with usage of a medical device are identified and indications of adverse events or recalls are stored in the patient record (Halpern [0050], [0058], noting device complaints (i.e. adverse event entries) are recorded in an associated patient’s record in an EHR). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the method of identifying and notifying patients affected by unsafe medical devices as in the combination such that indications of unsafe device events are integrated into a patient’s EHR as in Halpern in order to allow the system to store such indications in direct association with the patient for posterity (as suggested by Halpern [0050]), thereby allowing the patient and patient’s healthcare providers to be fully informed about potential issues with a medical device so that improved care and treatment decisions can be made for the patient.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KAREN A HRANEK whose telephone number is (571)272-1679. The examiner can normally be reached M-F 8:00-4:00 ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shahid Merchant can be reached on 571-270-1360. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/KAREN A HRANEK/ Primary Examiner, Art Unit 3684