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 .
Claim Rejections - 35 USC § 102
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.
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-15 are rejected under 35 U.S.C. 102(a)(1)(a)(2) as being anticipated by Xu (Patent No. 11,250,507 filed May 6, 2019).
Regarding Claim 1, Xu teaches a blockchain system trusted (Abstract, techniques for ensuring that a negotiable instrument has not been altered between the time the instrument leaves the hands of the payor and when the check is presented for redemption by the payee by recording an image of the check in a data block in a blockchain and retrieving the image when the check is presented for redemption for comparison with the check.); a sidecar database ([0019] In some embodiments, a bank receiving physical check for cashing may query the blockchain to retrieve an image of the check. Metadata available from information on the check, for example, one or more of the account number, the date, the amount of the check and the name of the payee may be cryptographically hashed to obtain an index which may be used to identify the image of the check the blockchain.); one or more tenant information handling systems (IHS) ([0019] In some embodiments, a bank receiving physical check for cashing may query the blockchain to retrieve an image of the check. Metadata available from information on the check, for example, one or more of the account number, the date, the amount of the check and the name of the payee may be cryptographically hashed to obtain an index which may be used to identify the image of the check the blockchain.); and a depositary IHS comprising: a network interface communicatively connectable ([0046] Banking application 204 may be equipped with an image capturing capability, which utilizes image capture device 206 for capturing an image of a check. Such image capturing capabilities are well-known in current banking applications for providing the ability for mobile deposits of a check. Typically, the image capturing capability of banking application 204 will capture an image of both the front and the back of the check and upload those to the financial institution server 210 for deposit of the check into the customer's account. The customer may thereafter destroy the physical check after the deposit into the customer's account is confirmed.), via a network, to one or more tenant IHSes, the blockchain system, and the sidecar database ([0046] Typically, the image capturing capability of banking application 204 will capture an image of both the front and the back of the check and upload those to the financial institution server 210 for deposit of the check into the customer's account. The customer may thereafter destroy the physical check after the deposit into the customer's account is confirmed.); a secure memory that stores an electronic deposit box (EpositBox) application ([0033] As described in detail with respect to FIG. 1B, blockchain 140 may be configured to store data payloads 107 from member systems 110, the data payloads 107 including one or more records, as described below. Blockchain 140 may be distributed and comprise many copies of blockchain 140 maintained by different systems or nodes, for example, member systems 110 may each have a local copy of the most recent version of blockchain 140.); and a controller communicatively coupled to the network interface and the secure memory and comprising at least one hardware processor that executes the EpositBox application to configure the HIS ( [0036] Blockchain 140 may comprise one or a combination of several different types of blockchain. In one embodiment, blockchain 140 may comprise, for example, a consortium blockchain in which all participants in the blockchain 140 are member systems 110, and wherein a proof-of-stake function determines which member system 110 will complete each data block 101, that is, which member system 110 will calculate the hash value 105 for data block 101.), and which: connects, via the network interface, with the tenant IHS; receives, from the tenant IHS, a tenant data structure comprising at least one tenant record, each tenant record having one tabular labels associated with a data payload ( [0038] blockchain 140 may comprise a public blockchain in which any node may participate in the blockchain 140 and complete blocks in the blockchain 140. In such cases, it may be desirable that data payloads 107, or individual records in data payloads 107 be encrypted before being included in the data payload 107 of a data block 101. ); assigns a block ID to the tenant record ( [0038] the reward may be, for example, a financial reward generated by fees collected from user systems 114 for storing records in the blockchain 140.); stores the one or more tenant records in a blockchain system ( [0052] FIG. 2B shows the contents of a record 214, which includes image data 230 comprising the digitized image of the check, metadata 232, and a hash value 234.); and stores the block ID and signature to the sidecar database ([0077] [0077] FIG. 5 is a flowchart showing the process undertaken by the system shown in FIG. 2A for adding a record for a single check to the blockchain 140. At 502, the financial institution server 210 receives the check image data 230 and metadata 232 and creates a record 214 containing the check image 230 and metadata 232.).
6. Regarding Claim 2, Xu teaches the tenant data structure comprises at least one tenant record having at least one tabular label which is tenant- hashed ([0077] In the event that financial institution server 210 is not the member system 110 designated to complete the next data block 207 in blockchain 140, the one or more records is published to all other member systems such that the member system 110 designated to create next data block 207 gains possession of the one or more records 214.).
7. Regarding Claim 3, Xu teaches the tenant data structure comprises at least one tenant record having at least one tabular label associated with a payload, wherein the payload is tenant-encrypted ([0077] In the event that financial institution server 210 is not the member system 110 designated to complete the next data block 207 in blockchain 140, the one or more records is published to all other member systems such that the member system 110 designated to create next data block 207 gains possession of the one or more records 214.).
8. Regarding Claim 4, Xu teaches the depositary IHS further comprises the sidecar ([0077] In the event that financial institution server 210 is not the member system 110 designated to complete the next data block 207 in blockchain 140, the one or more records is published to all other member systems such that the member system 110 designated to create next data block 207 gains possession of the one or more records 214.).
9. Regarding Claim 5, Xu teaches the tenant data structure comprises at least one tabular label associated with a payload which is tenant- encrypted ([0077] In the event that financial institution server 210 is not the member system 110 designated to complete the next data block 207 in blockchain 140, the one or more records is published to all other member systems such that the member system 110 designated to create next data block 207 gains possession of the one or more records 214.).
10. Regarding Claim 6, Xu teaches the tenant data structure comprises at least one tenant record having at least one tabular label associated with a payload, wherein the payload is tenant-encrypted; and wherein the depositary IHS selects an encryption key to over encrypt the tenant-encrypted payload ([0077] In the event that financial institution server 210 is not the member system 110 designated to complete the next data block 207 in blockchain 140, the one or more records is published to all other member systems such that the member system 110 designated to create next data block 207 gains possession of the one or more records 214.).
11. Regarding Claim 7, Xu teaches the blockchain system is a private blockchain ([0077] In the event that financial institution server 210 is not the member system 110 designated to complete the next data block 207 in blockchain 140, the one or more records is published to all other member systems such that the member system 110 designated to create next data block 207 gains possession of the one or more records 214.).
12. Regarding Claim 8, Xu teaches the blockchain system is a public blockchain ([0077] In the event that financial institution server 210 is not the member system 110 designated to complete the next data block 207 in blockchain 140, the one or more records is published to all other member systems such that the member system 110 designated to create next data block 207 gains possession of the one or more records 214.).
13. Regarding Claim 9, Xu teaches the blockchain system comprises a multiple-tenant data store ([0077] In the event that financial institution server 210 is not the member system 110 designated to complete the next data block 207 in blockchain 140, the one or more records is published to all other member systems such that the member system 110 designated to create next data block 207 gains possession of the one or more records 214.).
14. Regarding Claim 10, Xu teaches the depositary IHS further appends a JSON recovery object to the at least one tenant record of the tenant data structure ([0077] In the event that financial institution server 210 is not the member system 110 designated to complete the next data block 207 in blockchain 140, the one or more records is published to all other member systems such that the member system 110 designated to create next data block 207 gains possession of the one or more records 214.).
15. Regarding Claim 11, Xu teaches the sidecar database can be reconstituted using at least one JSON recovery object ([0077] In the event that financial institution server 210 is not the member system 110 designated to complete the next data block 207 in blockchain 140, the one or more records is published to all other member systems such that the member system 110 designated to create next data block 207 gains possession of the one or more records 214.).
16. Regarding Claim 12, Xu teaches securely connecting, via a network interface of a depositary information handling system (IHS), with a tenant HIS (Abstract, techniques for ensuring that a negotiable instrument has not been altered between the time the instrument leaves the hands of the payor and when the check is presented for redemption by the payee by recording an image of the check in a data block in a blockchain and retrieving the image when the check is presented for redemption for comparison with the check.); receiving, from the tenant IHS, a tenant data structure comprising at least one tenant record ([0019] In some embodiments, a bank receiving physical check for cashing may query the blockchain to retrieve an image of the check. Metadata available from information on the check, for example, one or more of the account number, the date, the amount of the check and the name of the payee may be cryptographically hashed to obtain an index which may be used to identify the image of the check the blockchain.), each tenant record having one or more tabular labels associated with a data payload ([0019] In some embodiments, a bank receiving physical check for cashing may query the blockchain to retrieve an image of the check. Metadata available from information on the check, for example, one or more of the account number, the date, the amount of the check and the name of the payee may be cryptographically hashed to obtain an index which may be used to identify the image of the check the blockchain.); assigning a block ID to the tenant record ([0019] In some embodiments, a bank receiving physical check for cashing may query the blockchain to retrieve an image of the check. Metadata available from information on the check, for example, one or more of the account number, the date, the amount of the check and the name of the payee may be cryptographically hashed to obtain an index which may be used to identify the image of the check the blockchain.); appending a tenant identifier associated with the tenant, and a signature, to the at least one tenant record of the tenant data structure ([0033] As described in detail with respect to FIG. 1B, blockchain 140 may be configured to store data payloads 107 from member systems 110, the data payloads 107 including one or more records, as described below. Blockchain 140 may be distributed and comprise many copies of blockchain 140 maintained by different systems or nodes, for example, member systems 110 may each have a local copy of the most recent version of blockchain 140.); storing the tenant record in a blockchain system ([0033] As described in detail with respect to FIG. 1B, blockchain 140 may be configured to store data payloads 107 from member systems 110, the data payloads 107 including one or more records, as described below. Blockchain 140 may be distributed and comprise many copies of blockchain 140 maintained by different systems or nodes, for example, member systems 110 may each have a local copy of the most recent version of blockchain 140.); and storing the block ID and signature to a sidecar database ([0033] As described in detail with respect to FIG. 1B, blockchain 140 may be configured to store data payloads 107 from member systems 110, the data payloads 107 including one or more records, as described below. Blockchain 140 may be distributed and comprise many copies of blockchain 140 maintained by different systems or nodes, for example, member systems 110 may each have a local copy of the most recent version of blockchain 140.).
17. Regarding Claim 13, Xu teaches querying the depositary IHS for the tenant record; retrieving the block ID for the tenant record from the sidecar; retrieving the payload stored at the block ID in the blockchain system ([0077] In the event that financial institution server 210 is not the member system 110 designated to complete the next data block 207 in blockchain 140, the one or more records is published to all other member systems such that the member system 110 designated to create next data block 207 gains possession of the one or more records 214.).
18. Regarding Claim 14, Xu teaches: a computer readable storage device (Abstract, techniques for ensuring that a negotiable instrument has not been altered between the time the instrument leaves the hands of the payor and when the check is presented for redemption by the payee by recording an image of the check in a data block in a blockchain and retrieving the image when the check is presented for redemption for comparison with the check.); and program code on the computer readable storage device that when executed by a processor associated with a depositary information handling system (IHS), the program code enables the depositary IHS to provide functionality of ([0019] In some embodiments, a bank receiving physical check for cashing may query the blockchain to retrieve an image of the check. Metadata available from information on the check, for example, one or more of the account number, the date, the amount of the check and the name of the payee may be cryptographically hashed to obtain an index which may be used to identify the image of the check the blockchain.): securely connecting, via a network interface of depositary IHS, with a tenant HIS ([0033] As described in detail with respect to FIG. 1B, blockchain 140 may be configured to store data payloads 107 from member systems 110, the data payloads 107 including one or more records, as described below. Blockchain 140 may be distributed and comprise many copies of blockchain 140 maintained by different systems or nodes, for example, member systems 110 may each have a local copy of the most recent version of blockchain 140.); receiving, from the tenant IHS, a tenant data structure comprising at least one tenant record, each tenant record having one or more tabular labels associated with a data payload; assigning a block ID to the tenant record ([0046] Banking application 204 may be equipped with an image capturing capability, which utilizes image capture device 206 for capturing an image of a check. Such image capturing capabilities are well-known in current banking applications for providing the ability for mobile deposits of a check. Typically, the image capturing capability of banking application 204 will capture an image of both the front and the back of the check and upload those to the financial institution server 210 for deposit of the check into the customer's account. The customer may thereafter destroy the physical check after the deposit into the customer's account is confirmed.); appending a tenant identifier associated with the tenant, and a signature, to the at least one tenant record of the tenant data structure ([0046] Banking application 204 may be equipped with an image capturing capability, which utilizes image capture device 206 for capturing an image of a check. Such image capturing capabilities are well-known in current banking applications for providing the ability for mobile deposits of a check. Typically, the image capturing capability of banking application 204 will capture an image of both the front and the back of the check and upload those to the financial institution server 210 for deposit of the check into the customer's account. The customer may thereafter destroy the physical check after the deposit into the customer's account is confirmed.); storing the one or more tenant records in a block chain system; and storing the block ID and signature to a sidecar database ([0077] FIG. 5 is a flowchart showing the process undertaken by the system shown in FIG. 2A for adding a record for a single check to the blockchain 140. At 502, the financial institution server 210 receives the check image data 230 and metadata 232 and creates a record 214 containing the check image 230 and metadata 232.).
19. Regarding Claim 15, Xu teaches controller appends a tenant identifier associated with the tenant, and a signature, to the at least one tenant record of the tenant data structure ([0077] In the event that financial institution server 210 is not the member system 110 designated to complete the next data block 207 in blockchain 140, the one or more records is published to all other member systems such that the member system 110 designated to create next data block 207 gains possession of the one or more records 214.).
Conclusion
20. Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHERYL R LEWIS whose telephone number is (571)272-4113. The examiner can normally be reached Monday-Thursday, 8am-5pm, EST.
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, Sanjiv Shah can be reached at 571-272-4098. 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.
/CHERYL LEWIS/Primary Examiner, Art Unit 2166 June 11, 2026
Prosecution Insights