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 § 112 Claims 4 and 5 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Regarding Claim 4, lines 10 and 11, the phrase “ the sheet management device generates n- th (n: integer not less than 2) block data ” is unclear and indefinite . Additionally, in line 12, regarding the word “including:”, it is unclear what items after the colon (:) are part of the included items. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-10 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. In the instant case, Claim (s) 10 is/are directed to a method and Claim(s) 1-9 is/are directed to a system comprising a memory and a processor. Therefore, these claims fall within the four statutory categories of invention. The claim(s) recite(s) the abstract idea of tracking sheets used in transactions. Specifically, the claims recite generat ( ing ) first block data that includes identification information of a plurality of sheets handled by a first sheet handling apparatus, generat ( ing ) second block data that includes identification information obtained by handling the plurality of sheets by a second sheet handling apparatus , which is grouped within the certain methods of organizing human activity grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test ( See 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50, 52, 54 (January 7, 2019)) because the sheet management device and the rest of the claim limitations exist in the context of handling cash in the form of banknotes, which is considered the commercial interactions group under the organizing human activity group of abstract ideas . Accordingly, the claims recite an abstract idea ( See pages 7, 10, Alice Corporation Pty. Ltd. v. CLS Bank International, et al. , US Supreme Court, No. 13-298, June 19, 2014; 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50, 53-54 (January 7, 2019)). This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test ( See 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50, 54-55 (January 7, 2019)), the additional element(s) of the claim(s) such as sheet management device and sheet handling devices merely use(s) a computer as a tool to perform an abstract idea . Specifically, the sheet management device and sheet handling devices perform(s) the steps or functions of generat ( ing ) first block data that includes identification information of a plurality of sheets handled by a first sheet handling apparatus, generat ( ing ) second block data that includes identification information obtained by handling the plurality of sheets by a second sheet handling apparatus . The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), the claims do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or medical condition (Vanda Memo), the claims do not apply the abstract idea with, or by use of, a particular machine (MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test ( See 2019 Revised Patent Subject Matter Eligibility Guidance, 84 Fed. Reg. 50, 52, 56 (January 7, 2019)), the additional element(s) of using a sheet management device and sheet handling devices to perform the steps amounts to no more than using a computer or processor to automate and/or implement the abstract idea of tracking sheets used in transactions . As discussed above, taking the claim elements separately, the sheet management device and sheet handling devices perform(s) the steps or functions of generat ( ing ) first block data that includes identification information of a plurality of sheets handled by a first sheet handling apparatus, generat ( ing ) second block data that includes identification information obtained by handling the plurality of sheets by a second sheet handling apparatus . These functions correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the concept of tracking sheets used in transactions . Therefore, the use of these additional elements does no more than employ the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)). Therefore, the claim is not patent eligible. Dependent claims 2-8 further describe the abstract idea of tracking sheets used in transactions . The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. Therefore, the dependent claims are also not patent eligible. Claim Rejections - 35 USC § 103 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 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. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claim (s) 1- 4, 9 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hunt et al (WO 2020/033458 A1) in view of Guo et al (US 2021/0026740 A1) . Regarding Claim 1, Hunt teach es a sheet management device , i.e., the cash management system as mentioned at paragraphs 44 and 45 and as illustrated in figures 1 and 2, for example, configured to: generate first block data that includes identification information of a plurality of sheets , i.e., the data scanned by scanner (210) as mentioned at paragraphs 44 and 49, handled by a first sheet handling apparatus , i.e., user interface stage (200) as illustrated in figures 1 and 2, and a first eigenvalue calculated based on first input values including the identification information , i.e., noting the mention of use of blockchain at paragraphs 9, 32, 54, 58, 69, 79, 106, 114, 118 and Claim 32 ; generate second block data that includes identification information obtained by handling the plurality of sheets by a second sheet handling apparatus , i.e., scanner (520), as mentioned at paragraphs 45 and 49 and as illustrated in figure 2, and a second eigenvalue calculated based on second input values including information on the first eigenvalue and the identification information obtained by the second sheet handling apparatus (520), as mentioned at paragraphs 8, 9, 44, 45 , 49, 54 and 73 , for example ; and manage the second block data in association with the first block data , as mentioned at paragraphs 73-106, for example . Regarding Claim 1, Hunt does not expressly teach first and second eigenvalues for first and second block data . Regarding Claim 1, Hunt does not expressly teach, but Guo teaches first and second eigenvalues for first and second block data, as mentioned at paragraphs 9, 15, 22, 74, 98, 122 and Claims 5, 11 and 18, which state as follows. [0009] A block header eigenvalue of a parent block included in the second block may be a block header eigenvalue of a last block in the first blockchain . [0015] A block header eigenvalue of a parent block included in the second block may be a block header eigenvalue of a last block in the first blockchain. [0022] A block header eigenvalue of a parent block included in the second block may be a block header eigenvalue of a last block in the first blockchain . Description [0074] In some embodiments, a block header eigenvalue of a parent block included in the second block is a block header eigenvalue of the last block in the first blockchain. For example, the first blockchain has ten blocks. After unused transaction output information is obtained by querying each of the ten blocks and the rolling transaction operation is performed, a new block (the second block) may be generated. Then, the parent block of the second block is the last block in the first blockchain, and the block header eigenvalue (such as a block header hash value) of the parent block recorded in the block header of the second block is a block header eigenvalue of the last block in the first blockchain. [0098] Optionally, a block header eigenvalue of a parent block included in the second block is a block header eigenvalue of the last block in the first blockchain. [0122] Optionally, a block header eigenvalue of a parent block included in the second block is a block header eigenvalue of the last block in the first blockchain . Claims 5 . The method according to claim 1, wherein a block header eigenvalue of a parent block included in the second block is a block header eigenvalue of a last block in the first blockchain. 11. The storage medium according to claim 8, wherein a block header eigenvalue of a parent block included in the second block is a block header eigenvalue of a last block in the first blockchain. 18. The computing device according to claim 14, wherein a block header eigenvalue of a parent block included in the second block is a block header eigenvalue of a last block in the first blockchain . Emphasis provided. Regarding Claim 1, before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to have provided first and second eigenvalues for first and second block data, as taught by Guo, in Hunt’s sheet management device for the purpose of effectuating the blockchain features with eigenvalues for first, second or any blocks of the blockchain as needed for the purpose of increasing security of transactions throughout the system. Regarding Claim 2 , Hunt teaches wherein in a case where the sheet management device , i.e., the cash management system as mentioned at paragraphs 44 and 45 and as illustrated in figures 1 and 2, for example, receives transaction information related to sheet handling, the input values includes the transaction information , as mentioned at paragraphs 4-9, 44- 5 5 and 106 , which state as follows. [0004] Provided herein, in certain embodiments, are devices and solutions for handling cash or quasi cash items in such a way as to substantially eliminate employee theft, error, or difficulties in reconciling a record of transactions with a total amount of money in a cash drawer . Embodiments of the invention provide cash drawers that are secure, cannot be opened manually, and have one point of entry. At the point of entry, or intake portal, embodiments of the invention provide a scanner capable of scanning every item to capture its unique identifier and its value. Optional scanning can also test for whether the currency is counterfeit. [0005] Advantages of keeping track of unique identifiers include: (1) creating a record of what exactly is in the system and within each collection of cash items either in“Dynamic Storage Package” (DSP, or “bundle”) or in a“Static Storage Package” (SSP, or“brick ”) record ed in the system, (2) making each brick transferrable and fraud-resistant, (3) enabling banking-like functionality because the cash is safe collateral and not fungible, (4) preventing counterfeits, because each scanned item is unique and duplicates can be identified . In some embodiments, the system gives each item a unique identity from scanning the identifier located on or within the physical item. Thus, even if the physical cash is stolen, the record of item’s identity can be provided to law enforcement and the items can be more easily located and returned . [0006] A complete record of every item of currency entering the system is made by communicating the scan data for each item into a spreadsheet, database, or like computer system for organizing data (the data manager) . A system inventory within the data manager retains record s of all items, bricks, bundles, and transactions . In addition, accounting may be done in real time either within the cash-management system through internal functions or through integration with commercial accounting software. Optionally, change can be made by having an exit/output function as part of the primary repository. The output is only triggered after an input of an amount of currency that is in excess of the amount of the transaction. In the event that the change required is a fraction of a currency unit (the units being, e.g., dollars, and the fractions being, e.g., cents), additional output functionality can be provided. In an embodiment, an automatic coin dispenser controlled by the data manager counts the coins and dispenses correct change. The transaction is not complete until money is entered into the cash drawer and any change is given. Real-time accounting for money entering or leaving the cash-management system is accomplished through communication between the intake portal, the output function, and the data manager . [0007] Embodiments of the invention reduces opportunities for human error or fraud. In some embodiments, the cash-management system also is capable of packaging like items of currency into packages containing a set number of bills, further facilitating handling of cash. In further optional embodiments the cash-management system can feed directly into a safe or vault or other secured storage area. [0008] In practice, a cash transaction involves, for example, entering a total transaction amount into a cash register or like device in the cash-management system of the present invention; or a calculation of a total transaction amount derived from one or more purchase decisions entered into an interactive user interface; or the like . A buyer provides cash in an amount that is equal to or greater than the transaction amount. In some embodiments, this cash is provided to a cashier, who inserts the cash into the point of entry. In other embodiments, the buyer provides the cash directly to the point of entry. The point of entry scans each item to capture its unique identifier and value. A record of total cash in the cash-management system, as well as a record of all item identifiers contained within the cash-management system, is maintained in the data manager and updated in real time . In the event that the amount of cash entered into the cash-management system is greater than the transaction amount, change is provided by dispensing currency from the cash-management system through a dispensing slot that scans the currency leaving the cash-management system. The data manager reconciles not only the total amount of cash remaining in the cash-management system, but also the individual identity of items entering and leaving the cash- management system, such that the data manager provides both an accurate total of the amount of money in the cash-management system, and an inventory record of each individual item of currency . In alternative embodiments, the system does not deal with change, has only a limited pool of change, or rounds purchases to the nearest dollar (or other unit of currency) and provides the remainder to charities or other recipients. [0009] The cash-management system can be linked to a permanent record -keeping system such as, e.g., a blockchain, to further reduce or eliminate risk of or opportunities for fraud in handling cash in the cash-management system . Linkage of data systems to blockchain systems is known within the art and is within the capability of a person practicing the invention. [00044] Figure 1 shows the first part of a transaction utilizing a cash-management system embodiment of the present invention. Cash 100 is provided to the intake portal 210 of the user interface stage 200. The cash is passed from the intake portal 210 through the scanner 220. The scanner 220 record s the value of each item of currency, and that data is conveyed to the record of cash value 420 within the data manager 400. The scanner 220 also record s the unique identifier of each item and conveys this information to the record of items of currency 410. The scanner also optionally provides information to the authenticator 440 which verifies whether each item is counterfeit or legitimate. The physical cash is passed from the user interface stage 200 to the primary repository 300. [00045] Figure 2 shows a transaction which requires the making of change. The transaction proceeds as described in Figure 1. The change calculator 430 determines the proper amount of change to be dispensed. The change calculator 430 communicates to the primary repository 300 the amount to be dispensed . The primary repository 300 provides to the user interface stage 200 the proper amount of cash. The scanner 520 scans each item as it exits the cash-management system and conveys the identity of each leaving item to the record of items of currency 410. The change calculator 430 provides information on the amount to be dispensed to the record of cash value 420 . The physical cash is then provided to the output portal 510 at the user interface stage 200. [00046] Figure 3 illustrates movement of the cash from the primary repository 300 to a local secondary repository 600 for optional eventual bank deposit. The bundle manager 450 in the data manager 400 is programmed to create bundles of like items of currency in predetermined values. The bundle manager 450 communicates with the record of cash value 420 to determine when the bundling threshold is reached. The bundle manager 450 instructs the primary repository 300 to create the bundle(s). The physical bundles are then passed from the primary repository 300 to a local secondary repository 600. The bundle manager 450 communicates with the record of items of currency 410 to collect the identities of each item placed in the bundle. The bundle manager 450 conveys the identity of items within the bundle, a“ Dynamic Storage Packet Identifier” (DSPID), and the cash value of the bundle to the bundle inventory 460. The bundles are kept in the local secondary repository 600 until they are optionally moved to a banking institution 700 for deposit, or accessed for transaction s supported by the secondary repository, or moved from the secondary repository to Static Secure Storage . [00047] Figure 4 illustrates movement of the cash from the primary repository 300 to a local secondary repository 600 when deposit with a banking institution is not the end goal. The initial bundling process follows that described in Figure 3. However, in this embodiment the bundling process is reversible. Bundles may be removed from the local secondary repository 600 into the primary repository 300 and are unbundled either within the secondary repository or within the primary repository or in a bundling/unbundling system operating between the primary repository and the secondary repository . The bundle manager 450 communicates with the primary repository 300 to identify the bundle being unbundled by correlation with the bundle’s DSPID . The bundle manager 450 communicates with the bundle inventory 460 to identify the cash value of the bundle and the identities of the items within that bundle. The bundle manager 450 conveys the identity information of the unbundled items to the record of items of currency 410. The bundle manager 450 conveys the cash value of the unbundled items to the record of cash value 420. The physical cash is removed from the local secondary repository 600 and passed to the primary repository 300 . [00048] Figure 5 illustrates a method for long term cash retention within the cash-management system. The brick manager 470 within the data manager 400 is programmed to create bricks of predetermined value from bundles within the local secondary repository 600. The brick manager 470 communicates with the bundle inventory 460 to determine when the brick creation threshold is reached. The brick manager 470 instructs the local secondary repository 600 to create a brick 1000 using bundles identified by their DSPIDs . The physical bricks 1000 can be moved as desired by the user. The brick manager 470 conveys the identity of the bundles in the brick 1000 to the bundle inventory 460 and conveys the identity all items in the brick to the record of items of currency 410 . The brick manager conveys the total cash value of the brick to the record of cash value 420. The brick manager 470 conveys the identity of items within the brick, an identifying brick signature (“SPID”), a unique brick access code, and the cash value of the brick to the brick inventory 480 . [00049] Figure 6 illustrates a countertop embodiment of the first stage of the invention. A user interface screen 230 is provided to facilitate human use of the invention, such as providing a display of the products involved in the transaction and a transaction price . Cash 100 is inserted into the intake portal 210. The cash is passed to a scanner 220, which scans each item of currency for value, unique identifier, and other data . The scanned data is conveyed to the system inventory (not shown). After being scanned, the cash is passed to a secure primary repository 300. Transaction s are not completed until data and currency are secured. When change is required, the proper amount of change can be removed from the primary repository 300 and provided to a scanner 520 which scans each item of currency to be dispensed as change for value, unique identifier, and other data. This data is conveyed to the system inventory and records are updated as appropriate . The cash is then provided to the user through an output portal 510. [00050] Figure 7 illustrates the bundling operations which occur below the countertop unit. One or more devices (not shown) are provided which collect cash in the amount to be bundled from the secure primary repository 300. The items within the bundle are recorded, along with the value of the bundle. After packaging, each bundle 610 is assigned a unique bundle identifier recorded in the bundle inventory 460. In some embodiments, the bundles 610 may be retrieved and unbundled to access the items contained within them to fulfill a wide range of business needs . [00051] Figure 8 illustrates the creation of a “Static Storage Package”, or brick 1000 . In this embodiment, the brick consists of two rectangular boxes with five sides, i.e. one side of each box is open. Cash is placed within the smaller box. The larger box is then secured over the top of the smaller box, resulting in a single box closed on all sides. The brick packaging may be comprised of a variety of materials and can comprise additional locking or security features. Each brick is assigned a“ Static Storage Package ID” (SSPID) which identifies it within the system. The SSPID is associated with records of each bundle and item of currency contained in the brick. Each brick is assigned an access key that is required to open the brick and access the cash . Use of the access key destroys the validity of the brick within the system. [00052] Figure 9 illustrates the retention of multiple bricks 1000 as an alternative to traditional banking deposit. The physical bricks may reside in any location desired by the user, and title to the cash can be transferred by transfer of the SSPID and access key to one or more bricks . DETAILED DESCRIPTION OF THE INVENTION [00053] As used herein,“ cash ” refers to physical monetary instruments, embodied in bills, coins, and/or the like . Cash is inclusive of such physical monetary instruments as may be issued by any national or international authority. Cash is also inclusive of quasi-monetary instruments, such as casino chips or physical instruments backed by digital currency or cryptocurrencies, as may be issued by any entity. Each of said individual physical monetary instruments is known as an“ item of currency”. Items can be classified based upon type of physical embodiment, national issuer, and/or the like. Each item carries a value denomination, and can further carry identifying indicia, such as serial numbers, embedded RFID signatures, and/or the like. In combination, these characteristics represent a data profile for each monetary instrument. For example, a United States one-dollar bill can have a data profile as follows: Type: United States Bill National Issuer: United States Value Denomination: 1 United States Dollar Serial Number: E19066540H [00054] The main concept of the system is to treat all pieces of currency as unique items of inventory carrying valuable data . The error and problem of prior cash-handling systems is the treatment of cash as fungible. This creates opportunities for fraud, mistake, and theft. But for each item of currency with a unique identity due to having a unique identifier, scanning technology makes it completely unnecessary to treat all items currency as fungible . Treating each item of currency as a discrete inventory item also significantly reduces the ability to counterfeit or duplicate known items of currency within the system. All currency in a transaction can be treated as unique items of inventory carrying valuable unique data . An early step in any transaction according to embodiments of the invention is to capture the data from each item of currency into a data stream. That data stream can further optionally be rendered secure and hackproof via blockchain or other secure technology . The system is concerned that each item is a unique individual with a unique identity and therefore each item’s location in the system can also be tracked, whether the item is in a primary repository, a bundle within a secondary repository, or a brick; likewise the location of each bundle and each brick can also be tracked.. In some embodiments a brick can be assembled to contain“ loose ” cash - i.e., cash that has not previously been packaged into DSPs . In such embodiments the inventory of the brick can be an inventory of each item of currency but does not include any DSPs and hence does not include any DSPIDs or other information relating to DSPs such as a DSP sub-inventory . [00055] The invention can be embodied in different forms. For example, the invention can relate to a traditional cash register with two slots: an intake scanning slot & an output scanning slot, where a cashier can operate the cash register by interacting with its user interface, such as by pressing keys. As another example, the invention can be configured in a way that is similar to an ATM, having a touch screen operated by the user without requiring a cashier, where the user can interact with touch screen and can input and retrieve money directly through a single point of interaction capable of scanning items of currency in and out of the system, or via an input portal/scanner and an output portal/scanner . The user interface can be configured to achieve additional functionality, such as display of products to be sold, quantities and prices of said products, displaying user or customer account information, allow modification of the transaction or transaction s, and more . The user interface can be configured to accept input and provide information verbally, through the use of keys, through use of a touchscreen, and more. In some embodiments, additional user interfaces can be provided for “back of house” settings, which allow review of information in the system record, such as total value, inventory of items of currency, activity data, and more without being directly tied to an intake or output portal . [000106] The vendor’s system inventory now reflects that it possesses title to the cash in the bundle and brick, even though vendor only possesses the physical cash in the bundle . The general principles embodied in this example can be repeated, altered, or expanded to carry out transaction s and transfers of funds between a plurality of businesses . Each business can install and integrate an instance of the system, which is capable of communicating with other instances belonging to other businesses. In the above example, the system inventories of the dispensary and vendor can also be linked to an instance possessed by the third- party warehouse operator, who retains an additional record of the transaction and the bricks, bundles, and bills involved, thereby increasing validity, transparency, and security . In the example above, any of the parties to the transaction can record the transaction and identities of the bricks, bundles, and bills involved in a blockchain ledger for security and verification purposes . Emphasis provided. Regarding Claim 2, Hunt does not expressly teach and the sheet management device calculates the eigenvalue from the input values including the transaction information and adds the transaction information to the block data . Regarding Claim 2, Hunt does not expressly teach , but Guo teaches and the sheet management device calculates the eigenvalue from the input values including the transaction information and adds the transaction information to the block data , as mentioned at paragraphs 9, 15, 22, 74, 98, 122 and Claims 5, 11 and 18. Regarding Claim 3 , Hunt does not expressly teach w herein the eigenvalue is a fixed-length value that is calculated by inputting the input values into a predetermined function and changed according to the input values . Regarding Claim 3, Huntdoes not expressly teach , but Guo teaches wherein the eigenvalue is a fixed-length value that is calculated by inputting the input values into a predetermined function and changed according to the input values , as shown in figure 3 and noting the mentioned at paragraph 52 of “generating a hash value through a SHA256 algorithm by using data of the block header of the block 200 A recently added to the blockchain, and filling the hash value into a parent block hash value of the current block ” . Regarding Claim 4, Hunt teaches wherein in a case where the plurality of sheets are handled a plurality of times , in a first handling and a second and subsequent handlings , noting that sheets such as documents of value/banknotes are used repeatedly in numerous transactions as is typical in commerce, and as mentioned in paragraph 97, i.e., “[t] his process is repeat ed until ten $100 bills have been provided to the cash bundling system ” and paragraph 106, i.e., “ The general principles embodied in this example can be repeat ed, altered, or expanded to carry out transactions and transfers of funds between a plurality of businesses ”. See also the mention of transactions and use with blockchain in paragraphs 8-10, 30, 31, 54, 69, 89, 101, 102 and 106, for example. Regarding Claim 4 , Hunt does not expressly teach in first handling, the sheet management device , generates the first block data including: identification information of the sheets obtained in the first handling; and the first eigenvalue calculated based on the first input values including the identification information, in second and subsequent handlings, the sheet management device generates n- th (n: integer not less than 2) block data including: identification information of the sheets obtained in n- th handling; and an n- th eigenvalue calculated based on n- th input values including information on an (n-1) - th eigenvalue and the identification information obtained in the n- th handling, and the sheet management device manages all the generated block data in association with each other by associating the n- th block data with the (n-1) - th block data . Regarding Claim 4, Hunt does not expressly teach , but Guo teaches in first handling, the sheet management device, generates the first block data including: identification information of the sheets obtained in the first handling; and the first eigenvalue calculated based on the first input values including the identification information, in second and subsequent handlings, the sheet management device generates n- th (n: integer not less than 2) block data including: identification information of the sheets obtained in n- th handling; and an n- th eigenvalue calculated based on n- th input values including information on an (n-1) - th eigenvalue and the identification information obtained in the n- th handling, and the sheet management device manages all the generated block data in association with each other by associating the n- th block data with the (n-1) - th block data , as illustrated in figure 1, noting notes (14) and blockchain (15) as mentioned at paragraphs 38 and 39 . See also figure 2, showing transactions 1 through m as part of a data structure of a block (200a), as mentioned at paragraph 42 and as illustrated at figure 3 showing blocks 23-24 of partial blockchain 200b and as mentioned at paragraph 56, for example. Regarding Claim 9, see the rejection of Claim 1, above, noting that Hunt teaches first sheet handling apparatus (200) and second sheet handling apparatus (200) as illustrated in figure 2, for example . Regarding Claim 10, see the rejection of Claims 1 and 4, for example. Claim (s) 5- 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hunt et al (WO 2020/033458 A1) in view of Guo et al (US 2021/0026740 A1) and further in view of White (US 2022/0207023 A1) . Regarding Claim s 5 -7 , Hunt teaches the system as described above. Regarding Claim 5 , Hunt does not expressly teac h w herein in a case where the n- th eigenvalue included in the n- th block data does not match an eigenvalue that is recalculated based on the n- th input values, the sheet management device , determines that there is abnormality in consistency between the n- th block data and the (n-1) - th block data, and performs a notification process for notifying determination result to a person in charge . Regarding Claim 5, Hunt does not expressly teach , but White teaches wherein in a case where the n- th eigenvalue , as taught by Guo, included in the n- th block data does not match an eigenvalue that is recalculated based on the n- th input values , the sheet management device , as taught by Hunt, determines that there is abnormality in consistency between the n- th block data and the (n-1) - th block data, and performs a notification process for notifying determination result to a person in charge , as mentioned at paragraphs 85 - 94, which state as follows . 0085] In some examples, the participating devices provide the hash values to a back-end server or other central service that compares the hash values to determine any that disagree . In one example, if only one of the participating devices disagrees with the target device, then the central service notif ies the participating device of the disagreement. Based upon the notif ication, the disagreeing participating device determines which block is bad and removes the bad block . The disagreeing participating device further requests the original block from a source device (e.g., from the target device) and recalculates the blockchain . In other examples, the target device performs the hash value comparison and, as appropriate, notif ies participating devices of disagreement . [0086] In some examples, all of the participating devices disagree with the target device . In this case, the target device determines the bad block, recovers the block from one of the participating devices and recalculates the block chain . In yet other examples, all of the participating devices including the target device agree, but the back-end server does not agree . In this case, the back-end server may recover the bad block from the target device and recalculate the blockchain . [0087] FIG. 6 is a flowchart illustrating a process 600 by which a device may recognize and remedy a blockchain error . At 602 , it is determined that an error exists in a blockchain being maintained by at least two devices. For example, a back-end server or a target device may determine that hash values reported in from various blockchain participants are not all in agreement . Based on which hash value or values are not in agreement, it may be inferred which of the devices is in error. For example, if all of the participating devices agree except for a target device, then it may be inferred that the target device is in error . If all of the participating devices including the target device agree, but a hash generated by the back-end server does not agree, then it may be inferred that the back-end server is in error. [0088] For example, the back-end server may receive the hashes from the participating devices and, processing the received hashes, determine that one of the participating devices or the back-end server is in error . When the back-end server determines one of the participating devices is in error, the back-end server may send an indication of the device in error to the participating device in error and/or, even if the participating device in error is not the target device, to the target device . The target device may then send an indication to the participating device in error . [0089] At 604, the participating device in error determines which block of the blockchain on the device is defective . At 606 , the participating device in error receives a replacement for the defective block from another device, i.e., a device inferred to not be in error. For example, the target device may provide the replacement for the defective block in response to a request from the device in error. If the target device is the device in error, the target device may request the replacement from another one of the participating devices. At 608, the device in error determines a recalculated blockchain that includes the replacement for the defective block . [0090] In some examples, in which the back-end server is determined to be in error, the back-end server may perform the operations 604, 606 and 608 . For example, at 604 , the back-end server may determine the defective block of the blockchain as maintained by the back-end server . For example, at 606 , the back-end server may receive a replacement for the defective block. At 608, the back-end server may determine a recalculated blockchain including the replacement for the defective block . [0091] FIG. 7 is a is a flowchart illustrating a process 700 by which a device, such as the back-end server, determines which device is exhibiting a blockchain error . At 702 , the device receives a blockchain hash from each of a plurality of participating devices. At 704, the device compares the received blockchain hashes to each other. At 706, based at least in part on the comparison, the device determines that a particular one of the participating devices is in error . For example, if all the blockchain hashes match except for one, then the device may infer that the blockchain participant that provided the non-matching blockchain hash is the device that is in error. As another example, if all the received blockchain hashes match each other, but they do not match the blockchain hash maintained by the device, then the device may infer that the device itself is in error. At 708, the device generates an indication of the device determined to be in error . For example, the device may generate the indication to send to the device determined to be in error . The device determined to be in error, once informed, may take steps to address the error, such as determining a defective block of the blockchain, receiving a replacement block and recalculating the blockchain . [0092] FIG. 8 is a diagram illustrating an example of how devices of the example network 300 may operate in accordance with the FIG. 6 example process 600 and the FIG. 7 example process 700 . In the FIG. 8 example, the participating devices are the device 308 , the device 310 , the device 312 and the device 318 , participating in a blockchain with the target device 302 . Referring to 702 of the process 700 and also referring to FIG. 8, the back-end server 304 may receive hashes (collectively, 802 ) from each of the device 308 , the device 310 , the device 312 and the device 318 , and the target device 302 . A route the hashes 802 take from each of the device 308 , the device 310 , the device 312 and the device 318 , and the target device 302 may be a result, for example, of how the devices are configured for mesh network communication. For example, as shown in FIG. 8, the device 308 may provide a hash 802 a to the back-end server 304 directly via the internet access point 306 . Similarly, the device 310 may provide a hash 802 b to the back-end server 304 directly via the internet access point 306 . The device 312 may provide a hash 802 c to the back-end server 304 via the device 308 . The device 318 may provide a hash 802 d to the back-end server 304 via the device 302 . The device 302 may provide a hash 802 e to the back-end server 304 via the device 310 . [0093] Continuing with the example and referring to 704 and 706 of the FIG. 7 process, the back-end server 304 may compare the hashes 802 a , 802 b , 802 c , 802 d and 802 e and determine that the target device 302 is in error . This is just one example and, in other examples, the back-end server 304 may determine that another one or more of the devices is in error, that none of the devices are in error or that the back-end server 304 itself is in error . At 708, the back-end server 304 may generate an indication 804 of the target device 302, determined to be in error . [0094] Referring now to 602 of the FIG. 6 process 600, the target device 302 may determine the existence of error in the blockchain by, for example, having received the indication 804 of the target device 302 generated by the back-end server 304 at 708 of the FIG. 7 process 700 . Referring to 604 of the process 600 , the target device 302 may determine a defective block of the blockchain and, at 606, the target device 302 may receive a replacement 806 for the defective block from the device 312 . For example, the device 312 may provide the replacement 806 to the target device 302 in response to the target device 302 making a request 808 to the device 312 for the replacement 806 . In some examples, the target device 302 may request each of the participating devices—the device 308 , the device 310 , the device 312 and the device 318 —to send its hash, and the target device 302 may request replacement from one of the participating devices whose hash matches hashes provided from other participating devices. Further, in some examples, the target device 302 may request the entire chain rather than a single block . At 608, the target device 302 may determine a recalculated blockchain including the replacement 806 . Emphasis provided. Regarding Claim 5 , before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to have provided wherein in a case where the n- th eigenvalue included in the n- th block data does not match an eigenvalue that is recalculated based on the n- th input values, the sheet management device, determines that there is abnormality in consistency between the n- th block data and the (n-1) - th block data, and performs a notification process for notifying determination result to a person in charge , as taught by White , in Hunt’s sheet management device for the purpose of maintaining the integrity of the blockchain by repairing a block/ blockdata and thus increasing security of transactions throughout the system . Regarding Claim 6 , see the rejection of Claim 5, above . Regarding Claim 7 , see the rejection of Claim 5, above . Claim (s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hunt et al (WO 2020/033458 A1) in view of Guo et al (US 2021/0026740 A1) and further in view of Klein et al (US 20 15 /0 146963 A1) . Regarding Claim 8 , Hunt teaches the system as described above. Regarding Claim 8 , Hunt does not expressly teach . wherein in a case where information on a sheet corresponding to identification information obtained by the first sheet handling apparatus is included in a list in which pieces of identification information to be detected are registered in advance, the sheet management device performs a notification process for notifying it to a predetermined person . Regarding Claim 8, Hunt does not expressly teach. wherein in a case where information on a sheet , i.e., a currency bill, corresponding to identification information obtained by the first sheet handling apparatus , i.e., document processing device (101, 101a, 101b ) , as illustrated in figures 1, 4a and 4b, for example, is included in a list in which pieces of identification information to be detected , i.e., banknote/bill serial numbers, are registered in advance, the sheet management device performs a notification process for notifying it to a predetermined person , as mentioned at paragraphs 282, 402, 454, 500 and 877, which states as follows . [0282] According to some embodiments, each bank maintains a suspect or blacklist database including records associated with suspect bills and/or records associated with checks tied to fraudulent activity. According to some embodiments, in response to a financial institution system determining a document is a suspect document, the system can be configured to transmit or otherwise make available such information to all of the bank's branches . It is contemplated that such a method would make it very difficult for an individual attempting to kite checks from one store location to another (or one bank branch to another) over a series of days and to successfully pass the checks. According to some embodiments, the system can further be configured to transmit or otherwise make the suspect or blacklist database available to other banks and/or financial institutions. For example, if Bank A identifies a problem with a checking account or currency bill, this information could be transmitted to Bank B. Bank B could then notify Bank B's entire branch network . In a like manner Store A could share with Store B. According to some embodiments, Store A, Store B and Bank A and Bank B can all enter into agreement to share their respective suspect and/or blacklist databases or pay a third party provider to develop a master database, such as the databases described in the Searching/Master Database Section and in connection with FIGS. 12A and 12B, and in other sections of the present disclosure . According to some embodiments, the master database contains information submitted by all participating banks and/or stores, armored carriers, casinos, etc. It is contemplated that such a master database is a citywide, statewide, national and/or international database. According to some such embodiments, all participating