DETAILED ACTION
Claims 1-20 have been examined.
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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 04/15/2024 has been considered by the examiner.
Claim Rejections - 35 USC § 103
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over United States Patent Application Publication No. US 20220270725 A1 to DeRosa-Grund, hereinafter DeRosa-Grund, and further in view of United States Patent Application Publication No. US 20130111552 A1 to Grube et al., hereinafter Grube.
Regarding claim 1, DeRosa-Grund discloses an apparatus comprising:
a first storage comprising a first partition and a second partition, the first partition and the second partition being defined by an operating system, the first partition being accessible to a first user using the operating system (Figure 6, paragraph 56, “assign the objects to multiple different partitions” and “the central receiving server is able to be one or more servers storing the platform operating system 206”, and paragraph 60, “for each of the partitions, the platform operating system (as executed by the platform server(s)) 206 assigns a different one of the nodes as a leader for that partition at the step 602. The platform operating system 206 receives a plurality of objects each including a unique transaction identifier and details of a single transaction between any two or more of the users at the step 604. The platform operating system 206 assigns each of the objects to one of the partitions at the step 606. The platform operating system 206 provides each of the objects to the nodes that lead the partition that the object is assigned to at the step 608.”),
the second partition being inaccessible to the first user (paragraph 36, “A plurality of MIDCs can be combined to form a micro-identifier chain arrays for the transaction platform. In such embodiments, for each user, only a specified single transaction block of their micro-identification chain that stores de-identified user data is able to be accessed by the notary blockchain(s) in order to form on-chain transactions. The data stored on the notary chain(s), and the other single transaction blocks of the micro-identification chain(s) is kept secure from any intruders.”, paragraph 72, “The notary module is the only module within the cluster permitted to execute operations with these keys (e.g. sign, encrypt, decrypt, etc.). As a result, the notary private keys are never known or accessible by the system”, paragraph 115, “the notary engine is able to access blocks of the micro-identification blockchains 202 including the encoded identifier and the set of personal information as encrypted, but restricted from accessing any blocks of the micro-identification chains 202 that include the native identifier”, and paragraph 179, “If it is determined that permission is not given, the module is able to send an access denial message to the entities requesting access and/or removing any access privileges”);
a communication interface (paragraph 119, “graphical user interface(s)”, “Examples of suitable computing devices include a personal computer, a laptop computer, a computer workstation, a server, a datacenter, a mainframe computer, a handheld computer, a personal digital assistant, a cellular/mobile telephone, a smart appliance, a gaming console, a digital camera, a digital camcorder, a camera phone”, and paragraph 189, “wireless transceivers”);
and a processor coupled to the first storage and the communication interface (paragraph 11, “user device processor”, paragraph 12, “device processor”, paragraph 19, “when executed by the entity device processor the health application is operable to enable the provider to input the updated electronic health data”, paragraph 119, “processor”, and paragraph 189, “executed by one or more processors of one or more of the electronic devices”),
wherein the processor is configured to:
process a first data, the first data comprising a second data and a third data (paragraph 11, “generate an electronic health record non-fungible token (EHRNFT) based on the selected portion of the electronic health data, the EHRNFT including a token identifier and the selected portion, store the EHRNFT on the micro-identification blockchain dedicated to the user as a single block separate from any existing blocks of the micro-identification blockchain”, paragraphs 12, 13, 19, and paragraph 167, “The creation of the ID and EHR NFTs is able to comprise generating a unique identifier for the NFT (e.g. a hash or other mathematical result of input the dataset) to be stored with the dataset as a block (e.g. single transaction block on the blockchain). In some embodiments, all of the collected health records (e.g. from multiple different sources) are combined into a single dataset that is used to generate the EHRNFT for the user. Alternatively or in addition, separate EHRNFTs are able to be created for separate portions of the user EHRs.”);
obtain the second data and the third data based on the first data (paragraph 12, “receiving the health record request message”, paragraph 13, “generate an updated EHRNFT based on the another portion of the updated electronic health data”, paragraphs 16 and 17, “providing access to the portion of the EHRNFT upon receiving input of the permission from the user”, and paragraph 167, “The creation of the ID and EHR NFTs is able to comprise generating a unique identifier for the NFT (e.g. a hash or other mathematical result of input the dataset) to be stored with the dataset as a block (e.g. single transaction block on the blockchain). In some embodiments, all of the collected health records (e.g. from multiple different sources) are combined into a single dataset that is used to generate the EHRNFT for the user. Alternatively or in addition, separate EHRNFTs are able to be created for separate portions of the user EHRs.”);
store the second data at the first partition (paragraph 14, “the micro-identification blockchain stored on a non-transitory computer-readable memory cluster” and paragraph 19, “storing the another EHRNFTs on the micro-identification blockchain dedicated to the user on another separate block”).
DeRosa-Grund discloses the claimed invention, as cited above. However, DeRosa-Grund is not relied upon to disclose the claim limitations pertaining to “send the third data to a second storage via the communication interface; remove the third data from the apparatus; and generate the first data by using the second data and by obtaining the third data via the communication interface”. Grube discloses said claim limitations, as cited below. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Grube with the teachings of DeRosa-Grund so that “the first slice of each of the data segments is to be stored in a first DS unit 36, the second slice of each of the data segments is to be stored in a second DS unit 36, etc. In this manner, the data is encoded and distributedly stored at physically diverse locations to improved data storage integrity and security” (Grube – paragraph 48).
Further regarding claim 1, Grube discloses send the third data to a second storage via the communication interface; remove the third data from the apparatus; and generate the first data by using the second data and by obtaining the third data via the communication interface (paragraph 38, “the DS managing unit 18 coordinates the creation of a vault (e.g., a virtual memory block) within the DSN memory 22 for a user device (for a group of devices, or for public access). The DS managing unit 18 also determines the distributed data storage parameters for the vault. In particular, the DS managing unit 18 determines a number of slices (e.g., the number that a data segment of a data file and/or data block is partitioned into for distributed storage) and a read threshold value (e.g., the minimum number of slices required to reconstruct the data segment)”, paragraphs 45 and 53, “When Y number of data segments has been reconstructed, the DS processing unit 16 provides the data file 38 and/or data block 40 to the user device 14”, and paragraph 68).
Regarding claim 2, DeRosa-Grund discloses a third partition, the second partition being inaccessible to the first user and accessible to a second user (paragraph 11, “remove the access to the portion of the EHRNFT upon a termination of the permission”, paragraphs 14 and 17, paragraph 36, “A plurality of MIDCs can be combined to form a micro-identifier chain arrays for the transaction platform. In such embodiments, for each user, only a specified single transaction block of their micro-identification chain that stores de-identified user data is able to be accessed by the notary blockchain(s) in order to form on-chain transactions. The data stored on the notary chain(s), and the other single transaction blocks of the micro-identification chain(s) is kept secure from any intruders.”, paragraph 72, “The notary module is the only module within the cluster permitted to execute operations with these keys (e.g. sign, encrypt, decrypt, etc.). As a result, the notary private keys are never known or accessible by the system”, paragraph 115, “the notary engine is able to access blocks of the micro-identification blockchains 202 including the encoded identifier and the set of personal information as encrypted, but restricted from accessing any blocks of the micro-identification chains 202 that include the native identifier”, paragraphs 169, 174, and paragraph 179, “Once permission has been determined as being given, the module provides access to the portion(s) of the EHRNFT(s) for which the permission was given at the step 1312. If it is determined that permission is not given, the module is able to send an access denial message to the entities requesting access and/or removing any access privileges”).
Regarding claim 3, DeRosa-Grund discloses wherein the first partition is associated with one or more storage addresses according to an operating system (paragraph 168).
Regarding claim 4, DeRosa-Grund discloses The apparatus of claim 1, further comprising a memory for storing the first data, the memory being coupled to the first storage and the processor, wherein the processor is configured to remove the third data from the memory (paragraph 94, “When the tolling period expires, effectuates the user’s Right to Erasure request by deleting the users MIDC 202 and notifies that their data has been removed from the system”).
Regarding claim 5, DeRosa-Grund discloses wherein the processor is further configured to store the third data received from the communication interface (paragraphs 75, 119, 162, and 169).
Regarding claim 6, DeRosa-Grund discloses wherein the third data is stored on a mobile device connected to the communication interface (paragraph 119, “graphical user interface(s)”, “Examples of suitable computing devices include a personal computer, a laptop computer, a computer workstation, a server, a datacenter, a mainframe computer, a handheld computer, a personal digital assistant, a cellular/mobile telephone, a smart appliance, a gaming console, a digital camera, a digital camcorder, a camera phone”).
Regarding claim 7, DeRosa-Grund discloses wherein the second partition is accessible to a second user via the communication interface (paragraph 11, “remove the access to the portion of the EHRNFT upon a termination of the permission”, paragraphs 14 and 17, paragraph 36, “A plurality of MIDCs can be combined to form a micro-identifier chain arrays for the transaction platform. In such embodiments, for each user, only a specified single transaction block of their micro-identification chain that stores de-identified user data is able to be accessed by the notary blockchain(s) in order to form on-chain transactions. The data stored on the notary chain(s), and the other single transaction blocks of the micro-identification chain(s) is kept secure from any intruders.”, paragraph 72, “The notary module is the only module within the cluster permitted to execute operations with these keys (e.g. sign, encrypt, decrypt, etc.). As a result, the notary private keys are never known or accessible by the system”, paragraph 115, “the notary engine is able to access blocks of the micro-identification blockchains 202 including the encoded identifier and the set of personal information as encrypted, but restricted from accessing any blocks of the micro-identification chains 202 that include the native identifier”, paragraphs 169, 174, and paragraph 179, “Once permission has been determined as being given, the module provides access to the portion(s) of the EHRNFT(s) for which the permission was given at the step 1312. If it is determined that permission is not given, the module is able to send an access denial message to the entities requesting access and/or removing any access privileges”).
Regarding claim 8, DeRosa-Grund discloses wherein the communication interface comprises a wireless transceiver (paragraph 189, “wireless transceivers”).
Regarding claim 9, DeRosa-Grund discloses wherein the processor is configured to encrypt the second data using a first key, the third data being encrypted using a second key (paragraphs 67, 69-72, 76, 81, 82, and 96).
Regarding claim 10, DeRosa-Grund discloses a user interface for receiving user authentication for accessing the first data (paragraph 64, “a biometric module, an authentication module”, paragraph 67, “The registration module inputs the PPI and creates an authentication hash and a key hash of the entered passwords at step 104”, paragraphs 69 and 71, “required using the user’s password”, and paragraph 75, “allowing the user/account to authenticate using the same credentials (e.g., password) on any of the instances while the PPI of the user/account would still be specific to each instance”).
Regarding claim 11, DeRosa-Grund discloses wherein the first storage further comprising a third partition for storing a fourth data stored at a second storage received via the communication interface (paragraphs 53 and 60).
Regarding claim 12, DeRosa-Grund discloses wherein: the second storage is configured in a mobile device; and the communication interface comprising a cellular interface (paragraph 119, “graphical user interface(s)”, “Examples of suitable computing devices include a personal computer, a laptop computer, a computer workstation, a server, a datacenter, a mainframe computer, a handheld computer, a personal digital assistant, a cellular/mobile telephone, a smart appliance, a gaming console, a digital camera, a digital camcorder, a camera phone”, and paragraph 189, “wireless transceivers”).
Regarding claim 13, DeRosa-Grund discloses wherein the second storage comprises a fourth partition and a fifth partition, the fourth partition being inaccessible to the first user, and the fifth partition being accessible to the first user via the communication interface (paragraph 11, “remove the access to the portion of the EHRNFT upon a termination of the permission”, paragraphs 14 and 17, paragraph 36, “A plurality of MIDCs can be combined to form a micro-identifier chain arrays for the transaction platform. In such embodiments, for each user, only a specified single transaction block of their micro-identification chain that stores de-identified user data is able to be accessed by the notary blockchain(s) in order to form on-chain transactions. The data stored on the notary chain(s), and the other single transaction blocks of the micro-identification chain(s) is kept secure from any intruders.”, paragraphs 53, 60, and 72, “The notary module is the only module within the cluster permitted to execute operations with these keys (e.g. sign, encrypt, decrypt, etc.). As a result, the notary private keys are never known or accessible by the system”, paragraph 115, “the notary engine is able to access blocks of the micro-identification blockchains 202 including the encoded identifier and the set of personal information as encrypted, but restricted from accessing any blocks of the micro-identification chains 202 that include the native identifier”, paragraphs 169, 174, and paragraph 179, “Once permission has been determined as being given, the module provides access to the portion(s) of the EHRNFT(s) for which the permission was given at the step 1312. If it is determined that permission is not given, the module is able to send an access denial message to the entities requesting access and/or removing any access privileges”).
Regarding claim 14, DeRosa-Grund discloses wherein the processor is further configured to identify and communicate with a mobile device comprising the second storage for obtaining the third data (paragraph 119, “graphical user interface(s)”, “Examples of suitable computing devices include a personal computer, a laptop computer, a computer workstation, a server, a datacenter, a mainframe computer, a handheld computer, a personal digital assistant, a cellular/mobile telephone, a smart appliance, a gaming console, a digital camera, a digital camcorder, a camera phone”).
Regarding claim 15, DeRosa-Grund discloses an apparatus comprising:
a first storage comprising a first partition and a second partition, the first partition being accessible to a first user (Figure 6, paragraph 56, “assign the objects to multiple different partitions” and “the central receiving server is able to be one or more servers storing the platform operating system 206”, and paragraph 60, “for each of the partitions, the platform operating system (as executed by the platform server(s)) 206 assigns a different one of the nodes as a leader for that partition at the step 602. The platform operating system 206 receives a plurality of objects each including a unique transaction identifier and details of a single transaction between any two or more of the users at the step 604. The platform operating system 206 assigns each of the objects to one of the partitions at the step 606. The platform operating system 206 provides each of the objects to the nodes that lead the partition that the object is assigned to at the step 608.”),
the second partition being inaccessible to the first user (paragraph 36, “A plurality of MIDCs can be combined to form a micro-identifier chain arrays for the transaction platform. In such embodiments, for each user, only a specified single transaction block of their micro-identification chain that stores de-identified user data is able to be accessed by the notary blockchain(s) in order to form on-chain transactions. The data stored on the notary chain(s), and the other single transaction blocks of the micro-identification chain(s) is kept secure from any intruders.”, paragraph 72, “The notary module is the only module within the cluster permitted to execute operations with these keys (e.g. sign, encrypt, decrypt, etc.). As a result, the notary private keys are never known or accessible by the system”, paragraph 115, “the notary engine is able to access blocks of the micro-identification blockchains 202 including the encoded identifier and the set of personal information as encrypted, but restricted from accessing any blocks of the micro-identification chains 202 that include the native identifier”, and paragraph 179, “If it is determined that permission is not given, the module is able to send an access denial message to the entities requesting access and/or removing any access privileges”);
a communication interface (paragraph 119, “graphical user interface(s)”, “Examples of suitable computing devices include a personal computer, a laptop computer, a computer workstation, a server, a datacenter, a mainframe computer, a handheld computer, a personal digital assistant, a cellular/mobile telephone, a smart appliance, a gaming console, a digital camera, a digital camcorder, a camera phone”, and paragraph 189, “wireless transceivers”);
and a processor coupled to the first storage and the communication interface (paragraph 11, “generate an electronic health record non-fungible token (EHRNFT) based on the selected portion of the electronic health data, the EHRNFT including a token identifier and the selected portion, store the EHRNFT on the micro-identification blockchain dedicated to the user as a single block separate from any existing blocks of the micro-identification blockchain”, paragraphs 12, 13, 19, and paragraph 167, “The creation of the ID and EHR NFTs is able to comprise generating a unique identifier for the NFT (e.g. a hash or other mathematical result of input the dataset) to be stored with the dataset as a block (e.g. single transaction block on the blockchain). In some embodiments, all of the collected health records (e.g. from multiple different sources) are combined into a single dataset that is used to generate the EHRNFT for the user. Alternatively or in addition, separate EHRNFTs are able to be created for separate portions of the user EHRs.”),
wherein the processor is configured to:
process a request for accessing a first data, the first data comprising a second data and a third data (paragraph 11, “generate an electronic health record non-fungible token (EHRNFT) based on the selected portion of the electronic health data, the EHRNFT including a token identifier and the selected portion, store the EHRNFT on the micro-identification blockchain dedicated to the user as a single block separate from any existing blocks of the micro-identification blockchain”, paragraphs 12, 13, 19, and paragraph 167, “The creation of the ID and EHR NFTs is able to comprise generating a unique identifier for the NFT (e.g. a hash or other mathematical result of input the dataset) to be stored with the dataset as a block (e.g. single transaction block on the blockchain). In some embodiments, all of the collected health records (e.g. from multiple different sources) are combined into a single dataset that is used to generate the EHRNFT for the user. Alternatively or in addition, separate EHRNFTs are able to be created for separate portions of the user EHRs.”);
identify the first partition of the first storage for storing the second data and third data being absent from the first storage (paragraph 14, “the micro-identification blockchain stored on a non-transitory computer-readable memory cluster” and paragraph 19, “storing the another EHRNFTs on the micro-identification blockchain dedicated to the user on another separate block”).
DeRosa-Grund discloses the claimed invention, as cited above. However, DeRosa-Grund is not relied upon to disclose the claim limitations pertaining to “transmit a first request to a first device for the third data via the communication interface; receive the third data from the first device via the communication interface; and generate the first data using the second data and the third data”. Grube discloses said claim limitations, as cited below. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Grube with the teachings of DeRosa-Grund so that “the first slice of each of the data segments is to be stored in a first DS unit 36, the second slice of each of the data segments is to be stored in a second DS unit 36, etc. In this manner, the data is encoded and distributedly stored at physically diverse locations to improved data storage integrity and security” (Grube – paragraph 48).
Further regarding claim 15, Grube discloses transmit a first request to a first device for the third data via the communication interface; receive the third data from the first device via the communication interface; and generate the first data using the second data and the third data (paragraph 38, “the DS managing unit 18 coordinates the creation of a vault (e.g., a virtual memory block) within the DSN memory 22 for a user device (for a group of devices, or for public access). The DS managing unit 18 also determines the distributed data storage parameters for the vault. In particular, the DS managing unit 18 determines a number of slices (e.g., the number that a data segment of a data file and/or data block is partitioned into for distributed storage) and a read threshold value (e.g., the minimum number of slices required to reconstruct the data segment)”, paragraphs 45 and 53, “When Y number of data segments has been reconstructed, the DS processing unit 16 provides the data file 38 and/or data block 40 to the user device 14”, and paragraph 68).
Regarding claim 16, DeRosa-Grund discloses wherein the processor is further configured to transmit a second request to a second device for obtaining the third data via the communication interface (paragraphs 53 and 60).
Regarding claim 17, DeRosa-Grund discloses wherein the processor is further configured to decrypt the third data (paragraphs 72, 76, 82, 83, and 99).
Regarding claim 18, DeRosa-Grund teaches a method for storing data, the method comprising:
processing a first data to obtain a second data and a third data (paragraph 11, “generate an electronic health record non-fungible token (EHRNFT) based on the selected portion of the electronic health data, the EHRNFT including a token identifier and the selected portion, store the EHRNFT on the micro-identification blockchain dedicated to the user as a single block separate from any existing blocks of the micro-identification blockchain”, paragraphs 12, 13, 19, and paragraph 167, “The creation of the ID and EHR NFTs is able to comprise generating a unique identifier for the NFT (e.g. a hash or other mathematical result of input the dataset) to be stored with the dataset as a block (e.g. single transaction block on the blockchain). In some embodiments, all of the collected health records (e.g. from multiple different sources) are combined into a single dataset that is used to generate the EHRNFT for the user. Alternatively or in addition, separate EHRNFTs are able to be created for separate portions of the user EHRs.”);
storing the second data at a first storage of a first device (paragraph 14, “the micro-identification blockchain stored on a non-transitory computer-readable memory cluster” and paragraph 19, “storing the another EHRNFTs on the micro-identification blockchain dedicated to the user on another separate block”);
identifying a second device comprising a second storage (paragraphs 53 and 60);
transmitting the third data to the second device for storing at the second storage via a first wireless communication link (paragraphs 36, 37, “wireless networks”, and paragraph 189, “wireless transceivers”, and paragraphs 53 and 60).
DeRosa-Grund teaches the claimed invention, as cited above. However, DeRosa-Grund is not relied upon to teach the claim limitations pertaining to “receiving a request for the first data; identifying one or more devices for having the third data; obtaining the third data from an identified device; and providing the first data using the second data and the third data”. Grube teaches said claim limitations, as cited below. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Grube with the teachings of DeRosa-Grund so that “the first slice of each of the data segments is to be stored in a first DS unit 36, the second slice of each of the data segments is to be stored in a second DS unit 36, etc. In this manner, the data is encoded and distributedly stored at physically diverse locations to improved data storage integrity and security” (Grube – paragraph 48).
Further regarding claim 18, Grube teaches receiving a request for the first data; identifying one or more devices for having the third data; obtaining the third data from an identified device; and providing the first data using the second data and the third data (paragraph 38, “the DS managing unit 18 coordinates the creation of a vault (e.g., a virtual memory block) within the DSN memory 22 for a user device (for a group of devices, or for public access). The DS managing unit 18 also determines the distributed data storage parameters for the vault. In particular, the DS managing unit 18 determines a number of slices (e.g., the number that a data segment of a data file and/or data block is partitioned into for distributed storage) and a read threshold value (e.g., the minimum number of slices required to reconstruct the data segment)”, paragraphs 45 and 53, “When Y number of data segments has been reconstructed, the DS processing unit 16 provides the data file 38 and/or data block 40 to the user device 14”, and paragraph 68).
Regarding claim 19, DeRosa-Grund teaches identifying a third device comprising a third storage; transmitting the third data to the third device for storing at the third storage via a second wireless communication link; and selecting between the second device and the third device for obtaining the third data (paragraphs 36, 37, 53, and 60).
Regarding claim 20, DeRosa-Grund teaches encrypting the third data before transmitting to the second device (paragraphs 67, 69-72, 76, 81, 82, and 96).;
and decrypting the third data after obtaining from the identified device (paragraphs 72, 76, 82, 83, and 99).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The references cited on form PTO-892 are cited to further show the state of the art with respect to protecting data within secure memory partitions.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEREMIAH L AVERY whose telephone number is (571)272-8627. The examiner can normally be reached M-F 8:30am -5:00pm.
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, Lynn Feild can be reached at 571-272-2092. 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.
/JEREMIAH L AVERY/Primary Examiner, Art Unit 2431