DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1-12 are currently pending. Claims 10-12 are withdrawn as being directed to unelected inventions. Claims 1-9 are under examination. As per the amendments filed on 06/18/2026, claims 1-3, 5-6, and 8 are amended.
Priority
The instant application (filed on 05/09/2024) is a national stage of PCT/EP2022/081499 (filed on 11/10/2022), filed under 35 USC 371. Acknowledgment is made of Applicant's claim for foreign priority based on application EP 21209161.5 filed on 11/19/2021. Amended instant claims 1-9 are sufficiently supported in EP 21209161.5 to receive an effective filing date of 11/19/2021.
Response to Arguments
Applicant’s arguments, see Remarks page 7 (Claims Objections), filed 06/18/2026, with respect to the objection to claim 6 have been fully considered and are found persuasive. Therefore, the objection to claim 6 is withdrawn.
Applicant’s arguments, see Remarks page 7 (Claim Rejections - § 112), filed 06/18/2026, with respect to the rejections of claims 1-9 under 35 U.S.C. § 112(b) have been fully considered and are found persuasive. Therefore, the rejections of claims 1-9 are withdrawn.
Applicant’s arguments, see Remarks pages 7-8 (Claim Rejections - § 101), filed 06/18/2026, with respect to the rejections of claims 1-9 under 35 U.S.C. § 101 have been fully considered. Applicant argues:
Claims 1-9 stand rejected under 35 U.S.C. § 101 because the claimed invention is allegedly directed to an abstract idea of a mental process without significantly more. Applicant respectfully traverses the § 101 rejections for at least the following reasons.
Applicant's claims are not directed to an abstract idea. At the very least, the claims prescribe steps to create a specific data structure for a computer that causes it to operate in a specific way - i.e., it creates a specific computing system for executing a firmware function.
Moreover, even when the claims are misconstrued as being directed to an abstract idea, they integrate any abstract idea into a practical application via meaningful limitations recited by the claims. More specifically, the claims create data structures of first and second checksums and cause the computer system to perform non-conventional operations with these checksums to prevent unauthorized or unintended execution of the firmware. An exemplary implementation of the claimed computer-implemented method can be appreciated as follows. The method makes use of a "fake" checksum CRC _ A ("the first checksum does not match a correct checksum") which is added to the code of the patient critical firmware function in order to prevent an unallowed or unintentional execution of the patient critical firmware function. However, after authorization of an execution request the fake checksum CRC A is replaced by a second checksum CRC B which had been stored during initialization in and is now read out from memory. After computing a checksum CRC_OK associated with the patient critical firmware function and obtaining a match with the second checksum CRC B, the firmware function is executed. Just before replacing CRC A by CRC_B, CRC_A had been read out and buffered for later replacing CRC _ B again. These operations are non-conventional and integrate the alleged abstract idea into a practical application for improving operations of the computer. Accordingly, Applicant respectfully requests withdrawal of the§ 101 claim rejections. (06/18/2026 Remarks, pages 7-8)
This argument is not persuasive. The removal of the conditional “if” statements as part of method claim 1 allows for the “executing the patient critical firmware function of the implantable medical device” limitation. However, this generic limitation cannot be considered a particular treatment or prophylaxis under MPEP 2106.04(d)(2) as a practical application of the mental process. The patient critical firmware function could simply be insignificant extra-solution activity such as issuing an alert, data storage, or data transmission. Applicant argues the operations are non-conventional, but nothing on the record attests to any non-conventionality in the generation and comparison of checksums.
Therefore, the rejections of claims 1-9 are maintained.
Applicant’s arguments, see Remarks pages 9-11 (Claim Rejections - § 102/103), filed 06/18/2026, with respect to the rejections of claims 1-9 under 35 U.S.C. § 102 and 35 U.S.C. § 103 have been fully considered. The Examiner notes the conditional “if” statements have been modified to remove the negative contingencies, thereby allowing all limitations of claims 1-9 to be formally considered. Regarding independent claim 1, Applicant argues:
Applicant's claim 1 requires:
1) receiving a request for execution of a firmware function;
2) verifying that a user associated with the request is authorized to run the firmware function;
3) reading a first checksum, wherein the first checksum does not match a correct checksum associated with the firmware function - this is the "fake" checksum;
4) reading a second checksum, wherein the second checksum matches the correct checksum associated with firmware function;
5) writing the second checksum to memory before execution of the firmware function;
6) computing the correct checksum associated with the firmware function and comparing it to the second checksum to ensure the second checksum and the correct checksum match; and
7) executing the firmware function.
The PTO cites to paragraphs [0056]-[0057] of Crawford for allegedly disclosing steps 3-7. Applicant submits that this is a mischaracterization of Crawford.
These paragraphs of Crawford state: "The checksum value or other relevant data may be encrypted with a suitable cryptographical key (e.g., the corresponding key of the key pair used for device 301). The encrypted data is then stored in device 301 as the validation data in some embodiments.
When device 301 attempts to verify the validity of an instance of programming data 308, device 301 recalculates the checksum value or relevant data using the same methodology used to create the original validation data in the instance of programming data 308 and generates local comparison data. Device 301 then decrypts the encrypted data of the validation data using its device key 306. Device 301 compares the decrypted data against the local comparison data. If the two sets of data match, the settings data is valid and device 301 continues with its operations according to the settings data (assuming that there is no applicable data in revocation data 307 to indicate otherwise as discussed herein for some embodiments)."
Crawford uses a checksum scheme to verify validity, wherein a checksum value is encrypted with a key and stored in memory. During a verification of validity operation, Crawford recalculates a checksum value from the request, decrypts the data, and makes a comparison. There is no intentional generation of a first checksum that does not match the correct checksum - i.e., there is no "fake" checksum. (06/18/2026 Remarks, pages 9-10)
This argument is not persuasive. The limitation identified by the Applicant as step 3 (“reading a first checksum from a first memory area of the implantable medical device or providing a first checksum as part of a code area of the patient critical firmware function of the implantable medical device, wherein the first checksum does not match a correct checksum associated with the patient critical firmware function of the implantable medical device”) does not limit the interpretation under BRI to an intentional fake checksum to shut down an operation. All the limitation requires is for a first checksum with an incorrect value to be read. This is the only time the first checksum is discussed in claim 1, where claim 1 does not further describe a role for the first checksum once it is read into the system. The method in Crawford [0057] describes a process where reading an incorrect checksum will stop the process with the medical device while reading a correct checksum will allow the process to continue. This can be reasonably interpreted as encompassing a process where an incorrect checksum is first read from a memory location (which stops the process) and a correct checksum is subsequently read (which allows the process to continue).
The intentional overwriting of the second checksum by the first checksum is not considered until claim 3 (“wherein during execution of the compound command of the patient critical firmware function of the implantable medical device, the second checksum is overwritten by the first checksum, said first checksum being read from a memory buffer of the first memory area or from a further code area of the code area of the patient critical firmware function of the implantable medical device”) and claim 4 (“wherein after overwriting the second checksum by the first checksum, the compound command of the patient critical firmware function of the implantable medical device is terminated”). The Examiner recognizes claims 3 and 4 are not entirely disclosed in Crawford and, therefore, incorporated the teachings of Smith (US 2019/0205244 A1) for claim 2 and Widmaier (EP 2400682 A1) for claims 3 and 4. Therefore, the rejection of claim 1 is maintained.
Applicant additionally argues:
Smith, Widmaier, and Bernstein also fail to disclose or suggest generating a fake checksum or a similar checksum scheme. Accordingly, none of the cited art, whether considered individually or in any combination, discloses or otherwise suggests each and every limitation of independent claim 1. Thus, independent claim 1 is allowable over the cited art, and Applicant respectfully requests withdrawal of the §§ 102/103 claim rejections. (06/18/2026 Remarks, page 11)
This argument is not persuasive. Widmaier teaches a system which modifies a correct checksum (so that the checksums do not match) to produce an error ([0026]). The incorrect (non-matching) checksum is used to intentionally cause an operation to fail ([0027]). In Widmaier, the modification of the checksum is used to program in an error signal and prevent normal (non-error) operations. No specific arguments are presented by the Applicant with respect to Widmaier.
Regarding dependent claims 2-9, Applicant argues:
Dependent claims 2-9 depend cognately from one of independent claim 1, and add further structural features which further remove the presently claimed invention from the cited art. Given at least the distinctions of claim 1 with respect to the cited art, dependent claims 2-9 are allowable over the cited art and a separate discussion of them will not be belabored for the sake of brevity. (06/18/2026 Remarks, page 11)
This argument is not persuasive. The arguments presented with respect to independent claim 1 were not found persuasive. Therefore, the rejections of dependent claims 2-9 are similarly maintained.
Summary: The rejections based on the conditional “if” statements are withdrawn, but the 35 U.S.C. § 101, 102, and 103 rejections for claims 1-9 are maintained.
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.
Section 33(a) of the America Invents Act reads as follows:
Notwithstanding any other provision of law, no patent may issue on a claim directed to or encompassing a human organism.
Claims 1-9 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea (mental process, mathematical relationship) without significantly more.
Step 1
The invention in claims 1-9 is to a statutory subject matter as the claims recite a method for protecting a patient critical firmware function, which would belong to one of the four statutory categories.
Step 2A, Prong One
Claim 1 recites abstract ideas in the form of mathematical concepts and mental processes that "can be performed in the human mind, or by a human using a pen and paper" (see MPEP 2106.04(a)(2) subsections (I) and (III)).
Regarding Claim 1, the limitation “verifying that a user associated with the request is authorized to run the patient critical firmware function” and “comparing it to the second checksum to ensure the
second checksum and the correct checksum match” could be performed by the human mind. The limitation “computing the correct checksum associated with the patient critical firmware function of
the implantable medical device” could be a mathematical concept for creating a checksum.
Step 2A, Prong Two
For the Claim 1 limitations from Step 2A Prong One, the claim does not recite additional elements that integrate the judicial exception into a practical application. Additional elements include “an implantable medical device,” “executing a patient firmware function,” “a computer,” first, second, and third “memory areas,” and first, second, and third “checksums.” The implantable medical device generally links the use of a judicial exception to a particular technological environment or field of use and the computer, containing the memory areas and checksums, is a generic computer structure for performing generic computer functions. Executing the patient firmware function could broadly be interpreted as an insignificant extra-solution activity such as issuing an alert, data storage, or data transmission and cannot be considered a particular treatment or prophylaxis under MPEP 2106.04(d)(2).
- Claims 2- 9: Further define the generic computer functions carried out by the computer code with the insignificant extra-solution activity of data transmission or storage.
- Claims 2, 4, 6, and 8: Further describe the execution of the patient critical firmware function but fail to provide the specificity to establish a practical application of the firmware function as a particular treatment or prophylaxis.
- Claim 8: Further defines the mental processes of computing a checksum and comparing checksums.
Step 2B
For the Claim 1 limitations from Step 2A Prong One, the claim does not recite additional
elements that amount to significantly more than the judicial exception. Additional elements include “an implantable medical device,” “executing a patient firmware function,” “a computer,” first, second, and third “memory areas,” and first, second, and third “checksums.” The implantable medical device generally links the use of a judicial exception to a particular technological environment or field of use and the computer, containing the memory areas and checksums, is a generic computer structure for performing generic computer functions. Executing the patient firmware function could broadly be interpreted as an insignificant extra-solution activity such as issuing an alert, data storage, or data transmission and cannot be considered a particular treatment or prophylaxis under MPEP 2106.04(d)(2).
- Claims 2- 9: Further define the generic computer functions carried out by the computer code with the insignificant extra-solution activity of data transmission or storage.
- Claims 2, 4, 6, and 8: Further describe the execution of the patient critical firmware function but fail to provide the specificity to establish a practical application of the firmware function as a particular treatment or prophylaxis.
- Claim 8: Further defines the mental processes of computing a checksum and comparing checksums.
Applicant argues the claimed operations are non-conventional. Crawford (US 2020/0139141 A1) and Widmaier (EP 2400682 A1) both establish checksums as known options for assessing the validity of control or data operations (Crawford [0055-0057]), Widmaier [0001-0006]). Widmaier teaches an intentional modification of a checksum produces a unique error when it does not match the correct checksum ([0026-0029]). Nothing on the record attests to any non-conventionality in the generation and comparison of checksums.
Therefore, claims 1-9 are directed to a judicial exception, as abstract ideas, without significantly more.
Claim Rejections - 35 USC § 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 and 5-8 are rejected under U.S.C 102(a)(1) and U.S.C 102(a)(2) as being anticipated by Crawford (US 2020/0139141 A1).
Regarding Claim 1, Crawford discloses a computer implemented method for protecting a patient critical firmware function ([0018-0020]) of an implantable medical device ([0031] – implantable medical devices such as pacemakers or defibrillators) against unintended execution ([0018]) via steps of:
• receiving a request for execution of a patient critical firmware function of the implantable medical device ([0033] – request by clinician for a particular setting to be implemented);
• verifying that a user associated with the request is authorized to run the patient critical firmware function ([0033] – authorization required so only intended clinician users can program the device);
• reading a first checksum from a first memory area of the implantable medical device or providing a first checksum as part of a code area of the patient critical firmware function of the implantable medical device, wherein the first checksum does not match a correct checksum associated with the patient critical firmware function of the implantable medical device ([0057] – reading a checksum value of the local programming data which might not match the correct checksum for the device operation – i.e. if the programming checksum is found not to match then the device does not execute the device operation);
• reading a second checksum from a second memory area of the implantable medical device, wherein the second checksum matches the correct checksum associated with the patient critical firmware function of the implantable medical device ([0057] – validation data as the correct checksum in another attempt);
• writing the second checksum to a third memory area of the implantable medical device from which a checksum is read before execution of the patient critical firmware function of the implantable medical device ([0056] – validation data stored);
• computing the correct checksum associated with the patient critical firmware function of the implantable medical device ([0057] - local comparison data is created and stored prior to comparison with validation data) and comparing it to the second checksum to ensure the second checksum and correct checksum match ([0057] – checksum comparison must match with correct value in order to execute the device function); and
• executing the patient critical firmware function of the implantable medical device ([0057] – checksums of local comparison data and validation data are compared where the device function is initiated if the checksums match).
Regarding Claim 5, Crawford anticipates the computer implemented method according to Claim 1, as indicated hereinabove. Crawford further discloses wherein the second checksum is read from a hardware read-only register of the implantable medical device ([0052] – identifiers related to a device function stored in memory where original validation data is stored in memory as stated in [0057]; [0101] – memory includes the use of ROM), and wherein the second checksum is a cyclical redundancy check, XOR, modulus, or cryptographic hash ([0055] – “In some embodiments, validation data is created using a checksum algorithm, a cryptographic hash function, and/or similar suitable processing” and “Known checksum functions apply exclusive-OR (XOR) and/or modular sum operations in succession to each character or value in a sequence of characters or values”).
Regarding Claim 6, Crawford anticipates the computer implemented method according to Claim 1, as indicated hereinabove. Crawford further discloses wherein the patient critical firmware function of the implantable medical device is executed by accessing a graphical user interface of a programmer ([0022] – processor allows the user to program the device via a graphical interface: “(1) provide one or more user interface (UI) screens to interact with a clinician to define therapeutic settings for the IMD, (2) validate the therapeutic settings with the remote server when network connectivity is obtained by obtaining validation data from the remote server that is signed with a key corresponding to the IMD, (3) create validation data that is signed with a temporary key when network connectivity to the remote server is not available, and (4) communicate the therapeutic settings and validation data to the IMD to control therapeutic operations of the IMD”) or an app operating on a mobile device, said programmer or mobile device being configured to communicate wirelessly with the implantable medical device ([0022-0024] – wireless communication between the programmer and device).
Regarding Claim 7, Crawford anticipates the computer implemented method according to Claim 6, as indicated hereinabove. Crawford further discloses wherein a user authentication procedure comprises a password input or a two-factor authentication comprising a password input and an additional security feature on the programmer or a web-interface configured to control the programmer ([0035] – at least discloses a password: “Different systems may require different types of credentials to ascertain user identity and may even require more than one credential. In computer systems, the credential very often takes the form of a user password, which is a secret known only to the individual and the system. Credentials may take other forms, however, including PIN numbers, certificates, tickets, etc”), and wherein the user session comprises a session ID and a timestamp ([0068] – an identifier and timestamp are used to define the session: “The metadata may include relevant data such as patient identifier(s), patient device identifier(s), programming session time and date, the physical location of a programming session, and/or the like”). The instant specification merely refers to the “session ID and timestamp” (page 6, line 20 and page 9, line 27) without further describing the details of how the session is identified.
Regarding Claim 8, Crawford anticipates the computer implemented method according to Claim 1, as indicated hereinabove. Crawford further discloses wherein the correct checksum associated with the patient critical firmware function of the implantable medical device is computed and compared to the second checksum within a predetermined time span ([0055-0057] – the checksum comparison is a mathematical comparison which would require a particular amount of time given a particular processor as part of the hardware) prior to execution of the patient critical firmware function of the implantable medical device ([0057] – checksum comparison occurs before the function of the implantable medical device is executed)
Claim Rejections - 35 USC § 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 for establishing a background for determining obviousness under 35 U.S.C.
103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or non-obviousness.
Claim 2 is rejected under U.S.C 103 as being unpatentable over Crawford (US 2020/0139141 A1) in view of Smith (US 2019/0205244).
Regarding Claim 2, Crawford anticipates the computer implemented method according to Claim 1, as indicated hereinabove. Crawford further discloses wherein the reading of the first checksum from the first memory area of the implantable medical device or the providing of the first checksum as part of the code area of the patient critical firmware function of the implantable medical device ([0057] – reading a checksum value of the local programming data which might not match the correct checksum for the device operation – i.e. if the programming checksum is found not to match then the device does not execute the device operation), the reading of the second checksum from the second memory area of the implantable medical device ([0057] – validation data as the correct checksum in another attempt); the writing of the second checksum to the third memory area of the implantable medical device from which the checksum is read before execution of the patient critical firmware function of the implantable medical device ([0056] – validation data stored); the computing of the correct checksum associated with the patient critical firmware function of the implantable medical device ([0057] - local comparison data is created and stored prior to comparison with validation data); the comparing it to the second checksum ([0057]), and the execution of the patient critical firmware function of the implantable medical device ([0057] – checksums of local comparison data and validation data compared where the device function is initiated if the checksums match). However, Crawford does not disclose these functions are performed by a non-interruptible compound command.
Smith would be considered “reasonably pertinent” (see MPEP 2141.01(a)1) to the claimed invention because Smith teaches modifying commands directed to memory ([0006]) and detecting faulty values in memory ([0323]) via check values such as checksums ([1066]). Smith teaches the code can be an atomic operation ([0057] – “Code may use an operation (or set of operations) that may be an atomic operation (also linearizable, indivisible, uninterruptible, etc.) that may appear (e.g. to the rest of the system, etc.) to occur instantaneously, as a single event, etc.”). The purpose of using atomic memory access operations is to prevent conflicting access to a single memory location by executing commands as a single, uninterruptable instruction ([0057] – “One mechanism to prevent race conditions etc. may guarantee that operations are atomic. An atomic operation is executed as a single instruction without interruption and without conflicting access to memory locations used. Atomic operations may be used as a base, building block, foundation, etc. for other mechanisms (e.g. more flexible operations, to create critical regions, etc.)”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to alter Crawford’s checksum error detecting comparison used to authorize a stimulation device function by incorporating the atomic error checking using checksums in Smith. Both Crawford and Smith assess the data integrity of computational functions using reference checksums and Smith establishes atomic command structures can be used to execute the error checking procedure as one uninterruptable instruction in order to prevent conflicting access to a memory location shared between two commands. Therefore, a person of ordinary skill in the art would be motivated to improve the method of Crawford by incorporating the atomic error checking using checksums in Smith.
Claims 3-4 are rejected under U.S.C 103 as being unpatentable over Crawford (US 2020/0139141 A1) in view of Smith (US 2019/0205244 A1) and Widmaier (EP 2400682 A1).
Regarding Claim 3, the computer implemented method is obvious over Crawford in view of Smith according to Claim 2, as indicated hereinabove. Crawford discloses memory locations having incorrect and correct checksum values for executing a function of the electrical stimulator device ([0057]). The stimulation only executes if the validation and local data match using the checksum comparison ([0057]). However, Crawford does not disclose wherein during execution of the compound command of the patient critical firmware function of the implantable medical device, the second checksum is overwritten by the first checksum, said first checksum being read from a memory buffer of the first memory area or from a further code area of the code area of the patient critical firmware function of the implantable medical device.
Widmaier would be considered “reasonably pertinent” (see MPEP 2141.01(a)1) to the claimed invention because Widmaier teaches using checksums to detect errors between memory locations ([0006] – the vehicle control is only provided as an example environment of error checking with a checksum, [0028]-[0029]). Widmaier teaches a system which modifies a correct checksum so that the checksums do not match and produce an error ([0026] – “The checksum 320 may e.g. be a CRC checksum. First, the sender prepares the data frame 300 comprising the actual data 310 and the correct 45 checksum 320. The sender knows of some internal error and wants to prevent the receiver to use the data 310. Therefore, the correct checksum 320 is changed by e.g. inverting all or distinct bits. Then the information, i.e. the data frame, is sent out”). The incorrect (non-matching) checksum is used to intentionally cause an operation to fail ([0027] – “The receiver receives the data frame 300' comprising the actual data 310 and the modified checksum 320'. The receiver calculates the correct checksum out of the actual data 310 and compares it to the received checksum 320'. The result is that they are different, which means that the data 310 cannot be used”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to alter Crawford’s checksum error detecting comparison used to authorize a stimulation device function by incorporating a feature to modify a correct checksum in memory to prevent execution of a command in Widmaier. Both Crawford and Widmaier assess whether a command is executed based on whether a checksum match occurs and Widmaier establishes a checksum in memory can be modified so that the command being tested intentionally fails as a mechanism to prevent that command from being executed due to a perceived error condition. Therefore, a person of ordinary skill in the art would be motivated to improve the method of Crawford by incorporating changing a correct checksum, in a particular fashion so that it no longer matches the reference, to prevent command execution in Widmaier (which could similarly intentionally stop the stimulation command in Crawford).
Regarding Claim 4, the computer implemented method is obvious over Crawford in view of Smith and Widmaier according to Claim 3, as indicated hereinabove. Crawford discloses memory locations having incorrect and correct checksum values for executing a function of the electrical stimulator device ([0057]). The stimulation only executes if the reference and local data match using the checksum comparison ([0057]). However, Crawford does not disclose wherein after overwriting the second checksum by the first checksum, the compound command of the patient critical firmware function of the implantable medical device is terminated.
As stated in claim 2, the proposed combination with Smith yields code using atomic operations ([0057]). The purpose of using atomic memory access operations is to prevent conflicting access to a single memory location by executing commands as a single, uninterruptable instruction ([0057]).
As stated in claim 3, the proposed combination with Widmaier yields a system which modifies a correct checksum so that the checksums do not match and produce an error ([0026]). The incorrect (non-matching) checksum is used to intentionally cause an operation to fail due to a perceived error ([0027]), which could similarly intentionally stop the stimulation command in Crawford due to a perceived error.
Claim 9 is rejected under U.S.C 103 as being unpatentable over Crawford (US 2020/0139141 A1) in view of Bernstein (US 2015/0293803 A1).
Regarding Claim 9, Crawford anticipates the computer implemented method according to Claim 1, as indicated hereinabove. Crawford discloses stored reference validation data to be compared with local data using a checksum ([0057]). Crawford does not disclose wherein the second checksum is written at a factory initialization of the implantable medical device to a predefined memory cell, said memory cell being accessible by running a predefined register code.
Bernstein, in the same field of endeavor of validating medical device settings to improve patient safety ([0002-0003]), teaches the reference checksum data is stored during the manufacturing process for the device ([0202] – “The reference checksum is a checksum for SCA 304 codetext (and/or additional data associated with SCA 304) in an uncorrupted state (e.g., a checksum calculated previously during manufacturing and testing and stored as a reference checksum for later integrity checks). In some instances, the reference checksum may be stored as part of reference data 408. At block 1315, it is determined based on the comparison whether SCA 304 codetext is corrupted”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to alter Crawford’s reference value for comparison during a checksum (to authorize a stimulation device’s function) by incorporating a reference checksum established and stored during the manufacturing process (factory setting) in Bernstein. Both Crawford and Bernstein assess the data integrity of medical device functions using reference checksums and Bernstein establishes a reference checksum can be added during the factory manufacturing process (i.e. the reference is present throughout the entire lifetime of the device) and accessible via coding. Therefore, a person of ordinary skill in the art would be motivated to improve the method of Crawford by incorporating the reference checksum established during the manufacturing process (factory setting) in Bernstein.
Conclusions
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Examiner Benjamin Schmitt, whose telephone number is 703-756-1345. The examiner can normally be reached on Monday-Friday from 9:00 am to 5:00 pm.
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, Jennifer McDonald can be reached at 571-270-3061. 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.
/Benjamin A. Schmitt/
Examiner
Art Unit 3796
/ALLEN PORTER/Primary Examiner, Art Unit 3796
Prosecution Insights