Centralized Tracking of Digital Currencies

Abstract

The central system may track virtual notes of digital currency involved in transactions such that current ownership of the virtual notes may be verified as a basis for approving transactions involving the virtual notes. The central system may create and maintain an electronic history of the virtual notes and update the electronic history after each transaction.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application claims priority to U.S. Provisional Patent Application No. 63 / 148,335, filed February 11, 2021, U.S. Provisional Patent Application No. 63 / 173,631, filed April 12, 2021, U.S. Provisional Patent Application No. 63 / 209,989, filed June 12, 2021, U.S. Provisional Patent Application No. 63 / 240,964, filed September 5, 2021, U.S. Provisional Patent Application No. 63 / 294,732, filed December 29, 2021, and U.S. Provisional Patent Application No. 63 / 304,684, filed January 30, 2022, the entire contents of which are incorporated herein by reference. [Background technology]

[0002] National digital currencies (NDC) may be useful as a complement or replacement for a nation's physical currency. Distributed ledger technology (DLT) has been explored in this context. Distributed ledger technology provides a consensus network in which a copy of the ledger is maintained and updated at each of its independent nodes. When a question arises about a transaction, consensus among the nodes determines the answer to that question. For a variety of reasons, including efficiency, distributed ledger technology is not particularly well suited to implementing NDC. For this reason, the inventors of the subject matter described in this and related applications have investigated how to practically and efficiently implement NDC using centralized tracking.

[0003] The illustrative embodiments are best understood from the following detailed description when read in connection with the accompanying drawing figures. [Brief description of the drawings]

[0004] [Figure 1A]FIG. 1 is a diagram showing tracking of NDC virtual notes (hereinafter sometimes abbreviated as "VN"). [Figure 1B] FIG. 1 is a diagram showing a functional network layout of a central system (hereinafter sometimes abbreviated as "CS"). [Figure 1C] FIG. 1 illustrates how a central system processes the communication of batches of virtual notes and convertible party information. [Figure 1D] FIG. 1 illustrates a method for validating transfer instructions for virtual notes for digital currency. [Figure 1E] FIG. 1 illustrates how a central system processes ownership queries relating to one or more virtual banknotes. [Figure 1F] FIG. 1 illustrates how a central system processes transfer instructions for one or more virtual banknotes. [Figure 1G] FIG. 1 illustrates a method for monitoring, inspecting, and exchanging digital currency. [Figure 2A] FIG. 1 illustrates a digital currency monitoring center. [Figure 2B] FIG. 1 illustrates separate addressing for different types of communications to a central system. [Figure 3A] FIG. 10B is a diagram showing a memory configuration of the memory system of FIG. 10A. [Figure 3B] FIG. 13 is a diagram showing another memory configuration of the memory system. [Figure 3C] FIG. 13 is a diagram showing another memory configuration of the memory system. [Figure 4] FIG. 1 illustrates a method for redeeming virtual notes of digital currency. [Figure 5A] FIG. 1 is a diagram showing an electronic communications network integrated with a security gateway system (hereinafter sometimes abbreviated as "SGS") of a central system. [Figure 5B] FIG. 5B illustrates a working memory configuration of a server in a security gateway of the central system of FIG. 5A. [Figure 5C]FIG. 2 illustrates how a received instruction or inquiry is processed by an SGS. [Figure 5D] FIG. 2 illustrates the memory organization of the SGS for processing received instructions or queries. [Figure 5E] FIG. 2 illustrates the processing architecture of the SGS for processing received instructions or queries. [Figure 5F] FIG. 2 illustrates another processing configuration of the SGS for processing received instructions or queries. [Figure 5G] FIG. 2 illustrates another processing configuration of the SGS for processing received instructions or queries. [Figure 5H] FIG. 2 illustrates another processing configuration of the SGS for processing received instructions or queries. [Figure 5I] 1 illustrates the processing order of packets received and stored at the SGS for processing received instructions or queries. [Figure 5J] FIG. 2 illustrates the use of dedicated queues by the processing resources of an SGS to process received instructions and queries. [Figure 6A] FIG. 2 illustrates how a received instruction or inquiry is processed by an SGS. [Figure 6B] FIG. 1 illustrates a method for performing aggregate security checks in a memory system of a central system. [Figure 6C] FIG. 2 illustrates how a received instruction or inquiry is processed by an SGS. [Figure 6D] FIG. 2 illustrates the memory organization of the SGS for processing received instructions or queries. [Figure 6E] FIG. 13 illustrates another memory organization of the SGS for processing received instructions or queries. [Figure 6F] FIG. 13 is a diagram showing an example of the format of SFIOI. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0005] In the following detailed description, for purposes of explanation and not limitation, representative embodiments disclosing specific details are described to provide a thorough understanding of representative embodiments according to the present teachings. However, other embodiments not inconsistent with the present disclosure may deviate from the specific details disclosed herein. Descriptions of known systems, devices, methods of operation, and methods of manufacture may be omitted so as not to obscure the description of the representative embodiments. Systems, devices, and methods that are within the ordinary skill of one or more of the many technologies related to the present teachings are nonetheless within the scope of the present teachings and can be used in accordance with the representative embodiments. It is to be understood that the terms used herein are for the purpose of describing particular embodiments only and are not intended to be limiting. Defined terms are in addition to the technical and scientific meaning of the defined terms as generally understood and accepted in the art of the present teachings.

[0006] If centralized tracking is used to implement NDC, many aspects of efficiency must be addressed. The central system tracking NDC must interface with the public and, in terms of efficiency, should only accept one or a very few predefined formats for incoming communications. Since the public could include any individual in the world connected to the Internet, the central system must be accessible with minimal complexity while remaining secure. Queries and instructions to the central system may be provided as short, formatted inquiry or instruction (SFIOI), which requires minimal information including at least the unique identification (ID) of each virtual banknote (VN) specified in the SFIOI and the unique identifier of each party related to the content conveyed in the SFIOI. NDC's centralized tracking could potentially offer benefits such as the ability to proactively and authoritatively verify ownership of virtual banknotes even in the absence of transactions or transfers, and to cooperate with courts, law enforcement and security authorities, for example by freezing virtual banknote transfers pursuant to a court order.

[0007] After creation, the virtual notes may first be assigned to financial institutions by a central system and then transferred between various parties before being returned to the central system for retirement. The virtual notes and SFIOI may be packetized and communicated over a packet-switched network that switches packets according to the Transmission Control Protocol / Internet Protocol (TCP-IP) and / or User Datagram Protocol (UDP-IP).

[0008] In tracking virtual banknotes (VNs) in the NDC illustrated in FIG. 1A, a transaction requester and / or a trading partner may send a SFIOI to the internet protocol (IP) address of the central system 150 to inquire about ownership of the virtual banknote or to provide instructions to transfer ownership of the virtual banknote. In some embodiments, a first electronic communication device (ECD) used by a party may initiate a transaction with a second electronic communication device used by the other party and send virtual banknote information (VN_info) to the second electronic communication device. The second electronic communication device may initiate an inquiry to the central system 150 and send the VN_info to the central system 150. In some embodiments, the trading partner may be pre-verified by the central system 150 that the transaction requester is the owner of the virtual banknote without the central system having to confirm to the transaction requester that the virtual banknote will be transferred, such as when the transaction requester provides verification information to the trading partner that uniquely identifies the transaction requester. Because the risk that a counterparty can infer that any particular party is the owner of record of any particular virtual note is extremely low, a counterparty's presentation of verification information to the central system 150 allows the central system 150 to assume that the transaction requester has consented to the transfer of the virtual note.

[0009] In some embodiments, the transaction requester may provide an encrypted unique identifier to the transaction counterparty for the transaction counterparty to query the central system 150. When the transaction requester confirms the transaction, the transaction counterparty obtains an unencrypted unique identifier that uniquely identifies the virtual banknote. The transaction requester may provide verification information that uniquely identifies the transaction requester. The transaction counterparty may present the verification information to the central system 150, thereby enabling the central system 150 to assume that the transaction requester has consented to the transfer of the virtual banknote. In these embodiments, the transaction counterparty pre-verifies the validity of the virtual banknote and the transaction requester's ownership of the virtual banknote by directly transmitting the transaction requester's verification information and the virtual banknote information (VN_info) to the central system 150.

[0010] In some embodiments, the transaction requester may notify the central system in advance that virtual notes will be transferred.

[0011] In some embodiments, an executable program may be embedded in the virtual banknote. The executable program may be configured to initiate a SFIOI with the central system 150 and begin reporting the current location of the virtual banknote periodically and / or when an internet connection becomes available after being unavailable. Metadata may be sent to the central system 150 to update the electronic records of the central system 150 as a non-party initiated check-in process. The metadata may include records of offline transactions involving the virtual banknote, such as transactions using near field communications (NFC).

[0012] A unique identifier for a party can be specified in as few as five bytes. The identifier of the country issuing the unique identifier can be incorporated in the unique identifier, so that the unique identifier can be used for different central systems. A unique identifier for a virtual banknote can be specified in four or five bytes. Using five bytes, up to approximately 1.1 trillion unique identifiers can be specified for a virtual banknote, using four bits (e.g. the first four bits) of the full five bytes, one of up to 16 different denominations for the virtual banknote can be specified, and using the remaining 36 bits, approximately 69 billion different unique identifiers can be specified for a virtual banknote of any particular denomination.

[0013] The SFIOI may be formatted exactly for any particular central system, but may be different for another central system. The logical format of the SFIOI for the central system 150 may require exactly 512 bytes, since a typical packet size for some communications is 512 bytes, and the minimum page size of flash memory is also 512 bytes. Also, fractions (e.g. 256 bytes) or multiples (e.g. 1024 bytes) of 512 bytes may be logical choices for format size from the perspective of processing and storage efficiency. The unique identifier of the party specified in the SFIOI and the unique identifier of the virtual banknote may be allocated a full word of 64 bits (or more). The number of virtual banknotes (VN number) that can be specified in any SFIOI may be limited to, for example, 7 or 9. The SFIOI may also specify the actual number of virtual banknotes specified in the SFIOI, the type of SFIOI, etc. Since most or perhaps all of the data provided in the various fields of the SFIOI format can be specified in less than 64 bits, the SFIOI format can be specified such that the data starts in the first bit of the field or ends in the last bit of the field. Thus, either the trailing or leading bit of the field is set to zero (0). Fields of the SFIOI may be provided to uniquely identify currency reader programs (CRPs) and electronic wallet programs (EWPs) that handle virtual banknotes. Authorized currency reader programs and electronic wallet programs can operate according to the expected format of the SFIOI and will not transmit an SFIOI that does not conform to the expected format. An example of the format of the SFIOI is illustrated in and described with respect to FIG. 6F.

[0014] In the functional network layout of the central system in FIG. 1B, a security gateway system (SGS) 156 serves as an interface with the public. The SGS 156 is used as an interface with the public of the central system 150. The central system 150 includes the SGS 156, an ID management system 151 (identifier management system), a ledger storage system (hereinafter sometimes abbreviated as "LSS") 152, and a main memory system (hereinafter sometimes abbreviated as "LSS"). The central system 150 includes a centralized management system (MMS) 153, an artificial intelligence and analytics system 154, and a backup memory system 155. The arrows in FIG. 1B indicate that in some cases, communication between elements of the central system 150 may be limited to mostly or entirely one-way communication. The identity management system 151 may be used to store and update records of parties authorized to use NDC that are tracked by the central system 150. Identifiers (IDs) may be standardized globally for multiple central systems, including the central system 150. The party identifiers may be formatted to explicitly or implicitly identify which country or region each party identifier originates from. The fields of the party identifier include state / region of country, type of ID (e.g., bank issued ID, national ID, social media ID, etc.), and the like. D, the ID number itself, etc. Additionally, there are approximately 5200 banks or similar entities in the United States. Identifiers for banks and similar entities that handle virtual banknotes can be assigned using 16 bits. A unique party identifier can also be obtained through a bank or similar entity. For example, the first 13 bits of a party identifier can be the identifier of the bank or similar entity from which the party identifier was obtained. One advantage of implementing party identifiers in this manner is that a profile managed by a central system can limit the party information. This is because the bank or similar entity has records that identify the customer, so the bank or similar entity can hold an identifier for the end user without requiring a complete profile managed by the central system 150.The ID management system 151 stores or is configured to store identification numbers of parties, at least some of which may be generated by a third party system (e.g., for a bank) for parties who are anonymous to the central system 150. Individuals without bank accounts may obtain a unique identifier for redeeming virtual banknotes through a local branch of a country's postal service (e.g., through a digital fingerprint pad that any individual with a finger can use to uniquely identify themselves).

[0015] The ledger storage system 152 is used to keep a record of the current ownership of all virtual banknotes issued through the central system 150. The ledger storage system 152 is used to respond to ownership inquiries from the public via the SGS 156. The ledger storage system 152 is updated from the main memory system 153 as virtual banknotes are transferred via the SFIOI. The ledger storage system 152 may be effectively isolated from other elements of the central system 150. Inquiries on the SFIOI may be provided from the SGS 156 via a first dedicated communication channel (e.g., a dedicated wired connection) and updates from the main memory system 153 may be provided through a second dedicated communication channel (e.g., a dedicated wired connection). The ledger storage system 152 may be used to quickly track and verify ownership of virtual banknotes by hierarchically storing the virtual banknote records in alphabetical, numerical or alphanumeric order. In this manner, the virtual banknote records may be searched using the virtual banknote's unique identifier. Using the ledger storage system 152, the central system 150 is configured to proactively confirm ownership of instances of tracked digital assets (e.g., NDC virtual banknotes) based on inquiries in packets of SFOI, and this can be done without transferring ownership of the tracked digital assets. The ability to proactively confirm or deny ownership of instances of tracked digital assets is an advantage provided by the central system 150.

[0016] The main memory system 153 may be used to store records of most or all types of NDCs, distributed by type. In the context of any tracked digital asset, including NDC virtual banknotes, the main memory system 153 stores or is configured to store records of every instance of the tracked digital asset. The main memory system stores records of every instance of the tracked digital asset (e.g., NDC virtual banknotes) in the central system 150. The main memory system 153 receives record updates from the SGS 156 as instructions in the SFIOI packets are processed by complex software algorithms executed by the SGS 156.

[0017] The identity management system 151 may send updates to the main memory system 153 when identifiers are updated, such as when an individual changes their name, dies, discards a previous identifier and obtains a new identifier, etc. The SGS 156 may send ownership updates to the main memory system 153.

[0018] The artificial intelligence and analysis system 154 may only be provided with access to the main memory system 153 and may be completely closed off from the public.

[0019] The backup memory system 155 may also be completely isolated from the public during normal operation, but when the backup memory system 155 is on, the functions of the main recording system 153s may be switched to the backup memory system 155.

[0020] SGS 156 may include a server assigned to handle incoming communications addressed to a specified Internet Protocol (IP) address. SGS 156 functions to seal main memory system 153 and other elements of central system 150 from the public. SGS 156 is a security system that executes complex software that systematically performs comprehensive checks on SFIOIs received at central system 150. This software may include a set of sub-applications that may conform to any of the various formats established for SFIOIs used in any central system the same or similar to those described herein. Each of the software sub-applications performs a different task or tasks than the other software sub-applications. A first set of algorithms of the SGS 156 complex software may send queries outside of SGS 156 and inside central system 150, and a second set of algorithms of the SGS 156 complex software checks responses to queries sent outside of SGS 156. Sub-applications or cores of a multi-core processor do not execute or process the entire SFIOI, instead the sub-applications process different parts of each SFIOI.

[0021] Sub-applications may perform security checks such as compliance with the format required by the SFIOI. One sub-application may check one field to ensure that the source ID of the virtual banknote corresponds to a provider of the SGS 156. Other software sub-applications may specialise in coordinating checks with other elements of the central system 150, including the ledger storage system 152 (e.g. ensuring that the virtual banknote specified in the SFIOI belongs to the owner specified in the SFIOI), the ID management system 151 or another element (e.g. checking owner specific processing instructions), the main memory system 153 (e.g. checking greylists and blacklists for the owner and virtual banknote specified in the SFIOI), etc. Although avoiding hangs waiting for responses from ledger storage system 152 or similar responses to similar queries to other elements of central system 150 may be the main or one of the main reasons why all processing of SFIOIs is not implemented linearly by stand-alone cores of a multi-core processor, proving knowledge of ownership of each virtual banknote specified in each SFIOI may be an important security measure. The software sub-applications may be provided as software programs, or as dedicated multi-core processors pre-programmed to implement the software programs, or as dedicated computers (e.g. servers) with one or more such multi-core processors programmed to implement the software programs.

[0022] SGS 156 may check that NULL fields in the SFIOI are NULL, that header information such as the number of hops is exactly the same as expected (e.g., 0), etc. Sub-applications may run on SFIOIs stored in a page in a first-in-first-out (FIFO) sequence. Each sub-application performs its assigned type of safety processing in the same way for each SFIOI it is allowed to process. Different sub-applications perform different types of checks. The processing of each page is highly coordinated by staggering the sub-applications to run in a predetermined order on each memory page until all sub-applications have processed the SFIOIs on that memory page.

[0023] SGS 156 may include multiple nodes, each capable of handling tens of thousands (e.g., 40,000 or more) of legitimate SFIOIs per minute. Incoming SFIOIs may be stored in a 512-byte sequential address space (i.e., a flash memory page acting as a uniform memory unit). The last few words (e.g., 8 words) of each 64-word SFIOI may be formatted as NULL and not written to the page.

[0024] Processing in the SGS 156 can be visualized as a fourth-dimensional process. A 512-byte page is a two-dimensional memory with 64 64-bit word lines. Each sub-application moves incrementally between pages in the third dimension, processing the same byte or word in each page. The sub-applications are staggered in time as a fourth dimension to avoid collisions where they try to simultaneously read or write from the same byte or word. Additionally, sub-application ownership checks and other types of external checks necessarily involve timing offsets. This is to ensure that one set of cores sends pairs to the ledger-keeping system 152 and another set of cores processes the response from the ledger-keeping system 152, preventing the core that sent the pair from hanging up waiting for a response.

[0025] The status update system of the SGS 156 may use the same memory pages used to store the SFIOI. The status update system is used to synchronize sub-applications when processing the SFIOI. To add some clarification, any form of tracking of the NDC may require a huge number of write cycles to the memory pages used to store the SFIOI. If the same memory cells, or the same type of memory cells, are used to update the status 10-20 times during processing of each SFIOI, the number of write cycles to the status memory cells will be many times the number of write cycles to the memory cells used to store the SFIOI, and as a result, when the status memory cells wear out, the entire memory will wear out more quickly. To address this, for example, eight 64-bit (8 byte) processing words at the end of a 512-byte SFIOI may be forced to be NULL and not written to the memory page, with the corresponding memory cells being used for status updates instead of the essential data in the SFIOI. The SFIOI may be stored on a one-to-one basis in the 512-byte pages of the SGS 156, but the eight 64-bit NULL processing words at the end of the SFIOI may not be written to the page. Alternatively, memory cells at the end of a memory page may be used to track the status of the sub-applications, allowing the sub-applications to check the appropriate status word / byte before performing an operation on the SFIOI, and update a different status word / byte respectively after performing an operation. The memory cells used for status updates may be written to at substantially the same rate as the memory cells used to store the actual data of the SFIOI, thereby extending memory life by at least 1000%.

[0026] A 24-core / 48-thread (e.g., AMD) processor is an example of a type of multi-core processor suitable for the SGS 156, and therefore 8 processing words (64 bytes) provide a sufficient number of bytes to be dedicated on a one-to-one or more basis for each thread's update when the processing implemented by the thread on the SFIOI is completed. Multi-core processor and flash memory pairs may be used in rotation by group in the SGS 156. Each sub-application may check (read) one assigned status field to ensure that the sub-application is cleared to process the SFIOI before processing. Each sub-application may also update (write) at least one different status field upon completion of processing, so that the next sub-application can check the update before performing safety processing on the SFIOI. After performing a safety check, the sub-application may mark the appropriate status field per 512-byte page or sector to inform the subsequent sub-application whether it should perform the processing before proceeding. For example, if any sub-application detects an error in any SFIOI, the sub-application may update the status of all update bytes in the status field to indicate that no further processing is required for any SFIOI on the page by any sub-application. This may be done simply to indicate that all necessary processing has already been performed, such that subsequent sub-applications may skip the SFIOI in which an error was detected.

[0027] Some sub-applications generate queries to external systems (i.e., external to the SGS 156) within the central system 150, and it would be inefficient for processing resources to pause while waiting for the query to be answered. For example, since the verification of ownership may be performed by sending a query as a SFIOI to the ledger storage system 152 and receiving a confirmation or denial of ownership from the ledger storage system 152, to avoid hang-ups, the query may be sent by one set of threads and the response checked by another set of threads. This avoids a particular thread accumulating delays while waiting for a response. As an example, if each SFIOI can specify up to 9 virtual banknotes, then checking the ownership may require up to 18 threads in total.

[0028] Communications within the central system 150 may use internal addressing so that an outside party cannot determine how the SGS 156 obtains information from the ledger storage system 152 or the identity management system 151. The SGS 156 may be the only element of the central system 150 that is assigned an IP address.

[0029] In some embodiments, 48 ​​threads can be executed simultaneously by different cores of an exemplary 24-core processor to process the SFIOI. The SGS 156 can run 24 / 7 by switching in and out different pairs of multi-core processors and flash memories.

[0030] In some embodiments, different NDCs may be exchanged in a currency exchange, such as by a first central system and a second central system in communication with each other. Each central system may receive information about the virtual banknote and the purported owner, and may verify to the other central system that the virtual banknote is owned by the purported owner. Thus, a central system may accept inquiries about virtual banknotes that it does not control or track, so long as the virtual banknote is controlled or tracked by the other central system. In some similar embodiments, the central systems may directly exchange virtual banknotes, such as for purposes of settling trade flows. Additionally or alternatively, a custodial institution may provide currency exchange services for virtual banknotes to assist one or more central systems in tracking different types of virtual banknotes.

[0031] The SFIOI may also specify the amount of the virtual note to be exchanged by the sender. In the example of a currency exchange transaction, a central system that handles multiple different digital currencies may facilitate the exchange when used to exchange virtual notes of different digital currencies.

[0032] Notification may be sent to the communication address of record of the owner of record as an anti-spoofing mechanism. Users of authorized currency reader or electronic wallet programs may be required to use a multi-factor push service similar to AuthPoint. In some embodiments, a service similar to AuthPoint may be used to implement multi-factor authentication for multiple applications or programs on an electronic user device, such that push notifications from the same service may be used to confirm virtual currency transfers, transaction initiation, VPN logins, and / or other types of actions for which multi-factor authentication may be appropriate. In some embodiments, multi-factor authentication may include dynamically generating a code, such as a set of two characters, and sending the code or characters to a predefined communication address, such as a phone number, of the actual owner of the virtual currency. The actual owner may be asked to enter the two characters in response to confirm the transfer.

[0033] Instances of authorized currency reader programs and / or electronic wallet programs used in transactions involving virtual banknotes may be provided with unique identifiers that are maintained in association with the parties' unique identifiers in the central system 150 records. A currency reader program is a program configured to read and appropriately interpret the virtual banknote file. An electronic wallet program is a program that provides access to one or more accounts in which virtual banknotes are stored and traded, and may be configured to read and appropriately interpret the virtual banknote file. In some embodiments, the authorized currency reader programs and electronic wallet programs may be centrally managed. For example, the central system 150 may interface with an application server of a third-party service provider that provides the authorized currency reader programs and electronic wallet programs so that parties using virtual banknotes are automatically updated as to where to send their SFIOI. The currency reader programs and electronic wallet programs may include instructions to stop transactions and transfers at the same time each day, week, month, or year. Additionally, each of the currency reader programs and electronic wallet programs may include subprograms that are activated by a signal sent from the central system and dynamically stopped for reasons such as emergencies or emergency situations. The currency reader programs and electronic wallet programs may be suspended for a set time or until notification to resume is received from the central system 1350. Synchronization may also be provided for all currency reader programs and electronic wallet programs, a subset of the currency reader programs and electronic wallet programs, or individual currency reader programs and electronic wallet programs.

[0034] A party's verification information may include one or more forms of verification information that can uniquely identify the party, such as, for example, a unique communications address, a unique identifier for an instance of a program used by the party, a unique account number for an account assigned to the party, a unique device identifier for an electronic communications device used by the party, a unique personal identifier assigned to the party by a government, biometric information, and other forms of unique information that may be uniquely associated with the party. In some embodiments, a party may be allowed to select which form of verification information is used to verify ownership by the party, and a party may be allowed to change the form of verification information associated with ownership of a virtual note.

[0035] Movement of NDC virtual banknotes may be detected and reported in various ways. Primarily, movement of virtual banknotes is detected and reported by programs involved in transferring virtual banknotes, such as currency reader programs and electronic wallet programs. However, the virtual banknote may additionally or alternatively include executable software subroutines of instructions that are retrieved from the virtual banknote each time metadata is extracted, such as generating VN_info. The executable software subroutines may be included in specific fields of the virtual banknote, such as metadata fields or other instruction fields. The executable software subroutines may be provided in duplicate in multiple software languages ​​so that the virtual banknotes can be processed on different computers using different types of operating systems. Once the executable software subroutines are retrieved and processed, such as generating VN_info, the executable software routines may recognize that the virtual banknote is about to be or has been moved, and the executable software subroutines may initiate a message reporting the movement to the central system 150 via the electronic communications network. A message is sent to a predefined hostname or IP address reporting that virtual currency is about to be transferred from one account to another.

[0036] In the method of the central system processing batch communication of virtual banknotes and convertible party information in FIG. 1C, in S111, the central system receives a SFIOI, such as an ownership inquiry or transfer instruction. The central system 150 receives or is configured to receive updates of the virtual banknote record from the SGS 156 once the instruction from the public passes processing by one or more algorithms that perform security checks at the security gateway system. In S112, the central system reads a batch number, sender information, counterparty information, and virtual banknote information. The batch number can specify how many virtual banknote information fields are being populated in the communication. The sender information and counterparty information can be a unique identifier of a universal type used by the central system or other type of unique identifier that can be converted to a universal type used by the central system. In S113, the central system converts the sender information and / or counterparty information as necessary. In S114, the central system reads the virtual banknote information. In S115, the central system uses the ledger storage system 152 to determine whether the virtual banknote information matches the current owner indicated in the SFIOI. If the virtual banknote information matches the current owner indicated in the SFIOI (S115=Yes), the central system determines in S116 whether the virtual banknote information is for the last virtual banknote specified in the communication. If the virtual banknote is not the last virtual banknote specified in the communication (S115=No), the central system reads the next virtual banknote information in S117 and returns to S114. If the virtual banknote is not the last virtual banknote specified in the communication (S116=No), the central system deletes the communication in S118 and transmits a response to the inquirer or instructor in S119. Also, if the central system determines that the virtual banknote information does not match the current owner indicated in the communication (S115=No), it deletes the communication in S118 and transmits a response to the inquirer or instructor at any time in S119.

[0037] In some embodiments, some or all of the folder for the virtual banknotes or one or more files in the application may constitute a lightweight database. The lightweight database may be activated by a trigger event such as a transfer of the virtual banknotes or an automatic report to the central system 150, such as a check-in via the SFIOI with an update of the current location. The lightweight database may include data in JSON format in a file in the application so that the data can be read by multiple different types of devices.

[0038] If a virtual note is lost, such as if the portable memory is lost, the owner can present proof of ownership to the central system 150. The central system 150 can cancel that virtual note and all other virtual notes registered to that owner, and simply issue a new virtual note of the same denomination to the owner.

[0039] An electronic history of the virtual banknote may be maintained in the main memory system 153. The electronic history may begin with a unique identifier and creation date and time of the virtual banknote, and may be populated with dates and identifiers identifying each party that owns the virtual banknote as the virtual banknote changes hands in transactions. For example, the electronic history may include a combination of the creation date and time, the location of creation, a sequential list of each owner of the virtual banknote, the identity of each owner, and the date or time of each transaction in which the virtual banknote was transferred between owners. An electronic history may be created and updated for each virtual banknote in a set of virtual banknotes of the NDC, such as virtual banknotes of a specified denomination or greater. For example, a record of a virtual banknote in the amount of 1,000 US dollars (hereinafter, dollar means "US dollar") is updated each time the virtual banknote is traded.

[0040] In the method for validating a transfer instruction of virtual banknotes for digital currency of FIG. 1D, detailed post-processing for the transfer of virtual banknotes is shown, which may be applied to any transfer of virtual banknotes.

[0041] The process of FIG. 1D begins at S150 when the central system 150 receives the transfer instruction as a SFIOI. At S152, the recipient's party information is retrieved. At S153, the party blacklist and the party greylist are checked. Other forms of scrutiny may be imposed, such as transactions involving large volumes of virtual notes or transactions involving parties involved in many other transactions within a relatively short period of time. For example, the history of the virtual note sender and / or virtual note recipient may be flagged if they have started using virtual notes relatively recently or are using a relatively new unique identifier to identify themselves. At S154, the party information is compared to the party blacklist and the party greylist. At S155, action is taken if there is a match resulting from the comparison at S154.

[0042] In the second sub-process, in S156, virtual banknote information is searched. In S157, the virtual banknote blacklist and the virtual banknote greylist are searched. In S158, the virtual banknote information of the virtual banknote that is the subject of the transfer instruction is compared with the virtual banknote blacklist and the virtual banknote greylist. In S159, if there is a match as a result of the comparison in S159, measures are taken.

[0043] In the third sub-process, the registered owner information of the virtual banknote may be retrieved in S160. The third sub-process may be an anti-spoofing process that is selectively or always applied to the virtual banknote. In S161, a notification is generated for the registered owner's virtual banknote, such as to the registered owner's virtual banknote's communication address of record. In S162, the notification is sent. In S163, the transfer of ownership of record is approved pending positive confirmation of the registered owner. In S177, a decision is made as to whether the transfer of ownership is OK. The transfer of ownership is OK only if there is no match with the blacklist in the first and second sub-processes, if all requirements regarding the greylist are met in the first and / or second sub-processes, and / or if confirmation is received in the third sub-process. If the transfer is OK (S177=Yes), the electronic history of the virtual banknote is updated in S178. If the transfer is not OK (S177=No), the transfer is rejected in S179. The process shown in Fig. 1D can be executed whenever the ownership of the virtual banknote is transferred and is a separate process from the inquiry process. Some of the sub-processes in Fig. 1D may be omitted, replaced by other sub-processes, or supplemented.

[0044] Grey lists may be maintained for virtual banknotes for a variety of reasons, including frequency of transfers by transaction requesters, frequency of activity by transaction requesters (e.g., handling large numbers of virtual banknotes), economic and / or statistical reasons, etc. Grey lists may also be maintained for parties, such as transaction requesters, that are subject to special monitoring. Grey lists may also be maintained for parties, such as transaction requesters, that are subject to special monitoring. Actions taken based on a match to a grey list may include notifying a third party, such as a government agency, or simply adding an entry for the transfer to records maintained for the monitored recipient. Black lists may be maintained for virtual banknotes and parties, and actions taken based on the black list may include notifying the parties that the transaction is not authorized. In some embodiments, a match to a grey list may initiate an inspection requirement for the virtual banknote by ordering the virtual banknote to be provided to the central system 150 for inspection of the virtual banknote file, or by ordering the virtual banknote file to be inspected by a currency reader program or an electronic wallet program on an electronic communication device.

[0045] As an example, virtual notes transferred to any address known to belong to a foreign central bank may be registered on a virtual note greylist, and the foreign central bank address may be registered on a party greylist. Thus, transferring virtual notes from a foreign central bank account may trigger an alert based on both the virtual note greylist and the party greylist, sending a notification to the central bank's currency flow monitoring system.

[0046] In the method of FIG. 1E for a central system to process an ownership inquiry for one or more virtual banknotes, at S121, the central system 150 receives the ownership inquiry as a SFIOI. At S122, pre-processing is performed on the SFIOI, such as starting with checking the VN number. At S123, the central system retrieves party information from the ownership inquiry. Processes S123 through S129 are performed to address aliasing, if allowed. For example, a party may be assigned a universal identifier to use with the central system, but may also associate other identifiers with the universal identifier, such as a phone number, driver's license number, email address, etc. At S124, the central system identifies and validates the country and state / region identified in the party identifier. At S124, the central system identifies and validates the country and state / region identified in the party identifier field. At S125, the central system determines whether the party information is a universal party identifier type. At S125, the central system determines whether the party identifier is a universal party identifier type. If the party identifier is of the universal party identifier type (S125=Yes), the universal ID number is retrieved from the last field and verified in S129. If the party identifier type is not a universal ID (S125=No), the central system identifies the ID type in S126. If the party identifier is not of the universal party identifier type (S125=No), the ID type of the party identifier is identified from the third field in S127. In one embodiment, the ID type may be an application identifier of a currency reader program or an electronic wallet program used by a user corresponding to the party ID. The central system retrieves and validates the ID number in S127. The ID number of the ID type identified in S126 is retrieved and verified in S127. The central system converts the ID number to a universal ID number for use by the central system in S128. The conversion in S128 is not required in all embodiments and should be considered a discretionary process in the teachings herein.The conversion includes looking up the universal ID from a lookup table in a database. At S129, the central system looks up and validates the universal ID number after conversion at S128 or if the party information is of universal party identifier type (S125=Yes). At S129, the central system looks up and validates the universal ID number. The universal ID number, whether converted or not, may be used for greylist or blacklist checking. At S130, the central system compares the virtual note(s) with the electronic history of the virtual note(s) to determine whether the current owner of the virtual note is a party listed by the universal party identifier received at S121 in the ownership inquiry. The central system then responds to the requester with a simple "Yes" or "No", etc.

[0047] FIG. 1F illustrates how the central system processes a transfer instruction. At S131, the central system receives the SFIOI as the transfer instruction. At S132, the central system starts performing pre-processing of the transfer instruction for security. Most or all of the pre-processing described with respect to FIG. 1E is equally applicable to the pre-processing of FIG. 1F. At S132, the central system reads the VN number. At S132, the central system also checks the VN number against the actual size of the substantial data in the VN ID field of the SFIOI. At S133, the central system retrieves the party information from the transfer instruction. The processes from S133 to S139 are performed to address aliasing, if this is permitted. At S134, the central system identifies and validates the country and state or region specified in the party identifier. At S135, the central system determines whether the party information is a universal party identifier type. At S136, if the party identifier type is not a universal ID (S135=No), the central system identifies the ID type. At S137, the central system retrieves and verifies the ID number. At S138, the central system converts the ID number to a universal ID number for use by the central system. At S139, the central system retrieves and verifies the universal ID number after conversion at S138 or if the party information is of universal party identifier type (S135=Yes). At S140, the central system compares the virtual note(s) to the electronic history of the virtual note(s) to determine whether the current owner of the virtual note is a party listed by the universal party identifier received at S131 in the transfer instruction.

[0048] In Figures 1E and 1F, when the SFIOI is received at the central system, the party identifiers are processed. The central system may be configured to accept only a universal ID as a party ID, or may be configured to accept and process multiple types of party IDs. Furthermore, if the central system receives multiple types of party IDs, the central system may convert the multiple types to a universal ID type for consistent processing, or it may process each of the different types of party IDs as they are accepted.

[0049] In some embodiments, the central system 150 may store different alternate IDs in different databases such that each different set of alternate IDs is separate from all other sets of alternate IDs. For example, the central system 150 may store a first database of conversion tables for converting all telephone numbers in the United States to corresponding universal IDs used by the central system, and another database of conversion tables for converting identifiers of all currency reader programs to corresponding universal IDs. Of course, more than two independent database configurations may be used for conversion to universal IDs. Separating the memory configurations of the different memories used for conversion of different types of IDs may ensure the fastest possible lookups of universal IDs whenever an alternate ID is received as part of an incoming inquiry or instruction. As an alternative to a lookup table storing alternates for universal IDs, the universal ID numbering system may be designed such that alternate IDs are accepted from approved sources such as major social network providers and communication service providers. For example, if a 10-digit universal ID were used for a population of up to 9.999 billion people, the 11th and 12th digits could be used to specify up to 99 different accounts or other characteristics for queries or instructions sent to a central tracking system.

[0050] In some embodiments, the exchange of virtual notes may be handled by a central system. For example, the central system may interpret the "change amount, if due field" of the SFIOI. The "change amount, if due field" may specify the exchange amount that the sender of the virtual note(s) should receive from the recipient of the virtual note(s). The central system 150 may store the universal electronic wallet program information of the parties using the virtual note and credit and / or debit the universal electronic wallet program for the exchange amount agreed upon in the notification from the sender and recipient. Additionally or alternatively, the central system 150 may store the third party (e.g., bank) account information of the sender and recipient of the virtual note and credit and / or debit the third party account for the exchange amount agreed upon in the notification from the sender and recipient. In some embodiments, the central system 150 may use a universal electronic wallet program as the default for crediting and debiting senders and recipients, although the senders and recipients may update the central system 150 to specify a third-party account to use instead of the universal electronic wallet program.

[0051] In the digital currency monitoring, inspection, and exchange method of FIG. 1G, the central system coordinates the inspection of the virtual banknote by the recipient of the virtual banknote. The process of FIG. 1G begins at S180 by receiving a greylist detection notification generated by the central system 150 when a notification of a movement of a greylisted virtual banknote or a movement between greylisted parties is detected. The central system 150 may have an automated process configured to initiate the process of FIG. 1G. At S185, the new owner of the virtual banknote is provided with the expected virtual banknote characteristics and instructed to compare the expected virtual banknote characteristics with the virtual banknote and report the results. At S190, a determination is made as to whether there is a match. The determination at S190 may be received as a notification result from the new owner of the virtual banknote after the currency reader program or electronic wallet program analyzes the virtual banknote. If there is a match, the process of FIG. 1G ends at S191. If there is no match, the central system 150 may exchange the virtual banknote for a replacement virtual banknote of the same denomination. For example, the central system 150 may instruct the electronic communication device to transfer a virtual note that does not match the characteristics of the expected virtual note, and then provide the electronic communication device with a new virtual note as a replacement. In the process of FIG. 1G, replacements may occur for a variety of reasons, including attempted tampering, successful tampering, wear-and-tear, aging, counterfeiting, passage through an owner or geographic region or country monitored by a grey list, or other explanation for why the virtual note does not contain the expected characteristics. However, because tampering, spoofing, counterfeiting, and other forms of fraudulent use can be successfully countered using the teachings herein, replacements such as S195 are typically contemplated for wear, such as data loss due to packet drops during communication over an electronic communication network.

[0052] In some embodiments, a persistent electronic wallet program may be provided for the life of an end user and managed in whole or in part by a central system. A persistent electronic wallet program may be assigned to a party after birth and the party may be assigned a unique identifier. A persistent electronic wallet program may then be created to receive and store financial instruments, such as digital currency, on behalf of the party. At any time during the person's life, an entity that owes a payment to the party for any reason may transfer the payment to the persistent electronic wallet program, such as if the entity cannot find the party to arrange for payment. A government wishing to distribute stimulus funds to adult citizens, etc. may transfer the stimulus funds for the party to a persistent electronic wallet program. A country may allow non-citizen residents, etc. to obtain unique identifiers and persistent electronic wallet programs. Additionally, a fingerprint, retinal scan, DNA, or other form of electronically recordable biometric identifier may be obtained and associated with the persistent electronic wallet program, allowing the party to identify itself to authorities authorized to provide access to the persistent electronic wallet program. The central system may allow the party to specify access control to the persistent electronic wallet program. For example, a party may require that subsequent withdrawals from a persistent electronic wallet program require the party's fingerprint, the party's retina scan, or one or more other forms of party-based input that can be used for access control.

[0053] In some embodiments, the central system may include a data center that handles large amounts of data managed by the central system, such as for the main memory system 153 and for multiple elements of the central system 150. The data center may be configured to process instructions derived from the SFIOI by referencing or updating data in the data center. Data stored in the data center and retrievable for use by the data center includes electronic history of virtual banknotes, group information of virtual banknotes (e.g., characteristics such as background image of a group of virtual banknotes), party information (e.g., unique electronic communication address and program / application identifier, nationality, place of residence, currently owned virtual banknotes and previously owned virtual banknotes, and transfer dates), grey list of virtual banknotes, black list of virtual banknotes, grey list of owners, black list of owners, etc. The data center may include multiple data centers and use scalable memory. Structured Query Language (SQL) may be used if the database configuration of the data center requires compatibility with legacy databases that already use SQL. SQL may be useful in handling structured data in relational databases. Alternatively, if the database configuration does not require a relational database, a non-SQL (NoSQL) may be used, which may be useful for real-time queries such as verifying ownership of virtual notes through the ledger storage system 152. One example of a NoSQL configuration that may be used is a MongoDB configuration. The MongoDB configuration provides a file system that may be used to store virtual notes according to unique identifiers, and is considered a document-oriented database that may be used to store user profile documents that include ownership history of various virtual notes. The data center may be implemented in a private cloud configuration that separates facilities and operations for the digital currency from facilities and operations for other parties and uses. For example, the data center may use solid state drive (SSD) arrays to store data. SSDs may be preferred over hard disk drives (HDDs) because they are faster, consume less power, etc. The database may be implemented on a paired basis, with each memory configuration paired with a dedicated server with a different memory configuration, or on a dynamically reconfigurable basis to run less used servers to relieve overloaded servers.

[0054] In some embodiments, the virtual banknote may be provided as a folder containing multiple files. For example, the virtual banknote may contain a relatively small amount of data, such as image data and variable data. A portion of the usage data stored as metadata for the virtual banknote may be provided as a separate encrypted file containing JSON or BSON data and may be sent to the central system via an application programming interface (API). The usage data may be captured and stored in a data field within the JSON / BSON file. The central system may send a signal via the API to the device on which the virtual banknote is stored, the signal indicating that the data in the JSON / BSON file has been stored in the central system and may be deleted from the device on which the virtual banknote is stored. This may reduce the amount of data sent with the virtual banknote when the virtual banknote is transferred. The virtual banknote and / or the API may also be configured to communicate and notify updates via specific ports of a server or database in a data center, thereby reducing the workload of the central system. One or more of the types of SFIOI described herein may include JSON / BSON updates, and these communications may be processed by updating the central system's records with details of the JSON / BSON updates once the SFIOI is cleared via SGS 156. In some embodiments, the virtual banknote may include a private address in a metadata field that is not publicly available but is interpretable by the central system or another control system, and may include a private server or database address, or a specific port address of a private server or database address. The central system may unpackage the update to identify which of the private server or database addresses stores the record for the virtual banknote, which may be a complement or alternative to addressing based on the virtual banknote's unique identifier.Thus, even if a central or control system uses the virtual banknote's unique identifier, even in part, to identify a subgroup of servers or databases used to store the virtual banknote records, the private addresses transmitted by the virtual banknote can be used to designate another internal communication address within the subgroup corresponding to a server, database, server port, database port, or component that cannot be reached via a public address.

[0055] The digital currency monitoring center of FIG. 2A can monitor the movement of virtual banknotes for use such as analysis by central bank economists. The monitoring center 245A receives digital currency data from the central system 250. The monitoring center 245A includes a first display 2451, a second display 2452, and a third display 2453. The monitoring center 245A can be used by government treasury department and / or central bank officials to monitor information such as the flow of virtual banknotes across borders, between different types of accounts, the flow of virtual banknotes at specific times of the day, days of the week, etc. The monitoring center 245A can also monitor information such as the flow of other currencies across borders, between different types of accounts, the flow of other currencies at specific times of the day, days of the week, etc. In this manner, authorities can compile and track data indicative of trends and patterns in the use of virtual banknotes. The monitoring center 245A can be integrated with the artificial intelligence and analysis system 154 of FIG. 1B or provided independently. The monitoring center 245A may be equipped with a computer that staff can use to generate and render images and videos on a first display 2451, a second display 2452, and a third display 2453 based on information obtained from the central system 250 or provided in other manners.

[0056] In FIG. 2B, separate addressing for different types of communication to the central system is shown. For example, the central system may include multiple subsystems that receive and process incoming SFIOI. Different types of SFIOI may present different levels of risk for hacking, spoofing, denial of service (DOS) attacks, and other types of malicious activity. Thus, if the authorities behind the central system have done due diligence before building the central system, the central system and any type of end user software and intermediate party software may be designed to accommodate multiple different electronic communication addresses corresponding to different types of SFIOI. In FIG. 2B, the multiple subsystems include a first central subsystem 251A, a second central subsystem 251B, a third central subsystem 251C, a fourth central subsystem 251D, a fifth central subsystem 251E, a sixth central subsystem 251F, and a seventh central subsystem 251G. As an example, the first central subsystem 251A may receive and process ownership inquiries for virtual banknotes and interact with a ledger subsystem that stores a limited subset of records such as the current ownership for each virtual banknote. As an example, the second central subsystem 251B may receive and process transfer instructions from trusted parties such as banks or large corporations. If a trusted party is the source of the transfer instruction, the trusted party may not undergo a high level of verification before the transfer of the virtual banknote is processed. As an example, the third central subsystem 251C may receive and process transfer instructions from end users that have a relationship with the trusted parties, such as end users that send transfer instructions using an application provided by a bank. The fourth central subsystem 251D may receive and process transfer instructions from purported recipients of the virtual banknotes. As an example, the fourth central subsystem 251D may be configured to verify the transfer instruction by contacting the current owner of the address of record as a form of additional authentication to combat spoofing attempts and to combat fraudulent transfer instructions from purported recipients of the virtual banknotes.The fifth central subsystem 251E can receive and process transfer instructions from overseas sources. For example, the fifth central subsystem 251E may be configured to validate transfer instructions in the manner of the fourth central subsystem 251D and to create and update records used to show cross-border currency flows. The sixth central subsystem 251F can receive and process transfer inquiries, such as complaints, notices of suspicious or fraudulent activity, and other forms of special matters that require special handling. Even complaints and notices received by the sixth central subsystem 251F may require specific processing and formatting in the manner described herein to combat hacking. The seventh central subsystem 251G can be used to exchange virtual banknotes with other central systems. In this way, the central bank can use dedicated resources to transfer virtual banknotes to and from other central banks. This is also to separate such cases from other types of inquiries and instructions that may be subject to a greater risk of fraud.

[0057] As another example, a separate central subsystem (not shown) may be used to process virtual banknotes stored on legacy-type user devices that do not have a browser. For example, the separate central subsystem may receive formatted messages from such user devices as text messages without a browser, and the separate central subsystem may have its own security protocols, such as by validating the user device with a wireless communication carrier and / or by sending an anti-spoofing message to the phone number of the user device requesting confirmation of an instruction to transfer one or more virtual banknotes.

[0058] In the memory configuration of the memory system of FIG. 3A, the communication system divides the memory system based on, for example, the unique identifier of the virtual banknote. The main memory system 351 is divided into ten independent sections. Each of the ten independent sections of the main memory system 351 may be independently addressable by an independent communication address recognizable by the switch 353. The switch 353 is representative of a switching system and may include a number of switches, each of which receives instructions such as updating a record of the virtual banknote. Each section of the main memory system 351 may be physically separated from the others, such as different rooms, different buildings, different zip codes, different counties, different states, or different countries. The logical arrangement of the ten independent sections of the main memory system 351 may correspond to the first character of the unique identifier of the virtual banknote. For example, each unique identifier of the virtual banknote may start with a number from 0 to 9. A virtual banknote with a unique identifier starting with 1 may be assigned to section 351-1, a virtual banknote with a unique identifier starting with 2 may be assigned to section 351-2, and so on. The division of the main memory system 351 is not required, but if implemented in this manner, the division is not limited to three sections. For example, the addressable memory system may be logically divided into up to 26 sections corresponding to the letters A through Z. The addressable memory system may also be logically divided into up to 30 sections corresponding to the two-digit numbers 0 through 99. Thus, addressing based on the unique identifier of the virtual banknote may be used to distribute the workload so that read and write operations of the main memory system 351 are performed more quickly and efficiently.

[0059] In the memory configuration of the memory system of FIG. 3B, the communication system divides the workload of the servers based on a load balancer that measures the workload of the equipment used to process the virtual banknotes, for example. In FIG. 3B, a server system 350 is used to communicate with a separate section of the main memory system 351. A load balancer 354 monitors the workload of the servers in the server system 350 and can reduce or increase the amount of work assigned to the servers in the server system 350. Each server in the server system 350 may be configured to receive updates for any of the separate sections of the main memory system 351 and may be used to program updates and read or write data to any of the separate sections of the main memory system 351. Thus, internal addressing in the central system may be based on a common address of the server system 350 or on individual addresses of the individual sections for the main memory system 351. For example, where communications are generally addressed to server system 350, each server in server system 350 may be configured to identify a unique identifier that uniquely identifies each virtual banknote that is the subject of a query or update assigned to that server, and each server in server system 350 may then be configured to implement the query or update against an appropriate section of main memory system 351. Alternatively, where addressing is based in part on the virtual banknote's unique identifier, each server in server system 350 may be configured to identify the appropriate section of main memory system 351 based on the addressing.

[0060] In the memory configuration of the memory system of FIG. 3C, the communication system divides the server and memory workload based on, for example, the unique identifier of the virtual banknote. In FIG. 3C, the server system includes servers, each of which is assigned one-to-one to a corresponding section of the main memory system 351. The switch 353 can assign queries or updates to a corresponding server based on the unique addressing of the corresponding server, such as where the addressing of the incoming communication is based in part on the unique identifier of the virtual banknote. The server system of FIG. 3C is divided into three independent sections. Each of the three separate sections of the server system may be independently addressable by an independent communication address recognizable by the switch 353. The switch 353 is again representative of a switching system and may include multiple switches, each of which receives requests, such as a request to validate or update a record of a virtual banknote. The servers of the server system of FIG. 3C may be physically separated from each other, such as in different rooms, different buildings, different zip codes, different counties, different states, or different countries.

[0061] Additionally, the central system may require that communications conform to a specific format limited to the few types of communications it is approved to handle. Internal servers and databases may be assigned private local addresses that are meaningful only to the central system or another type of control system. Internal servers may be numbered from 1 to 1000 and internal databases may be numbered from 1 to 1000. The central system then keeps track of records for updates and retrievals by private local addresses rather than public addresses.

[0062] In some embodiments, embodiments herein may use artificial intelligence to optimize the operation of the central system 150. For example, problematic data sets that may be applied to train the artificial intelligence to detect features and patterns include: data corresponding to detected attempts to counterfeit virtual banknotes, data corresponding to detected attempts to impersonate parties or user devices, data corresponding to detected attempts to impersonate authentication software programs, data corresponding to reported lost virtual banknotes, data corresponding to reported stolen virtual banknotes, and data corresponding to detected fraudulent attempts to verify ownership of virtual banknotes. Using artificial intelligence, some of the incoming communications, such as transfer instructions, may be automatically subjected to multi-party authentication, owner impersonation checks using the virtual banknote owner's address of record, and other forms of additional processing. The artificial intelligence may be trained using transaction data, virtual banknote data, account data, party data, and / or other data sets in the server system 350 as training data. For example, the artificial intelligence may be used to detect suspicious or illegitimate transactions, transactions likely to be erroneous, transactions likely to be fraudulent, or other problematic behavior detectable based on patterns identified from the artificial intelligence. Multiple different instances of the artificial intelligence program can be applied to new data and information stored in the server system 350 for a variety of reasons, such as to detect fraud or counterfeiting attempts based on the account, the type of transaction, the location where the transaction is made, and the type of virtual note involved.

[0063] In the method of redeeming a digital currency virtual note of FIG. 4, a request for verification of the virtual note is received, such as by a verification system, from a first party electronic communication device 101, a second party electronic communication device 102, or a third party electronic communication device 103, at S410. The verification system, such as the central system 150, looks up the electronic history of the virtual note, at S420. The verification system may retrieve the complete electronic history from the main memory system 153, at S420. At S430, the verification system determines whether the verification request contains fraud, such as if the virtual note does not belong to the purported owner. If the verification request contains fraud (S430=Yes), the virtual note is redeemed, at S435. The virtual note may be redeemed by contacting the last owner of record of the virtual note and instructing the last owner of record to transfer the virtual note to the central system 150 in exchange for another virtual note of the same denomination. The virtual banknote may then be retained in storage, such as the main memory system 153. If the verification request does not include fraud (S430=No), then the transaction count of the virtual banknote is incremented at S440. At S450, the verification system determines whether the transaction count of the virtual banknote exceeds a threshold. For example, the threshold amount of virtual banknote usage before the virtual banknote is withdrawn may be 100 transactions, 1,000 transactions, 5,000 transactions, or other value. If the transaction count of the virtual banknote exceeds the threshold (S450=Yes), then the virtual banknote is withdrawn at S435. If the transaction count of the virtual banknote does not exceed the threshold (S450=No), then the verification system determines whether the circulation period of the virtual banknote exceeds a threshold at S460. For example, the threshold circulation period of the virtual banknote may be one year, three years, five years, or other period. If the virtual banknote's time in circulation exceeds the threshold (S460=Yes), the virtual banknote is withdrawn at S435. If the virtual banknote's threshold time does not exceed the threshold (S460=No), the virtual banknote is not withdrawn and is verified at S470. A virtual banknote may be withdrawn from the service if an unfair attempt to trade the virtual banknote is detected, if the virtual banknote has been involved in more than a predefined threshold number of transactions, or if the virtual banknote has been in circulation for more than a predefined threshold amount.The reasons and grounds for redeeming virtual banknotes are not limited to those described herein.

[0064] In some embodiments, the central system may be synchronized with electronic communication devices. The synchronization may include a predefined arrangement to prevent transactions of transfers involving virtual banknotes managed by the central system for a certain period of time. The period of no transactions or transfers may be a period during which the central system replaces equipment, updates backup memory such as electronic records, user profiles, account profiles, etc., performs software updates, or is otherwise inaccessible. The period may be a predefined period of time, such as daily, weekly, monthly, or yearly, during which minimal activity is expected to be affected. In some embodiments, the period may be dynamically set for reasons such as emergencies or emergency situations. In some embodiments, synchronization may be used to stop transactions or transfers at different times, such as different time zones. For example, the stop may be set for 5 minutes at 3:30 a.m. every Monday, and may be gradually stopped in each time zone as each time zone reaches 3:30 a.m. every Monday. Alternatively, electronic communication devices may be grouped based on other criteria, such as manufacturer, wireless communication service provider, year of manufacture, service provider of currency reader program or electronic wallet program, or other logical basis, such that different groups may be suspended at different times for set periods or until notification is received from the central system. In some embodiments, synchronization may be used to suspend transactions or transfers in different locations. For example, suspension may be set to 3:30 AM every Monday in North America, 3:30 AM every Tuesday in Europe, 3:30 AM Saturday in the Middle East, etc. Synchronization may also be performed for reasons other than suspension, such as updating communication addresses in the central system.

[0065] 5A , electronic communications network 530 includes routers including at least a first router 531, a second router 532, a third router 533, a fourth router 534, and a fifth router 535. SGS 556 includes servers including at least a first server 5561, a second server 5562, a third server 5563, a fourth server 5564, and a fifth server 5565. Because addressing to central system 550 through electronic communications network 530 may be simplified by limiting communications to one or a few specific Internet Protocol (IP) addresses, the routers in electronic communications network 530 may be configured to ensure that a particular server of SGS 556 is not overloaded. For example, a router in the electronic communications network 530 may logically vary communications addressed to a particular Internet Protocol (IP) address, sequentially sending a first incoming packet or set of packets to a first server in the SGS 556, then a second incoming packet or set of packets to a second server in the SGS 556, then a third incoming packet or set of packets to a third server in the SGS 556, and so on. The router may also use a clock to determine the recipient router in the SGS 556, such that an incoming packet or set of packets received on a second ending with a "1" is sent to the first server, and an incoming packet or set of packets received on a second ending with a "2" is sent to the second server. Any known mechanism for varying addressing and routing to avoid recipient congestion and overload may be used in the electronic communications network 530, so long as the load on the servers in the SGS 556 is balanced in the manner intended by the designers of the central system 550. In some embodiments, the central system 550 may include a last-mile router.In this way, the router may be dedicated to the internet protocol (IP) addresses of the central system 550, and the router may route only or primarily, but not exclusively, to or from these internet protocol (IP) addresses. In this way, the logical variation of packet routing to the servers of the SGS 556 may be specifically controlled by the engineer designing and / or implementing the SGS 556. In some embodiments, the network router implemented as the intake of the electronic communication network 530 or the central system 550 may disable the reception of incoming transmission control protocol (TCP) and only allow the reception of user datagram protocol (UDP) to prevent any external entity from establishing a connection through TCP. Alternatively, sequence throttling may be implemented by such a router to remove packet sequences higher than 1, 2, 3 or other predefined thresholds. This may ensure that the SFIOI described herein is consistently sent via standalone IP packets even when transmitted via TCP.

[0066] The working memory configuration of the servers in the security gateway system (SGS) of FIG. 5B includes a first server 5561 illustrated with nine groups of address spaces (AS) in memory, each having eight independent address spaces. The individual address spaces may be physically independent memory addresses of a memory such as an SSD memory, or may be specialized for the function of the individual address space. Alternatively, the individual address spaces may be logically separated and re-assignable memory addresses of a memory such as an SSD memory. The first server 5561 is representative of the servers in the SGS 556. Each address space can temporarily store one SFIOI received from the public when it is processed in the central system 550. The first server 5561 can perform a predetermined security process on one SFIOI.

[0067] In some embodiments, the SFIOI may be sent as individual packets over UDP without a handshake, and the response may be sent after a handshake over TCP. In this way, the central system can receive standalone SFIOIs over UDP or over TCP with sequence slots as individual packets and conduct sessions only with familiar communication addresses of record.

[0068] In some embodiments, the entire SFIOI is stored in a separate address space, and bytes of the SFIOI in the separate address space are processed in a particular order for a particular purpose. For example, if a predefined format of the SFIOI sets a size requirement for a packet of the SFIOI, the first process may check the size of the SFIOI. The predefined format may also set one or more format requirements for the party identifier included in the packet and the unique identifier of the instance of the tracked digital asset (e.g., NDC virtual banknote) included in the packet. If the SFIOI is too large or too small, it may be removed. The second process may check the type of the SFIOI, such as by interpreting certain bytes required by the format to describe the type of SFIOI. The type may be limited to ownership queries, transfer instructions, special processing instructions (e.g., please take the virtual banknote offline, require multi-factor authentication before allowing the transfer of the virtual banknote, etc.). Other processes are described elsewhere herein. The processes may be staggered sequentially on each packet, or different processes may operate in parallel on different packets. Additionally, processes that involve checks with external resources (e.g., ownership checks, special processing instructions for the owner, multi-factor authentication checks) may be initiated by one set of processes that do not wait for a response. Instead, another set of processes may process the response from the external resource.

[0069] The different bytes and bits of the SFIOI that are to be processed separately may be separated using masks, for example by effectively using a bit or byte mask to uniformly set data that is not to be processed (i.e., data that is to be ignored) to zero. The data of the read word line to be processed may then be processed separately. Different masks may be used for different processors, cores, and threads. A thread may apply the same mask thousands of times per minute at work, as it performs the same processing over and over on different packets, and the processing itself may involve fewer steps and operations compared to other processing applied by the SGS556. The format of the SFIOI may specify that each of multiple or all of the different entity elements (fields) of the SFIOI should start every 64 bits or end every 64 bits, and that all other bits should be set to zero or one. Thus, the first virtual note may start at byte #33, the second virtual note (if any) at byte #41, the third virtual note (if any) at byte #49, etc. Since each thread processes different bytes according to the format of the SFIOI, a thread can isolate and iterate over the value assigned to it, effectively ignoring other data.

[0070] In the method of processing a received SFIOI by the security gateway system of FIG. 5C, an overview of an efficient security check performed by the security gateway system begins with storing the packet payload in an address space at S502A. The packets may be stored individually in pages of flash memory for processing by the security gateway system. Because packets can be sent asynchronously from anywhere in the world without initiating a connection, the sender can expect a rapid response if the packet is processed and meets the security gateway system's expectations. Of course, the teachings herein are not limited to 512 byte packets or packets that are all of a uniform size.

[0071] At S504A, the size of the packet payload is checked in bytes. The total length of meaningful data of the packet payload may be specified in the packet's header, and this header information may be compared with the actual length of meaningful data stored in the address space. At S508A, the number of virtual notes (VN number) purportedly identified in the SFIOI is determined. The number of VNs purportedly identified in the SFIOI may be specified in specific bytes according to a format set in the SFIOI. At S510A, from the VN number determined at S508A, the expected size of meaningful data in the packet is determined, and the expected size determined at S510A is compared with the actual size determined at S504A. At S512A, the identifier of the purported owner of the virtual note specified in the SFIOI is determined. At S514A, the identifier of the purported owner is sent together with each individual virtual note identifier for an owner check. The identifier of the purported owner may be sent together with each individual virtual note identifier to the ledger storage system 152 in a single communication or as a batch of separate communications. If stored instructions from the real owner of the virtual banknote are present, then in S516A the instructions are checked. The check in S516A may be made against the main memory system 153 if processing instructions from the owner of the virtual banknote are stored in the main memory system 153, against the ledger storage system 152 if processing instructions from the owner of the virtual banknote are stored in the ledger storage system 152, or against another memory system storing processing instructions if different from the ledger storage system 152 or the main memory system 153. In S518A, anti-spoofing measures are initiated if the stored instructions checked in S516A indicate anti-spoofing measures. In S520A, the type of the SFIOI is checked. The type may include an inquiry, a transfer instruction to another party, a transfer instruction to another account or device of the same owner, special processing instructions, etc. In S522A, the SFIOI is processed depending on the type checked. If the instruction is to transfer ownership of the virtual note, then an instruction may be sent to main memory system 153 to update the record of ownership of the virtual note.Processing may include decoding the virtual banknote's unique identifier if the SFIOI is an ownership inquiry, which may only be decodable by the central system 150, and in particular the SGS 156. Other processing may include notifying other central systems that track other digital currencies, and other instructions and confirmations processed by the SGS 156.

[0072] In FIG. 5D, a memory configuration of a security gateway system (SGS) for processing received SFIOIs shows nine independent bays for the first server 1561. Each bay includes an address space listed from address space #1 (i.e. AS1) to address space #50,000 (i.e. AS50K). Packets received by the server may be stored consecutively in bay 1 until, for example, the 40,000 address space is filled with 40,000 packets. The processing resources of the first server 1561 may start processing packets as soon as they are first added to the bay. If 40,000 packets are received per minute at the SGS 156, the packets may be stored in one bay of one server until the 40,000th packet is received, after which newly received packets may be assigned to another bay of the same or different server. As another example, packets may be distributed among different packets on a random or logical basis, such as when one group of one or more servers is tasked with processing instructions and queries for a period of time before being replaced by another group of one or more servers.

[0073] In the processing configuration of a security gateway system (SGS) for processing received SFIOIs of Figure 5E, a first server 1561 includes eight cores, each with a dedicated pointer queue. The cores may be some or all of the cores of a multi-core processor, or may be distributed across multiple multi-core and / or single-core processors. The cores perform operations on the address spaces of bay X in the order in which the address spaces are assigned to their dedicated pointer queues.

[0074] In the processing configuration of the security gateway system (SGS) for processing received SFIOIs in FIG. 5F, the first server 1561 includes eight threads, each with a dedicated pointer queue. The threads operate on the address spaces of bay X in the order in which the address spaces are assigned to their dedicated pointer queues. In effect, each thread repeatedly performs one or a very small number of tasks on a number of address spaces that store newly received packets, and the threads should be able to easily process 40,000 packets per minute. The first server 1561 may be specially configured to have an amount of threads that can process all the tasks described herein, and possibly even more tasks than those described herein.

[0075] In the processing configuration of the security gateway system (SGS) for processing the received SFIOI of FIG. 5G, the set of cores of the first server 1561 refer to a status space that stores the status of each address space on a one-to-one basis. In this regard, the address space may fit 512 bytes or other relatively large amount of fully formatted SFIOI, while the status space may be on the order of 4 bytes. The address space may be a non-volatile flash memory, and the status space may be, for example, a volatile DRAM memory. Within the 4 bytes, or perhaps 5 bytes, the status space may specify which address space corresponds to, along with the actual status of the address space. The status may specify the core that will process the address space next, and / or the core that last processed the address space. In this manner, the set of cores may sequentially refer to the status space and process the packet payload of the corresponding address space, if the status indicates that the core will process the packet payload in the corresponding address space. The first core (Core #1) starts processing any address space starting with the first address space (AS1), updates the corresponding status space (SS1), then starts processing the second address space (AS2), and updates the corresponding status space (SS2). The remaining cores start processing from the first address space when the first status space (SS1) indicates processing, and update the first status space (SS1) before checking the next status space. Of course, if any processing indicates that the packet payload in the corresponding address space should be deleted or should be left alone, the status of the status space may be updated to reflect a status indicating deletion, such as "99" indicating the next processing is deletion. Once processing for any address space is completed, the status of the corresponding address space may also be updated to reflect that the next processing is deletion.In this way, when all packet payloads in bay X are periodically processed and ready to be deleted, the latest status of the corresponding status space may uniformly reflect a status indicating deletion. Once bay X has been completely deleted, bay X may be returned to circulation for another batch of incoming packets. A bay may be followed by a quiet period, such as 30 or 60 minutes, to allow the circuitry to cool, etc.

[0076] In the processing configuration of the security gateway system (SGS) for processing received instructions or queries of FIG. 5H, individual threads refer to the status space instead of individual cores.

[0077] In the processing order of packets received and stored in a security gateway system (SGS) processing received instructions and queries of Figure 5I, a thread may be assigned to process a first packet (i.e., packet #1) and then assigned to process a second packet (i.e., packet #2). Most or all packets in a bay may be processed in the same order by the same thread, core, or processor, although some packets may be processed in a different order than other packets if the processing includes branching that allows processing by one or more threads, cores, or processors to be skipped.

[0078] In the use of dedicated queues by processing resources in a security gateway system (SGS) to process received instructions and queries in Figure 5J, a first-in, first-out pointer queue is shown, where address space is read from the top of an existing entry in the queue and address space is written to the first open space for an entry in the queue. Threads may reference the address space pointed to by the pointer queue to retrieve and process bytes processed by the thread. Each thread may process a subset of bytes from packets in the address space in the manner described herein.

[0079] In the method of processing a received SFIOI by a security gateway system (SGS) of Figure 6A, resources individually and independently process packet payloads within the address space of the SGS 156. Before the method of Figure 6A begins, a packet is received. After all packets in a bay are processed, all address space in the bay may be cleared by deleting the data therein.

[0080] At S602B, the packet payload is stored in the address space. The header of the packet added to the packet payload may also be stored in the address space, and data may be retrieved from both the packet payload and the header and processed by the resource. In FIG. 6A, the resource iteratively performs the respective process for each address space in the bay of address spaces. The resource may be a thread, a processor, a core of a multi-core processor, etc. At S604B, the size of the packet payload in bytes is checked by the first resource (i.e., resource #1). The size of the packet payload may be checked by inspecting the presence of meaningful data in the address space, for example, by searching for an end pattern used to specify the end of the packet payload and / or by reading a packet size field in the header. In some embodiments, the packet size data from the header may be compared to the result of searching for the presence of meaningful data in the address space. The packet size data and the actual size of the meaningful data in the address space may be compared to one or more predefined threshold(s), such as the maximum size allowed by the format. At S606A, it is determined whether the checked size is OK or not. If the checked size is not OK, the packet is removed from the address space in S606C. If the checked size is OK, the first resource is incremented in S606B and the address space for which the packet payload size was checked is added to the address queue of the next resource (i.e., resource #2), which then processes the address space. In S608B, the number of virtual banknotes that are supposed to be identified in the SFIOI is determined by the second resource (resource #2). This VN number may be specified in a field required by the format of the SFIOI, e.g., one byte, or less than 8 bits. In S608C, the second resource is incremented and the address space processed by resource #2 is added to the address queue for the next resource (resource #3) that processes the address space.In S610B, the expected size of the packet payload is determined from the number of VNs determined in S608B. Since the identifiers of the virtual banknotes should be of uniform size, the expected size of the packet payload may be predetermined based on the number of VNs. Furthermore, the number of VNs that can be specified in a packet can be kept below a maximum value, so the potential size of the packet payload may also be minimized. In S610B, the expected size is compared with the size checked in S604B. In S610C, it is determined whether the comparison in S610B is a match (OK) or a mismatch (not OK). If the expected size and the checked size match (S610C=Yes), the third resource is incremented and the address space compared in S610B is added to the address queue of the next resource (resource #4). If the expected size and the checked size do not match (S610C=No), the packet is deleted in S610E. At S612B, the party identifier of the alleged owner of the virtual banknote and the party identifier of the alleged counterparty (if any) are determined by the fourth resource and sent for aggregate checks by the fourth resource. The fourth resource is incremented and the address space for which the determination was made at S612B is added to the queue of the next seven resources (resources 5-11). The aggregate check of the owner and counterparty identifiers is performed by sending an internal query to another part of the central system 150, such as the ID management system 151. The aggregate check may include checking whether the party identifier of the alleged owner of the virtual banknote and the party identifier of the alleged counterparty (if any) are blacklisted or greylisted. The aggregate check may be performed in parallel with the remainder of the method of FIG. 6A such that a result that prevents execution of the response to the SFIOI at S622B is received before S622B is executed at a later time. Further, the address space is added to the queue(s) for the next seven resources in the example where the maximum number of virtual notes allowed in the format for indications and queries is seven, although a resource may process more than one virtual note identifier and the maximum number is less than seven or greater than seven.At S614B, the alleged owner identifier and each virtual note identifier are sent separately for an ownership check by the next seven resources (resources 5-11). The ownership check may be performed by sending an internal query to the ledger storage system 152 and may include a simple comparison of whether the alleged virtual note owner matches the listed virtual note owners. The address space of the SFIOI is added to the queue of the next seven resources (resources 12-18). Using a separate set of resources for the response maximizes the efficiency of the resources used for processing at the SGS 156. At S614C, the response to the ownership check at S614B is received by each of the next seven resources (resources 12-18) and may identify, for example, whether the current owner matches or does not match. Even a single bit may be used to indicate a match or no match in the ownership check. The response in S614C may simply specify the address space of the packet payload to be checked and either the virtual note in the packet payload to be checked or the resource that made the request in S614B. In S614D, it is checked whether the results of the ownership queries in S614B all match. If the ownership queries in S614B all match (S614D=Yes) according to the results received in S614C, then increment resources 12 through 18 in S614E and add the address space to the queue for the next resource (i.e., resource #19). If the ownership queries in S614B do not match (S614D=No), then the packet is removed from the address space in S614F. In S616B, a check is made by resource 19 for stored instructions (if any) from the real owner. This check may be performed by sending a query to the main memory system 153 for any virtual notes to find out the real owner and see if processing instructions have been specified. For example, an owner may specify that virtual notes should not be transferred from their possession without the use of multi-factor authentication, confirmation of the transfer via phone, email or another mechanism, or another type of special processing.After sending the query, resource 19 may increment its address space and add it to the queue for the next resource (resource #20). In some embodiments, the owner's instructions for the virtual note may be stored in the ledger storage system 152 or in another system (not shown) provided in parallel with the ledger storage system 152 that stores cursory information regarding special instructions for processing the virtual note owned by the owner. At S618B, the twentieth resource initiates anti-spoofing measures if instructed by the response to the query by the nineteenth resource from S616B. The anti-spoofing measures may be performed by initiating a multi-factor authentication check and then having another resource (not shown in FIG. 6A) wait for authentication. After the anti-spoofing check, the resource(s) that performed the anti-spoofing check increment their address space and add it to the queue(s) for the next resource. At S620B, the next resource (i.e., resource 21) checks the type of the SFIOF. The type may be specified in a field required in the format of the SFIOI, e.g., a full byte, or two or three bits. Because the tracking described herein may be extended to many other uses, the "type" field may include a full byte so that ultimately up to 256 different types can be specified using the same format, even though relatively few types are used for tracking digital currency as described herein. At S620C, resource 21 is incremented and the address space of the packet is added to the queue of the next resource that will actually process the SFIOI. The number of resources that process the SFIOI may vary based on how many different actions can be performed based on the SFIOI. At S622B, the SFIOI is processed by one or more next resources (resource 22+). This processing may include sending instructions to update the ownership and owner records in main memory system 153 and confirming a transfer instruction to the sender, or simply confirming an ownership inquiry to the sender.The ownership inquiry confirmation may occur by default without further inquiry, since the ownership inquiry was performed in S614B and the SFIOI has already responded or the SFIOI has been deleted if one or more of the ownership inquiries were negative. Other types of processing may include updating processing instructions or transferring ownership records to reflect that an owner has moved a particular virtual note between custodial accounts or devices.

[0081] In the method of aggregate security checks in the memory system of the central system of FIG. 6B, the method may be performed in or by the main memory system 153, in or by the AI ​​and analysis system 154, or in another element of the central system 150. The method may be performed to check the patterns of the initiating party and / or the counterparty in every transfer, for example to see if suspicious funds are being drained or replenished from an account. Since suspiciousness may be relative to person, place, and time, different thresholds and analyses may be applied to look for different patterns. At S630, updates to the records of the transferred virtual banknotes are received. The updates to the records may be stored in both the virtual banknote history and the initiating party and counterparty history. Different algorithms may be applied to the virtual banknote history and the initiating party history to check for different pattern features. At S631, aggregate amounts of transferee and transferor amounts for a recent period are determined. The total amount may be the total amount of transfers between the transfer destination and the transfer source in the last 60 seconds, 5 minutes, 30 minutes, 1 hour, 24 hours, and / or other time periods. At S632, the total amount is compared to a threshold to see if the total amount is higher than the threshold. If one or more total amounts are higher than the corresponding threshold (S632=Yes), then at S633 the corresponding party may be added to a blacklist or greylist. If there are no total amounts higher than the corresponding threshold (S632=No), then additional checks may be performed. At S634, another check may be related to a timing or location trigger. For example, a transfer from a party to an Internet Protocol address in a risky area may trigger a blacklist or greylist addition. As another example, a transfer from a party at 2 a.m. local time may trigger a blacklist or greylist addition. At S3635, if the timing or location causes a trigger (S634=Yes), then the party is added to the blacklist or greylist, otherwise the process of FIG. 6B ends.

[0082] In the method of processing received instructions or queries by the security gateway system (SGS) of FIG. 6C, the method of FIG. 6A is divided into four sections as an example of how different graphics cards or processor groups in one or more graphics cards can be assigned to different tasks in the security gateway system. The graphics card may include many processors that operate in a nearly parallel manner. The tasks performed in the security gateway system are essentially parallel for different received packets. As long as the processing that the graphics card provides can be properly applied to the SFIOI, the graphics card can be used. In FIG. 6C, the processors are divided into four groups. One of the simplest ways to ensure efficient processing, if not the simplest, is to not have all processors specifically wait for an answer to a query they sent and not route the answer back to the particular processor that sent the query, so that the processing of each group may end when the query is sent to another internal system. The use of status spaces can ensure that each address space is efficiently processed. As an example, the 3200 processors in the graphics card may be divided into four groups of 800 processors. These processors may process address space 800 at a time. The parallel aspect of processing that leverages the graphics card comes from applying groups to different groups of address spaces simultaneously, so that a first group can handle address space 2401-3200, a second group can handle address space 1601-2400, a third group can handle address space 801-1600, and a fourth group can handle address space 001-800. The processors in each group can increment the address space 800 at a time as they complete their current processing. Of course, it is not necessary for the processor groups to all have the same number of processors, for example if a task performed by one group can be executed faster than a task performed by another group.Rather, to increase the relative continuity of processing, one or more first task sets that require more processing time than one or more second task sets can be assigned to a first processor group that includes more processors than a second processor group executing the one or more second task sets.

[0083] In the memory configuration of the security gateway system (SGS) for processing received instructions or inquiries of FIG. 6D, the security gateway system includes various electronic components including a SFIOI memory 6561 and a status memory 6562 physically separate from the SFIOI memory 6561. The SFIOI memory is intended to store SFIOIs on a one-to-one basis, one SFIOI per 512-byte page or one SFIOI per multiples or fractions of a 512-byte page. The status memory 6562 is intended to store status updates as a processor, core, or thread processes an SFIOI in the SFIOI memory. One aspect of the technical problem addressed in this disclosure is the program / erase cycles of the SGS 156. The status updates may require writing more than one status update to the status memory 6562 for each SFIOI written to the SFIOI memory 6561. However, since writing to the status memory 6562 may be limited to one byte or word at each instance, each potential status update may be written to a different byte or word of the status memory 6562. In this way, a thread may determine whether prerequisite processing has been performed by first reading the status memory 6562 and referencing the status of the byte or word that has already been updated. As a simple example, thread #7 may check the status of byte #6 updated by thread #6, and if that status indicates that thread #6 has processed the SFIOI, thread #7 may read the portion of the SFIOI that is being processed by thread #7. Once thread #7 has finished processing the SFIOI, thread #7 may update byte #7 of the status memory to indicate that thread #7 has finished processing the SFIOI.The SFIOI memory 6561 may include a plurality of memories, such as a first SFIOI memory 6561-1, a second SFIOI memory 6561-2, ..., a forty thousandth SFIOI memory 6561-3. The status memory 6562 may include a plurality of memories, such as a first status memory 6562-1, a second status memory 6562-2, ..., a forty thousandth status memory 6562-3. Each processor, core or thread first checks the corresponding status in the status memory 6562, and then performs a specific process on the SFIOI in the SFIOI memory 6561 before updating the corresponding status in the status memory 6562. The SFIOI memory 6561 may be the first bay of the SGS 156, and may be assigned SFIOIs arriving in one minute, as an example. A second bay of SGS 156 may be substantially identical to the first bay and may be assigned SFIOIs arriving during the next minute in this exemplary timing. The bays may be cycled periodically, such as every 5, 10, 15, 30, 60 minutes, etc. Additionally, bays may be assigned SFIOS for processing in fixed time frames, although this is likely not a particularly best practice. Rather, load balancing or other types of implementations may be implemented dynamically, such that SFIOI memory and status memory are augmented with additional physical resources as needed. In FIG. 6D, status memory 6562 is physically separate from SFIOI memory 6561, such that a processor, core, or thread may switch back and forth between the two during processing. However, each individual processor, core, or thread processes only a specific portion of the SFIOI, rather than the entire SFIOI in SFIOI memory 6561, and operates by checking and writing only individual bytes or words in status memory 6562.

[0084] In the memory configuration for a security gateway system (SGS) processing a received SFIOI of FIG. 6E, memory management includes using a unified SFIOI and status memory 6563 for memory space for the SFIOI and memory space for status in the SGS 156. In other words, the unified SFIOI and status memory 6563 includes a first area for storing the SFIOI and a second area used to track the processing status of the SFIOI. For example, even if the SFIOI format requires that the notification to the central system be exactly 256 bytes and each virtual banknote is specified in a separate 64-bit word, the number of VNs specified in the SFIOI may be limited to 7 or 13, or any other number that can be individually specified in the 256 bytes of the SFIOI. Another 256 bytes of the page may be reserved for specific use in processing by a processor, core, or thread of the SGS 156. For example, if a 512-byte page can store up to 64 64-bit words, with 32 of the 64-bit words reserved for the SFIOI, then the memory starting at the 33rd word line of the unified SFIOI and status memory 6563 may be used for status. The status may be updated by writing at the byte or word level. For example, since the default status of the status space may be set to 0 (zero) and may be updated to one (1) in a status update, a byte or word of the status space in the unified SFIOI and status memory 6563 may be written to 1 in one or more bit positions upon completion of the corresponding processing. Thus, during processing of the SFIOI, a processor, core, or thread may process a particular portion of the SFIOI and then read the status from the 33rd word line onwards of the unified SFIOI and status memory 6563 before updating another portion of the status space. The processors, cores, or threads may be organized to efficiently use the memory pages of the SGS 156 such that the individual physical memory pages are logically partitioned.Of course, the division need not be exactly one-half of the total area of ​​a memory page or other predefined addressable memory unit. For example, for a 512-byte memory page, the SFIOI format may require 384 bytes, with 128 bytes used for status updates during processing. Clearly, the most efficient way to perform processing of SFIOIs may be to use predefined memory units that are the same size or larger than each SFIOI and that provide the memory space required for status updates for each SFIOI. In this way, SFIOIs are stored on a one-to-one basis in the predefined addressable memory space.

[0085] In some embodiments, the format of the SFIOI may be set to the size of the addressable memory space, such as a 512-byte page of flash memory, and a few words at the end of the format may be set to NULL values ​​and not written to the addressable memory space. Instead, the addressable memory space corresponding to the last words of the format is not written to by the SFIOI, but is used for tracking and updating status as described herein.

[0086] In the example format of the SFIOI in FIG. 6F, 64 64-bit words are shown, with each row in FIG. 6F including 64 bytes, for example, in a 512-byte format. The first 24 bytes are used for the header, and additional fields are used for the VN number, VN origin ID, first party ID, second party ID, 16 VN ID fields, and SFIOI type field. The first party ID may correspond to the person who is supposed to be the owner in each instance of the SFIOI, etc., or may correspond to the transaction requester or transaction requester ID (requester_ID) in the transaction. The first party ID may be the only ID specified when the SFIOI updates the owner's processing instructions in the central system 150. The second party ID is for the counterparty or counterparty ID (counterparty_ID) in the transaction, and may not be entered if the SFIOI is not for a transaction, etc. The VN ID may include a first byte for a country / region code, a second byte for the denomination if the denomination is less than or equal to 256, and six more bytes for the actual unique identifier of the denomination issued in that country / region. Because the processing of an SFIOI involves various security checks, each SFIOI may be subject to the same processing, regardless of the type of SFIOI. Security checks may be performed before performing the type of processing requested / instructed by the SFIOI. Although not shown, the notifier type field may indicate whether the notification is performed by the transaction requester or the counterparty, if either party may perform the notification. The notifier type may also indicate whether the notifier is a system trusted by the central system 150 to perform notifications as a transaction requester and counterparty, such as if the notifier is a private bank supervised and regulated by the central bank that provides the central system 150. An exemplary format size for the SFIOI is 512 bytes.The SFIOI format allows a new field to start every 64 bits so that it can be uniformly read as a 64-bit word line by a 64-bit processor, so that each field can contain 64 bits as long as the data therein can be specified as meaningful data in 64 bits or less. The remaining bits of a 64-bit / 8-byte field can be uniformly set to 0 or 1.

[0087] In some embodiments, the VN ID may be provided as part of the VN_info sent to the central system 150. The VN_info may include the unique identifier and the denomination and may be provided as more than the 8 bytes shown in FIG. 6D. The VN_info may also include the creation date and / or location. The VN_info may be or include an encrypted version of the unique identifier extracted from a metadata field of the virtual banknote or provided with but independent of the virtual banknote from when the central system 150 first issued the virtual banknote. The central system 150 can decrypt the encrypted unique identifier.

[0088] Although the header shown in Figure 6F contains 24 bytes (e.g., the last 4 bytes are empty), in larger IP addressing schemes, IPv6 packet headers are typically allocated 40 bytes. The format of the SFIOI should be large enough to contain the header information and the amount of payload information anticipated by the provider of the central system described herein.

[0089] The last field of the SFIOI is empty and reserved for status updates at the SGS 156. Two words totaling 16 bytes may be sufficient to track the status of 16 security checks, and three words totaling 24 bytes may be sufficient to track the status of 24 security checks. Even a 256-byte format for the SFIOI may be adequate to handle processing at the SGS 156, so long as the number of VNs allowed in a packet remains below a maximum limit. However, this disclosure primarily uses the example of a 512-byte format. Of course, other sizes for the format of the SFIOI may be logically appropriate, such as when other types of predefined memory sizes or arrangements are used at the SGS 156. For example, the SFIOI may be allowed to have different sizes and may be tracked sequentially as it is received at the SGS 156. However, an ad-hoc size of the SFIOI is not optimal, and the best form for implementing such a SFIOI is to specify a format that takes advantage of the packetization of the network, standard pre-defined memory sizes of ubiquitous memory types such as flash memory, standard instruction sizes of modern processors, such as by using 64-bit words, etc.

[0090] In some embodiments, another field of the SFIOI may specify the total amount involved in the transaction, the amount of change involved in the transaction (i.e., amounts less than one dollar), or another amount. For example, if small denomination notes have not been issued for virtual bills or if small denomination notes are not tracked in the central system, the SFIOI may specify the amount of change to be credited and / or debited from the account corresponding to the party, depending on whether the SFIOI specifies a transfer in the transaction. In this way, the format of the SFIOI may accommodate transfers including denominations not issued as virtual bills or not tracked in the central system. As an example, if a party in a transaction pays $50 for an item and expects 65 cents in change, the change may be automatically credited to the party's associated account and debited from the seller's associated account. The associated accounts are managed outside of the central system, such that the associated accounts are managed by a financial institution that provides the accounts as a service. The central system may simply notify the identity management system 151 or another node that manages the party's identity records to initiate a debit or credit with the financial institution. In some embodiments, parties registered with the central system may be required to have an associated account, but governments and / or central banks may encourage segments of the population that do not have such accounts to open accounts (e.g., by providing incentives to financial institutions). For example, governments and / or central banks may make payments to financial institutions to remove minimum balance or spending requirements, or may provide a form of insurance against losses that financial institutions would incur in the event of fraud or other such events. Alternatively, the central system 150 may store information about third-party (e.g., bank) accounts of senders and recipients of virtual notes, and credit and / or debit third-party accounts for exchange amounts agreed upon in notifications from the sender and recipient. In some embodiments, the central system 150 may use a universal electronic wallet program as a default for crediting and debiting senders and recipients.However, senders and recipients may be able to update the central system 150 to designate third-party accounts to be used instead of the universal electronic wallet program.

[0091] One advantage of allowing sufficient room for modification in the requirements for the formatted SFIOI is that the techniques described herein can be used for many other purposes. For example, if a central system reserves 32 or 64 "types" for the SFIOI type field, private systems can use the same type format to track other types of transactions, such as mortgages and other types of loans, real estate transfers, automobiles, etc.

[0092] The format of the SFIOI may differ from that taught herein while still being consistent with the intent and teachings of this specification, for example, the order of the fields may differ, more or fewer fields may be specified in the format than shown, blank fields or blank spaces may differ, etc., so long as the format is clear from the outset, so that parties around the world may appropriately program end user devices, intermediate user devices, and central system devices to accommodate whatever the format of the SFIOI may be.

[0093] Furthermore, the format of the SFIOI shown in Figure 6F is independent of the format of the virtual banknote: as long as the virtual banknote is provided with a unique identifier, the SFIOI format, such as that of Figure 6F, can be used to track the virtual banknote.

[0094] Financial institutions and other types of organizations may be provided with the ability to issue party IDs as described herein. For example, financial institutions may be provided with a four or five digit unique identifier, such that the unique identifier is described as two or three bytes. The financial institution may use the unique identifier as the first two or three bytes of the entire identifier assigned to it as the party ID. The party ID may be three bytes, four bytes, or five bytes for the party, two bytes, or three bytes for the financial institution, etc. In this way, the central system does not need to store the identity of the parties, but instead can rely on the financial institution to know who the party ID corresponds to. At least in the United States, the financial institution may store the party ID, and if a government agency wants to know who the party ID corresponds to, it need only request a warrant. Other types of organizations that may be permitted to issue unique identifiers to customers may include entities such as Coinbase, Facebook®, or other entities with large customer bases, so long as those customer bases include customers who actually trust such entities to protect their privacy as much as possible or reasonably possible. As an example, the central system may provide the unique ID of the parties to the bank without transmitting the identifier of the account, and the bank may determine which relevant account to credit with the virtual banknotes based on the unique ID of the parties.

[0095] In some embodiments, the central system 150 can accept several different types of SFIOI. For example, the format type may be listed at the beginning of the incoming communication. The central system 150 can read the format type at the beginning (rather than at the end of processing) so that it can begin processing using an algorithm appropriate for the format type. Different algorithms may be applied to different types of SFIOI, just as different processing is performed for different types of SFIOI when the type of SFIOI is processed after security checks. However, the central system 150 may accept fewer or more than six format types without departing from the scope of this disclosure. Various types may include ownership inquiries, transfer instructions, etc.

[0096] In some embodiments, a party trusted by the central system 150 may correspond to a specific party ID, which can be used to bypass some forms of security processing. In other embodiments, a trusted party may have a dedicated communications link to the central system 150. In some embodiments, large entities that provide their own secure environments to customers (e.g., Apple, Google, JP Morgan) may be permitted to collocate one or more servers in the data center used by the central system 150. This allows customers to submit the SFIOI in the entity's secure environment and enter the unpackaged SFIOI directly into the SGS 156.

[0097] In the description herein, the blockchain is not necessarily used to implement a digital currency. However, the use of the blockchain is not specifically prohibited and may be useful in some circumstances. For example, recording transactions involving a large amount of virtual banknotes on a blockchain with separate ledgers of a distributed ledger at each of a group of cooperating central banks may be useful to resolve disagreements between the central banks regarding details of previous transactions. A group of users of a particular digital currency may agree to record transactions involving virtual banknotes on a blockchain. Thus, the use of the blockchain is not specifically prohibited or incompatible with the central system herein, even if it is not part of a blockchain that specifically implements a digital currency.

[0098] Additionally, the use of encryption has been described for certain embodiments and purposes herein. However, the use of encryption mechanisms such as SSL may be envisaged for most, or perhaps all, communications involving the transmission of virtual banknotes. To the extent that alternative mechanisms for encryption may be used in the processing of virtual banknotes, the teachings herein should not be considered to be specifically inconsistent with the use of particular encryption in appropriate circumstances.

[0099] Although centralized tracking of digital currency has been described with respect to virtual paper money, the teachings herein are not limited in application to virtual paper money or any particular digital currency authorized by a government or issued by or on behalf of a central bank. Rather, various aspects of the teachings herein may be implemented with respect to other forms of digital currency, including stable coins and other forms of cryptocurrencies, as well as other forms of digital tokens used as a medium of value, including digital currencies that do not share one or more characteristics of virtual paper money as described herein.

[0100] Although centralized tracking of digital currency has been described with reference to several exemplary embodiments, it is understood that the words used are terms of description and illustration, rather than terms of limitation. Changes may be made within the scope of the appended claims, as currently described and as amended, without departing from the scope and spirit of centralized tracking of digital currency. Although centralized tracking of digital currency has been described with reference to specific means, materials, and embodiments, it is not intended that centralized tracking of digital currency be limited to the particulars disclosed. Rather, centralized tracking of digital currency extends to all functionally equivalent structures, methods, and uses, as fall within the scope of the appended claims.

[0101] Although components and functionality that may be implemented in particular embodiments are described herein with reference to particular standards and protocols, the present disclosure is not limited to such standards and protocols. For example, because the legal framework for introducing digital currencies has not yet been established in the United States or Europe, standards that comply with such legal standards may be developed in the future and are expected to implement one or more of the mechanisms described herein.

[0102] In the foregoing detailed description, various features may be described together or in a single embodiment for the purpose of streamlining the disclosure. This disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter may be directed to less than all of the features of any of the disclosed embodiments. Thus, the following claims are hereby incorporated into the detailed description, with each claim standing on its own as defining separately claimed subject matter.

[0103] The foregoing description of the disclosed embodiments is provided to enable any person skilled in the art to practice the concepts described in this disclosure. As such, the above disclosed subject matter is considered to be illustrative and not limiting, and the appended claims are intended to cover all such modifications, enhancements, and other embodiments that are within the true spirit and scope of the present disclosure. Accordingly, the scope of the present disclosure shall be determined by the broadest permissible interpretation of the following claims and their equivalents to the maximum extent permitted by law, and shall not be limited or restricted by the foregoing detailed description.

Claims

1. A security gateway system for interfacing with the public via the Internet, comprising: a memory for storing packets received via the Internet; and a processor for executing at least one algorithm for processing packets stored in said memory, said packets being required to conform to a predefined format specifying requirements for a field at a predefined relative position in the payload of an acceptable packet, each algorithm processing packets stored in said memory by checking whether data in said field at said predefined relative position in the payload of said packet conforms to said format; a main memory system remote from said security gateway system, said main memory system storing a record of all instances of tracked digital assets for a centralized tracking system, said main memory system receiving updates to said record as acceptable packets stored in said memory pass processing by at least one algorithm; Equipped with the centralized tracking system is configured to check data from a designated field in a predetermined relative position of the payload of the acceptable packet after the at least one algorithm processes the acceptable packet for compliance with the format, and if the data from the designated field in the predetermined relative position of the payload of the acceptable packet indicates updating a record of the instance of the tracked digital asset listed in the acceptable packet, update the record of the instance of the tracked digital asset listed in the acceptable packet to transfer ownership of the instance of the tracked digital asset listed in the acceptable packet; the centralized tracking system is configured to check data from a designated field in a predetermined relative position of the payload of the acceptable packet after the at least one algorithm processes the acceptable packet for compliance with the format, and if the data from the designated field in the predetermined relative position of the payload of the acceptable packet indicates to pre-confirm ownership of the instance of the tracked digital asset listed in the acceptable packet without transferring ownership of the tracked digital asset listed in the acceptable packet, Centralized tracking system.

2. 2. The centralized tracking system of claim 1, further comprising a ledger-keeping system, sealed off from direct access by the security gateway system to the public, that stores a record of current ownership of instances of the tracked digital assets and that verifies whether the ownership listed in the packets that have passed processing by the at least one algorithm is correct for the tracked digital assets listed in the packets.

3. 3. The centralized tracking system of claim 2, wherein the ledger-keeping system is configured to proactively verify ownership of each tracked digital asset contained in the packets that have passed through processing by the at least one algorithm.

4. 10. The centralized tracking system of claim 1, further comprising an identifier management system that stores identification numbers of parties, at least a portion of which are generated by a third party system for parties that are anonymous to the centralized tracking system.

5. The centralized tracking system of claim 1, wherein the at least one algorithm includes a plurality of algorithms that send queries external to the security gateway system and internal to the centralized tracking system.

6. The packets received at the security gateway system are filtered to ensure that they conform to the format; The format sets size requirements for the packets, sets format requirements for party identifiers included in the packets, and sets format requirements for unique identifiers for instances of the tracked digital assets included in the packets. The centralized tracking system of claim 1 .

7. The at least one algorithm comprises a plurality of algorithms, 2. The centralized tracking system of claim 1, wherein the packets are stored in uniformly sized memory units within the memory at the security gateway system.

8. interfacing a security gateway system of a centralized tracking system with the public via the Internet, the security gateway system comprising: a memory for storing packets received via the Internet; and a processor for executing at least one algorithm for processing the packets stored in the memory, the packets being required to conform to a predefined format specifying requirements for a field at a predefined relative position in the payload of an acceptable packet, each algorithm processing a packet by checking whether data in the field at the predefined relative position in the payload of the packet conforms to the format; isolating said main memory system from said public by said security gateway system by locating said main memory system remotely from said security gateway system; storing in the main memory system a record of all instances of digital assets being tracked for the centralized tracking system; receiving updates to said record in said main memory system as acceptable packets stored in said memory pass processing by said at least one algorithm; checking data from a designated field in a predetermined relative location of the payload of the acceptable packet after the at least one algorithm processes the acceptable packet for compliance with the format, and if the data from the designated field in the predetermined relative location of the payload of the acceptable packet indicates updating a record of the instance of the tracked digital asset listed in the acceptable packet, updating the record of the instance of the tracked digital asset listed in the acceptable packet to transfer ownership of the instance of the tracked digital asset listed in the acceptable packet; checking data from a designated field in a predetermined relative position of the payload of the acceptable packet after the at least one algorithm processes the acceptable packet for compliance with the format, and if the data from the designated field in the predetermined relative position of the payload of the acceptable packet indicates to pre-confirm ownership of the instance of the tracked digital asset listed in the acceptable packet without transferring ownership of the tracked digital asset listed in the acceptable packet; A centralized tracking method including:

9. blocking said ledger storage system from direct access by said security gateway system from said public; storing, in the ledger storage system, a record of current ownership of instances of the tracked digital assets; verifying whether the ownership listed in the packet that has passed the at least one algorithmic process is correct for each of the tracked digital assets listed in the packet; The centralized tracking method of claim 8 , further comprising:

10. 10. The centralized tracking method of claim 9, further comprising: pre-verifying, by the ledger-keeping system, the ownership of each of the tracked digital assets contained in the packets that have passed through processing by the at least one algorithm.

11. 10. The centralized tracking method of claim 8, further comprising storing by an identifier management system an identification number of a party, at least a portion of which is generated by a third party system for the party that is anonymous to the centralized tracking system.

12. The at least one algorithm comprises a plurality of algorithms, 10. The centralized tracking method of claim 8, further comprising: sending a query by the plurality of algorithms in the security gateway system, external to the security gateway system and internal to the centralized tracking system.

13. 10. The centralized tracking method of claim 8, further comprising filtering the packets received at the security gateway system to ensure that they comply with the format, the format setting a size requirement for the packet, setting a format requirement for a party identifier included in the packet, and setting a format requirement for a unique identifier for an instance of the tracked digital asset included in the packet.

14. The at least one algorithm comprises a plurality of algorithms, 9. The centralized tracing method of claim 8, wherein the packets are stored in uniformly sized memory units within the memory at the security gateway system.

15. The centralized tracking system of claim 1 , wherein the packets received from the public are limited to individual, out-of-sequence packets.

Images