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 § 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 and 3-20 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, 3-9 and 11-20 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/apparatus’ merely use(s) a computer as a tool to perform an abstract idea. Additionally, it is noted that the sheet management device and sheet handling devices/apparatus’ are all recited at a high level without any details beyond the mention of “a sheet management device” in line 1 of Claim 1 and “a first sheet handling apparatus configured to receive a plurality of sheets and obtain first identification from each sheet” and “a second sheet handling apparatus configured to receive the plurality of sheets and obtain second identification information from each sheet” in Claim 9. 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 3-8 and 11-20 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, 3-4 and 9-20 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 teaches
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, comprising:
a memory, i.e., interpreted as the database and data manager (400), as illustrated in figure 2 and as mentioned in paragraphs 6, 61 and 94, for example; and
a control circuit, i.e., construed as the processor as mentioned at paragraphs 11 and 61, configured to:
receive transaction information related to sheet handling, i.e., noting the mention in paragraph 53, sixth sentence, that “[e]ach item (item of currency) carries a value denomination, and can further carry identifying indicia, such as serial numbers, embedded RFID signatures, and/or the like”, and also noting the example of a US one dollar bill having a data profile including the following:
Type: United States Bill
National Issuer: United States
Value Denomination: 1 United States Dollar
Serial Number: E19066540H;
And noting further examples of transaction related data in tables 1-27, for example.
generate first block data, noting again the mention of the use of blockchain at paragraphs 9, 32, 54, 58, 69, 79, 106, 114, 118 and Claim 32, that includes:
the transaction information, as mentioned at paragraph 53 and tables 1-27, for example,
first 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 first 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, and the transaction information, i.e., as mentioned at paragraph 53 and tables 1-27;
generate second block data, noting again the mention of the use of blockchain at paragraphs 9, 32, 54, 58, 69, 79, 106, 114, 118 and Claim 32, that includes:
the transaction information, as mentioned at paragraph 53 and tables 1-27,
second identification information, i.e., via the blockchain and/or the transaction information as mentioned at , as mentioned at paragraph 53 and tables 1-27, 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, i.e., from the blockchain structure, including information on the first eigenvalue, the transaction information, as mentioned at paragraph 53 and tables 1-27, and the second 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 1, note that Hunt further 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-55 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”) recorded 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 records 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 records 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 records 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 transactions 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. Transactions 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 transactions, 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 transactions 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 1, Note that Guo further 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
wherein the second eigenvalue is a fixed-length value that is
calculated by inputting the second input values into a predetermined
function and changed according to the second input values.
Regarding Claim 3, Hunt does not expressly teach, but Guo teaches
wherein the second eigenvalue is a fixed-length value that is
calculated by inputting the second input values into a predetermined
function and changed according to the second 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 200A 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 handling 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 repeated 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 repeated, 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 control circuit
generates the first block data including:
the first identification information of the sheets obtained in the first handling; and
the first eigenvalue calculated based on the first input values
including the first identification information,
in a second handling and subsequent handlings, the control circuit generates n-th block data including:
nth identification information of the sheets obtained in an n-th handling; and an n-th eigenvalue calculated based on n-th input values including information on an (n-1)-th, eigenvalue, the transaction information, and the n-th identification information, and
the control circuit 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,
wherein n is an integer of 2 or more.
Regarding Claim 4, Hunt does not expressly teach, but Guo teaches
in first handling, the control circuit
generates the first block data including:
the first identification information of the sheets obtained in the first handling; and
the first eigenvalue calculated based on the first input values
including the first identification information,
in a second handling and subsequent handlings, the control circuit generates n-th block data including:
nth identification information of the sheets obtained in an n-th handling; and an n-th eigenvalue calculated based on n-th input values including information on an (n-1)-th, eigenvalue, the transaction information, and the n-th identification information, and
the control circuit 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,
wherein n is an integer of 2 or more, 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) on the left and second sheet handling apparatus (200) on the right as illustrated in figure 2, for example.
Regarding Claim 10, see the rejection of Claims 1 and 4, for example.
Regarding Claim 11, Hunt does not expressly teach
wherein the first eigenvalue and the second eigenvalue are hash values calculated by inputting the first input values and the second input values, respectively, into a hash function.
Regarding Claim 11, Hunt does not expressly teach, but Guo teaches
wherein the first eigenvalue, i.e., the parent block, and the second eigenvalue, i.e., the second block, are hash values calculated/generated by inputting the first input values and the second input values, respectively, into a hash function, as mentioned at paragraphs 74 and 75, for example.
[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.
[0075] In some embodiments, when backing up the first blockchain into the storage system, the node 14 records, in a local data backup table, identification information (such as a block height and a block header hash value) of each block in the backed up first blockchain and a storage address, in the storage system, of each block in the backed up first blockchain. In this way, when the node 14 needs to access any block in the backed up first blockchain, a target block may be obtained by querying the storage system by using information in the data backup table, and the target block may be restored into the node 14.
Regarding Claim 12, Hunt teaches
wherein the transaction information includes container information of a container in which the plurality of sheets are stored for transport, noting the DSPID for bundles of banknotes in Table 25, p. 40, and SSPID for bricks of banknotes are found in Table 26, p. 40, for example. See also paragraph 48, last sentence, stating that “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”.
Regarding Claim 13, Hunt does not expressly teach,
wherein the transaction information includes at least one of: store information identifying a store at which the plurality of sheets are handled; apparatus information identifying the first sheet handling apparatus; and a transaction number assigned to a handling of the plurality of sheets, noting the transaction numbers in the transaction history in Table 16, p. 31, for example.
Regarding Claim 14, Hunt does not expressly teach,
wherein the control circuit is further configured to: generate a first sheet-group eigenvalue calculated based on the first identification information; and generate a second sheet-group eigenvalue calculated based on the second identification information, and
the first block data further includes the first sheet-group eigenvalue, and the second block data further includes the second sheet-group eigenvalue.
Regarding Claim 14, Hunt does not expressly teach, but Guo teaches
wherein the control circuit, i.e., application clients (11, 12), transaction platform (13), blockchain nodes (14) on network layer (103), as illustrated in figure 1 and as mentioned at paragraphs 37 and 38, for example, and processor (602), as illustrated in figure 9, is further configured to: generate a first sheet-group eigenvalue calculated based on the first identification information; and generate a second sheet-group eigenvalue calculated based on the second identification information, and
the first block data further includes the first sheet-group eigenvalue, and the second block data further includes the second sheet-group eigenvalue, as mentioned at paragraph 73 and 74, which mentions the basic structure of the blockchain and how eigenvalues are calculated/generated as well as illustrated in figure 1, noting data layer (104) and blockchain (15), for example.
Regarding Claim 15, Hunt teaches at paragraph 61 that the data manager (400) compares the identify of each item against a database of known items to verify that the items is authentic, for example. Note also the data structures that identify various transactions, bundles and bricks at tables 1-27. Note that Hunt also teaches at paragraph 109, last sentence, that “[t]he screen displays an error message indicating to the patron that this chip is not accepted at the Royale Casino”.
Regarding Claim 15, Hunt does not expressly teach,
wherein in a case where the first sheet-group eigenvalue does not match the second sheet-group eigenvalue, the control circuit determines that the plurality of sheets handled by the first sheet handling apparatus do not match the plurality of sheets handled by the second sheet handling apparatus, and performs a notification process for notifying determination result to a person in charge.
Regarding Claim 15, Hunt does not expressly teach, but Guo teaches
wherein in a case where the first sheet-group eigenvalue does not match the second sheet-group eigenvalue, the control circuit, i.e., application clients (11, 12), transaction platform (13), blockchain nodes (14) on network layer (103), as illustrated in figure 1 and as mentioned at paragraphs 37 and 38, for example, and processor (602), as illustrated in figure 9, determines that the plurality of sheets handled by the first sheet handling apparatus, as taught by Hunt, do not match the plurality of sheets handled by the second sheet handling apparatus, as taught by Hunt, and performs a notification process for notifying determination result to a person in charge, as taught by Hunt, noting that since Hunt already teaches notification of an error, it would have been obvious to have notified a determination result to a person in charge.
Regarding Claim 16, Hunt already teaches searching data in the records stored in the database of the data manager (400) as shown in figure 1 and in Tables 1-27.
Regarding Claim 16, Hunt does not expressly teach,
wherein the control circuit is further configured to, upon obtaining the second identification information from the second sheet handling apparatus, search past block data based on the second identification information to identify the first block data corresponding to the plurality of sheets.
Regarding Claim 16, Hunt does not expressly teach, but Guo teaches
wherein the control circuit, i.e., application clients (11, 12), transaction platform (13), blockchain nodes (14) on network layer (103), as illustrated in figure 1 and as mentioned at paragraphs 37 and 38, for example, and processor (602), as illustrated in figure 9, is further configured to, upon obtaining the second identification information from the second sheet handling apparatus, as taught by Hunt, search past block data based on the second identification information to identify the first block data corresponding to the plurality of sheets, noting Guo’s blockchain (15) structure has searchable blocks as seen in figures 1-9, for example.
Regarding Claim 17, Hunt does not expressly teach,
wherein the control circuit performs the recalculating of the eigenvalue at a predetermined time interval or each time new block data is generated.
Regarding Claim 17, Hunt does not expressly teach, but Guo teaches
wherein the control circuit, i.e., application clients (11, 12), transaction platform (13), blockchain nodes (14) on network layer (103), as illustrated in figure 1 and as mentioned at paragraphs 37 and 38, for example, and processor (602), as illustrated in figure 9, performs the recalculating of the eigenvalue at a predetermined time interval or each time new block data is generated, as illustrated in figures1-9, for example.
Regarding Claim 18, Hunt does not expressly teach,
wherein the control circuit is further configured to: receive approver information from a communication terminal communicably connected to the sheet management device, the approver information identifying an approver of the second block data;
generate third block data that includes: the approver information, the second identification information, and a third eigenvalue calculated based on third input values including information on the second eigenvalue, the second identification information, and the approver information; and manage the third block data in association with the second block data.
Regarding Claim 18, Hunt does not expressly teach, but Guo teaches
wherein the control circuit, i.e., application clients (11, 12), transaction platform (13), blockchain nodes (14) on network layer (103), as illustrated in figure 1 and as mentioned at paragraphs 37 and 38, for example, and processor (602), as illustrated in figure 9, is further configured to: receive approver information from a communication terminal, i.e., such as any one of the nodes (14), as illustrated in figure 1, communicably connected to the sheet management device, as taught by Hunt, the approver information identifying an approver of the second block data, i.e., block n-1 of blockchain (15) as illustrated in figure 1;
generate third block data, i.e., any of blocks (1 or 2) of blockchain (15), as illustrated in figure 1, that includes: the approver information, the second identification information, and a third eigenvalue/hash calculated/generated based on third input values including information on the second eigenvalue/hash, the second identification information, and the approver information; and manage the third block data , i.e., any of blocks (1 or 2) of blockchain (15), in association with the second block data, i.e., block n-1 of blockchain (15).
Regarding Claim 19, Hunt teaches,
wherein the notification process is performed by at least one of: displaying information indicating the determination result on a display, i.e., user interface screen (230), as mentioned at paragraph 49 and as illustrated in figure 6; transmitting predetermined information to an address registered in advance; and emitting at least one of sound and light, noting also paragraphs 55, 83, 94, 95 and 109, mentioning screens and displays.
Regarding Claim 20, Hunt teaches,
wherein each piece of the first identification information and each piece of the second identification information includes a combination of a serial number of a corresponding sheet, i.e., noting the item/banknote identifiers as seen in Table 1, for example, and information indicating a denomination of the corresponding sheet, noting the item value column in Table 1 on p. 21, 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 Claims 5-7, Hunt teaches the system as described above.
Regarding Claim 5, Hunt does not expressly teach
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 control circuit,
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 control circuit, 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 notifies the participating device of the disagreement. Based upon the notification, 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, notifies 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 802a to the back-end server 304 directly via the internet access point 306. Similarly, the device 310 may provide a hash 802b to the back-end server 304 directly via the internet access point 306. The device 312 may provide a hash 802c to the back-end server 304 via the device 308. The device 318 may provide a hash 802d to the back-end server 304 via the device 302. The device 302 may provide a hash 802e 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 802a, 802b, 802c, 802d and 802e 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 control circuit,
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 2015/0146963 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
the first 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 control circuit 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
first 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 control circuit 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 entities can have real time visibility for any suspect currency bills or checks associated with fraudulent activities found in the participating network the very same day the document is originally flagged as a suspect document by one of the participating entities.
[0402] Now referring to FIG. 9A, a representation of an interface 200a for entering denomination information of a flagged no-call denomination document is shown according to some embodiments. According to some embodiments, a no-call denomination document is a currency bill (as shown in FIG. 9A) that the document processing system 100 failed to denominate (e.g., a currency bill whose denomination could not be called or determined by the controller 150). In some such embodiments, the controller 150 is configured to flag a no-call denomination currency bill to an operator of the document processing system 100 according to a designated mode of operation, such as, for example, the run-and-present mode or the stop-and-present mode. As described above, according to the run-and-present mode and/or the stop-and-present mode, the document processing system 100 can be configured to display a visually readable image 210a of the flagged no-call denomination document on the interface 200a to indicate to the operator that the controller 150 could not call or determine the denomination of the currency bill. According to some embodiments, the document processing system 100 can be configured to display the visually readable image 210a to flag the currency bill as satisfying any one or more other flag criteria, such as, for example, the extraction error-currency bill criterion such as a serial number extraction error criterion (described in reference to FIGS. 9C-9E), the extraction error-check criterion such as a MICR line extraction error criterion, the suspect criterion (described in reference to FIGS. 11A and 11B in the Modes of Operation--Blacklist Section, and in other sections of the present disclosure), the doubles criterion, the overlap criterion, the fitness criterion, and/or the soil criterion. According to some embodiments, the interface 200a is the control panel 170 or a local display device, such as, for example, a touch screen display of the document processing system 100. According to some embodiments, the interface 200a is a remote display device communicatively connected to the document processing system 100.
[0454] According to some embodiments, the document processing system 100 receives and stores in a memory and/or is coupled to a memory having stored therein a blacklist database of serial numbers and/or MICR lines or a currency bill blacklist database and a check blacklist database as described above or a database including both currency bill blacklist information and check blacklist information. According to some embodiments, the blacklist database of serial numbers can further include information in addition to serial numbers, such as, for example, a reason why a particular currency bill was determined to be suspect and/or counterfeit. For example, the blacklist database can further indicate that a blacklisted currency bill having serial number AL12345678B was blacklisted because of non-conforming magnetics. For another example, the blacklist database can further indicate that a blacklisted currency bill having serial number IF12345678C was blacklisted because of non-conforming paper characteristics. It is contemplated that according to some embodiments, the document processing devices and/or systems of the present disclosure, such as device 101, can include such reasons that bills were determined to be suspect in generated records and/or databases, such as, for example, the records and databases described in the Document Records and Data Files Section and/or the Modes of Operation--Searching/Master Database Section, and in other sections of the present disclosure.
[0500] For another example, many banks include one or more bundles of currency bills with prerecorded serial numbers and/or prerecorded denominations in each teller draw and/or at each teller station. When a bank robber holds up the bank, the tellers are trained to give these bundles of currency bills to the bank robber. Thus, law enforcement agencies can use the prerecorded serial numbers and/or denominations to track the stolen money. For example, the prerecorded serial numbers and/or denominations can be added to a database such as a stolen money database and/or a crime money database, similar to a blacklist database according to the present disclosure. Thus, when banks and/or other entities use one or more document processing systems or devices according to the present disclosure to process currency bills, the serial numbers and/or denominations of the processed currency bills can be extracted and compared to the serial numbers and/or denominations of the currency bills included in the crime money database. When a match occurs, law enforcement agencies can be notified and provided information associated with how a particular entity having a document processing system came to be in possession of currency bills having serial numbers and/or denominations matching those stored in the stolen money database. For example, when a bank receives a deposit including currency bills from a customer, the teller can run the money through a document processing system or device as described in the present disclosure. The document processing system or device images each received bill, denominates each bill, and extracts the serial number of each bill. Data files and/or records are generated for the deposit transaction as described herein. In addition to serial number and denomination information the data file and/or records may include information associating the deposit of each bill with a customer who deposited the currency bills and/or the customer account which was credited for the associated deposit. Thus, a match can help the law enforcement agencies track the stolen money and/or find the bank robber or a bank account associated with the bank robber or provide leads for law enforcement personnel by allowing them to determine into which accounts stolen currency bills were deposits and thus investigate the owner of such accounts and/or question them about how they came into possession of the stolen currency bills.
[0877] As discussed elsewhere, the extracted denomination, serial number, Federal Reserve Letter/Number, Series, check letter and quadrant number, check letter and face plate number, and/or back plate number data fields may be used for cross-referencing purposes to determine if a currency bill is a suspect bill. For example, the serial number of a currency bill may be related to the series. If the series information known to be associated with a currency bill's serial number does not match for a particular bill, then the bill is a deemed a suspect bill. Therefore, it is contemplated that in certain embodiments a memory stores known serial number information for genuine currency bills along with the proper additional currency bill data field information (e.g., denomination, Federal Reserves Letter/Number, series, check letter and face plate number) that should be associated with the genuine currency bills. For example, a group of currency bills of the same denomination and printed during the same run on a given date are expected to have the same Check Letter and Quadrant Number. It is contemplated that a central bank or a government entity would maintain a database with the denomination and serial numbers of currency bills along with each currency bills associated additional information. For example, the Bureau of Engraving or other government entity may maintain a database indicating that the $50 US Federal Reserve Notes printed for the Federal Reserve Bank of Dallas with serial numbers ranging from EK03500000A to EK03600000A are Series 2004 and were printed using Check Letter and Quadrant Number D1 and back plate number nine. Such information may be stored in a memory of a document processing device and/or system or may be accessed by the document processing device and/or system (e.g., devices 100, 101', 101a,b, 400, 1171a-n, 1173a-n) over a network. In certain embodiments information about the relationships between currency bill series letters, series year, Federal Reserve Letter/Number, and the serial number may also be stored in a memory or may be accessed by a document processing device and/or system. One or more processors and/or controllers in the document processing device and/or system can then compare serial numbers extracted from image data associated with currency bills to see if their respective serial numbers have been identified as a suspect serial number, such as by being placed on a blacklist database described in the Modes of Operation--Blacklists Section and in connection with FIG. 11C, and in other sections of the present disclosure. The processor can further cross-reference the additional identifying character information extracted from the images of the currency bills with the extracted serial number and compare the cross-referenced extracted information with the stored information on the relationships of serial numbers and additional information for genuine currency bills.
Emphasis provided.
Regarding Claim 8, 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 information on a sheet corresponding to
the first 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 control circuit performs a notification
process for notifying it to a predetermined person, as taught by Klein, in Hunt’s sheet management device for the purpose of increasing the likelihood of identifying suspect banknotes such as those involved in bank thefts as well as counterfeit banknotes.
Response to Arguments
Applicant's arguments filed 5/15/26 have been fully considered but they are not persuasive.
Rejections under 35 USC Section 101
Applicant asserts that Claims 1-20 are patent eligible under the Alice/Desjardins framework. As Applicant states at p. 11 of The Remarks received 5/15/26, “the Desjardins Panel held that “claims directed to an improvement in the functioning of a computer or an improvement to other technology or technical field are patent eligible”. However, Applicant’s claims, such as Independent Claim 1, recites “a sheet management device comprising” which is a very high level recitation with no further structural details other than the memory and control circuit, which constitutes substantially a generic computer. Claim 9 mentions in the first five lines
“a sheet management system comprising: a first sheet handling apparatus configured to receive a plurality of sheets and obtain first identification information from each sheet; a second sheet handling apparatus configured to receive the plurality of sheets and obtain second identification information from each sheet; and a management device”.
These limitations are also recited at a high level with no structural details. The fact that there are first and second sheet handling apparatus does not constitute an improvement as recognized under the Alice/Desjardins framework. Instead, they constitute generic computers with an implied scanner that elicits data that is then collected in a data gathering process, similar to the scanning system in the Content Extraction and Transmission v. Wells Fargo Bank decision. The remaining limitations in both Independent Claims 1 and 9 constitute functional steps that amount to an algorithm to safeguard business information which is a commercial activity.
Claim 10 recites no structural limitations and recites a sheet management method with functional method steps that amount to an algorithm to safeguard business information which is a commercial activity.
Rather than a special technical solution, the limitations in Claims 1 and 3-20 concern a an algorithm to safeguard business information which is a commercial activity.
Therefore, Claims 1 and 3-20 remain rejected under 35 USC Section 101.
Rejections under 35 USC Section 103
Regarding Claim 1, Applicant asserts that “Hunt does not describe an eigenvalue calculated based on input values that include transaction information” as mentioned in Remarks, p. 17, lines 6 and 7.
In response to Applicant's arguments, it is noted that the test for obviousness is not whether the features of a secondary reference may be bodily incorporated into the structure of the primary reference; nor is it that the claimed invention must be expressly suggested in any one or all of the references. Rather, the test is what the combined teachings of the references would have suggested to those of ordinary skill in the art. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981).
In response to Applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
In this situation, although Hunt does not teach calculating an eigenvalue, it does mention the use of blockchain to secure information such as transaction information and related data including DSPIDs, SSPIDs and access codes, for example, as mentioned at paragraphs 9, 32, 54, 58, 69, 79, 106, 114 and 118, which state as follows.
[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.
[00032] In some embodiments, information in the system is recorded in a blockchain.
[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.
[00058] The data manager and records within the system can also be designed to have desired characteristics, such as EMP-proof (in that the data will not be destroyed upon exposure to an electromagnetic pulse), offsite backup (in that the data is stored either on a cloud platform or remote servers), and blockchain interface (in that the data manager can interact with blockchain protocols to enhance security).
[00069] The system is configured to allow removal of bundles from the secondary repository, such as when a code is entered or at the end of each business period such as, for example, a day or a week. The bundles with DSPIDs are physically removed from the secondary repository and delivered to the user’s bank, where verification of amounts and value is greatly facilitated by correlation of the DSPIDs already in the bank’s possession and/or delivered with the bundles. Because the DSPID is associated with discrete items of currency, there is no need to remove items for bank deposit on an item-by-item basis. In some cases, the bank can unbundle the cash for its own purposes, and the information on the destroyed bundles can be expunged from the system. In other cases, the bank can retain the cash in the bundled state, incorporate the bundle’s associated information into its own systems, and/or facilitate further transactions using the bundle(s). In some embodiments, the system inventory creates and retains a record of all bundles and items of currency which have been deposited into a bank.
Some embodiments of the invention provide a cash inventory and tracking system, without regard to the mechanical features by which the inventory is created and/or security provided. In these embodiments, cash is scanned for creation of the inventory, whether in a system as described herein or in any other system capable of scanning and capturing the relevant data for a cash inventory system. In some embodiments, cash having been thus inventoried is bundled and a DPSID is created for the bundle, to facilitate tracking of a group of bills in the system. The system can include data for movement of bundles within the system, such as movement within a bank, a private vault system, or the like. In some embodiments, bundles and/or loose inventoried bills are packaged into bricks to secure larger value amounts for ease of tracking and transport without risk of loss, theft, fraud, or damage by fire, water, or the like.
Some embodiments of the invention provide a cash-based banking system wherein transactions are collateralized by cash inventoried according to the cash inventory and tracking system of the invention. The banking system can further include one or more locations for centralized storage of cash collateral in the form of bricks and/or bundles and/or loose, inventoried, bills. The banking system can be adapted to permit electronic transactions in which parties trade title to the bricks and/or bundles and/or individual bills by trading electronic information permitting control over and access to the bricks and/or bundles and/or individual bills. The difference between this banking system and conventional banking systems is that the transactions are collateralized by specific, unique items of cash in inventory rather than by cash equivalents or claims on deliverable but fungible value units. In the system, each and every brick, bundle and/or loose bill is a unique item of property personal to one party in the transaction and title to those specific items of property is transferred by transfer of electronic information permitting real-time transactions between parties anywhere in the world. In this system, a party receiving payment by obtaining title to specific bricks, bundles, etc., can then claim physical possession and delivery of these items or can maintain a ledger of such items of property for other transactions.
Transactions and related data can be handled, tracked, and secured by approaches known in the art and can be rendered hackproof via use of blockchain technology, encryption, or the like.
[00079] Within and across instances of the cash-management system, bricks are standardized and secure such that they can function as reliable collateral for transactions. A brick can be removed from one instance of the system by scanning its SSPID out of that instance, and then scanned into another instance of the system by scanning the SSPID into that instance. The two instances communicate from their respective inventories the records of bundles, items, and item data, and other records associated with the brick, such that the records indicate that said bundles and items are present in the second instances and not present in the first instance. In some embodiments, this transfer of information is recorded and verified by blockchain, encryption, and/or the like. The standardized nature of the bricks enables the user to transfer bricks as described in Stage 4 to facilitate transactions.
[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 transactions 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.
[000114] A convenience store implements the cash management system of the present invention. Records and inventory are maintained in a manner similar to those shown in Examples 1 and 2. Because the store has only limited space to retain cash, and for security reasons, the store has implemented procedures to deposit unneeded cash with its bank. The first step of this procedure is bundling cash periodically throughout the day. The store is open 24 hours a day, so it has decided to bundle cash in excess of a defined amount to always be retained in the register at 10:00 am and 8:00 pm. When these bundles are created, their DSPIDs and contents are transmitted to the store’s bank. This transmission is encrypted and verified by blockchain technology. Thus, whenever a bundle is created, both the store and the bank are simultaneously made aware of the cash value and items of currency that the store possesses.
[000118] The selected bundles are enclosed within a brick package, which is then assigned a the SSPID and given an access key by the system inventory. The selected bricks are similarly enclosed within a brick package, assigned an SSPID and access key. The system inventory alerts the bank of an incoming transfer and transmits the SSPIDs and access codes through an encrypted, blockchain verified communication. The bank acknowledges that the transfer is incoming. A courier for the casino securely and discretely physically transfers the two new bricks to the bank.
Emphasis provided.
Therefore, Hunt teaches the sheet feeding aspects in the environment of handling banknotes, and scanning them via scanner (220, 520), as mentioned at paragraph 44 and illustrated in figures 1, 2 and 6, for example, to elicite transaction and related information, and then using blockchain technology to secure the datastream.
Guo further teaches the details of blockchain technology that are directly applicable to Hunt’s use of blockchain, in which each block of the chain are detailed as to the creation/generation/calculation of eigenvalues/hash values to create the block header (21) attached to the block body (22) to which the information, i.e., transactions 1..m” are attached, as illustrated in figures 1-3 of Hunt, for example.
Applicant asserts at Remarks, p. 17, last sentence that also bridges p. 18, first line, states “Guo provides no discussion or suggestion of calculating an eigenvalue based on input values that include transaction information related to sheet handling”.
However, Guo teaches calculating hash values at paragraphs 45, 54 and 55, which states as follows.
[0054] 5. adjusting a difficulty value field according to an average generation time of blocks in a previous period of time to adapt to a total constantly changing calculation amount of the entire network. If the total calculation amount increases, the system increases the difficulty value of the math problem so that a time to complete the next block is still within a certain period of time.
[0055] A block header hash value may uniquely identify a block, and any node 14 may independently obtain the block header hash value by performing a hash calculation on the block header. The block header hash value is not actually included in a data structure of the block. The block header hash value is calculated by a node 14 when the node 14 receives the block from the blockchain network. The block header hash value may be stored in an independent database table as a part of block metadata, for easy indexing and faster retrieval of a block from a magnetic disk. In addition, the block further has a block height in the blockchain, which may be used for identifying a position of the block in the blockchain. A block height of the first block (that is, the genesis block) is 0, a height of a block referencing the genesis block is 1, and so on. Each block stored in the blockchain later has a position 1 “higher” than that of a previous block, and its block height value is equal to a block height value of the previous block plus 1. Different from the block header hash value, the block height is not a unique identifier of the block. Two or more blocks may have the same block height and contend for the same position in the blockchain. The block height is not a part of the data structure of the block either, and is not stored in the block. When receiving a block from the blockchain network, the node 14 dynamically identifies a position (that is, a block height) of the block in the blockchain. The block height may also be stored as metadata in an indexed database table for quick retrieval.
Emphasis provided.
Guo also mentions a block header eigenvalue as mentioned at paragraphs 9, 15, 22, 74, 98, 122, and as mentioned at Claims 5, 11 and 18, which state as follows.
[0008] A block height of the second block may correspond to a block height of a last block in the first blockchain.
[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.
[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.
(Claim) 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.
(Claim) 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.
(Claim) 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.
Guo also teaches each node generates information as mentioned at paragraphs 17, 18, 39, 49-54, 67, 73 and 74, for example, as follows.
[0017] The instructions may be further configured to cause at least one of the one or more processors to perform, after the first blockchain is deleted, querying the data backup table for a storage address corresponding to identification information of a block included in the first blockchain, and accessing the block in the storage system according to the storage address.
[0018] According to an aspect of an example embodiment, a computing device is provided, including: at least one memory configured to store program code; and at least one processor configured to read the program code and operate as instructed by the program code. The program code includes: first querying code configured to cause at least one of the at least one processor to query a first block of a first blockchain for unused transaction output information based on a first condition being met, the first block including each block of all blocks included in the first blockchain; generating code configured to cause at least one of the at least one processor to generate transaction information according to the unused transaction output information obtained based on querying of the first querying code, the transaction information indicating a transaction operation based on an account address to which the unused transaction output information belongs; first recording code configured to cause at least one of the at least one processor to record the transaction information in a second block and releasing the second block, and recording the second block on which a consensus is reached on a second blockchain; and backup code configured to cause at least one of the at least one processor to back up the first blockchain into a storage system, and deleting the first blockchain.
[0039] The blockchain network is essentially a P2P network. Each node 14 receives and generates information, and a common blockchain is maintained between the nodes 14 to keep communication. In a blockchain network, each node 14 may create a new block. After the new block is created, another node is notified through broadcast, and verifies the block. After verified by the node, the new block may be added to the blockchain. The data layer 104 encapsulates a data structure of the blockchain 15. As shown in FIG. 1, the blockchain 15 is formed by linking a plurality of blocks (a block 0 to a block n). The first created block 0 is a “genesis block”, and then blocks with the same data structure created according to a rule are connected in sequence through a chain structure to form a main chain. With an increasingly long running time, new blocks are continuously added to the main chain after being verified, and the main chain becomes longer and longer.
[0049] After the block 200A is added to the blockchain, all miners (blockchain nodes 14) begin to generate a next block, including:
[0050] 1. recording transaction information in a local memory into a block body;
[0051] 2. generating, in the block body, a Merkle tree of all transaction information in the block, and saving a value of a Merkle tree root (that is, a Merkle root) in a block header;
[0052] 3. generating a hash value through a SHA256 algorithm by using data of the block header of the block 200A recently added to the blockchain, and filling the hash value into a parent block hash value of the current block;
[0053] 4. saving a current time in a timestamp field; and
[0054] 5. adjusting a difficulty value field according to an average generation time of blocks in a previous period of time to adapt to a total constantly changing calculation amount of the entire network. If the total calculation amount increases, the system increases the difficulty value of the math problem so that a time to complete the next block is still within a certain period of time.
[0067] In operation S302, the node 14 generates one or more pieces of transaction information according to the unused transaction output information obtained by query, the generated transaction information indicating a transaction operation based on an account address (e.g., a transaction operation that does not change an account address) to which the unused transaction output information belongs, which may be a transaction operation of transferring money to itself (or referred to as a transaction rolling operation or change operation). One piece of transaction information includes at least one piece of transaction input information and at least one piece of transaction output information. The at least one piece of transaction input information respectively references at least one piece of unused transaction output information obtained by query. Transaction output information corresponding to each piece of transaction input information includes the unused transaction output information obtained by query and referenced by the transaction input information, to represent the transaction operation of transferring money to itself. Herein, the node 14 may generate one piece of transaction information according to a plurality of pieces of unused transaction output information, which may alternatively generate more than one piece of transaction information according to implementation requirements. For example, if five pieces of unused transaction output information are obtained by query, one piece of transaction information may be generated, which includes five transaction operation records (five sets of transaction input information and transaction output information). The five transaction operation records respectively describe transaction rolling operations for the five pieces of unused transaction output information. Alternatively, another number of pieces of transaction information may be generated. Each piece of transaction information includes one or more transaction operation records. The transaction information includes a total of five transaction operation records to describe the transaction rolling operations for the five pieces of unused transaction output information.
[0073] In some embodiments, a block height of the second block may follow (or correspond to) a block height of the last block in the first blockchain. For example, the first blockchain has ten blocks (with block heights being 1 to 10 respectively). After unused transaction output information is obtained from the ten blocks by query and the rolling transaction operation is performed, a new block (the second block) with a height being 11 may be generated. Then, an initial block height of the second blockchain is 11, which follows the block height 10 of the last block in the first blockchain.
[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.
Emphasis provided.
Thus, at the very least, Guo teaches creating an eigenvalue as part of the block header. Note that the terms generating and calculating are considered to be referring to the same process of creating a block element in the blockchain, i.e., the block header. The block header is taught to have an eigenvalue which is also referred to as a hash value. At the very least, the eigenvalue is suggested/implied to be calculated by the processor through program instructions/code. The processor is construed as a control circuit.
The blocks of the blockchain are expressly taught by Guo at figures 5 and 6 and at paragraphs 68 and 78, for example, which state as follows.
[0068] As shown in FIG. 5, for example, the unused transaction output information obtained by query includes UTXO1 to UTXO5, and three pieces of transaction information TX1 to TX3 may be generated. TX1 includes two pieces of transaction input information Input11 and Input12 that respectively reference UTXO1 and UTXO2. Input11 and Input12 correspond to transaction output information Output11 and Output12, respectively. Output11 includes UTXO1, and Output12 includes UTXO2, that is, in terms of quantity and address, Output1 is the same as UTXO1, and Output12 is the same as UTXO2. TX2 includes transaction input information Input21 that references UTXO3, Input21 corresponds to transaction output information Output21, Output21 includes UTXO3, and Output21 is the same as UTXO3 in terms of quantity and address. TX3 includes two pieces of transaction input information Input3l and Input32 that respectively reference UTXO4 and UTXO5. Input31 and Input32 correspond to transaction output information Output31 and Output32, respectively. In terms of quantity and address, Output3l is the same as UTXO4, and Output32 is the same as UTXO5. In this way, the amount of unused assets respectively represented by UTXO1 to UTXO5 is transferred to the owner of the assets. In other words, the transaction operations neither change ownership of the assets, nor bring substantial changes to the account data.
[0078] FIG. 6 shows a schematic diagram of a block according to an embodiment of the disclosure. In FIG. 6, the node 14 queries blocks 1 and 2 in an old blockchain to obtain unused transaction output information TX14 and TX25, and performs transaction rolling operations respectively on TX14 and TX25 to generate a piece of transaction information TXN1. TXN1 includes two transaction records that respectively include transaction output information in TX14 and TX25. Subsequently, the node 14 creates a new blockchain, adds TXN1 to a new block N in the new blockchain, backs up the old blockchain into the storage system in a cold backup manner, and deletes the old blockchain including the blocks 1 and 2.
Emphasis provided.
Therefore, Claims 1 and 3-20 remain rejected.
Conclusion
Applicant is encouraged to contact the Examiner should there be any questions about this rejection or in an endeavor to explore potential amendments or potential allowable subject matter.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Huang ‘005 is cited as teaching an eigenvalue algorithm used for calculating an eigenvalue, as mentioned at paragraph 150-153, which states as follows.
[0150] When blocks are generated in the blockchain, referring to FIG. 5C, when a node where the blockchain is located receives the inputted information, the inputted information is verified. After the verification is completed, the inputted information is stored in a memory pool, and a hash tree used for recording the inputted information is updated. Next, the timestamp is updated to the time when the inputted information is received, different random numbers are tried, and eigenvalue calculation is performed a plurality of times, so that the calculated eigenvalue may satisfy the following formula:
[0151] SHA256 is an eigenvalue algorithm used for calculating an eigenvalue; version (a version number) is version information of the related block protocol in the blockchain; prev_hash is a block header eigenvalue of the parent block of the current block; merkle_root is an eigenvalue of inputted information; ntime is the update time of updating a timestamp; nbits is current difficulty, and is a fixed value within a period of time and is redetermined after the fixed period of time; and x is a random number; and TARGET is an eigenvalue threshold. The eigenvalue threshold may be determined and obtained according to nbits.
[0152] In this way, when a random number satisfying the above formula is obtained through calculation, information may be correspondingly stored, and a block header and a block body are generated, to obtain a current block. Subsequently, the node where the blockchain is located transmits, according to the node identifiers of other nodes in the blockchain system, a newly generated block to the other nodes in the blockchain system in which the node is located, and the other nodes verify the newly generated block and add the newly generated block after the verification to the blockchain stored in other nodes
Emphasis provided.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEFFREY ALAN SHAPIRO whose telephone number is (571)272-6943. The examiner can normally be reached Monday-Friday generally between 8:30AM and 6:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Anita Y Coupe can be reached at 571-270-3614. 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.
/JEFFREY A SHAPIRO/Primary Examiner, Art Unit 3619
August 7, 2026
Prosecution Insights