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 .
The following is a Final Office action in response to communications received 12/02/2025.
Response to Amendment
Claims 3, 10, and 15 have been cancelled.
Claims 1, 2, 4-9, 11-14, and 16-20 have been amended.
Claims 1, 2, 4-9, 11-14, and 16-20 have been examined.
The rejection of claims 14-20 under 35 U.S.C 101 based on the remarks made by the applicant in the reply filed on 12/02/2025.
Applicant’s arguments with respect to claims 1, 8, and 15 regarding the new limitations: “receiving a data block comprising host data and an expected encryption state of the host data” and “determining an expected compression ratio of the host data based on the received expected encryption state of the host data” 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 § 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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1, 2, 4-6, 8, 9, 11, 12, 14, and 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over US 12235961 to Davies et al (hereinafter Davies) and prior art of record WO 2023232239 A1 to Natanzon (hereinafter Natanzon).
As per claim 1, Davies teaches:
A computer-implemented method, comprising:
receiving a data block comprising host data and an expected encryption state of the host data, wherein the received expected encryption state includes one of: an encrypted state, a partially encrypted state, or an unencrypted state (Davies: column 5, lines 31-35: The malware mitigator 208 may determine the compressibility of one or more of data to be written (e.g., data transmitted from the host computing device 202 to be written to a data volume 224A-C). Column 6, lines 19-22: The malware mitigator 208 may also look to determine whether other data that is predefined to be unencrypted, such as database files and host system metadata, are incompressible, i.e., if the data received from the host computing device is host system metadata or database files, the type of the data which is indicated in the received data gives the encryption state of the received data which is unencrypted state);
determining an expected compression ratio of the host data based on the received expected encryption state of the host data (Davies: column 5, line 31-40: The determined compressibility may include a compression ratio. Equation 1 shows an example equation for determining the compression ratio. Column 5, line 63-column 6, line 10: For example, the storage controller may detect that a compressibility of data including one or more of a current compressibility of the data and a change in compressibility of the data satisfies a data corruption condition. To determine the satisfaction of the data corruption condition, the malware mitigator 208 may compare the compressibility or change in compressibility with a predefined threshold compressibility value or a predefined threshold compressibility change value. Column 6, lines 19-22: The malware mitigator 208 may also look to determine whether other data that is predefined to be unencrypted, such as database files and host system metadata, are incompressible. It is inherent that a change in compressibility based on the current compressibility of the data is calculated based on an expected compressibility of the type (i.e., encryption state) of data);
determining an actual encryption state for the host data based on a first comparison between the determined expected compression ratio of the host data and an actual compressed ratio of the host data (Davies: column 1, lines 7-14: A common technique used by ransomware is to encrypt data on a computer system, making the data inaccessible by its owners. One attribute of encrypted data is its high entropy. High entropy data can be less compressible than low entropy data. Storage systems that compress data can detect data that happens to have been encrypted by ransomware as incompressible. Column 5, line 63-column 6, line 10: For example, the storage controller may detect that a compressibility of data including one or more of a current compressibility of the data and a change in compressibility of the data satisfies a data corruption condition. To determine the satisfaction of the data corruption condition, the malware mitigator 208 may compare the compressibility or change in compressibility with a predefined threshold compressibility value or a predefined threshold compressibility change value, i.e., the data corruption state indicates the actual encrypted state of the data and is determined based on comparing a change in compressibility to a threshold value); and
storing a tag for the host data based on a second comparison between the determined actual encryption state of the host data and the received expected encryption state of the host data (Davies: column 6, lines 32-36: If the data corruption condition is satisfied, the storage controller 210 and/or its malware mitigator 208 may determine that the data that satisfies the data corruption condition is suspicious data and may take one or more responsive actions).
Davies does not explicitly teach storing a tag for the host data. However, Natanzon teaches:
storing a tag for the host data (Natanzon: page 3, lines 10-21: Ransomware encrypts data, and encrypted data has a much higher entropy than other data. If the average entropy increases significantly it is an indication of ransomware. This is due to the fact encrypted data has a higher entropy than nonencrypted data. Page 4, lines 32-34 and page 5, lines 1-15: store one or more data chunks in the backup storage; store metadata in association with each data chunk in the backup storage; store ransomware detection information in the metadata, wherein the ransomware detection information comprises one or more indicators for the presence of ransomware. The ransomware detection information comprises an indicator for an entropy value of the data chunk).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Natanzon in the invention of Davies to include the above limitations. The motivation to do so would be to detect ransomware in a backup storage, which is less compute intensive (Natanzon: page 4, lines 23-24).
As per claim 8, Davies teaches:
A system, comprising:
a processing circuitry configured to:
receive a data block comprising host data associated with and an expected encryption state of the host data, wherein the received expected encryption state includes one of: an encrypted state, a partially encrypted state, or an unencrypted state (Davies: column 5, lines 31-35: The malware mitigator 208 may determine the compressibility of one or more of data to be written (e.g., data transmitted from the host computing device 202 to be written to a data volume 224A-C). Column 6, lines 19-22: The malware mitigator 208 may also look to determine whether other data that is predefined to be unencrypted, such as database files and host system metadata, are incompressible, i.e., if the data received from the host computing device is host system metadata or database files, the type of the data which is indicated in the received data gives the encryption state of the received data which is unencrypted state);
determine an expected compression ratio of the host data based on the received expected encryption state of the host data (Davies: column 5, line 31-40: The determined compressibility may include a compression ratio. Equation 1 shows an example equation for determining the compression ratio. Column 5, line 63-column 6, line 10: For example, the storage controller may detect that a compressibility of data including one or more of a current compressibility of the data and a change in compressibility of the data satisfies a data corruption condition. To determine the satisfaction of the data corruption condition, the malware mitigator 208 may compare the compressibility or change in compressibility with a predefined threshold compressibility value or a predefined threshold compressibility change value. Column 6, lines 19-22: The malware mitigator 208 may also look to determine whether other data that is predefined to be unencrypted, such as database files and host system metadata, are incompressible. It is inherent that a change in compressibility based on the current compressibility of the data is calculated based on an expected compressibility of the type (i.e., encryption state) of data);
compress the host data using a compression model based on the determined expected compression ratio (Davies: column 5, lines 59-61: The storage controller 210 may use any compression method to compress the data (e.g., Lempel-Ziv compression));
determine, based on an output of the compression model, an actual compressed ratio of the host data (Davies: column 5, lines 31-40: The malware mitigator 208 may determine the compressibility of one or more of data to be written (e.g., data transmitted from the host computing device 202 to be written to a data volume 224A-C) or data already written to a data volume 224A-C at any level of data storage. The determined compressibility may include a compression ratio. Equation 1 shows an example equation for determining the compression ratio);
determine an actual encryption state for the host data based on a first comparison between the determined expected compression ratio of the host data and the actual compressed ratio of the host data (Davies: column 1, lines 7-14: A common technique used by ransomware is to encrypt data on a computer system, making the data inaccessible by its owners. One attribute of encrypted data is its high entropy. High entropy data can be less compressible than low entropy data. Storage systems that compress data can detect data that happens to have been encrypted by ransomware as incompressible. Column 5, line 63-column 6, line 10: For example, the storage controller may detect that a compressibility of data including one or more of a current compressibility of the data and a change in compressibility of the data satisfies a data corruption condition. To determine the satisfaction of the data corruption condition, the malware mitigator 208 may compare the compressibility or change in compressibility with a predefined threshold compressibility value or a predefined threshold compressibility change value, i.e., the data corruption state indicates the actual encrypted state of the data and is determined based on comparing a change in compressibility to a threshold value); and
store a tag for the host data based on a second comparison between the determined actual encryption state of the host data and the received expected encryption state of the host data (Davies: column 6, lines 32-36: If the data corruption condition is satisfied, the storage controller 210 and/or its malware mitigator 208 may determine that the data that satisfies the data corruption condition is suspicious data and may take one or more responsive actions).
Davies does not explicitly teach storing a tag for the host data. However, Natanzon teaches:
storing a tag for the host data (Natanzon: page 3, lines 10-21: Ransomware encrypts data, and encrypted data has a much higher entropy than other data. If the average entropy increases significantly it is an indication of ransomware. This is due to the fact encrypted data has a higher entropy than nonencrypted data. Page 4, lines 32-34 and page 5, lines 1-15: store one or more data chunks in the backup storage; store metadata in association with each data chunk in the backup storage; store ransomware detection information in the metadata, wherein the ransomware detection information comprises one or more indicators for the presence of ransomware. The ransomware detection information comprises an indicator for an entropy value of the data chunk).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Natanzon in the invention of Davies to include the above limitations. The motivation to do so would be to detect ransomware in a backup storage, which is less compute intensive (Natanzon: page 4, lines 23-24).
As per claim 14, Davies teaches:
A computer program product for malware encryption detection, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions when executed by a system cause the system to execute operations comprising:
receiving a data block comprising host data associated with and an expected encryption state of the host data, wherein the received expected encryption state includes at least one of: an encrypted state, a partially encrypted state, or an unencrypted state (Davies: column 5, lines 31-35: The malware mitigator 208 may determine the compressibility of one or more of data to be written (e.g., data transmitted from the host computing device 202 to be written to a data volume 224A-C). Column 6, lines 19-22: The malware mitigator 208 may also look to determine whether other data that is predefined to be unencrypted, such as database files and host system metadata, are incompressible, i.e., if the data received from the host computing device is host system metadata or database files, the type of the data which is indicated in the received data gives the encryption state of the received data which is unencrypted state);
determining an expected compression ratio of the host data based on the received expected encryption state of the host data (Davies: column 5, line 31-40: The determined compressibility may include a compression ratio. Equation 1 shows an example equation for determining the compression ratio. Column 5, line 63-column 6, line 10: For example, the storage controller may detect that a compressibility of data including one or more of a current compressibility of the data and a change in compressibility of the data satisfies a data corruption condition. To determine the satisfaction of the data corruption condition, the malware mitigator 208 may compare the compressibility or change in compressibility with a predefined threshold compressibility value or a predefined threshold compressibility change value. Column 6, lines 19-22: The malware mitigator 208 may also look to determine whether other data that is predefined to be unencrypted, such as database files and host system metadata, are incompressible. It is inherent that a change in compressibility based on the current compressibility of the data is calculated based on an expected compressibility of the type (i.e., encryption state) of data);
determining an actual encryption state for the host data based on a first comparison between the determined expected compression ratio of the host data and an actual compressed ratio of the host data (Davies: column 1, lines 7-14: A common technique used by ransomware is to encrypt data on a computer system, making the data inaccessible by its owners. One attribute of encrypted data is its high entropy. High entropy data can be less compressible than low entropy data. Storage systems that compress data can detect data that happens to have been encrypted by ransomware as incompressible. Column 5, line 63-column 6, line 10: For example, the storage controller may detect that a compressibility of data including one or more of a current compressibility of the data and a change in compressibility of the data satisfies a data corruption condition. To determine the satisfaction of the data corruption condition, the malware mitigator 208 may compare the compressibility or change in compressibility with a predefined threshold compressibility value or a predefined threshold compressibility change value, i.e., the data corruption state indicates the actual encrypted state of the data and is determined based on comparing a change in compressibility to a threshold value);
storing a tag for the host data based on a second comparison between the determined actual encryption state of the host data and the received expected encryption state of the host data (Davies: column 6, lines 32-36: If the data corruption condition is satisfied, the storage controller 210 and/or its malware mitigator 208 may determine that the data that satisfies the data corruption condition is suspicious data and may take one or more responsive actions); and
that the received expected encryption state of the host data indicates the unencrypted state and the determined actual encryption state of the host data indicates the encrypted state (Davies: column 6, lines 19-22: The malware mitigator 208 may also look to determine whether other data that is predefined to be unencrypted, such as database files and host system metadata, are incompressible (encrypted).
Davies teaches taking one or more responsive actions but does not explicitly teach storing a tag for the host data and updating the stored tag for the host data to indicate malicious data based on determining that the received expected encryption state of the host data indicates the unencrypted state and the determined actual encryption state of the host data indicates the encrypted state. However, Natanzon teaches:
storing a tag for the host data (Nataonzon: page 4, lines 32-34 and page 5, lines 1-15: store one or more data chunks in the backup storage; store metadata in association with each data chunk in the backup storage; store ransomware detection information in the metadata, wherein the ransomware detection information comprises one or more indicators for the presence of ransomware. The ransomware detection information comprises an indicator for an entropy value of the data chunk); and
updating the stored tag for the host data to indicate malicious data based on determining that the received expected encryption state of the host data indicates the unencrypted state and the determined actual encryption state of the host data indicates the encrypted state (Natanzon: page 3, lines 10-21: Ransomware encrypts data, and encrypted data has a much higher entropy than other data (compassed data is also similar). The data may be chunked and the entropy may be calculated for each data chunk. The total change in the entropy of all the data may be taken into account as a parameter for detecting ransomware. If the average entropy increases significantly it is an indication of ransomware. This is due to the fact encrypted data has a higher entropy than nonencrypted data. Non-encrypted data like text or code is more ordered data, and thus has lower entropy. Page 9, lines 1-20: receiving data from a primary storage; separating the received data into one or more received data chunks; determining, for each received data chunk, whether the received data chunk is already stored in the backup storage; if the received data chunk is already stored in the backup storage, adding a pointer to the location of the received data chunk in the primary storage to the metadata stored in association with the already stored data chunk; and if the received data chunk is not yet stored in the backup storage, storing the received data chunk in the backup storage system, store metadata including a pointer to the location of the received data chunk in the primary storage in association with the data chunk, and store the ransomware detection information in the metadata. In an implementation form of the third aspect, the method further comprises determining the ransomware detection information based on the received data chunk before storing the ransomware detection information in the metadata. Page 15, lines 23-page 16, line 5: The device 100 may calculate the ransomware detection information 104, which can then be used by a ransomware detection device. If the data chunk 101 is new, the device 100 may calculate one or more of the above-described indicators 201, 301, 302, 303, 304 of ransomware, and stores them in the metadata 102 of the data chunk. If there are clear indications of ransomware, the device 100 may notify an upper layer, and may inform a ransomware detection engine of the suspicious activity, i.e., the metadata (tag) of the data chunk is updated with ransomware detection information when ransomware is detected).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Natanzon in the invention of Davies to include the above limitations. The motivation to do so would be to detect ransomware in a backup storage, which is less compute intensive (Natanzon: page 4, lines 23-24)
As per claims 2 and 9, Davies in view of Natanzon teaches:
The computer-implemented method of claim 1, further comprising: updating the stored tag for the host data to indicate malicious data based on determining that the received expected encryption state of the host data indicates the unencrypted state and the actual encryption state of the host data indicates the encrypted state (Natanzon: page 3, lines 10-21: Ransomware encrypts data, and encrypted data has a much higher entropy than other data. The data may be chunked and the entropy may be calculated for each data chunk. The total change in the entropy of all the data may be taken into account as a parameter for detecting ransomware. If the average entropy increases significantly it is an indication of ransomware. This is due to the fact encrypted data has a higher entropy than nonencrypted data. Non-encrypted data like text or code is more ordered data, and thus has lower entropy. Page 15, lines 23-page 16, line 5: shows a case, in which the received data chunk 101 is not yet stored in the backup storage 110. In this case, the device 100 is configured to store the data chunk 101 in the backup storage 110 (for the first time), store metadata 102 including a pointer 103 to the location of the data chunk 101 in the primary storage 110 in association with the data chunk 101, and store the ransomware detection information 104 in the metadata 102. The device 100 may calculate the ransomware detection information 104, which can then be used by a ransomware detection device. If the data chunk 101 is new, the device 100 may calculate one or more of the above-described indicators 201, 301, 302, 303, 304 of ransomware, and stores them in the metadata 102 of the data chunk. If there are clear indications of ransomware, the device 100 may notify an upper layer, and may inform a ransomware detection engine of the suspicious activity, i.e., the metadata (tag) of the data chunk is updated with ransomware detection information when ransomware is detected).
The examiner provides the same rationale to combine prior arts Davies and Natanzon as in claim 1 above.
As per claims 4 and 16, Davies in view of Natanzon teaches:
The computer-implemented method of claim 1, further comprising: inputting the host data to a compression model, wherein the compression model is configured to compress the host data based on the determined expected compression ratio (Davies: column 5, lines 59-61: The storage controller 210 may use any compression method to compress the data (e.g., Lempel-Ziv compression)); and determining, based on an output of the compression model, the actual compressed ratio of the host data (Davies: column 5, lines 31-40: The malware mitigator 208 may determine the compressibility of one or more of data to be written (e.g., data transmitted from the host computing device 202 to be written to a data volume 224A-C) or data already written to a data volume 224A-C at any level of data storage. The determined compressibility may include a compression ratio. Equation 1 shows an example equation for determining the compression ratio).
As per claims 5 and 18, Davies in view of Natanzon teaches:
The computer-implemented method of claim 4, further comprising: inputting the host data to the compression model based on determining that the received expected encryption state of the host data indicates one of the partially encrypted state or the unencrypted state (Davies: column 5, lines 31-35 and 59-61: The malware mitigator 208 may determine the compressibility of one or more of data to be written (e.g., data transmitted from the host computing device 202 to be written to a data volume 224A-C). The storage controller 210 may use any compression method to compress the data (e.g., Lempel-Ziv compression). Column 6, lines 19-22: The malware mitigator 208 may also look to determine whether other data that is predefined to be unencrypted, such as database files and host system metadata, are incompressible).
As per claims 6, 12, and 19, Davies in view of Natanzon teaches:
The computer-implemented method of claim 4, further comprising: inputting the host data to the compression model at periodic intervals based on the determining that the received expected encryption state of the host data indicates the encrypted state (Davies: column 8, lines 53-67: The malware mitigator 208 may check the compressibility or change in compressibility at predefined rates or in response to predefined events. For example, the malware mitigator 208 may check the compressibility or change in compressibility of vulnerable data at …, at regular intervals).
As per claim 11, Davies in view of Natanzon teaches:
The system of claim 8, wherein the processing circuitry is further configured to: compress the host data using the compression model based on the determining that the received expected encryption state of the host data indicates one of the partially encrypted state or the unencrypted state (Davies: column 5, lines 31-35 and 59-61: The malware mitigator 208 may determine the compressibility of one or more of data to be written (e.g., data transmitted from the host computing device 202 to be written to a data volume 224A-C). The storage controller 210 may use any compression method to compress the data (e.g., Lempel-Ziv compression). Column 6, lines 19-22: The malware mitigator 208 may also look to determine whether other data that is predefined to be unencrypted, such as database files and host system metadata, are incompressible).
As per claim 17, Davies in view of Natanzon teaches:
The computer program product of claim 14, wherein the program instructions further cause the system to execute the operations further comprising: updating the actual encryption state for the host data to an encryption state based on the determining that the actual compressed ratio of the host data is less than the determined expected compression ratio (Davies: Column 5, line 63-column 6, line 10: For example, the storage controller may detect that a compressibility of data including one or more of a current compressibility of the data and a change in compressibility of the data satisfies a data corruption condition. To determine the satisfaction of the data corruption condition, the malware mitigator 208 may compare the compressibility or change in compressibility with a predefined threshold compressibility value or a predefined threshold compressibility change value. Natanzon: page 5, lines 1-17: In an implementation form of the first aspect, the ransomware detection information comprises an indicator for an entropy value of the data chunk. As mentioned above, the entropy value of data is a good indicator for encrypted data, and thus ransomware-affected data. In particular, changes in entropy. In an implementation form of the first aspect, the indicator for the entropy value comprises 3-8 bits per each kB of data of the data chunk).
Claims 7, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Davies in view of Natanzon as applied to claims 1, 8, and 14 above, and further in view of prior art of record US 20110231923 to Bollay et al (hereinafter Bollay).
As per claims 7, 13, and 20, Davies in view of Natanzon does not teach the limitations of claims 7, 13, and 20. However, Bollay teaches:
further comprising: transmitting a first message to a host, wherein the first message is transmitted to determine a participation of the host in an encryption state communication; receiving, based on the transmitted first message, a second message from the host, wherein the second message indicates the participation of the host in the encryption state communication; determining, based on the received second message, that the host is participating in the encryption state communication; and receiving, from the host, the host data associated with the received expected encryption state of the host data based on the determining that the host is participating in the encryption state communication (Bollay: [0023]: An SSL connection is created at the request of a client device or a server device that are endpoints of an established SSL session. Regardless of which device requests the SSL connection, one or more keys used to encrypt/decrypt data transmitted over the SSL connection are independently derived by the client device and the server device based on the master secret of the associated SSL session. [0027]: Once an SSL session has been established, either the client device or the server device may requests that an SSL connection be created, i.e., the server/client determines based on receiving the request from the client/server that an SSL connection be created that the client/server is participating in an encrypted state communication. Creation of an SSL session includes independently generating a key at both the client device and the server device based on the shared master secret. Connection keys may include, but are not limited to, cipher keys used to encrypt and decrypt communicated data over the SSL session, and/or authentication keys used verify messages received over the SSL session. The client device and the server device may then use their respective instances of the connection key(s) to generate and send messages containing encrypted payloads to each other. Also, [0031]-[0033]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to employ the teachings of Bollay in the invention of Davies in view of Natanzon to include the above limitations. The claim would have been obvious because a particular known technique was recognized as part of the ordinary capabilities of one skilled in the art (see KSR Int’l Co. v. Teleflex Inc. 550 U.S. ___, 82 USPQ2d 1385 (Supreme Court 2007) (KSR)).
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 MADHURI R HERZOG whose telephone number is (571)270-3359. The examiner can normally be reached 8:30AM-4:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Taghi Arani can be reached at (571)272-3787. 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.
MADHURI R. HERZOG
Primary Examiner
Art Unit 2438
/MADHURI R HERZOG/Primary Examiner, Art Unit 2438