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 based on U.S. Provisional Patent Application No. 63 / 148,335 filed on February 11, 2021, U.S. Provisional Patent Application No. 63 / 173,631 filed on April 12, 2021, U.S. Provisional Patent Application No. 63 / 209,989 filed on June 12, 2021, U.S. Provisional Patent Application No. 63 / 240,964 filed on September 5, 2021, U.S. Provisional Patent Application No. 63 / 294,732 filed on December 29, 2021, and U.S. Provisional Patent Application No. 63 / 304,684 filed on January 30, 2022, and incorporates their entire contents herein by reference.

Background Art

[0002] National digital currencies (hereinafter referred to as "NDCs") may be useful as a complement or alternative to a country's physical currency. Distributed ledger technology (DLT) has been studied in this context. Distributed ledger technology provides a consensus network in which copies of the ledger are maintained and updated at each of its independent nodes. When doubts arise regarding a transaction, the consensus among the nodes determines the answer to the doubt. For various reasons such as efficiency, distributed ledger technology is not particularly suitable for the implementation of NDCs. Therefore, the inventors of the subject matter described in this application and related applications investigated a method for realistically and efficiently implementing NDCs using centralized tracking.

[0003] Exemplary embodiments are best understood from the following detailed description when read in conjunction with the accompanying drawings.

Brief Description of the Drawings

[0004] [Figure 1A]This diagram shows the tracking of NDC virtual notes (sometimes abbreviated as "VN"). [Figure 1B] This diagram shows the functional network layout of the central system (hereinafter sometimes abbreviated as "CS"). [Figure 1C] This diagram shows how a central system processes batches of virtual currency and communication of convertible party information. [Figure 1D] This diagram shows how to verify instructions for transferring virtual banknotes for digital currency. [Figure 1E] This diagram shows how a central system processes ownership inquiries for one or more virtual banknotes. [Figure 1F] This diagram shows how a central system processes transfer instructions for one or more virtual banknotes. [Figure 1G] This diagram shows methods for monitoring, inspecting, and exchanging digital currencies. [Figure 2A] This diagram shows a monitoring center for digital currencies. [Figure 2B] This diagram shows separate addressing for different types of communications to the central system. [Figure 3A] Figure 10A shows the memory configuration of the memory system. [Figure 3B] This diagram shows another memory configuration for the memory system. [Figure 3C] This diagram shows another memory configuration for the memory system. [Figure 4] This diagram shows how to redeem virtual banknotes of digital currency. [Figure 5A] This diagram shows the electronic communication network integrated with the central system's security gateway system (hereinafter sometimes abbreviated as "SGS"). [Figure 5B] Figure 5A shows the working memory configuration of the server in the security gateway of the central system. [Figure 5C]This diagram shows how SGS processes received instructions or inquiries. [Figure 5D] This diagram shows the memory configuration of the SGS that processes received instructions or inquiries. [Figure 5E] This diagram shows the processing configuration of SGS for processing received instructions or inquiries. [Figure 5F] This figure shows another processing configuration for SGS that processes received instructions or inquiries. [Figure 5G] This figure shows another processing configuration for SGS that processes received instructions or inquiries. [Figure 5H] This figure shows another processing configuration for SGS that processes received instructions or inquiries. [Figure 5I] This diagram shows the processing order of packets received and stored by the SGS, which processes received instructions and inquiries. [Figure 5J] This diagram shows the use of dedicated queues by SGS processing resources to handle received instructions and inquiries. [Figure 6A] This diagram shows how SGS processes received instructions or inquiries. [Figure 6B] This diagram shows how to perform centralized security checks using the memory system of the central system. [Figure 6C] This diagram shows how SGS processes received instructions or inquiries. [Figure 6D] This diagram shows the memory configuration of the SGS that processes received instructions or inquiries. [Figure 6E] This figure shows another memory configuration for the SGS that processes received instructions or queries. [Figure 6F] This figure shows an example of the SFIOI format. [Modes for carrying out the invention]

[0005] The following detailed descriptions are for illustrative purposes only, and not limiting, but representative embodiments disclosing specific details are included to provide a complete understanding of the representative embodiments described herein. However, other embodiments that are not inconsistent with this disclosure may deviate from the specific details disclosed herein. To avoid obscuring the description of representative embodiments, descriptions of known systems, apparatus, methods of operation and methods of manufacture may be omitted. In such cases, systems, apparatus and methods that are within the ordinary scope of the art in one or more of the numerous technologies relating to this teaching are within the scope of this teaching and can be used in accordance with the representative embodiments. It should be understood that the terms used herein are for illustrative purposes only, and not intended to limit, specific embodiments. Defined terms are in addition to the technical and scientific meanings of defined terms that are generally understood and accepted in the art of this teaching.

[0006] When centralized tracking is used for the implementation of NDC, many aspects regarding efficiency must be addressed. The central system that tracks NDC must serve as an interface with the public and, from the perspective of efficiency, should only accept incoming communications in one or very few predefined formats. Since the public may include any individual around the world connected to the Internet, the central system must be accessible with minimal complexity while maintaining security. Queries and instructions to the central system may be provided as short, formatted inquiries or instructions (hereinafter referred to as "SFIOI"), and SFIOI requires a minimum amount of information that includes at least the unique identification (ID) of each virtual note (VN) specified by the SFIOI and the unique identifier of each party related to the content transmitted by the SFIOI. Centralized tracking of NDC can potentially bring advantages such as being able to proactively and authoritatively confirm the ownership of virtual notes even when there are no transactions or transfers, and being able to cooperate with courts, law enforcement agencies, and security authorities, for example, freezing the transfer of virtual notes based on a court order.

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

[0008] In tracking virtual currency (VN) in NDC as shown in Figure 1A, the transaction requester and / or trading partner send an SFIOI to the Internet Protocol (IP) address of the central system 150 to inquire about ownership of the virtual currency or to give instructions to transfer ownership of the virtual currency. In some embodiments, a first electronic communication device (ECD) used by one party may initiate a transaction with a second electronic communication device used by the other party and send virtual currency information (VN_info) to the second electronic communication device. The second electronic communication device may initiate a query to the central system 150 and send VN_info to the central system 150. In some embodiments, for example, if the transaction requester provides the trading partner with verification information that uniquely identifies the transaction requester, the trading partner can have the central system 150 pre-verify that the transaction requester is the owner of the virtual currency without the central system confirming with the transaction requester that the virtual currency is being transferred. Because the risk to a trading partner that any particular party is the recorded owner of any particular virtual currency is extremely low, the central system 150 can consider that the transaction requester has agreed to the transfer of the virtual currency when the trading partner provides verification information to the central system 150.

[0009] In some embodiments, the transaction requester may provide the counterparty with an encrypted unique identifier so that the counterparty can query the central system 150. Once the transaction requester confirms the transaction, the counterparty obtains an unencrypted unique identifier that uniquely identifies the virtual currency. The transaction requester may also provide verification information that uniquely identifies the transaction requester. The counterparty may present the verification information to the central system 150 so that the central system 150 can consider that the transaction requester has agreed to transfer the virtual currency. In these embodiments, the counterparty pre-verifies the validity of the virtual currency and the transaction requester's ownership of the virtual currency by directly transmitting the transaction requester's verification information and virtual currency information (VN_info) to the central system 150.

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

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

[0012] A unique identifier for a party can be specified with just 5 bytes. The identifier of the country that issues the unique identifier can be incorporated into the unique identifier, so that the unique identifier can be used for different central systems. The unique identifier for the virtual currency can be specified with 4 or 5 bytes. Using 5 bytes, up to approximately 1.1 trillion unique identifiers can be specified for the virtual currency, and 4 bits (e.g., the first 4 bits) of the total 5 bytes can be used to specify any one of up to 16 denominations for the virtual currency, and the remaining 36 bits can be used to specify approximately 69 billion different unique identifiers for any particular denomination of virtual currency.

[0013] An SFIOI may be strictly formatted for any particular central system, but may differ for other central systems. Since a typical packet size in certain communications is 512 bytes, and the minimum page size of flash memory is also 512 bytes, the logical format of an SFIOI for central system 150 may require exactly 512 bytes. Fractions (e.g., 256 bytes) and multiples (e.g., 1024 bytes) of 512 bytes can also be logical choices for the format size from the standpoint of processing and storage efficiency. The unique identifiers of the parties and the unique identifiers of the virtual currency specified in the SFIOI can be assigned 64-bit full words (or more). The number of virtual currency units (VNs) that can be specified in any SFIOI can be limited to, for example, 7 or 9. An SFIOI can also specify the actual number of virtual currency units specified in the SFIOI, the type of SFIOI, etc. Since most, and perhaps all, of the data provided in the various fields of the SFIOI format can be specified with less than 64 bits, the SFIOI format can specify that the data either starts with the first bit of the field or ends with the last bit of the field. For this reason, either the last or first bit of the field is set to zero (0). Fields in the SFIOI may be provided to uniquely identify currency reader programs (CRPs) and electronic wallet programs (EWPs) that handle virtual currency. Authenticated currency reader programs and electronic wallet programs can operate according to the expected format of the SFIOI and will not send an SFIOI that does not conform to the expected format. An example of the SFIOI format is illustrated in Figure 6F and will be explained in relation to Figure 6F.

[0014] In the functional network layout of the central system in Figure 1B, the security gateway system (SGS) 156 serves as the interface with the public. SGS 156 is used as the interface of the central system 150 with the public. The central system 150 includes SGS 156, ID management system 151 (identifier management system), ledger storage system (hereinafter sometimes abbreviated as "LSS") 152, (main memory system The system includes a system (hereinafter sometimes abbreviated as "MMS") 153, an artificial intelligence and analysis system 154, and a backup memory system 155. The arrows in Figure 1B indicate that, depending on the circumstances, communication between elements of the central system 150 may be limited to mostly or entirely one-way communication. An ID management system 151 may be used to store and update records of parties authorized to use NDCs tracked by the central system 150. Identifiers (IDs) may be globally standardized across multiple central systems, including the central system 150. Party identifiers may be formatted to explicitly or implicitly identify which country or region originates each party identifier. Fields of the party identifier include the state / region of the country, the type of ID (e.g., bank-issued ID, national ID, social media ID) D may be provided to identify the ID number itself, etc. Furthermore, there are approximately 5200 banks or similar entities in the United States. Identifiers for banks and similar entities that handle virtual currency can be assigned using 16 bits. Unique party identifiers can also be obtained through banks or similar entities. For example, the first 13 bits of a party identifier may be the identifier of the bank or similar entity from which the party identifier was obtained. One advantage of implementing party identifiers in this way is that profiles managed by a central system can limit the information of the parties. This is because banks or similar entities have records that identify their customers, and thus banks or similar entities can maintain end-user identifiers without requiring a complete profile managed by the central system 150.The ID management system 151 stores or is configured to store the identification numbers of parties, at least a portion of which may be generated by a third-party system (e.g., for banks) for parties who are anonymous to the central system 150. Individuals without bank accounts can obtain a unique identifier for using virtual currency through local branches of the national postal service (e.g., through a digital fingerprint pad that can be used to uniquely identify any individual with fingers).

[0015] The ledger storage system 152 is used to maintain 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 when 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 in 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 via 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 records of virtual banknotes in alphabetical, numerical, or alphanumeric order. In this way, records of virtual banknotes may be retrieved using the unique identifier of the virtual banknote. Using the ledger storage system 152, the central system 150 is configured to pre-confirm ownership of instances of traceable digital assets (e.g., virtual banknotes of NDCs) based on queries within SFOI packets, which can be done without transferring ownership of the traceable digital assets. The ability to pre-confirm or deny ownership of instances of traceable digital assets is an advantage provided by the central system 150.

[0016] The main memory system 153 is used to store records of most or all types of NDCs, and may be distributed by type. In the context of any trackable digital asset, including virtual NDCs, the main memory system 153 stores, or is configured to store, records of all instances of the trackable digital asset. The main memory system stores records of all instances of trackable digital assets (e.g., virtual NDCs) in the central system 150. The main memory system 153 receives record updates from the SGS 156 when instructions in an SFIOI packet are processed by a complex software algorithm executed by the SGS 156.

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

[0018] The artificial intelligence and analysis system 154 may be provided with access only to the main memory system 153 and may be completely isolated 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 turned on, the functions of the main recording system 153s may be switched to the backup memory system 155.

[0020] SGS156 may include a server assigned to process incoming communications addressed to a specified Internet Protocol (IP) address. SGS156 serves to isolate the main memory system 153 and other elements of the central system 150 from the public. SGS156 is a security system that runs complex software that systematically performs comprehensive checks on SFIOIs received by the central system 150. This software may include a set of sub-applications that can be adapted to any of the various formats configured for SFIOIs used in any central system identical or similar to those described herein. Each software sub-application performs a different task or multiple different tasks than other software sub-applications. A first set of algorithms in the SGS156 composite software can send queries outside of SGS156 but inside the central system 150, and a second set of algorithms in the SGS156 composite software checks responses to queries sent outside of SGS156. A sub-application or core of a multicore processor does not execute or process the entire SFIOI; instead, the sub-application processes 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 a virtual banknote corresponds to an SGS156 provider. Other software sub-applications may specialize in coordinating checks with other elements of the central system 150, including the ledger storage system 152 (e.g., verifying that virtual banknotes specified in the SFIOI belong to owners 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 graylists and blacklists for owners and virtual banknotes specified in the SFIOI), etc. Even though avoiding hang-ups waiting for responses from the ledger storage system 152 or similar responses to similar queries to other elements of the central system 150 may be the main reason, or one of the main reasons, why all processing of SFIOIs is not implemented linearly by a standalone core of a multicore processor, proving knowledge of ownership of each virtual banknote specified in each SFIOI can be an important security measure. The software sub-application may be provided as a software program, or as a pre-programmed dedicated multicore processor implementing the software program, or as a dedicated computer (e.g., a server) equipped with one or more such multicore processors programmed to implement the software program.

[0022] SGS156 can check that the NULL field of an SFIOI is NULL, and that header information such as the hop count is exactly the same as expected (e.g., 0). Subapplications may run on SFIOIs stored in a page in a first-in, first-out (FIFO) sequence. Each subapplication performs the assigned type of safety processing in the same manner for each SFIOI it is permitted to process. Different subapplications perform different types of checks. Processing on each page is highly coordinated by staggering the execution of subapplications in a predetermined order on each memory page until all subapplications have finished processing the SFIOIs on that memory page.

[0023] The SGS156 may include multiple nodes, each capable of processing tens of thousands (e.g., over 40,000) regular SFIOIs per minute. Incoming SFIOIs may be stored in a 512-byte sequential address space (i.e., flash memory pages that function as uniform memory units). 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 SGS156 can be visualized as four-dimensional processing. A 512-byte page is a two-dimensional memory with 64 64-bit word lines. Each sub-application moves incrementally between the three-dimensional pages, processing the same byte or word on each page. Sub-applications are positioned with a time stagger as a fourth dimension to avoid collisions where they attempt to read or write the same byte or word simultaneously. Furthermore, ownership checks and other types of external checks for sub-applications inevitably involve timing offsets. This is to prevent the core that sent the pair from hanging up waiting for a response, as one set of cores sends the pair to the ledger storage system 152 and another set of cores processes the response from the ledger storage system 152.

[0025] The SGS156 status update system can use the same memory pages used to store SFIOIs. The status update system is used to synchronize sub-applications when processing SFIOIs. To elaborate, any form of tracking NDCs can require a large number of write cycles to the memory pages used to store SFIOIs. If the status is updated 10 to 20 times during the processing of each SFIOI using the same memory cell, or memory cell of the same type, the number of write cycles to the status memory cell will be many times the number of write cycles to the memory cell used to store the SFIOI. As a result, if the status memory cell becomes exhausted, the entire memory will become exhausted 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, and the corresponding memory cell may be used for status updates instead of the essential data in the SFIOI. SFIOIs may be stored on a one-to-one basis in the SGS156's 512-byte pages, but the eight 64-bit NULL processing words at the end of the SFIOI may not be written to the page. Alternatively, the memory cells at the end of the memory page may be used to track the status of a sub-application, allowing it to check for the appropriate status word / byte before performing operations on the SFIOI and update each different status word / byte after performing operations. The memory cells used for status updates can be written to at virtually the same rate as the memory cells used to store the actual data on the SFIOI, thereby extending the memory life by at least 1000%.

[0026] A 24-core / 48-thread processor (e.g., AMD) is an example of a suitable multi-core processor type for the SGS156, and thus eight processing words (64 bytes) provide enough bytes to be dedicated to updating each thread on a one-to-one basis or better when processing implemented on the SFIOI by a thread is complete. Pairs of multi-core processors and flash memory may be used alternately in groups in the SGS156. Each sub-application may check (read) one allocated status field before processing to ensure that the sub-application is clear for processing the SFIOI. 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 for updates before performing safety processing on the SFIOI. After performing safety checks, a sub-application may mark the appropriate status field per 512-byte page or per sector to notify subsequent sub-applications whether processing should be performed before proceeding. For example, if any subapplication detects an error in any SFIOI, the subapplication can update the status of all update bytes in the status field to indicate that no further processing is required for the SFIOI on the page. This can be done simply to indicate that all necessary processing has already been performed so that subsequent subapplications can skip the SFIOI where the error was detected.

[0027] Some sub-applications generate queries to external systems within the central system 150 (i.e., outside of SGS156), and it is inefficient for processing resources to pause while waiting for a response to the query. For example, ownership verification may be performed by sending a query as an SFIOI to the ledger storage system 152 and receiving 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 prevents a particular thread from accumulating delays while waiting for a response. As an example, if each SFIOI can specify up to 9 virtual banknotes, a total of up to 18 threads may be required for ownership checks.

[0028] Since communications within the central system 150 can use internal addressing, external parties cannot determine how SGS156 retrieves information from the ledger storage system 152 or the ID management system 151. SGS156 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 SFIOI. The SGS156 can operate 24 hours a day, 365 days a year by switching in and out different pairs of multi-core processors and flash memory.

[0030] In some embodiments, different NDCs may be exchanged in a currency exchange (exchange) by a first and second central system, etc., that communicate with each other. Each central system can receive information on virtual banknotes and their alleged owners and can confirm with the other central system that the virtual banknotes are owned by the alleged owners. Thus, a central system can accept inquiries regarding virtual banknotes that it does not manage or track, as long as the virtual banknotes are managed or tracked by the other central system. In some similar embodiments, central systems can directly exchange virtual banknotes for purposes such as settling trade flows. In addition, or alternatively, a custodial institution can provide currency exchange (exchange) services for virtual banknotes and assist one or more central systems in tracking different types of virtual banknotes.

[0031] SFIOI can also specify the exchange amount by the sender of the virtual currency. In the example of currency exchange processing, a central system handling multiple different digital currencies can facilitate exchanges when used to exchange virtual currency of different digital currencies.

[0032] As an anti-spoofing mechanism, notifications may be sent to the record owner's recorded communication address. Users of authenticated currency reader programs or e-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, thereby allowing the same service's push notifications to be used to verify virtual currency transfers, transaction initiations, VPN logins, and / or other types of actions for which multi-factor authentication is deemed appropriate. In some embodiments, multi-factor authentication may include dynamically generating a code, such as a set of two characters, and sending that code or characters to a predetermined communication address, such as the telephone number of the actual owner of the virtual currency. The actual owner may be asked to enter the two characters in a response confirming the transfer.

[0033] Instances of an authenticated currency reader program and / or electronic wallet program used in transactions involving virtual currency may be provided with a unique identifier maintained in association with a unique identifier of the party in the records of the central system 150. The currency reader program is a program configured to read and appropriately interpret a file of virtual currency. The electronic wallet program is a program that provides access to one or more accounts where virtual currency is stored and traded, and may be configured to read and appropriately interpret a file of virtual currency. In some embodiments, the authenticated currency reader program and electronic wallet program may be centrally managed. For example, the central system 150 may work with an application server of a third-party service provider that provides the authenticated currency reader program and electronic wallet program so that the information on where parties using virtual currency should send their SFIOIs is automatically updated. The currency reader program and electronic wallet program may include instructions to suspend transactions and transfers at the same time daily, weekly, monthly, or yearly. The currency reader program and electronic wallet program may also each include subprograms that are activated by signals transmitted from the central system and dynamically stopped for reasons such as emergencies or crises. The currency reader program and the e-wallet program may be suspended for a set time or until they receive notification of resumption from the central system 1350. Synchronization may also be provided for all currency reader programs and e-wallet programs, a subset of currency reader programs and e-wallet programs, or individual currency reader programs and e-wallet programs.

[0034] The verification information of a party may include one or more forms of verification information that uniquely identify the party, such as a unique communication 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 communication device used by the party, a unique personal identifier assigned to the party by the government, biometric information, and other forms of unique information that may be uniquely associated with the party. In some embodiments, the party may be allowed to choose which form of verification information to use for verifying ownership, and the party may be allowed to change the form of verification information related to ownership of virtual currency.

[0035] The movement of NDC virtual currency may be detected and reported in various ways. Primarily, the movement of virtual currency is detected and reported by programs involved in the transfer of virtual currency, such as currency reader programs and electronic wallet programs. However, the virtual currency may also include, or alternatively, executable software subroutines that are retrieved from the virtual currency each time metadata is extracted, such as generating VN_info. The executable software subroutines may be included in specific fields of the virtual currency, 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 currency can be processed on different computers using different types of operating systems. Once the executable software subroutine is retrieved and processes such as generating VN_info are performed, the executable software subroutine can recognize that the virtual currency is about to be moved or has been moved, and can initiate a message to the central system 150 via the electronic communication network reporting the movement. The message is sent to a predetermined hostname or IP address and reports that virtual currency is about to be transferred from one account to another.

[0036] In the method by which the central system processes batch communications of virtual currency and convertible party information in Figure 1C, at S111, the central system receives SFIOIs such as ownership inquiries and transfer instructions. The central system 150 receives, or is configured to receive, an update to the virtual currency record from SGS 156 when the instructions from the public have passed processing by one or more algorithms that perform security checks in the security gateway system. At S112, the central system reads the batch number, sender information, counterparty information, and virtual currency information. The batch number can specify how many virtual currency information fields are entered in the communication. The sender information and counterparty information may be unique identifiers of a universal type used by the central system, or other types of unique identifiers convertible to a universal type used by the central system. At S113, the central system converts the sender information and / or counterparty information as necessary. At S114, the central system reads the virtual currency information. At S115, the central system uses the ledger storage system 152 to determine whether the virtual currency information matches the current owner indicated in the SFIOI. If the virtual banknote information matches the current owner indicated in the SFIOI (S115=Yes), in S116 the central system determines whether the virtual banknote information is that of 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 sends a response to the inquirer or instructor in S119. The central system also determines, at any time, that the virtual banknote information does not match the current owner indicated in the communication (S115=No), and deletes the communication in S118 and sends a response to the inquirer or instructor in S119.

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

[0038] If a virtual banknote is lost, such as when a portable memory device is lost, the owner can present a certificate of ownership to the central system 150. The central system 150 can then cancel the virtual banknote in question and all other virtual banknotes registered with that owner, and simply issue a new virtual banknote of the same denomination to the owner.

[0039] The electronic history of virtual currency may be managed in the main memory system 153. The electronic history begins with the unique identifier and creation date of the virtual currency, and may include dates and identifiers that identify each party owning the virtual currency as the virtual currency changes ownership in transactions. For example, the electronic history may include the creation date and time, creation location, a sequential list of each owner of the virtual currency, identification information for each owner, and a combination of dates or times for each transaction in which the virtual currency was transferred between owners. The electronic history can be created and updated for each virtual currency in a set of NDCs, such as virtual currency above a specified face value. For example, the record for a virtual currency with a value of 1,000 US dollars (hereinafter, dollars means "US dollars") is updated each time the virtual currency is traded.

[0040] Figure 1D shows a method for verifying a transfer instruction for virtual banknotes for digital currency, illustrating detailed post-processing for virtual banknote transfers that may be applicable to any transfer of virtual banknotes.

[0041] The process shown in Figure 1D begins at S150 when the central system 150 receives a transfer instruction as an SFIOI. In S152, the recipient's party information is retrieved. In S153, the party's blacklist and party graylist are checked. Other forms of monitoring may be imposed, such as transactions involving large amounts of virtual currency or transactions involving parties involved in many other transactions within a relatively short period. For example, if the sender or recipient of virtual currency has started using virtual currency relatively recently, or is using a relatively new unique identifier to identify themselves, the history of the sender and / or recipient of virtual currency may be flagged. In S154, the party information is compared with the party's blacklist and party graylist. In S155, if any matches are found as a result of the comparison in S154, action is taken.

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

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

[0044] A greylist may be maintained for virtual currency for various reasons, including the frequency of transfers by the transaction requester, the frequency of activity by the transaction requester (e.g., processing of a large number of virtual banknotes), and economic and / or statistical reasons. The greylist may also be maintained for parties such as transaction requesters that are subject to special monitoring. Actions taken based on a greylist match may include notifying a third party, such as a government agency, or simply adding a transfer entry to the records maintained for the monitored recipient. A blacklist may be maintained for virtual currency and parties, and actions taken based on a blacklist may include notifying the party that the transaction is not permitted. In some embodiments, a greylist match may initiate a virtual currency inspection requirement by ordering the virtual currency to be provided to the central system 150 for inspection of the virtual currency file, or by ordering an electronic communication device to inspect the virtual currency file by a currency reader program or electronic wallet program.

[0045] For example, virtual currency transferred to any address known to belong to a foreign central bank may be placed on the virtual currency greylist, and the foreign central bank's address may be placed on the party greylist. Thus, transferring virtual currency from a foreign central bank account may trigger alerts based on both the virtual currency greylist and the party greylist, and a notification may be sent to the system that monitors the central bank's currency flows.

[0046] In Figure 1E, in the way the central system processes ownership inquiries for one or more virtual banknotes, at S121, the central system 150 receives the ownership inquiry as an SFIOI. At S122, preprocessing related to the SFIOI is performed, starting with a check of the VN number. At S123, the central system retrieves party information from the ownership inquiry. Processing from S123 to S129 is performed to address the use of aliasing, if permitted. For example, a party may be assigned a universal identifier to use with the central system, but other identifiers such as a telephone number, driver's license number, or email address may also be associated with the universal identifier. At S124, the central system identifies and verifies the country and state / region identified in the party identifier. At S125, the central system determines whether the party information is of the universal party identifier type. If the party identifier is of the Universal Party Identifier type (S125=Yes), in S129, the Universal ID number is retrieved and confirmed from the last field. If the party identifier type is not a Universal ID (S125=No), in S126, the central system identifies the ID type. If the party identifier is not of the Universal Party Identifier type (S125=No), in S127, the ID type of the party identifier is identified from the third field. In one embodiment, the ID type may be an application identifier for a currency reader program or electronic wallet program used by the user corresponding to the party ID. In S127, the central system retrieves and confirms the ID number. In S127, the ID number of the ID type identified in S126 is retrieved and confirmed. In S128, the central system converts the ID number to a Universal ID number used by the central system. The conversion in S128 is not required in all embodiments and should be considered an optional (discretionary) process in the teachings herein.The conversion involves retrieving the Universal ID from a lookup table in the database. In S129, the central system retrieves and verifies the Universal ID number after the conversion in S128, or if the party information is of Universal Party Identifier type (S125=Yes). The Universal ID number may be used to check against a greylist or blacklist, regardless of whether it has been converted. In S130, the central system compares the virtual banknote(s) with the electronic history of the virtual banknote(s) to determine whether the current owner of the virtual banknote is a party listed by the Universal Party Identifier received in S121 in the ownership inquiry. The central system then responds to the requester with a simple "Yes" or "No," etc.

[0047] Figure 1F shows how the central system processes a transfer instruction. In S131, the central system receives an SFIOI as a transfer instruction. In S132, the central system begins performing preprocessing of the transfer instruction for security purposes. Most or all of the preprocessing described for Figure 1E can also be applied to the preprocessing in Figure 1F. In S132, the central system reads the VN number. In S132, the central system also checks the VN number relative to the actual size of the substantial data in the VN ID field of the SFIOI. In S133, the central system retrieves party information from the transfer instruction. Processing from S133 to S139 is performed to address the use of aliasing if permitted. In S134, the central system identifies and verifies the country and state or region identified by the party identifier. In S135, the central system determines whether the party information is of a universal party identifier type. In S136, if the party identifier type is not a universal ID (S135=No), the central system identifies the ID type. In S137, the central system searches for and verifies the ID number. In S138, the central system converts the ID number into a universal ID number used by the central system. In S139, the central system searches for and verifies the universal ID number after the conversion in S138, or if the party information is of the universal party identifier type (S135=Yes). In S140, the central system compares the virtual banknote(s) with the electronic history of the virtual banknote(s) to determine whether the current owner of the virtual banknote is a party listed by the universal party identifier received in S131 in the transfer instruction.

[0048] In Figures 1E and 1F, when the SFIOI is received by the central system, the party identifier is processed. The central system may be configured to accept only universal IDs as party IDs, or it may be configured to accept and process multiple types of party IDs. Furthermore, if the central system receives multiple types of party IDs, it may convert these 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, insofar as they are acceptable.

[0049] In some embodiments, the central system 150 may store different alternate IDs in different databases, such that each of the different sets of alternate IDs is isolated from all other sets of alternate IDs. For example, the central system 150 may store a first database of conversion tables for translating all telephone numbers in the United States into corresponding universal IDs used by the central system, and another database of conversion tables for translating all currency reader program identifiers into corresponding universal IDs. Naturally, three or more independent database configurations may be used for the translation into universal IDs. By separating the memory configurations of different memory used for translating different types of IDs, it is possible to ensure the fastest possible lookups of universal IDs whenever an alternate ID is received as part of an incoming query or instruction. As an alternative to lookup tables for storing universal ID alternates, the universal ID numbering system may be designed so that alternate IDs are accepted from authorized sources such as major social network providers or telecommunications service providers. For example, if a 10-digit universal ID is used for a population of up to 9.999 billion people, the last 11th and 12th digits can be used to specify up to 99 different accounts or other characteristics for inquiries and instructions sent to a central tracking system.

[0050] In some embodiments, the exchange of virtual currency may be handled by a central system. For example, the central system may interpret a "change amount, if due field" of the SFIOI. The "change amount, if due field" allows the sender of the virtual currency(s) to specify the amount of exchange that the sender should receive from the recipient(s). The central system 150 stores information about the universal electronic wallet programs of the parties using the virtual currency and can credit and / or debit the universal electronic wallet program for the exchange amount agreed upon in the notification from the sender and recipient. In addition, or alternatively, the central system 150 may store information about the third-party (e.g., bank) accounts of the sender and recipient of the virtual currency and credit and / or debit the exchange amount agreed upon in the notification from the sender and recipient from the third-party account. In some embodiments, the central system 150 may use the Universal Electronic Wallet Program as the default for deposits and withdrawals to senders and recipients, but senders and recipients may update the central system 150 and 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 Figure 1G, the central system coordinates the inspection of virtual banknotes by recipients of virtual banknotes. The process of Figure 1G begins in S180 when the central system 150 receives a greylist detection notification, which is generated when a notification of a movement of virtual banknotes on the greylist or a movement between parties on the greylist is detected. The central system 150 may have an automated process configured to initiate the process of Figure 1G. In S185, the new owner of the virtual banknote is provided with the expected characteristics of the virtual banknote and instructed to compare the expected characteristics of the virtual banknote with the virtual banknote and report the result. In S190, a determination is made as to whether there is a match or not. The determination in 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 has analyzed the virtual banknote. If there is a match, the process of Figure 1G ends in S191. If there is no match, the central system 150 may exchange the virtual banknote for an alternative virtual banknote of the same denomination. For example, the central system 150 may instruct an electronic communication device to transfer virtual banknotes that do not match the characteristics of the assumed virtual banknotes, and then provide the electronic communication device with new virtual banknotes as replacements. In the process of Figure 1G, replacements may occur for a variety of reasons, including attempted tampering, successful tampering, wear and tear, deterioration over time, counterfeiting, passing through an owner or geographical area or country monitored by a greylist, or other explanations for why the virtual banknotes do not have the assumed characteristics. However, since tampering, impersonation, counterfeiting, and other forms of misuse can be adequately addressed using the teachings herein, replacements like those in S195 are typically assumed to be due to wear and tear, 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 lifetime of an end user and may be fully or partially managed by a central system. The persistent electronic wallet program may be assigned after the birth of the party, and the party may be assigned a unique identifier. Subsequently, the persistent electronic wallet program is created and can receive and store financial instruments such as digital currency on behalf of the party. At any time during the party's lifetime, an entity that has an obligation to pay the party for any reason may transfer that payment to the persistent electronic wallet program if it is unable to find the party to arrange the payment. A government that wishes to distribute stimulus funds to adult citizens may transfer those stimulus funds to the persistent electronic wallet program. The state may enable non-citizen residents to obtain a unique identifier and a persistent electronic wallet program. Furthermore, by obtaining a biometric identifier such as a fingerprint, retinal scan, DNA, or other electronically recordable form and associating it with the persistent electronic wallet program, the party may enable authorities authorized to provide access to the persistent electronic wallet program to recognize them. The central system may allow the party to specify access controls to the persistent electronic wallet program. For example, a party may require subsequent withdrawals from a persistent electronic wallet program to be accompanied by the party's fingerprint, a retinal scan of the party, 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 data centers that handle large amounts of data managed by the central system, such as for the main memory system 153 or for multiple elements of the central system 150. The data centers may be configured to process instructions derived from the SFIOI by referencing or updating data within the data centers. Data stored in the data centers and searchable for use from the data centers may include the electronic history of virtual currency, group information of virtual currency (e.g., features such as background images of groups of virtual currency), party information (e.g., unique electronic communication addresses and program / application identifiers, nationality, place of residence, currently owned and previously owned virtual currency, and transfer dates), a graylist of virtual currency, a blacklist of virtual currency, a graylist of owners, a blacklist of owners, etc. The data centers may include multiple data centers and use expandable memory. SQL may be used if the database configuration of the data centers requires compatibility with legacy databases that already use Structured Query Language (SQL). SQL can be useful when handling structured data in relational databases. Alternatively, if the database configuration does not require a relational database, a non-SQL (NoSQL) database may be used, which may be useful for real-time queries such as verifying ownership of virtual currency through the ledger storage system 152. One example of a usable NoSQL configuration is a MongoDB configuration. A MongoDB configuration is considered a document-oriented database that provides a file system that can be used to store virtual currency according to a unique identifier and can be used to store user profile documents containing the ownership history of various virtual currencies. The data center may be implemented in a private cloud configuration that separates the facilities and operations for digital currency from those for other parties and applications. For example, the data center may use solid-state drive (SSD) arrays for data storage. SSDs may be preferable to hard disk drives (HDDs) in that they are faster and more power-efficient. The database may be implemented on a pair-based basis, with dedicated servers paired with each memory configuration, or on a dynamically reconfigurable basis to run less used servers to alleviate the load on overloaded servers.

[0054] In some embodiments, virtual currency may be provided as a folder containing multiple files. For example, virtual currency may contain a relatively small amount of data, such as image data or variable data. Some of the usage data stored as metadata for virtual currency may be provided as a separate encrypted file containing JSON or BSON data and may be transmitted to a central system via an Application Programming Interface (API). The usage data may be incorporated into and stored in data fields within the JSON / BSON file. The central system may send a signal via the API to the device storing the virtual currency, indicating that the data in the JSON / BSON file is stored in the central system and can be deleted from the device storing the virtual currency. This reduces the amount of data transmitted with the virtual currency when it is transferred. Virtual currency and / or the API may also be configured to communicate via specific ports on servers or databases in a data center to notify of updates, thereby reducing the workload on the central system. One or more types of SFIOIs described herein may include JSON / BSON updates, and these communications may be handled by updating the central system's records with the details of the JSON / BSON updates when the SFIOI is cleared via SGS156. In some embodiments, the virtual currency may include a private address in its metadata field that is not publicly available but is interpretable by the central system or another control system, which may include the address of a private server or database, or a specific port address of the address of a private server or database. The central system may unpack the updates to identify which of the private server or database addresses stores the records of the virtual currency, which may supplement or replace addressing based on the unique identifier of the virtual currency.Therefore, even if a central system or control system partially uses the unique identifier of virtual currency to identify subgroups of servers and databases used to store records of virtual currency, the private addresses transmitted from virtual currency can be used to specify another internal communication address within the subgroup corresponding to a server, database, server port, database port, or component that is unreachable by a public address.

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

[0056] Figure 2B illustrates the separate addressing of different types of communications to a central system. For example, a central system may include multiple subsystems that receive and process incoming SFIOIs. Different types of SFIOIs may present different levels of risk regarding hacking, impersonation, denial-of-service (DOS) attacks, and other types of malicious activity. Therefore, if the authorities behind the central system exercise sufficient caution before constructing the central system, the central system and all types of end-user and intermediary software can be designed to handle multiple different electronic communications addresses corresponding to different types of SFIOIs. In Figure 2B, the multiple subsystems include the first central subsystem 251A, the second central subsystem 251B, the third central subsystem 251C, the fourth central subsystem 251D, the fifth central subsystem 251E, the sixth central subsystem 251F, and the seventh central subsystem 251G. For example, the first central subsystem 251A can receive and process ownership inquiries for virtual currency and interact with a ledger subsystem that stores a limited subset of records, such as current ownership, for each virtual currency. For example, the second central subsystem 251B can receive and process transfer instructions from trusted parties such as banks and large corporations. When a trusted party is the source of a transfer instruction, that trusted party may not undergo high-level verification before the transfer of virtual currency is processed. For example, the third central subsystem 251C can receive and process transfer instructions from end users who have a relationship with a trusted party, such as end users who send transfer instructions using applications provided by banks. The fourth central subsystem 251D can receive and process transfer instructions from persons who are supposed to be recipients of virtual currency. For example, the fourth central subsystem 251D may be configured to verify transfer instructions by contacting the current owner of the recorded address as a form of additional authentication, in order to counter attempts at impersonation and to counter fraudulent transfer instructions from persons who are supposed to be recipients of virtual currency.A fifth central subsystem 251E can receive and process transfer instructions from overseas sources. For example, the fifth central subsystem 251E may be configured to verify transfer instructions in the manner of the fourth central subsystem 251D and to create and update records used to indicate cross-border currency flows. A sixth central subsystem 251F can receive and process transfer inquiries such as complaints, notices of suspicious activity or fraud, and other forms of special matters requiring special handling. Even complaints and notices received by the sixth central subsystem 251F may require specific processing or formatting in the manner described herein to counter hacking. A seventh central subsystem 251G can be used to exchange virtual currency with other central systems. In this way, a central bank can use dedicated resources to transfer virtual currency with other central banks. This is also to isolate such matters from other types of inquiries and instructions where a greater risk of fraud is assumed.

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

[0058] In the memory configuration of the memory system shown in Figure 3A, the communication system divides the memory system based, for example, on the unique identifier of a virtual banknote. The main memory system 351 is divided into 10 independent sections. Each of the 10 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 represents the switching system and may include multiple switches, each receiving instructions such as updating the virtual banknote record. Each section of the main memory system 351 may be physically separated from each other, such as different rooms, different buildings, different zip codes, different counties, different states, or different countries. The logical arrangement of the 10 independent sections of the main memory system 351 may correspond to the first letter of the unique identifier of a virtual banknote. For example, the unique identifiers of virtual banknotes may each begin with a number from 0 to 9. Virtual banknotes with unique identifiers starting with 1 may be assigned to section 351-1, virtual banknotes with unique identifiers starting with 2 may be assigned to section 351-2, and so on. While partitioning the main memory system 351 is not mandatory, if implemented in this manner, the partitioning is not limited to three sections. For example, the addressable memory system can be logically partitioned into up to 26 sections to correspond to the characters A through Z. Alternatively, the addressable memory system can be logically partitioned into up to 30 sections to correspond to two-digit numbers from 0 to 99. Therefore, addressing based on the unique identifier of the virtual currency may be used to distribute the workload so that read and write operations to the main memory system 351 can be performed more quickly and efficiently.

[0059] In the memory configuration of the memory system shown in Figure 3B, the communication system divides the server workload based on a load balancer that measures the workload of equipment used, for example, to process virtual currency. In Figure 3B, server system 350 is used to communicate with separate sections of main memory system 351. Load balancer 354 monitors the workload of servers within server system 350 and can reduce or increase the workload allocated to servers within server system 350. Each server within server system 350 may be configured to receive updates to any of the separate sections of main memory system 351, program updates, and read or write data to any of the separate sections of main memory system 351. Therefore, internal addressing in the central system may be based on a common address for server system 350 or on the individual addresses of the separate sections for main memory system 351. For example, if communication is 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 currency that is the subject of the query or update assigned to that server, and each server in server system 350 may then be configured to implement the query or update to the appropriate section of main memory system 351. Alternatively, if the addressing is partially based on the unique identifier of the virtual currency, 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 in Figure 3C, the communication system divides the workload between the servers and memory based, for example, on a unique identifier for virtual currency. In Figure 3C, the server system includes servers, each assigned one-to-one to a corresponding section of the main memory system 351. Switch 353 can assign queries or updates to the corresponding servers based on addressing specific to the corresponding server, such as when the addressing of incoming communications is partially based on a unique identifier for virtual currency. The server system in Figure 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 switch 353. Switch 353 again represents the switching system and may include multiple switches, each receiving requests such as verification requests or requests to update virtual currency records. The servers in the server system in Figure 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] Furthermore, the central system may require communications to conform to a specific format limited to a small number of authorized types of communications. Internal servers and databases may be assigned private local addresses that are meaningful only to the central system or another form of control system. Internal servers may be numbered from 1 to 1000, and internal databases may be numbered from 1 to 1000. This allows the central system to track records for updating and retrieving using private local addresses rather than public addresses.

[0062] In some embodiments, as described herein, artificial intelligence may be used to optimize the operation of the central system 150. For example, problematic datasets that can be applied to training the artificial intelligence to detect features and patterns include: data corresponding to detected attempts to counterfeit virtual currency; data corresponding to detected attempts to impersonate a party or user device; data corresponding to detected attempts to impersonate an authentication software program; data corresponding to reported lost virtual currency; data corresponding to reported stolen virtual currency; and data corresponding to detected fraudulent attempts to verify ownership of virtual currency. Using artificial intelligence, portions of incoming communications, such as transfer instructions, can be automatically subjected to multi-party authentication, owner impersonation checks using the recorded address of the virtual currency owner, and other forms of additional processing. The artificial intelligence may be trained using transaction data, virtual currency data, account data, party data, and / or other datasets within the server system 350 as training data. For example, the artificial intelligence can be used to detect suspicious or illegal transactions, transactions likely to be error-prone, transactions likely to be fraudulent, or other problematic behavior detectable based on patterns identified by 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, and can be applied for various reasons, such as detecting fraud and counterfeiting attempts based on accounts, transaction types, locations where transactions take place, and the types of virtual currency involved.

[0063] In the method for recovering virtual banknotes of digital currency shown in Figure 4, in S410, a verification request for virtual banknotes is received by a verification system or the like from the electronic communication device 101 of the first party, the electronic communication device 102 of the second party, or the electronic communication device 103 of the third party. In S420, a verification system such as the central system 150 looks up the electronic history of the virtual banknotes. The verification system can retrieve the complete electronic history from the main memory system 153 in S420. In S430, the verification system determines whether the verification request contains fraud, such as when the virtual banknotes do not belong to the person who is supposed to be the owner. If the verification request contains fraud (S430=Yes), the virtual banknotes are recovered in S435. The virtual banknotes may also be recovered by contacting the last recorded owner of the virtual banknotes and instructing the last recorded owner to transfer the virtual banknotes to the central system 150 in exchange for another virtual banknote of the same denomination. Subsequently, the virtual banknotes may be stored in storage such as the main memory system 153. If the verification request does not contain any fraud (S430=No), in S440, the transaction count of the virtual banknotes is incremented. In S450, the verification system determines whether the transaction count of the virtual banknotes exceeds a threshold. For example, the threshold for the amount of virtual banknotes used before they are redeemed can be 100 transactions, 1,000 transactions, 5,000 transactions, or any other number. If the transaction count of the virtual banknotes exceeds the threshold (S450=Yes), in S435, the virtual banknotes are redeemed. If the transaction count of the virtual banknotes does not exceed the threshold (S450=No), in S460, the verification system determines whether the circulation period of the virtual banknotes exceeds a threshold. For example, the threshold circulation period of the virtual banknotes can be 1 year, 3 years, 5 years, or any other period. If the circulation period of virtual currency exceeds the threshold (S460=Yes), the virtual currency is returned in S435. If the threshold period of virtual currency does not exceed the threshold (S460=No), the virtual currency is not returned and is verified in S470. Virtual currency may be returned from the service if an unfair attempt to trade virtual currency is detected, if the virtual currency is involved in transactions exceeding a predetermined threshold number, or if the virtual currency circulates for a period exceeding a predetermined threshold amount.The reasons and grounds for returning virtual currency are not limited to those stated herein.

[0064] In some embodiments, the central system may be synchronized with electronic communication equipment. Synchronization may include a predetermined arrangement to refrain from transfer transactions, including virtual currency managed by the central system, for a certain period of time. The period during which no transactions or transfers occur may be a period during which the central system is replacing equipment, updating backup memory such as electronic records, user profiles, or account profiles, performing software updates, or otherwise becoming inaccessible. The period may be a predetermined period, such as daily, weekly, monthly, or yearly, and may be a period during which minimal activity is expected to be affected. In some embodiments, the period may be set dynamically for reasons such as emergencies or crises. In some embodiments, synchronization can be used to suspend transactions or transfers at different times, such as in different time zones. For example, the suspension may be set for 5 minutes at 3:30 a.m. every Monday, and each time zone may be halted gradually as it reaches 3:30 a.m. every Monday. Alternatively, electronic communication devices may be grouped based on the manufacturer, wireless communication service provider, year of manufacture, service provider of currency reader programs or electronic wallet programs, or other logical grounds, so that different groups may be suspended at different times for a set period or until notification is received from a central system. In some embodiments, synchronization can be used to suspend transactions or transfers in different locations. For example, suspensions may be set for 3:30 a.m. every Monday in North America, 3:30 a.m. every Tuesday in Europe, 3:30 a.m. every Saturday in the Middle East, etc. Synchronization may also occur for reasons other than suspension, such as updates to the central system's communication addresses.

[0065] In the electronic communications network integrated with the central system's security gateway system (SGS) in Figure 5A, the 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. The 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. Addressing to the central system 550 via the electronic communications network 530 can be simplified by restricting communications to one or a few specific Internet Protocol (IP) addresses; therefore, routers in the electronic communications network 530 may be configured to ensure that no specific server in the SGS 556 is overloaded. For example, a router in the electronic communication network 530 may logically change the addressing and routing of communications addressed to a particular Internet Protocol (IP) address, such as sequentially sending a first incoming packet or packet set to a first server of SGS556, then a second incoming packet or packet set to a second server of SGS556, and then a third incoming packet or packet set to a third server of SGS556. The router may also use a clock to determine the receiving routers of SGS556, such that incoming packets or packet sets received in seconds ending in "1" are sent to the first server, and incoming packets or packet sets received in seconds ending in "2" are sent to the second server. Any known mechanism for changing addressing and routing to avoid congestion and overload of recipients may be used within the electronic communication network 530, as long as the load on the servers of SGS556 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.Thus, the router may be dedicated to the Internet Protocol (IP) addresses of the central system 550, and the router may perform routing only to or from these Internet Protocol (IP) addresses, or not exclusively but primarily this routing. In this way, the logical variations of packet routing to the servers of SGS556 can be specifically controlled by the technicians who design and / or operate SGS556. In some embodiments, a network router implemented as an intake for the electronic communications network 530 or the central system 550 may disable the reception of incoming Transmission Control Protocol (TCP) and allow only the reception of User Datagram Protocol (UDP) to prevent any external entity from establishing a connection via TCP. Alternatively, sequence throttling may be implemented by such a router to remove packet sequences that are higher than 1, 2, 3 or other predetermined thresholds. This ensures that the SFIOIs described herein are consistently transmitted via standalone IP packets, even when transmitted over TCP.

[0066] The working memory configuration of the servers in the Security Gateway System (SGS) shown in Figure 5B includes a first server 5561, which is illustrated with nine groups of address spaces (AS) in memory, each having eight independent address spaces. Each address space may be a physically independent memory address of memory such as SSD memory, or it may be specialized for the function of the individual address space. Alternatively, each address space may be a logically isolated and reassignable memory address of memory such as SSD memory. The first server 5561 is representative of the servers in SGS 556. Each address space can temporarily store one SFIOI received from the public when processed by the central system 550. The first server 5561 can perform predetermined security processing on one SFIOI.

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

[0068] In some embodiments, the entire SFIOI is stored in a separate address space, and the bytes of the SFIOI within the separate address space are processed in a specific order for a particular purpose. For example, if a predetermined format of the SFIOI sets a size requirement for the SFIOI packet, the first process may check the size of the SFIOI. The predetermined 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 digital asset being tracked (e.g., virtual currency in an NDC) included in the packet. If the SFIOI is too large or too small, it may be deleted. The second process may check the type of the SFIOI, for example, by interpreting specific bytes required by the format to describe the type of the SFIOI. This type may be limited to inquiries about ownership, transfer instructions, instructions for special processing (e.g., requesting virtual currency to be taken offline, requesting multi-factor authentication before allowing the transfer of virtual currency, etc.). Other processing is described elsewhere in this specification. Processing may be sequentially staggered on each packet, or different processing may operate in parallel on different packets. Furthermore, processes involving checks with external resources (e.g., ownership checks, instructions for special actions on the owner, multi-factor authentication checks) may be initiated by a set of processes that do not wait for a response. Alternatively, another set of processes may handle the response from the external resource.

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

[0070] In the method by which the security gateway system processes received SFIOIs in Figure 5C, an overview of the efficient security checks performed by the security gateway system begins with storing the packet payload in the address space in S502A. Packets may also be stored individually in pages of flash memory for processing by the security gateway system. Since packets can be sent asynchronously from anywhere in the world without initiating a connection, the sender can expect a quick response if the packet is processed and satisfies the expectations of the security gateway system. Naturally, the teachings herein are not limited to 512-byte packets or packets of uniform size.

[0071] In S504A, the size of the packet payload is checked in bytes. The total length of meaningful data in the packet payload may be specified in the packet header, and this header information may be compared with the actual length of meaningful data stored in the address space. In S508A, the number of virtual banknotes (VN number) identified by the SFIOI is determined. The VN number identified by the SFIOI can be specified in specific bytes according to the format set in the SFIOI. In S510A, the assumed size of meaningful data in the packet is determined from the VN number determined in S508A, and the assumed size determined in S510A is compared with the actual size determined in S504A. In S512A, the identifier of the person who is supposed to be the owner of the virtual banknote specified in the SFIOI is determined. In S514A, for owner check, the identifier of the person who is supposed to be the owner is sent along with each individual virtual banknote identifier. The identifier of the person who is supposed to be the owner may be sent to the ledger storage system 152 along with each individual virtual banknote identifier in a single communication or as a batch of individual communications. If there are stored instructions from the actual owner of the virtual banknote, these instructions are checked in S516A. The check in S516A can be performed on the main memory system 153 if the processing instructions from the virtual banknote owner are stored in the main memory system 153, on the ledger storage system 152 if the processing instructions from the virtual banknote owner are stored in the ledger storage system 152, or on another memory system that stores the processing instructions if it is different from the ledger storage system 152 or the main memory system 153. In S518A, if the stored instructions checked in S516A instruct anti-spoofing measures, the anti-spoofing measures are initiated. In S520A, the type of SFIOI is checked. The type may include inquiries, transfer instructions to other parties, transfer instructions to other accounts or devices of the same owner, special processing instructions, etc. In S522A, the SFIOI is processed according to the checked type. If the instruction is an instruction to transfer ownership of virtual currency, an instruction to update the record of ownership of virtual currency may be sent to the main memory system 153.The processing may include decrypting the unique identifier of the virtual currency if the SFIOI is an ownership inquiry, and the unique identifier of the virtual currency may be decryptable only by the central system 150, in particular by SGS156. Other processing may include notifying other central systems that track other digital currencies, or other instructions or confirmation notices processed by SGS156.

[0072] In Figure 5D, the memory configuration of the security gateway system (SGS) that processes received SFIOIs shows nine independent bays for the first server 1561. Each bay contains address spaces listed from address space #1 (i.e., AS1) to address space #50,000 (i.e., AS50K). Packets received by the server may be stored contiguously in bay 1 until, for example, 40,000 address spaces are filled with 40,000 packets. The processing resources of the first server 1561 can begin processing packets as soon as they are first added to a bay. If 40,000 packets are received per minute in SGS156, packets will be stored in one bay of one server until the 40,000th packet is received, and thereafter newly received packets may be allocated to another bay of the same server or a different server. As another example, if one group of one or more servers is tasked with processing instructions and queries for a certain period of time before being replaced by another group of one or more servers, the packets may be distributed randomly or logically into different packets.

[0073] In the processing configuration of the security gateway system (SGS) that processes received SFIOIs, shown in Figure 5E, the first server 1561 includes eight cores, each having its own dedicated pointer queue. The cores may be some or all of the cores of a multicore processor, or they may be distributed across multiple multicore processors and / or single-core processors. The cores perform operations on the address space of bay X in the order in which the address space is allocated to its dedicated pointer queue.

[0074] In the processing configuration of the security gateway system (SGS) that processes received SFIOIs shown in Figure 5F, the first server 1561 includes eight threads, each having its own dedicated pointer queue. The threads operate on the address space of bay X in the order in which their address spaces are allocated to their dedicated pointer queues. In effect, each thread repeatedly and iteratively executes one or a very small number of tasks on a large 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 specifically configured to have a number of threads capable of handling 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) that processes received SFIOIs in Figure 5G, the set of cores of the first server 1561 references a status space that stores the status of each address space on a one-to-one basis. In this regard, the address space may accommodate 512 bytes or other relatively large amounts of fully formatted SFIOIs, while the status space may be on the order of 4 bytes. The address space may be non-volatile flash memory, while the status space may be volatile DRAM memory, for example. Within 4 bytes or possibly 5 bytes, the status space can specify which address space corresponds to, along with the actual status of the address space. The status can specify the core that will next process the address space, and / or the core that last processed the address space. In this way, the set of cores can sequentially reference the status space and process the packet payload of the corresponding address space if the status indicates that the core is processing the packet payload in the corresponding address space. The first core (core #1) begins processing any address space starting from the first address space (AS1), updates the corresponding status space (SS1), then begins processing the second address space (AS2), and updates the corresponding status space (SS2). The remaining cores begin processing from the first address space when the first status space (SS1) instructs them to process, and update the first status space (SS1) before checking the next status space. Naturally, if some processing indicates that the packet payload in the corresponding address space should be deleted, or otherwise left as is, the status of the status space may be updated to reflect a deletion status, such as "99," indicating that the next processing is deletion. Once processing for any address space is complete, the status of the corresponding address space may also be updated to reflect that the next processing is deletion.In this way, all packet payloads within Bay X are processed periodically, and when they are ready to be deleted, the latest status in the corresponding status space may uniformly reflect the status indicating deletion. Once Bay X is completely deleted, it may be returned to the cycle for another batch of incoming packets. After use, a downtime of 30 or 60 minutes may be provided to allow the circuit to cool down, etc.

[0076] In the processing configuration of the security gateway system (SGS) that processes received instructions or queries, as shown in Figure 5H, individual threads refer to the status space instead of individual cores.

[0077] In the processing order of packets received and stored in the security gateway system (SGS) that processes received instructions and queries in Figure 5I, a thread may be assigned to process the first packet (i.e., packet #1), and then to process the 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, but some packets may be processed in a different order than others if the processing involves a branch that allows processing by one or more threads, cores, or processors to be skipped.

[0078] In Figure 5J, the use of a dedicated queue by processing resources in the security gateway system (SGS) that processes received instructions and queries is shown, where a first-in, first-out pointer queue is indicated, and the address space is read from the beginning of existing entries in the queue, and the address space is written to a first open space for entries in the queue. A thread may refer to the address space pointed to by the pointer queue and retrieve and process bytes processed by the thread. Each thread may process a subset of bytes from a packet in the address space in the manner described herein.

[0079] In the method by which the Security Gateway System (SGS) in Figure 6A processes received SFIOIs, the resources process packet payloads within the address space of SGS156 individually and independently. Packets are received before the method in Figure 6A is initiated. After all packets in the bay have been processed, the entire address space in the bay may be cleared by deleting the data within it.

[0080] In S602B, the packet payload is stored in the address space. The packet header attached 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 a resource. In Figure 6A, the resource iteratively performs its respective processing for each address space in the address space bay. The resource may be a thread, a processor, a core of a multicore processor, etc. In S604B, the size of the packet payload in bytes is checked by a first resource (i.e., resource #1). The size of the packet payload can be checked for 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 the packet size field in the header. In some embodiments, the packet size data from the header may be compared with the result of searching for the presence of meaningful data in the address space. The actual size of the packet size data and the meaningful data in the address space may be compared with one or more predetermined thresholds, such as the maximum size allowed by the format. In S606A, it is determined whether the checked size is OK or not. If the checked size is not OK, at S606C the packet is removed from the address space. If the checked size is OK, at S606B the first resource is incremented 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). The next resource then processes the address space. At S608B, the number of virtual banknotes identified by the SFIOI is determined by the second resource (resource #2). This VN number may be specified in the fields required in the SFIOI format, for example, one byte or less than eight bits. At 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 will process that 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 virtual currency should be of a uniform size, the expected size of the packet payload may be predetermined based on the number of VNs. Furthermore, since the number of VNs that can be specified in the packet can be kept below the maximum value, 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, a decision is made as to 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. In S612B, the party identifier of the person alleged to be the owner of the virtual banknote and the party identifier of the alleged trading partner (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 determined in S612B is added to the queue of the next seven resources (resources 5-11). Aggregate checks of the owner and trading partner identifiers are performed by sending an internal query to another part of the central system 150, such as the ID management system 151. Aggregate checks may include checking whether the party identifier of the person alleged to be the owner of the virtual banknote and the party identifier of the alleged trading partner (if any) are on a blacklist or greylist. Aggregate checks may be performed in parallel with the rest of the method in Figure 6A so that results that prevent the execution of the response to the SFIOI in S622B are received before S622B is executed later. Furthermore, the address space is added to a queue(s) for the following seven resources, in an example where the maximum number of virtual banknotes allowed in the format for instructions and queries is seven. However, a resource may handle one or more virtual banknote identifiers, with a maximum of less than seven or more than seven.In S614B, the identifier of the alleged owner and each virtual banknote identifier are transmitted separately for ownership checks by the following seven resources (resources 5-11). The ownership check may also be performed by sending an internal query to the ledger storage system 152, and may include a simple comparison of whether the alleged owner of the virtual banknote matches the listed owners of the virtual banknotes. The SFIOI address space is added to the queue of the following seven resources (resources 12-18). Using a different set of resources for the response can maximize the efficiency of the resources used for processing in SGS156. In S614C, the response to the ownership check in S614B is received by each of the following seven resources (resources 12-18), which may, for example, identify whether the current owner matches or does not match. Even a single bit may be used to indicate a match or mismatch 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 currency to be checked in the packet payload or the resource that made the request in S614B. In S614D, it is checked whether all the results of the ownership queries in S614B match. If all the ownership queries in S614B match according to the results received in S614C (S614D=Yes), then in S614E, resources 12 through 18 are incremented and the address space is added to the queue for the next resource (i.e., resource #19). If any of the ownership queries in S614B do not match (S614D=No), then in S614F, the packet is removed from the address space. In S616B, resource 19 checks for any stored instructions from the actual owner. This check may be performed by sending a query to the main memory system 153 for any of the virtual currencies to find out the actual owner and confirm whether any processing instructions have been specified. For example, an owner may specify that the virtual currency should not be transferred from their possession without using multi-factor authentication, without confirming the transfer via telephone, email, or another mechanism, or without performing any other 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 virtual banknotes may be stored in the ledger storage system 152, or in another system (not shown) provided in parallel with the ledger storage system 152, which stores cursory information regarding special instructions for processing virtual banknotes owned by the owner. In S618B, resource 20 initiates anti-spoofing measures if instructed by the response to the query from resource 19 from S616B. Anti-spoofing measures may be performed by initiating a multi-factor authentication check and then having another resource (not shown in Figure 6A) await authentication. After the anti-spoofing check, the resource(s) that performed the anti-spoofing check increments its address space and adds it to the queue(s) for the next resource(s). In S620B, the next resource (i.e., resource 21) checks the type of the SFIOI. This type may be specified by the fields required in the SFIOI format, e.g., a full byte, or 2 or 3 bits. Since the tracking described herein can be extended to many other uses, the “type” field may contain a full byte so that, even though relatively few types are used for tracking digital currencies as described herein, ultimately up to 256 different types can be specified using the same format. In S620C, resource 21 is incremented, and the packet’s address space is added to the queue of the next resource that will actually process the SFIOI. The number of resources processing the SFIOI may vary based on how many different actions can be performed based on the SFIOI. In 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 the main memory system 153, and confirming a transfer instruction to the source, or simply confirming an ownership inquiry to the source.Ownership verification may be performed by default without further verification. This is because ownership verification has been performed in S614B and the SFIOI has already responded, or the SFIOI has been deleted if one or more ownership verification results are negative. Other types of processing may include updating processing instructions or transferring ownership records to reflect that the owner has moved specific virtual currency between storage accounts or devices.

[0081] In the method for aggregated security checks in the central system's memory system shown in Figure 6B, the method may be performed in or by the main memory system 153 in the AI ​​and analysis system 154, or by the AI ​​and analysis system 154, or in another element of the central system 150. This method may be performed to check patterns of the initiating party and / or trading partner in all transfers, for example, to verify whether suspicious funds have been withdrawn from or added to an account. Since suspicion may be relative to people, places, and times, different thresholds and analyses may be applied to look for different patterns. In S630, an update to the record of transferred virtual currency is received. The record update may be stored in both the virtual currency history and the initiating party and trading partner history. Different algorithms may be applied to the virtual currency history and the initiating party history to check for different pattern characteristics. In S631, the aggregate amounts of the transferee and transferor for the most recent period are determined. The total amount may be the sum of transfers between the transfer destination and the transfer source over the past 60 seconds, 5 minutes, 30 minutes, 1 hour, 24 hours, and / or other periods. In S632, the total amount is compared to a threshold to determine if it is higher than the threshold. If one or more total amounts are higher than the corresponding threshold (S632=Yes), in S633, the corresponding parties may be added to the blacklist or graylist. If no total amounts are higher than the corresponding threshold (S632=No), additional checks may be performed. In S634, another check may be related to a timing trigger or a location trigger. For example, a transfer from a party to an Internet Protocol address in a dangerous area may trigger addition to the blacklist or graylist. As another example, a transfer from a party at 2 a.m. local time may trigger addition to the blacklist or graylist. In S3635, if the timing or location triggers (S634=Yes), the party is added to the blacklist or graylist; otherwise, the process in Figure 6B ends.

[0082] The method by which the Security Gateway System (SGS) in Figure 6C processes received instructions or queries is an example of how different graphics cards or groups of processors within one or more graphics cards can be assigned to different tasks within the Security Gateway System, with the method in Figure 6A divided into four sections. A graphics card may contain a large number of processors operating nearly in parallel. Tasks performed in the Security Gateway System are inherently parallel to different incoming packets. Graphics cards can be used as long as the processing they provide is adequately applicable to the SFIOI. In Figure 6C, the processors are divided into four groups. One of the simplest ways to ensure efficient processing is, if not the simplest, that all processors do not have to wait specifically for a response to a query they sent, and do not have to route the response back to the specific processor that sent the query; therefore, processing in each group may end when the query is sent to another internal system. Using a status space can ensure that each address space is processed efficiently. As an example, 3200 processors in a graphics card may be divided into four groups of 800 processors each. These processors may process 800 address spaces at once. The parallel processing aspect of leveraging graphics cards arises from applying groups to different groups of address spaces simultaneously. For example, the first group can process address spaces 2401-3200, the second group 1601-2400, the third group 801-1600, and the fourth group 001-800. Each group's processors can increment 800 address spaces at once once their current processing is complete. Naturally, the processor groups do not all need to have the same number of processors; for example, a task performed by one group may be faster than a task performed by another group.Rather, in order to increase the relative continuity in 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 contains more processors than the second processor group running one or more second task sets.

[0083] In the memory configuration of the security gateway system (SGS) that processes received instructions or queries, as shown in Figure 6D, the security gateway system includes various electronic components, including an SFIOI memory 6561 and a status memory 6562 that is physically separated from the SFIOI memory 6561. The SFIOI memory is intended to store SFIOIs on a one-to-one basis, such as one SFIOI per 512-byte page, or one SFIOI per multiples or fractions of 512-byte pages. The status memory 6562 is intended to store status updates when a processor, core, or thread processes an SFIOI in the SFIOI memory. One aspect of the technical challenges addressed in this disclosure is the program / erase cycles of the SGS 156. Status updates may require writing two or more status updates to the status memory 6562 for each SFIOI written to the SFIOI memory 6561. However, since writes to status memory 6562 may be limited to one byte or one word per instance, each potential status update may be written to a different byte or word in status memory 6562. Thus, a thread can determine whether a prerequisite process has been performed by first reading status memory 6562 and referring to the status of any already updated bytes or words. As a simple example, thread #7 can check the status of byte #6 updated by thread #6, and if its status indicates that thread #6 has processed the SFIOI, thread #7 can read the portion of the SFIOI that thread #7 is processing. Once thread #7 has finished processing the SFIOI, it can update byte #7 in status memory to indicate that thread #7 has finished processing the SFIOI.SFIOI memory 6561 can contain multiple memories, up to the 40000th SFIOI memory 6561-3, including the first SFIOI memory 6561-1, the second SFIOI memory 6561-2, ..., and the 40000th SFIOI memory 6561-3. Status memory 6562 can contain multiple memories, up to the 40000th status memory 6562-1, the second status memory 6562-2, ..., and the 40000th status memory 6562-3. Each processor, core, or thread first checks the corresponding status in status memory 6562, and then performs specific processing on the SFIOI in SFIOI memory 6561 before updating the corresponding status in status memory 6562. SFIOI memory 6561 may be the first bay of the SGS156, and may, for example, be allocated to incoming SFIOIs per minute. The second bay of the SGS156 may be substantially identical to the first bay and may be allocated the SFIOIs that will arrive in the next minute at this exemplary timing. The bay cycle may be performed periodically, such as every 5, 10, 15, 30, or 60 minutes. Furthermore, the bay may be allocated an SFIOS for processing within a fixed time frame, although this is likely not the best embodiment. Rather, load balancing or other types of embodiments may be dynamically implemented so that the SFIOI memory and status memory are augmented with additional physical resources as needed. In Figure 6D, the status memory 6562 is physically separated from the SFIOI memory 6561, and a processor, core, or thread moves back and forth between the two during processing. However, each processor, core, or thread processes only a specific portion of the SFIOI in the SFIOI memory 6561, rather than the entire SFIOI, and operates by checking and writing only individual bytes or words in the status memory 6562.

[0084] In the memory configuration for the security gateway system (SGS) that processes received SFIOIs in Figure 6E, memory management includes using an integrated SFIOI memory and status memory 6563 for memory space for SFIOIs and memory space for status in the SGS156. In other words, the integrated SFIOI memory and status memory 6563 includes a first area for storing SFIOIs and a second area used to track the processing status of SFIOIs. 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 by a separate 64-bit word, the number of VNs specified in the SFIOI may be limited to 7 or 13, or to 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 uses in processing by the processor, core, or thread of the SGS156. For example, if a 512-byte page can store up to 64 64-bit words, and 32 of these 64-bit words are reserved for SFIOIs, then the memory starting from the 33rd word line of the integrated SFIOI and status memory 6563 may be used for the status. The status may be updated by writing at the byte level or at the word level. For example, since the default status of the status space may be set to 0 (zero) and updated to 1 (1) in a status update, bytes or words of the status space in the integrated SFIOI and status memory 6563 may be written to 1 at one or more bit positions when the corresponding processing is complete. Therefore, during SFIOI processing, a processor, core, or thread may read the status from the 33rd word line onward of the integrated SFIOI and status memory 6563 before processing a particular part of the SFIOI and then updating another part of the status space. The processor, core, or thread may organize the memory pages of the SGS156 to efficiently use them so that individual physical memory pages are logically partitioned.Naturally, the partition does not have to be exactly half 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. As is obvious, the most efficient way to process SFIOIs might be to use a predefined memory unit that is the same size as or larger than each SFIOI and provides the memory space required for status updates of 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 SFIOI format may be set to the size of the addressable memory space, such as a 512-byte page of flash memory, and the last few words 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 and is used for tracking and updating the status as described herein.

[0086] The example SFIOI format in Figure 6F shows 64 64-bit words, but each line in Figure 6F contains, for example, 64 bytes 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 designated as the owner in each instance of the SFIOI, etc., or to the transaction requester or transaction requester ID (requester_ID) in a 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 transaction counterparty or transaction counterparty ID (counterparty_ID) in a transaction, and the second party ID does not need to be entered if the SFIOI is not for a transaction, etc. The VN ID may include a first byte for the country / region code, a second byte for the face value if the face value is 256 or less, and a further six bytes for the actual unique identifier of the face value issued in that country / region. Because processing of SFIOIs 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 processing the type of processing requested / instructed by the SFIOI. Although not shown, the Notifier Type field may indicate whether the notification is made by the transaction requester or the counterparty, if either party can make the notification. The Notifier Type may also indicate whether the Notifier is a system trusted by Central System 150 to make notifications as both a transaction requester and a counterparty, such as a private bank supervised and regulated by the central bank providing Central System 150. The exemplary format size of an SFIOI is 512 bytes.The SFIOI format allows a new field to be started every 64 bits, so that it can be uniformly read as a 64-bit word line on a 64-bit processor. This means each field can contain 64 bits, as long as the data within it can be specified as meaningful data of 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 VN_info transmitted to the central system 150. VN_info may include a unique identifier and a face value, and may be provided as a number larger than the 8 bytes shown in Figure 6D. VN_info may also include the creation date and / or creation location. VN_info may be an encrypted version of the unique identifier extracted from the metadata field of the virtual banknote, or provided with the virtual banknote from the time the central system 150 first issued the virtual banknote, but provided independently of the virtual banknote, or may include an encrypted version of the unique identifier. The central system 150 can decrypt the encrypted unique identifier.

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

[0089] The trailing field of the SFIOI is empty and reserved for status updates at the SGS156. 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. As long as the number of allowed VNs in the packet remains below the maximum limit, a 256-byte format for the SFIOI may also be appropriate for handling processing at the SGS156. However, this disclosure primarily uses the 512-byte format as an example. Naturally, other sizes for the SFIOI format may be logically appropriate, such as when the SGS156 uses other types of predefined memory sizes or arrangements. For example, SFIOIs may be allowed to have different sizes and may be tracked sequentially when received at the SGS156. However, an arbitrary (ad-hoc) size for an SFIOI is not optimal, and the best way to implement such an SFIOI is to specify a format that utilizes standard predefined memory sizes for ubiquitous memory types such as network packetization and flash memory, and standard instruction sizes for modern processors, such as using 64-bit words.

[0090] In some embodiments, another field in 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 denominations are not issued for virtual currency, or if small denominations are not tracked in the central system, the SFIOI may specify the amount of change to be deposited and / or withdrawn from the accounts corresponding to the parties, depending on whether the SFIOI specifies a transfer in the transaction. Thus, the format of the SFIOI can accommodate transfers that include denominations not issued as virtual currency or denominations not tracked in the central system. As an example, if a transaction involves parties paying $50 for goods and expecting 65 cents in change, the change can be automatically deposited into the parties' associated account and withdrawn from the seller's associated account. The associated account is managed outside the central system and is therefore managed by a financial institution that provides the account as a service. The central system only needs to notify the ID management system 151 or another node managing the parties' ID records to initiate the withdrawal or deposit with the financial institution. In some embodiments, parties registered with the central system may be required to have a relevant account, but the government and / or central bank may encourage account opening among those who do not have such an account (for example, by providing incentives to financial institutions). For example, the government and / or central bank may make payments to financial institutions to eliminate minimum balance or spending requirements, or may provide something like insurance against losses that financial institutions might incur in the event of fraudulent activity, etc. Alternatively, the central system 150 may store information on the accounts of third parties (e.g., banks) of the senders and recipients of virtual currency, and deposit and / or withdraw the exchange amount agreed upon in notifications from the senders and recipients into and / or from the third-party accounts. In some embodiments, the central system 150 may use a universal electronic wallet program as the default for deposits and withdrawals to and from senders and recipients.However, the sender and recipient may update the central system 150 to specify a third-party account to be used instead of the Universal Electronic Wallet Program.

[0091] One advantage of allowing ample room for modification in the requirements of a standardized 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” in the SFIOI type field, a private system could use the same type of format to track other types of transactions, such as mortgages and other types of loans, real estate transfers, automobiles, etc.

[0092] The format of an SFIOI may differ from that taught herein, but in accordance with the intent and teachings of this specification. For example, the order of fields may differ, more or fewer fields may be specified in the format than shown, and blank fields or spaces may differ, as long as the format is clear from the outset. This will enable parties around the world to appropriately program end-user devices, intermediate user devices, and central system devices accordingly, regardless of the SFIOI format.

[0093] Furthermore, the SFIOI format shown in Figure 6F is independent of the virtual currency format. As long as the virtual currency has a unique identifier, it can be tracked using an SFIOI format like the one in Figure 6F.

[0094] Financial institutions and other types of organizations may provide the ability to issue party IDs as described herein. For example, financial institutions may be provided with four- or five-digit unique identifiers, such that the unique identifier is described in two or three bytes. Financial institutions may use that unique identifier as the first two or three bytes of the entire identifier assigned as a party ID. The party ID may be three, four, or five bytes for the party and two or three bytes for the financial institution, etc. Thus, a central system does not need to store the identity information of the parties and instead can rely on financial institutions to know who a party ID corresponds to. At least in the United States, if a financial institution stores party IDs and a government agency wants to know who a party ID corresponds to, it only needs to 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, provided that their customer bases include customers who actually trust that such entities will protect privacy to the extent possible or reasonable. For example, a central system could provide a bank with a unique ID for a party without requiring the bank to transmit an account identifier, and the bank could then determine which associated account to deposit the virtual currency into based on the unique ID of the party.

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

[0096] In some embodiments, a party trusted by the central system 150 may correspond to a specific party ID, which can be used to omit some forms of security processing. In other embodiments, a trusted party may have a dedicated communication link to the central system 150. In some embodiments, a large entity providing its own secure environment to customers (e.g., Apple, Google, JP Morgan) may be permitted to co-locate one or more servers with the data center used by the central system 150. This allows customers to send SFIOIs within the entity's secure environment and input unpackaged SFIOIs directly into the SGS 156.

[0097] In this specification, blockchain is not necessarily used to implement digital currencies. However, the use of blockchain is not specifically prohibited and may be useful in certain situations. For example, recording transactions involving a large amount of virtual currency on a blockchain, each of which has its own distributed ledger in a group of cooperating central banks, may be useful in resolving disagreements among central banks regarding the details of previous transactions. A group of users of a particular digital currency may agree to record transactions involving virtual currency on a blockchain. Therefore, the use of blockchain is not specifically prohibited or incompatible, even if the central system described herein is not part of a blockchain specifically implementing a digital currency.

[0098] Furthermore, the use of encryption is described herein for specific embodiments and purposes. However, the use of encryption mechanisms such as SSL can be assumed in most, or perhaps all, communications with respect to the transmission of virtual currency. To the extent that other encryption mechanisms may be used for processing virtual currency, the teachings herein should not be considered particularly inconsistent with the use of specific encryption in appropriate circumstances.

[0099] While centralized tracking of digital currencies has been described in relation to virtual banknotes, the teachings herein are not limited to application to virtual banknotes or any specific digital currency authenticated by a government or issued by or on behalf of a central bank. Rather, various aspects of the teachings herein can be implemented for other forms of digital currencies, including stablecoins and other forms of cryptocurrencies, and similarly for other forms of digital tokens used as a medium of value, including digital currencies that do not share one or more of the characteristics of virtual banknotes as described herein.

[0100] While the centralized tracking of digital currencies has been described with reference to several exemplary embodiments, it should be understood that the terms used are descriptive and illustrative, not limiting. Modifications can be made to the appended claims, as currently described and as amended, without departing from the scope and spirit of the centralized tracking of digital currencies. While the centralized tracking of digital currencies has been described with reference to specific means, materials, and embodiments, it is not intended to be limited to those specifically disclosed. Rather, the centralized tracking of digital currencies extends to all functionally equivalent structures, methods, and uses, such as those found within the appended claims.

[0101] This specification describes components and functions that may be implemented in specific embodiments, with reference to certain standards and protocols, but this disclosure is not limited to such standards and protocols. For example, since the legal framework for introducing digital currencies is not yet in place in the United States or Europe, standards compliant with such legal criteria may be developed in the future and are expected to implement one or more of the mechanisms described herein.

[0102] In the detailed description above, various features may be grouped together or described in a single embodiment for the purpose of simplifying the disclosure. This disclosure is not intended to be interpreted as reflecting an intention that the claimed embodiments require more features than those expressly described in each claim. Rather, as reflected in the following claims, the inventive subject matter may be directed toward fewer than all of the features of any of the disclosed embodiments. Accordingly, the following claims are incorporated into the detailed description in a self-contained manner, defining the subject matter for which each claim is separately claimed.

[0103] The foregoing description of the disclosed embodiments is provided so that anyone skilled in the art can implement the concepts described herein. Thus, the above disclosed subject matter is considered illustrative and not restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other embodiments that fall within the original intent and scope of this disclosure. Accordingly, the scope of this disclosure shall be determined, to the maximum extent permitted by law, by the most broadly permissible interpretation of the following claims and their equivalents, and shall not be limited or restricted by the foregoing detailed description.

Claims

1. A security gateway system that interfaces 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 the packets stored in the memory, wherein the packets are required to conform to a predefined format that specifies requirements for fields at predetermined relative positions of the payload of an acceptable packet, and each algorithm processes the packets stored in the memory by checking whether the data of the fields at predetermined relative positions of the payload of the packet conforms to the format. A main memory system separated from the security gateway system, which stores records of all instances of a digital asset to be tracked for a centralized tracking system, and which receives updates to the records when an acceptable packet stored in the memory passes through processing by at least one algorithm, Equipped with, The centralized tracking system is configured to update the record of the instance of the tracked digital asset listed in the acceptable packet and transfer ownership of the instance of the tracked digital asset listed in the acceptable packet if the data from the specified field at a predetermined relative position in the payload of the acceptable packet indicates that the record of the instance of the tracked digital asset listed in the acceptable packet should be updated, after the at least one algorithm has processed the acceptable packet for compliance with the format, The centralized tracking system is configured to, after at least one algorithm has processed the acceptable packet for compliance with the format, check data from a designated field at a predetermined relative position of the payload of the acceptable packet, and if the data from the designated field at the predetermined relative position of the payload of the acceptable packet indicates that ownership of an instance of the tracked digital asset listed in the acceptable packet has been pre-confirmed without transferring ownership of the tracked digital asset listed in the acceptable packet, then to pre-confirm ownership of an 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 system.

2. A centralized tracking system according to claim 1, comprising a ledger storage system that is blocked by the security gateway system from being directly accessible from the public, the ledger storage system storing a record of the current ownership of instances of the tracked digital assets, and verifying whether the ownership listed in the packets that have passed through processing by the at least one algorithm is correct for the tracked digital assets listed in the packets.

3. The centralized tracking system according to claim 2, wherein the ledger storage system is configured to pre-verify ownership of each tracked digital asset contained in the packet that has passed through processing by the at least one algorithm.

4. The centralized tracking system according to claim 1, further comprising an identifier management system for storing identification numbers of parties, wherein at least a portion of the identification numbers are generated by a third-party system for parties who are anonymous to the centralized tracking system.

5. The centralized tracking system according to claim 1, wherein the at least one algorithm includes a plurality of algorithms that transmit queries outside the security gateway system to inside the centralized tracking system.

6. The packets received by the security gateway system are filtered to ensure they conform to the format. The format sets the size requirements for the packet, the format requirements for the party identifier included in the packet, and the format requirements for the unique identifier of the instance of the tracked digital asset included in the packet. The centralized tracking system according to claim 1.

7. The at least one algorithm includes a plurality of algorithms, The centralized tracking system according to claim 1, wherein the packets are stored in a memory unit of uniform size within the memory of the security gateway system.

8. Interfaceing a security gateway system of a centralized tracking system with the public via the internet, wherein the security gateway system comprises 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, wherein the packets are required to conform to a predefined format that specifies requirements for fields at predetermined relative positions of the payload of an acceptable packet, and each algorithm processes the packet by checking whether the data of the fields at predetermined relative positions of the payload of the packet conforms to the format, By positioning the main memory system separately from the security gateway system, the security gateway system isolates the main memory system from the public. For the aforementioned centralized tracking system, records of all instances of the digital assets to be tracked are stored in the main memory system, When an acceptable packet stored in the memory passes through processing by the at least one algorithm, the main memory system receives an update to the record. After the at least one algorithm processes the acceptable packet for compliance with the format, it checks the data from a specified field at a predetermined relative position in the payload of the acceptable packet, and if the data from the specified field at the predetermined relative position in the payload of the acceptable packet indicates that it updates the record of the instance of the tracked digital asset listed in the acceptable packet, it updates the record of the instance of the tracked digital asset listed in the acceptable packet and transfers ownership of the instance of the tracked digital asset listed in the acceptable packet. After the at least one algorithm processes the acceptable packet for compliance with the format, it checks the data from a specified field at a predetermined relative position in the payload of the acceptable packet, and if the data from the specified field at the predetermined relative position in the payload of the acceptable packet indicates that ownership of an instance of the tracked digital asset listed in the acceptable packet has been pre-confirmed without transferring ownership of the tracked digital asset listed in the acceptable packet, then the ownership of an instance of the tracked digital asset listed in the acceptable packet has been pre-confirmed without transferring ownership of the tracked digital asset listed in the acceptable packet, A centralized tracking method that includes this.

9. The security gateway system blocks direct access to the ledger storage system from the public, The ledger storage system stores a record of the current ownership of the instance of the digital asset being tracked. The process involves verifying whether the ownership listed in the packet that has passed through processing by at least one algorithm is correct for each of the digital assets to be tracked that are listed in the packet, The centralized tracking method according to claim 8, further comprising:

10. The centralized tracking method according to claim 9, further comprising the ledger storage system pre-verifying the ownership of each of the traceable digital assets contained in the packet that has passed through processing by the at least one algorithm.

11. A centralized tracking method according to claim 8, comprising storing the identification numbers of parties in an identifier management system, further comprising storing the identification numbers of parties, at least a portion of which are generated by a third-party system for parties who are anonymous to the centralized tracking system.

12. The at least one algorithm includes a plurality of algorithms, The centralized tracking method according to claim 8, further comprising using the plurality of algorithms in the security gateway system to send a query outside the security gateway system but inside the centralized tracking system.

13. The centralized tracking method according to claim 8, further comprising filtering the packets received by the security gateway system to ensure they conform to the format, wherein the format sets a size requirement for the packets, a format requirement for the party identifiers contained in the packets, and a format requirement for the unique identifiers of the instances of the digital assets being tracked contained in the packets.

14. The at least one algorithm includes a plurality of algorithms, The centralized tracking method according to claim 8, wherein the packets are stored in a memory unit of uniform size within the memory of the security gateway system.

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

Images