Digital currency security mechanisms

Abstract

The centralized tracking system includes a security gateway system and a main memory system. The security gateway system interfaces with the public over the Internet at an Internet Protocol address and includes a memory for storing packets received from the public over the Internet, and a processor for executing a number of algorithms for imposing safety checks on packets received from the public. The main memory system is shielded from the public by the security gateway system and stores records for the centralized tracking system and receives updates to the records from the security gateway system when instructions from the public pass the safety checks.

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 the entire contents thereof herein by reference.

Background Art

[0002] National digital currencies (NDCs) may be useful for complementing or replacing 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 security, 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 ways to realistically and securely implement 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] It is a diagram showing an overview of the life cycle of NDC. [Figure 1B]This is a diagram showing the NDC tracking. [Figure 1C] This diagram shows the central system (hereinafter sometimes abbreviated as "CS") for tracking NDCs. [Figure 2A] This diagram shows how to process short, formatted inquiries and instructions (hereinafter referred to as "SFIOI") for NDC. [Figure 2B] This diagram shows how to handle SFIOIs. [Figure 2C] This diagram shows how to handle SFIOIs. [Figure 2D] This diagram shows how to handle SFIOIs. [Figure 2E] This diagram shows how to handle SFIOIs. [Figure 2F] This diagram shows how to handle SFIOIs. [Figure 3A] This diagram shows the cloud-based transaction flow for NDC. [Figure 3B] This diagram shows a system for storing records of NDC virtual notes (sometimes abbreviated as "VN"). [Figure 4A] This diagram shows how the security gateway system processes received SFIOIs. [Figure 4B] This diagram shows the processing configuration of the security gateway system. [Figure 4C] This diagram shows how the security gateway system processes received SFIOIs. [Figure 4D] This diagram shows the security check method for the central system's memory system. [Figure 4E] This diagram shows the security check method for the central system's memory system. [Figure 5A] This diagram shows the memory configuration of the security gateway system that processes received SFIOIs. [Figure 5B] This diagram shows the memory configuration of the security gateway system that processes received SFIOIs. [Figure 5C] This diagram shows the memory configuration of the security gateway system that processes received SFIOIs. [Figure 5D] This diagram shows the memory configuration of the security gateway system that processes received SFIOIs. [Figure 6] This figure shows an example of the SFIOI format. [Figure 7A] This diagram shows the placement of internet network routers. [Figure 7B] This diagram shows the placement of internet network routers. [Figure 7C] This diagram shows how packets are filtered before they reach the destination address of the Internet Protocol. [Figure 7D] This diagram shows a communication system for filtering packets before they reach the destination address of an Internet Protocol. [Figure 7E] This diagram shows how a security gateway system distributes safety checks for packets addressed to destination addresses of Internet protocols. [Figure 7F] This diagram shows how a security gateway system distributes safety checks for packets addressed to destination addresses of Internet protocols. [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 provided to give 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, operating methods and manufacturing methods 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 the purpose of describing specific embodiments only, and are not intended to limit them. 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] If centralized tracking is used to implement a nation's digital currency (NDC), many security aspects must be addressed. The central system tracking the NDC must be an interface with the public and must be kept secure from all conceivable forms of threats. In the technological society, it is widely believed that nothing connected to the public via the internet is secure. In other words, the central system must be accessible to any individual worldwide with internet access, but it must be able to filter or deny all conceivable threats posed by any individual worldwide with internet access. One aspect of security that could serve as a starting point for challenging this idea is for the government to define what is acceptable in the central system and to take measures to block and exclude anything that falls outside of that defined acceptable category.

[0007] In the NDC lifecycle overview shown in Figure 1A, virtual currency (VN) is transferred between a central system 150 and electronic communication devices (ECDs) controlled by the parties. In step A, after the creation of virtual currency, it is transferred, for example, by initially allocating it to financial institutions. Each NDC virtual currency may be a defined dataset, each assigned a unique identification (ID), denomination, and source of the virtual currency. However, other information may also be included. The central system 150 and any other central systems described herein are centralized tracking systems. Subsequently, in steps B, C, D, and E, the virtual currency is transferred between multiple electronic communication devices (devices 101, 102, 103, and 104) controlled by different parties. Then, in step F, the virtual currency is returned to the central system 150 for purposes such as temporary or permanent redemption. The devices used for communicating virtual currency (e.g., devices 101, 102, 103, and 104) are electronic communication devices such as computers and mobile phones. The virtual currency may be packetized and communicated via a packet-switched network that switches packets according to the Transmission Control Protocol / Internet Protocol (TCP-IP) and / or User Datagram Protocol (UDP-IP). The central system 150 in Figure 1A can create, distribute, track, and / or redeem virtual currency.

[0008] In the NDC tracking shown in Figure 1B, the transaction requester and / or counterparty transmit short, formatted inquiries and instructions (SFIOIs) to the central system 150 to inquire about ownership of virtual currency or to give instructions for transferring ownership of virtual currency. For example, a counterparty can pre-verify to the central system 150 that the transaction requester owns the virtual currency, and the central system 150 can transfer the virtual currency based on the instructions in the SFIOI. The format of the SFIOI is defined by the source of the virtual currency. Using a predefined format ensures compliance for electronic communication equipment used by the public, and SFIOI packets may be pre-filtered before the packets are received at the Internet Protocol address of the security gateway system 156, or post-filtered by an algorithm executed by the security gateway system 156 to ensure that the packets conform to the predefined format.

[0009] The central system 150 can generate a multi-factor push notification and send it to the electronic communication device to confirm a transfer or inquiry that is assumed to be initiated by the electronic communication device. The electronic communication device that initiates a transaction or transfer notification is assumed to be in the hands of the transaction requester so that the transaction requester can reasonably predict multi-factor authentication in real time. Since the notification can be provided to the communication address of the record owner in the record, the transaction requester can receive a separate notification from the central system 150 only if the transaction requester is the record owner, in order to provide or confirm consent for the transfer of virtual currency. In some embodiments, when the transaction requester provides the verification information that uniquely identifies the transaction requester to the transaction requester, etc., the counterparty can verify with the central system that the transaction requester is the owner of the virtual currency without the central system confirming to the transaction requester that the virtual currency is transferred. Since the risk that any particular party can infer that they are the record owner of any particular virtual currency is extremely low, and the central system 150 can impose severe penalties for inaccurate SFIOI, by presenting the verification information to the central system 150, the central system 150 can consider that the transaction requester has consented to the transfer of the virtual currency.

[0010] The SFIOI may be sent to a predetermined host name or IP address of the central system 150. The transfer of virtual currency may be reported to the central system 150 by one or both of the transaction requesters at the time of sending and receiving the virtual currency.

[0011] The gray list may be maintained for various reasons regarding virtual currency, including the frequency of transfers by the transaction requester, the frequency of activities by the transaction requester (e.g., processing a large number of virtual currencies), and many other reasons. The gray list may also be maintained for parties such as transaction requesters who are subject to special monitoring. In some embodiments, after transferring the ownership of virtual currency, the transaction requester may be prohibited from reacquiring the ownership of the virtual currency while a predetermined minimum number of different owners, such as two or five, are involved, or within a predetermined time frame such as 48 hours.

[0012] One way to ensure that the requirements for the proper format of the SFIOI are met is to use an authenticated currency reader application and / or an electronic wallet program. Instances of the authenticated currency reader application and / or the electronic wallet program may be provided with unique identifiers that are maintained in association with the unique identifier of the party on the records of the central system 150.

[0013] In the central system that tracks the NDC shown in FIG. 1C, a security gateway system 156 is used as an interface between the public and the other elements of the central system 150. The central system 150 includes a security gateway system 156, an ID management system 151 (identifier management system), a ledger storage system (hereinafter sometimes abbreviated as "LSS") 152, a main memory system 153, an artificial intelligence and analysis system 154, and a backup memory system 155. The arrows in FIG. 1C indicate that, in some cases, the communication between the elements of the central system 150 may be restricted to almost or completely one-way communication. In an embodiment based on FIG. 1C, at least the communication from the public may be restricted to the security gateway system 156. An intermediary service provider having a large customer base that wishes to send encrypted communication may be permitted access to a proximity facility adjacent to the security gateway system 156, whereby appropriate encryption is provided to the endpoint of the proximity facility and then decrypted and supplied directly to the security gateway system 156.

[0014] The ID management system 151 may be used to store and update records of parties permitted to use the NDC tracked by the central system 150.

[0015] The ledger storage system 152 is used to maintain records of the current ownership of all virtual banknotes tracked by the central system 150. The ledger storage system 152 is used to respond to ownership inquiries from the public once the inquiry in the SFIOI has passed a security check in the security gateway system 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 can be used to quickly track and verify ownership of virtual banknotes by storing records of virtual banknotes hierarchically in alphabetical, numerical, or alphanumeric order. In this way, records of virtual banknotes can be retrieved using the unique identifier of the virtual banknote. The records in the ledger storage system 152 may include only the most recent owner of the virtual banknote. Using the ledger storage system 152, the central system 153 stores records of the current ownership of each instance of the tracked digital asset (e.g., virtual banknotes of NDCs). In some embodiments, the security gateway system 156 may, in all or almost all cases, verify the ownership of the virtual banknotes listed in the SFIOI with the ledger storage system 152, insofar as verifying that the sender of the SFIOI has accurate knowledge of the ownership of all virtual banknotes listed in the SFIOI can always or almost always be an important safety check for the SFIOI.

[0016] The main memory system 153 includes one or more databases, solid-state storage (SSDs), and / or other forms of memory suitable for storing millions, billions, or even trillions of data items, such as unique identifiers for virtual currency, electronic wallet programs, currency reader programs, parties, and electronic communication devices. The artificial intelligence and analysis system 154 applies artificial intelligence and analysis to the data items in the main memory system 153. For example, the artificial intelligence and analysis system 154 may be configured to retrieve and analyze records of virtual currency from the data items stored in the main memory system 153. The backup memory system 155 stores backups of the records in the main memory system 153. One or more backup memory systems 155 may be provided for the main memory system 153, and one or more backup systems (not shown) may be provided for the ledger storage system 152. The security gateway system 156 serves as the sole interface to the public for the central system 150 in Figure 1C.

[0017] The central system 150 provides numerous internal security measures. For example, the ledger storage system 152 is effectively isolated from, or at least can be isolated from, the ID management system 151. The main memory system 153 and the ID management system 151 can communicate via one-way communication with no interaction or minimal interaction. The artificial intelligence and analysis system 154 may be provided with access only to the main memory system 153, completely isolated from the public, and available only to approved government officials and approved researchers. The backup memory system 155 may also be completely isolated from the public during normal operation, but when the backup memory system 155 is on, updates to the main memory system 153 may be provided to the backup memory system 155, and interactions between the main memory system 153 and other elements of the central system 150 may be switched to the backup memory system 155. The main memory system 153 and / or the backup memory system 155 may be physically protected, for example, by being located underground and implemented in a civilian data center shielded from electromagnetic pulses (EMP). Updates to the main memory system 153 and the backup memory system 155 may be limited to updates performed locally, and the main memory system 153 and the backup memory system 155 may be completely isolated from the public insofar as they can be used to store records relating to virtual currency based on instructions provided via SFIOI processed by the security gateway system 156.

[0018] The number of virtual banknotes (VNs) that can be specified in an SFIOI may be limited to, for example, up to 9. The SFIOI format may also be limited to a specific size, such as 512 bytes, for the SFIOI data size. Furthermore, the security gateway system 156 can implement anti-spoofing measures through outgoing communications. For example, the security gateway system 156 may initiate the generation of a short code to be sent along with a multi-factor authentication check used to verify the transfer instruction. The short code may be sent with the message to the owner's recorded communication address, or it may be displayed in a pop-up window on the device corresponding to the owner's recorded communication address. The owner may be asked to manually reply with a short code, such as two characters, to verify the transfer. In this way, even if a spoofer learns of the transmission of an anti-spoofing message and attempts to spoof a response to it, they may be blocked if they cannot guess the characters dynamically generated and transmitted by the security gateway system 156.

[0019] The security gateway system 156 can provide access to law enforcement agencies, post offices, banks and similar entity systems, as well as other government agencies such as the offices of secretaries of states, via dedicated and / or otherwise secure lines or communication channels, or via one or more call centers. The security gateway system 156 functions as a controlled access point for the central system 150, having only publicly exposed Internet Protocol addresses, and restricts all access to other elements of the central system 150 to prevent direct public access to those elements. The security gateway system 156 also functions to isolate the main memory system 153 and other components of the central system 150 from the public. Communications that do not conform to the specific format of SFIOI may be discarded without exception.

[0020] The security gateway system 156 can run complex software that systematically performs comprehensive safety checks on SFIOIs received by the central system 150. Software capable of performing comprehensive safety checks on the security gateway system 156 can quickly and efficiently process a vast number of appropriate SFIOIs and detect and remove others. A full set of flexible software subapplications 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 subapplication contains instructions for various algorithms, each performing a different task or multiple different tasks than other software subapplications. In other words, each software subapplication is unique and specialized for a different task compared to other software subapplications. A subapplication or core of a multicore processor does not execute or process the entire SFIOI packet; instead, the subapplication processes different parts of each packet. Software subapplications may be provided as software programs, or as pre-programmed, dedicated multicore processors that implement the software programs. Multiple types of software sub-applications may be provided as safety programs for the security gateway system 156, and can detect various types of corruption in SFIOIs so that corrupted SFIOIs are detected and not treated in the same way as non-corrupted SFIOIs.

[0021] Mandating a size of 512 bytes or other for packets conforming to the SFIOI format provides several types of security. For example, security gateway system 156 may check one field to ensure that the source ID of a virtual banknote corresponds to a provider of security gateway system 156. In another example, security gateway system 156 may check whether each virtual banknote specified in the SFIOI actually belongs to party #1, which is designated as the owner in the SFIOI. Security gateway system 156 may check to ensure that NULL fields are NULL, that header information such as the hop count is exactly as expected (e.g., 0), and that fields assigned to one or more virtual banknotes are as expected (for example, if the virtual banknote count (VN count) specifies that there is either an identified virtual banknote or no virtual banknote, then #8 and #9 will be NULL).

[0022] 32 bits (4 bytes) is more than sufficient to uniquely identify the U.S. population with a unique identifier for NDCs. 8 bits (1 byte) is more than sufficient to uniquely identify each country with a unique identifier for NDCs. 16 bits (2 bytes) is more than sufficient to uniquely identify each bank or similar entity within the U.S. with a unique identifier for NDCs. Unique party identifiers can be obtained through financial institutions such as banks and similar entities. The unique identifier of a bank or similar entity may be part of the unique identifier of a party. Unique party identifiers assigned by banks and similar entities may require more than 4 bytes, for example, 5 bytes, to accommodate banks and similar entities with very large customer bases exceeding 500,000. One advantage of banks or similar entities assigning unique party identifiers for NDCs is that party profiles can be maintained by the bank or similar entity rather than being maintained in the central system 150. Similarly, unique party identifiers for NDCs for individuals without bank accounts may be provided through local branches of the national postal service. Branches of the national postal service may be equipped with digital fingerprint pads that any individual with fingers can use to uniquely identify themselves. While the postal service retains fingerprints, names, and / or other information provided by parties who do not have bank accounts, it can use the digital fingerprint pads to verify existing identities and transmit unique party identities to the ID management system 151.

[0023] The processing environment of the security gateway system 156 can logically store a large number of pre-filtered SFIOIs in flash memory pages on a one-to-one basis, 24 hours a day, 365 days a year. A coordinated set of software safety subapplications may be executed on SFIOIs that reach the security gateway system 156 by a single multi-core processor within the security gateway system 156. Safety subapplications are executable on SFIOIs stored in flash memory pages in a first-in, first-out (FIFO) sequence. Each safety subapplication performs its assigned type of safety processing in the same manner for each SFIOI it is authorized to process. Processing on each page is highly coordinated by staggering the execution of safety subapplications on each page in a predetermined order until all safety subapplications have finished processing the SFIOIs on that page.

[0024] The security of the central system 150 can also be ensured by the security gateway system 156 rejecting incoming connection requests and accepting only individual packets. For example, the central system 150 may not accept any type of incoming connection request and may block such requests at network routers in the internet before they reach the central system 150. Additional safety mechanisms may be provided for the central system 150. For example, a public IP address may be provided for interfacing with the public without providing a domain for SFIOIs to reach the security gateway system 156. This completely prevents domain hijacking. To help prevent DoS attacks, the security gateway system 156 may receive and accept only individual non-sequential SFIOIs, such as UDP / IP packets, and may not accept or establish any incoming connections, such as those from TCP / IP packet sequences. Furthermore, the SFIOI requirement can set a maximum number of virtual currency (e.g., 9) that can be specified in a single SFIOI.

[0025] The SFIOI and the technology of the central system 150, including the security gateway system 156, can also be used for other purposes. For example, updating the travel records of passport holders, tracking real estate ownership and associated mortgages, automobile ownership and associated auto loans, ownership of digital entertainment and computer software, digital rights management (DRM) related to digital entertainment and computer software, and other information such as ownership of private company shares and related private company liabilities.

[0026] The security gateway system 156 of the central system 150 may include multiple nodes, each capable of processing tens of thousands (e.g., more than 40,000) of legitimate SFIOIs per minute. The safety sub-applications described herein may be configurable to process a unified format specifying data sizes other than 512 bytes or 256 bytes. Incoming SFIOIs may be stored in a sequential address space (i.e., flash memory pages) in uniform memory units such as 512 bytes. The last few words (e.g., 8 words) of each SFIOI are required to be NULL and may not be written to the flash memory pages.

[0027] A set of safety sub-applications performs different safety processing for each SFIOI received, as a condition for responding to any query or executing any instructions. Each safety sub-application processes only one or more specific bytes at the same relative position on each page in order to perform its function, and does not process bytes that are expected to contain no substantial data unless it is tasked with verifying that there is no substantial data.

[0028] The processing in the security gateway system 156 can be visualized as four-dimensional processing. A 512-byte page is a two-dimensional memory with 64 64-bit word lines. Each safety sub-application moves incrementally between the three-dimensional pages, processing the same byte or word on each page. The safety sub-applications are positioned with a time stagger as a fourth dimension to avoid collisions where they attempt to read or write from the same byte or word simultaneously. Furthermore, ownership checks for this fourth type of safety sub-application inevitably involve a timing offset. 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.

[0029] The status update system can use the same memory pages used to store the SFIOIs. The status update system is used to synchronize the safety sub-application when processing a large number of SFIOIs. NDC tracking may require a huge number of write cycles to the memory used to store the 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 SFIOIs. This means that if the status memory cell becomes exhausted, the entire memory may become exhausted more quickly. 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 page, and the corresponding memory cell in the memory page may be used for status updates instead of the essential data in the SFIOI. In other words, in the security gateway system 156, SFIOIs may be stored on a one-to-one basis in 512-byte pages, but for example, eight 64-bit NULL processing words at the end of the SFIOI may not be written to the page. Alternatively, the memory cell at the end of the page may be used to track the status of the safety sub-application, allowing it to check for the appropriate status word / byte before performing safety operations on the SFIOI and update different status words / bytes after performing safety operations. The status checking and status updating functions may be part of each safety sub-application. The status update system ensures that status updates can be written at substantially the same rate as the memory cells used to store the actual data of the SFIOI, thereby extending memory lifetime by at least 1000% compared to repeatedly writing status updates to the same byte 10 or more times for status updates during the processing of each SFIOI.

[0030] Even if avoiding hang-ups waiting for a response from ledger storage system 152 is the primary reason, or one of the primary reasons, that all safety processes are not linearly implemented by the standalone cores of a multicore processor, requiring proof that the person designated as the owner in each SFIOI is the actual owner can be an important safety measure. If owner-specific processing instructions, blacklists, and graylists are checked, other hang-ups may be required.

[0031] The 64 words of the 512-byte SFIOI in an IPv4 packet may include at least: 3 words (20 bytes + 4 NULL bytes) for the IP header, 9 words for virtual currency identification, 2 words for party identification, 1 word for virtual currency country / region identification, 1 word for VN number specification to be identified in the SFIOI, 1 word for SFIOI type (purpose) specification, and the last 8 words may be forced to NULL and may correspond to the memory space at the end of the page used for status updates during SFIOI processing. The remaining words may be NULL. A 24-core / 48-thread (e.g., AMD) processor is an example of a multi-core processor type suitable for security gateway system 156, and therefore the 8 processing words (64 bytes) provide enough bytes to be dedicated to updating each thread on a one-to-one basis or more when the processing implemented for the SFIOI by the thread is complete.

[0032] Hundreds or thousands of multicore processor and flash memory pairs may be uniformly installed in any security gateway system 156. The multicore processor and flash memory pairs may be used alternately by group. Each safety sub-application may check (read) one assigned status field before processing to ensure that the safety sub-application is cleared for processing the SFIOI. Each safety 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. A set of safety sub-applications may check each SFIOI for at least the following items: ○Confirmation that SFIOI was received on the correct central system 150. - The exemplary algorithm includes checking the status, and if permission to continue is granted, reading one or more bytes from the VN origin field, comparing its value to a predicted value such as 187, and updating the status according to the comparison result. ○Confirmation that the SFIOI payload size satisfies the expected value for the number of VNs specified in the SFIOI. For example, if the field indicates that SFIOI specifies six virtual banknotes, and it is expected that these six virtual banknotes will be listed in words 8, 9, 10, 11, 12, and 13, the sub-application can check words 14, 15, and 16 before proceeding to verify that the values ​​in these words are NULL. ○Verification that one or more NULL words or NULL bytes are actually NULL. ○Verification that one or more NULL bits are actually NULL, such as the bit following the Party ID in the Party ID-specific word, or the bit following the VN ID in the VN ID-specific word. ○ Verification that the person claimed to be the owner of the virtual currency is actually the owner. - The exemplary algorithm includes checking the status and, if permission to continue is granted, reading one or more bytes from the Party #1 ID field and the VN#1 ID field, and sending the read data and page number to the ledger storage system 152. - Another sub-application receives the response to the ownership check for the VN#1 ID and updates the status field accordingly. ○Check the owner's instructions, and if requested by the owner's instructions, initiate an outgoing connection from the security gateway system 156 and start the process of performing multi-factor authentication to a predetermined communication address. - The exemplary algorithm includes checking the status, and if permission to continue is granted, reading one or more bytes from the party #1 ID field, and, at the owner's request, sending the read data and page number to the identity management system 151 to initiate multi-factor authentication. - Another sub-application receives a response from the ID management system 151 and updates the status field accordingly.

[0033] After performing a safety check, a safety sub-application may mark the appropriate status field on each 512-byte page or sector to inform subsequent safety sub-applications whether processing should proceed. For example, if any safety sub-application detects an error in any SFIOI, it can update the status of all update fields to indicate that no sub-application needs to process the SFIOI on that page any further. This can be done simply to indicate that all necessary processing has already been performed so that subsequent safety sub-applications can skip the SFIOI where the error was detected.

[0034] Some safety sub-applications generate queries to external systems within the central system 150 (i.e., outside the security gateway system 156), and it is inefficient for processing resources to pause while waiting for a response to the query. Since communications within the central system 150 can use internal addressing, external parties cannot know how the security gateway system 156 retrieves information from the ledger storage system 152 or the ID management system 151. The security gateway system 156 may be the only element of the central system 150 to be assigned an IP address. For queries to persistent systems within the central system 150, a first set of algorithms in the composite software of the security gateway system 156 may send the query (e.g., an ownership query to the ledger storage system 152), and a second set of algorithms in the composite software of the security gateway system 156 may check the response to the query.

[0035] In the method for processing the NDC SFIOI in Figure 2A, when the central system receives the SFIOI, the method begins at S211. In S212, the central system reads the batch number, sender information, counterparty information, and virtual currency information (VN information) within the SFIOI. The batch number can specify how many VN information fields there are in the SFIOI, so the central system knows where the substantial data for the VN information fields ends. The sender information and counterparty information may be unique identifiers of a universal type used by the central system, or other types of identifiers that can be converted to a universal type used by the central system. The VN information may contain unique identifiers for one or more VNs specified in the SFIOI. In S213, the central system converts the sender information and / or counterparty information as necessary. That is, if the sender information and / or counterparty information is not of a universal type used by the central system, the central system can convert the sender information and / or counterparty information to a universal type used by the central system. In S214, the central system reads the VN information. In S215, the central system determines whether the VN information matches the current owner indicated in the SFIOI. If the VN information matches the current owner indicated in the SFIOI (S215=Yes), in S216 the central system determines whether the VN information belongs to the last virtual banknote specified in the SFIOI. If it does not belong to the last virtual banknote specified in the SFIOI (S215=No), the central system reads the next VN information in S217 and returns to S215. If the virtual banknote is the last virtual banknote specified in the SFIOI (S216=Yes), the central system deletes the SFIOI in S218 and sends a response to the inquirer or instructor in S219. The central system may also, at any time, delete the SFIOI in S218 and send a response to the inquirer or instructor in S219 if it determines that the VN information does not match the current owner indicated in the SFIOI (S215=No).

[0036] In the SFIOI processing method shown in Figure 2B, the sender sends a transfer SFIOI to be received by the central system in S221. Normally, a transfer SFIOI from a suitable sender should be accepted by the central system. However, if the central system is programmed to confirm receipt of virtual currency from the person designated as the recipient, the central system can perform the remainder of the method shown in Figure 2B. In S222, the central system stores the VN information of the SFIOI in the cache and starts a first timer. The first timer can be, for example, 2 minutes, 5 minutes, or any other relatively short period that the central system assumes the recipient can receive the virtual currency and notify the central system of receipt. In S223, the central system waits for the first time to elapse. Once the first time has elapsed, the central system checks in S224 whether the recipient has notified the central system of receipt of the virtual currency. If the recipient has notified the central system of receipt of the virtual currency (S224=Yes), the central system updates the virtual currency record in S226 and clears the cache. If the recipient has not notified the recipient of the virtual currency (S224=No), in S225 the central system sends an inquiry to the recipient and starts a second timer. The second timer may be the same length as the first timer or longer. For example, the second timer may be longer than one day to accommodate cases where the recipient is asleep or busy with other matters. In S227 the central system waits for the second time to elapse. The wait in S227 may be a precautionary measure and is not necessarily required if it is a predetermined assumption that the virtual currency has been received. Once the second time has elapsed, in S228 the central system determines whether the recipient has notified the recipient of receipt. If the recipient has not notified the recipient of receipt after the second time has elapsed (S228=No), in S229 the central system notifies the sender and recipient of the cancellation of the transfer and clears the cache. If the recipient notifies of receipt after the second time period has elapsed (S228=Yes), the central system updates the virtual banknote record in S226 and clears the cache.

[0037] The method for verifying the transfer SFIOI of virtual currency for NDC in Figure 2C begins in S251 when the transfer SFIOI is received by the central system. The transfer SFIOI may include a unique identifier that uniquely identifies the virtual currency, an identifier that identifies the recipient of the virtual currency, and an identifier that identifies the source of the virtual currency. In the embodiment based on Figure 2C, three independent processes may occur before the electronic history of the virtual currency is updated based on the transfer SFIOI. In S252, the recipient's party information is retrieved. The party information may be a unique identifier that identifies the party. The party information may include personal information, device information, account information, and / or program information. In S253, the party's blacklist and party graylist are retrieved. For example, the central system 150 may store the blacklist and graylist. Apart from the blacklist and graylist, other forms of monitoring may be imposed, such as transactions involving a large amount of virtual currency or transactions involving parties involved in many other transactions within a relatively short period of time. 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 S254, the party information is compared against the parties' blacklist and graylist. This comparison may be a simple pattern matching to determine whether the presented recipient information matches an entry in either the parties' blacklist or graylist. In S255, if the comparison in S254 results in a match, an action is taken. Actions may include notifying a third party, such as a government agency, if a graylist match is found, or simply adding a transfer entry to the records maintained for the monitored recipient. In the case of a blacklist, actions may include simply notifying the recipient and / or sender of virtual currency that the sender is not authorized to transfer virtual currency, or that the recipient is not authorized to receive virtual currency.

[0038] In the second subprocess, in S256, virtual currency information is retrieved. In S257, the virtual currency blacklist and virtual currency graylist are retrieved. In S258, the virtual currency information of the virtual currency subject to the transfer SFIOI is compared with the virtual currency blacklist and virtual currency graylist. The comparison in S258 may be a simple pattern matching to check whether a unique identifier that uniquely identifies the virtual currency matches an entry in the virtual currency blacklist or virtual currency graylist. In S259, if a match is found as a result of the comparison in S258, an action is taken. Actions that may be taken in S259 include updating the virtual currency record if the virtual currency is on the graylist. Actions taken when a match is found on the graylist include initiating the virtual currency inspection requirement by providing the virtual currency to the central system 150 for inspection of the virtual currency file, or by ordering the virtual currency file to be inspected by the currency reader program or electronic wallet program of the electronic communication device. If it matches an entry on the blacklist, the measures taken under S259 include simply notifying the recipient and the sender of the virtual currency that the virtual currency is ineligible for transfer.

[0039] In a third subprocess, in S260, 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 is always applied. In S261, a notification is generated for the virtual banknote of the registered owner. The notification may be addressed to the registered owner of the virtual banknote's recorded communication address, which may include a telephone number for text messages, an email address, or another form of communication address for push notifications. The communication address may be obtained from records held by the central system 150 for the parties registered to conduct the virtual banknote transaction, and may be obtained completely independently of the party information provided with the transfer SFIOI in S251. In S262, the notification is sent via text message, email, or push notification, etc. In S263, the third subprocess includes approving the transfer of recorded ownership after awaiting positive confirmation from the registered owner. The third sub-processing is expected by the sender of the virtual currency and can be provided via a broadband internet network within seconds of the sender issuing the transferred SFIOI, even if the sender is on the other side of the world from the central system 150.

[0040] In S264, the process in Figure 2C includes determining whether the transfer is OK. The transfer of ownership is OK only if there is no match with the blacklist in the first and second subprocesses, if the requirements for 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 (S264=Yes), the electronic history of the virtual banknote is updated in S265. Furthermore, the recipient of the virtual banknote may be notified that the electronic history of the virtual banknote has been successfully updated. If the transfer is not OK (S264=No), the transfer is rejected in S266. Furthermore, both the recipient and the sender of the virtual banknote may be notified that the electronic history of the virtual banknote has not been updated.

[0041] The process in Figure 2C can be executed whenever ownership of virtual currency is transferred and is separate from the inquiry process normally performed on the trading partner. In various embodiments based on Figure 2C, some of the subprocesses in Figure 2C may be omitted, replaced by other subprocesses, or supplemented. The updates in the process in Figure 2C may be performed in real time or near real time, or in some respects, periodically, but not necessarily in real time or near real time. For example, if the complete set of records for the central system 150 is stored in a central location, the complete set of records may be updated every 12 hours or every 24 hours. An intermediate system located away from the central location may accumulate 12-hour or 24-hour updates and periodically update the central system 150 with the accumulated updates. Furthermore, a ledger storage system that stores only limited records, such as the current owner of each virtual currency, and can be used for real-time ownership inquiries, may be updated in real time and may be physically separated from the central location that stores the complete set of records and from any intermediate system that accumulates updates for a fixed period, such as every 12 or 24 hours. In some embodiments, the main memory system may be updated in real time and subsequently used to update a secondary ledger storage system that stores limited records, such as the current ownership of virtual currency. In some embodiments, delayed updates are provided to primary, secondary, and / or tertiary backup record systems but not to record systems that require updated records to provide responses to prior ownership queries.

[0042] In the method for which the central system processes ownership inquiries for one or more virtual banknotes in Figure 2D, in S231, the central system receives ownership SFIOIs for one or more virtual banknotes. The ownership SFIOI may include the party identifier of the inquirer, the party identifier of the alleged owner, and the unique identifiers of one or more virtual banknotes. The ownership SFIOI may be received by the security gateway system 156 of the central system 150. In S232, the central system begins pre-processing of the ownership SFIOI for security purposes. In S232, the central system reads the VN number. Also in S232, the central system checks the VN number against the actual size of the VN information in the VN information field of the SFIOI. The central system may include a range of bytes in the SFIOI that should be assumed based on the size of the VN number, and if the actual size of the information in the VN information field exceeds the assumed size, the ownership SFIOI may be deleted in S232.

[0043] Security checks in the central system may be performed by systematically processing incoming SFIOIs via a dedicated thread, core, or processor that repeatedly performs the same task on specific fields of the SFIOI, and by masking or otherwise blanking other bits of the read word (e.g., a 64-bit word) that are not read as part of the instruction. In S233, the central system retrieves party information from the ownership SFIOI. The party information consists of 4 to 8 bytes for each party and may be provided as a party identifier in a predetermined field of the SFIOI packet payload. Processing from S233 to S239 is performed to address 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. In S234, the central system identifies and verifies the country and state or region identified by the party identifier. In some embodiments, the universal identifier may also include a country code so that the central system can recognize external parties that are primarily registered with other central systems. When using a state identification document, such as a driver's license issued by a U.S. state, as party information, the state identification document may also specify which state the party identifier originates from. In S234, the central system identifies and verifies the country and state / region identified in the party identifier field. If the country is a country represented by the central system, the central system may use the data in the state / region field to check the expected format of the party identifier for the specified state / region. In S235, the central system determines whether the party information is of a universal party identifier type. For example, several countries, each tracking its own NDC, may agree on a format for a universal party ID, such as a 16-digit identifier where the first two or three digits indicate which state the party is registered in. In S235, the central system determines whether the party identifier is of a universal party identifier type.For example, a universal party identifier type may include a national identifier such as a social security number, or a state identifier such as a state driver's license number or state identification number. The central system may be configured to process party IDs universally, and only universal IDs may be accepted and processed. If the party identifier is a universal party identifier type (S235=Yes), in S239, the universal ID number is retrieved and verified from the last field. If the party identifier type is not a universal ID (S235=No), in S236, the central system identifies the ID type. For example, the ID type may specify a social network ID and the identifier of that social network, or a communication address ID and an identifier indicating the type of communication carrier or service provider that provides the communication account corresponding to that communication address ID. In one embodiment, the ID type may be a telephone number. In another embodiment, the ID type may be an application identifier of a currency reader program or electronic wallet program used by the user corresponding to the party ID. In S237, the central system retrieves and verifies the ID number. In S237, the ID number of the ID type identified in S236 is retrieved and verified. The ID number may be formatted in a format specific to the ID type, and therefore the verification in S237 may include checking the ID number against one or more predetermined parameters of the ID type, for example, the length of the ID number. In S238, the central system converts the ID number to a universal ID number used by the central system. The conversion includes retrieving the universal ID from a lookup table in the database. The universal ID may be used if the processing in the central system is performed using only the universal ID, even if the central system accepts other ID types in the SFIOI. In S239, the central system retrieves and verifies the universal ID number after the conversion in S238, or if the party information is of the universal party identifier type (S235=Yes).Universal ID numbers may be used to cross-reference with greylists and blacklists, whether converted or not. Naturally, greylists and blacklists may be provided for both universal IDs and other types of IDs, thereby identifying parties prohibited from using virtual currency or parties under surveillance, and processing transactions accordingly. Furthermore, party records may be updated to reflect that virtual currency has been provided to a party or transferred to another party, assuming that the transfer is authorized based on the transfer SFIOI. In S240, the central system compares the virtual currency(s) with their electronic history to determine whether the current owner of the virtual currency is a party listed by the universal party identifier in the ownership SFIOI received in S231. The central system then responds to the requester with a simple "Yes" or "No," etc.

[0044] In Figure 2E, the central system processes transfer SFIOIs for one or more virtual banknotes. In S270, the central system receives transfer SFIOIs for one or more virtual banknotes. A transfer SFIOI may specify the party identifier of the initiator, the party identifier of the recipient, and the unique identifiers of one or more virtual banknotes. In S272, the central system begins pre-processing of the transfer SFIOI for security purposes. While we will not repeat all the pre-processing aspects described for Figure 2D here, most or all of the pre-processing described for Figure 2D can be similarly applied to the pre-processing in Figure 2E. In S272, the central system reads the VN number of the transfer SFIOI. Also in S272, the central system checks the VN number against the actual size of the substantial data in the VN information field of the transfer SFIOI. The central system may include a range of assumed sizes of the substantial data in the VN information for various possible VN numbers, and if the size of the substantial data exceeds the assumed size, the transfer SFIOI may be deleted in S272. In S273, the central system retrieves party information from the transferred SFIOI. Processes S273 through S279 are performed to address the use of aliasing if permitted. In S274, the central system identifies and verifies the country and state or region identified by the party identifier. In S275, the central system determines whether the party information is of a universal party identifier type. If the party identifier type is not a universal ID (S275=No), in S276 the central system identifies the ID type. In S277, the central system retrieves and verifies the ID number. In S278, the central system converts the ID number to a universal ID number used by the central system. In S279, after the conversion in S278, or if the party information is of a universal party identifier type (S275=Yes), the central system retrieves and verifies the universal ID number. In S280, 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 in the transfer SFIOI received in S270.Subsequently, the central system responds to the user by confirming that the electronic history of the virtual currency has been updated, etc.

[0045] In Figures 2D and 2E, when the SFIOI is received by the central system, the party identifier is processed. The central system 150 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, the central system 150 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.

[0046] In some embodiments based on Figure 2D and / or Figure 2E, the central system 150 may store different sets of alternate IDs in different databases, such that each set 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 to corresponding universal IDs used by the central system, and another database of conversion tables for translating all currency reader application identifiers to corresponding universal IDs. Naturally, it is also possible to use three or more independent database configurations for the translation to 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 the universal ID whenever an alternate ID is received as part of an incoming SFIOI.

[0047] As an alternative to a lookup table for storing alternative Universal IDs, a Universal ID numbering system may be designed so that alternative IDs are accepted from authorized sources such as major social network providers or telecommunications service providers. For example, if an 11-digit Universal ID is used for a population of up to 99.9 billion people, the last 12 digits can be used to specify whether the SFIOI is from a particular account of a major social network provider or telecommunications service provider. For example, user 99999999999 (11 digits) may use 9999999991 (12 digits) to specify instructions coming from the user's Facebook® messaging account, 999999999992 (12 digits) to specify instructions coming from the user's Gmail account, or 999999999993 (12 digits) to specify instructions coming from the user's Verizon messaging account. If a 10-digit universal ID is used for a population of up to 9.999 billion, the last 11th and 12th digits can be used to specify up to 99 different accounts or other characteristics for the SFIOI sent to the central tracking system. An alternative is to send a unique social media identifier, email address, phone number, etc., instead of the universal ID that is looked up by the central system.

[0048] The NDC monitoring, inspection, and exchange method in Figure 2F begins in S290 with the receipt of a greylist detection notification. A greylist detection notification is generated in the central system 150 when a transfer of virtual currency on the greylist, or a transfer between parties on the greylist, is detected. The central system 150 may have an automated process configured to initiate the process in Figure 2F for some or all of such notifications. In S291, the new owner of the virtual currency is provided with the expected characteristics of the virtual currency and instructed to compare the expected characteristics of the virtual currency with the virtual currency and report the result. In S292, a determination is made as to whether there is a match or not. The determination in S292 may be received as a result of a notification from the new owner of the virtual currency after the currency reader program or electronic wallet program has analyzed the virtual currency. If there is a match, the process in Figure 2F ends in S293. If there is no match, the central system 150 may exchange the virtual currency for an alternative virtual currency of the same denomination in S294. 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 shown in Figure 2F, 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. Replacements like S294 are typically assumed to be due to wear and tear such as data loss due to packet drops during transmission over an electronic communication network.

[0049] In the cloud-based transaction flow for NDC in Figure 3A, a data center 340 is used to process large amounts of data managed by a central system, as described herein. The infrastructure in Figure 3A includes equipment 101, equipment 102, one or more electronic communication networks 130, a central system 150, and a data center 340. In step A, equipment 101 initiates communication with the central system 150 via the electronic communication network 130. The communication in step A may be a transfer SFIOI for transferring virtual currency from equipment 101 to equipment 102. In step B, the central system 150 sends a request to the data center 340 to verify and / or retrieve information. The request to verify and / or retrieve information in step B may be a request to confirm that the virtual currency is owned by the owner of equipment 101. In step C, the data center 340 responds with either verification or the requested information. The verification or requested information in step C confirms that the virtual currency is owned by the owner of equipment 101. The central system 150 initiates communication with device 102 in step D. The communication in step D may notify device 102 that virtual currency will be transferred to device 102 by instruction from device 101. In Figure 3A, the communication in step A is from device 101, but in an alternative embodiment, the central system 150 may receive the communication in step A from device 102, or from both device 101 and device 102. In step E, the central system 150 responds to device 101, such as confirming the transfer SFIOI, based on the verification or requested information from step C. The infrastructure in Figure 3A can be used to verify, transfer, and track virtual currency of NDC. For example, if device 101 requests the transfer of virtual currency to device 102, the central system 150 can check the records in the data center 340 and, if the virtual currency belongs to device 101, notify device 102 of the transfer. The central system 150 may update the records of the data center 340.

[0050] Data center 340 can store a large amount of data. Data stored in data center 340 and searchable for use from data center 340 may include the following: ○Greylist of cryptocurrencies: This is a list of virtual currency currently suspected of being involved in problematic activities, and includes processing instructions for each virtual currency on the greylist whenever it is transferred. ○Blacklist of cryptocurrency: This is a list of virtual currency that has been reported lost, stolen, or recovered and should not be involved in transfers, and includes processing instructions for each instance in which a virtual currency on the blacklist is alleged to have been transferred. ○Greylist of parties involved: A list of parties, electronic communication devices, currency reader programs, and electronic wallet programs suspected of being involved in problematic activities, including processing instructions each time an entry on the greylist is designated as a transfer destination or transfer source in the SFIOI. ○ Blacklist of parties involved: A list of parties, electronic communication devices, currency reader programs, and electronic wallet programs prohibited for any reason from being involved in the use of virtual currency, including processing instructions whenever an entry on the blacklist is designated as a transfer destination or transfer source in the SFIOI.

[0051] The data center 340 in Figure 3A is representative of one or more data centers that may be used to store data for the central system 150, and is representative of any other form of large-scale storage used to implement the NDC. The data center 340 can provide one or more elements of Figure 1C even if the data center 340 is isolated from the public in ways other than through the security gateway system 156.

[0052] The data center 340 in Figure 3A may be implemented as part of a cloud configuration for the NDC, including a private cloud configuration that separates the equipment and operations for the NDC from the equipment and operations for other parties and applications. The data center 340 can be implemented using a solid-state drive (SSD) array. SSDs may be preferable to hard disk drives (HDDs) in that they are faster and consume less power.

[0053] Furthermore, virtual currency may include private addresses in its metadata fields that are not publicly accessible. These private addresses may be interpretable by the central system 150 and may include the addresses of private servers or databases, or specific port addresses of private servers or databases. Thus, if virtual currency also sends updates to its records back to the private cloud, the central system 150 may unpack some of the updates to identify which of the private server or database addresses is storing the virtual currency records. This could serve as a supplement or alternative to addressing based on the unique identifier of the virtual currency, so that even if the central system or control system partially uses the unique identifier of the virtual currency to identify subgroups of servers or databases used to store the virtual currency records, the private addresses sent by the virtual currency can be used to specify a server, database, server port, database port, or another internal communication address within a subgroup corresponding to a component unreachable by a public address.

[0054] In the system for storing records of virtual banknotes in NDC shown in Figure 3B, a filtering / separation system 349 filters and separates SFIOIs before they are received by the central system 150. The filtering / separation system 349 may inspect each SFIOI to ensure that each SFIOI conforms to the requirements of an SFIOI. The inspection may include size checks to determine the data size of each SFIOI, the type of each SFIOI, the expected order of information within each SFIOI, and / or any other types of information that may be derived from the SFIOI. The filtering / separation system 349 can serve two purposes: 1) Filtering all hacking attempts by ensuring that SFIOI does not contain executable code that could corrupt either the first memory subsystem 151A or the ledger storage system 152, and 2) Strictly ensure that the SFIOI satisfies the requirements. The filtering / separation system 349 may include the security gateway system 156 in Figure 1C, or be included in the security gateway system 156 in Figure 1C, or may be integrated with the security gateway system 156, or may be a substitute for the security gateway system 156.

[0055] The method by which the security gateway system in Figure 4A processes received SFIOI packets outlines the security checks performed by the security gateway system 156, beginning with the storage of the packet payload in the address space in S402A. The packet size may be standardized for processing by the security gateway system. For example, an SFIOI packet may be 512 bytes and may 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. Of course, the teachings herein are not limited to 512-byte packets or packets of uniform size. However, the above details may be considered optimal in some respects. Packets may also be standardized to fractions or multiples of 512 bytes for similar reasons relating to standardized, uniform processing and storage. In S404A, the size of the packet payload in bytes is checked. For example, the size checked may be the amount of meaningful data in the packet, such as all data excluding the header. An SFIOI specifying seven virtual banknotes may contain as little as 43 bytes of meaningful data, provided that the parties to a transaction can be uniquely identified in just 4 bytes and the virtual banknotes specified in the SFIOI can be uniquely identified in just 5 bytes. However, other fields may be required, such as a field for the country or region issuing the virtual banknotes (1 byte), another field for each virtual banknote specifying its face value (1 byte for each virtual banknote if not implicitly specified in the virtual banknote identifier), another field for the number of virtual banknotes to be identified in the SFIOI (VN number) (1 byte), and another field for the relative placement in the total number of packets sent individually in a batch (1 byte). The total length of meaningful data in a packet may be specified in the packet header, which may be compared to the actual length of meaningful data stored in the address space.In S408A, the number of virtual banknotes (VN number) identified by the SFIOI is determined. The number of virtual banknotes identified by the SFIOI may be specified by a specific byte in the SFIOI. In S410A, the assumed size of meaningful data in the packet is determined from the VN number determined in S408A, and the assumed size determined in S410A is compared with the actual size determined in S404A. Naturally, the security gateway system can consistently eliminate threats and potential threats as soon as they are identified, so if there is a discrepancy, the packet may be deleted from the address space. In S412A, the identifier of the person who is supposed to be the owner of the virtual banknotes specified in the SFIOI is determined. The person who is supposed to be the owner may be identified by just 4 bytes specified in the SFIOI. In S414A, for owner verification, 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 in Figure 1C, along with each individual virtual banknote identifier, in a single communication or as a batch of separate communications. Note that the ledger storage system 152 may contain records of only the current owner of each virtual banknote, or may contain other datasets that are less than the complete record of any virtual banknote or party stored in the main memory system 153. If there are stored instructions from the actual owner of the virtual banknote, these instructions are checked in S416A. The check in S416A can be performed on the main memory system 153 if the processing instructions from the owner of the virtual banknote are stored in the main memory system 153, on the ledger storage system 152 if the processing instructions from the owner of the virtual banknote 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 S418A, if the stored instructions checked in S416A instruct anti-spoofing measures to be taken, the anti-spoofing measures are initiated.For example, the owner of a virtual banknote can specify that multi-factor authentication be invoked whenever the virtual banknotes owned by the owner become the subject of an SFIOI to the central system 150. In S420A, the type of SFIOI is checked. The type may include inquiries, instructions for transfer to another party, instructions for transfer to another account or device of the same owner, and instructions for special processing. In S422A, the SFIOI is processed according to the checked type. If the instruction is an instruction to transfer ownership of the virtual banknote, an instruction to update the ownership record of the virtual banknote is sent to the main memory system 153, and another confirmation notice may be sent to the sender of the instruction. If the instruction is an inquiry regarding the ownership of the virtual banknote, if the person identified as the owner in the SFIOI is correct, a confirmation response confirming that ownership may be sent to the sender of the instruction. In some embodiments, the unique identifier of the virtual banknote is encrypted so that the trading partner can send the encrypted unique identifier to the central system 150 to confirm the face value and ownership of the virtual banknote without knowing the unique identifier until the transaction actually occurs. Therefore, the processing also includes decrypting the unique identifier of the virtual banknote when the SFIOI is an ownership inquiry, and the unique identifier of the virtual banknote can only be decrypted by the central system 150, in particular the security gateway system 156. Other processing may include notifying other central systems that track other NDCs, and other instructions or confirmation notices processed by the security gateway system 156.

[0056] In the processing configuration of the security gateway system shown in Figure 4B, the set of cores of the first server 41561 references a status space that stores the status of each address space on a one-to-one basis. The status space may be RAM, similar to the working memory used in internet routers and switches, while the address space may be flash memory. In this regard, the address space may fit to a 512-byte or other relatively large SFIOI size, while the status space may be on the order of 4 bytes. For example, within 4 bytes or perhaps 5 bytes, the status space can specify which address space it 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, when the first status space (SS1) instructs them to process, begin processing from the first address space 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 should 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.

[0057] In Figure 4B, a core may be triggered to delay processing when it recognizes that it is not yet needed. However, for a core processing more than 40,000 packets per minute, the processing delay can be very small, such as less than a quarter or tenth of a second. In a quarter of a second, the core should be able to process only about 170 packets. Considering the advantages in simplification, processing, and memory resources, the embodiment based on Figure 4B may use a relatively large address space for a relatively large volume of incoming packets. For example, the first server 41561 in Figure 4B can accept more than 200,000 packets for 5 minutes before new packets are switched to the second server or at least another bay of the first server 41561. Before the central system 150 is implemented and before packets are rotated out of line, tests may be performed to optimize which servers operate for how long to receive and process packets. Tests may also be performed to optimize how many servers are used at once, how incoming packets are distributed to different servers, etc.

[0058] In some embodiments, the core in Figure 4B may be replaced by individual threads referencing the status space instead of individual cores, insofar as the core may implement multiple threads and therefore perform multiple operations on the same address space and update the corresponding status space multiple times.

[0059] In the method of processing received SFIOIs by the security gateway system in Figure 4C, the resource processes packet payloads individually and independently within the address space of the security gateway system 156. Before the method in Figure 4C begins, packets are received. In the case of an NDC, SFIOIs are expected to occur at a rate of tens of thousands per minute, and may be even higher for at least a few days. Therefore, as soon as a packet is received, it is immediately written to a contiguous address space so that it can be processed. After all packets in the bay have been processed, all address spaces in the bay may be cleared by deleting the data within them. In S402B, 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 the resource in the method in Figure 4C.

[0060] In S404B, the size of the packet payload in bytes is checked by a first resource (i.e., resource 1). The first resource may be a thread, core, or processor, or it may be a resource that iteratively performs the same operation one by one on the address space in the bay. The size of the packet payload may also be checked for the presence of meaningful data in the address space, such as 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. An end pattern may be used in the SFIOI to specify the last byte of the packet payload. 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 or exact size allowed for the SFIOI.

[0061] In S406A, it is determined whether the checked size is OK or not. If the checked size is not OK, for example, if the actual size of the packet size data and / or meaningful data in the address space indicates that the packet payload is larger than the maximum or exact size allowed by the SFIOI, in S406C, the packet is removed from the address space or marked for removal. If the checked size is OK, in S406B, the first resource is incremented, and the address space for which the packet payload size was checked in S404B is added to the address queue of the next resource (i.e., resource #2) that will process that address space. In S408B, the number of virtual banknotes identified by the SFIOI is determined by the second resource (i.e., resource #2). This number may be specified in the field required by the SFIOI, for example, one byte or less than eight bits. In S408C, the second resource is incremented, and the address space in which the number of virtual banknotes identified by SFIOI has been determined is added to the address queue of the next resource (resource 3) that will process that address space. In S410B, the expected size of the packet payload is determined from the number of virtual banknotes determined in S408B. Since the identifiers of virtual banknotes should be of a uniform size, the expected size of the packet payload may be predetermined based on the number of virtual banknotes. Furthermore, since the number of virtual banknotes that can be specified in a packet can be kept below a maximum value such as 7, the potential size of the packet payload may also be minimized to 7 or less. In S410B, the expected size is compared with the size checked in S404B. The expected size should match the checked size, but slight discrepancies may be allowed for reasons that are not yet clear.

[0062] In S410C, a determination is made as to whether the comparison in S410B results in a match (OK) or a mismatch (not OK). If the expected size and the checked size match (S410C=Yes), the third resource is incremented, and the address space compared in S410B is added to the address queue of the next resource (resource 4) that will process the address space in S410D. If the expected size and the checked size do not match (S410C=No), in S410E, the packet is either removed from the address space or marked for removal.

[0063] In S412B, 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 S412B 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 4C so that results that would prevent the execution of the response to the SFIOI in S422B are received before S422B 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 an SFIOI is seven. However, in some embodiments, a resource processes multiple virtual banknote identifiers at once, and in some embodiments, the maximum number is less than or greater than seven. In S414B, the identifier of the alleged owner and each virtual banknote identifier are sent 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, which may include a simple comparison of whether the alleged owner of the virtual banknote matches the listed owners of the virtual banknotes. The address space of the SFIOI under ownership check is added to a queue for the following seven resources (resources 12-18). To maximize the efficiency of the resources used for processing in the security gateway system 156, a separate set of resources can be used for responses, eliminating the need for resources to both send queries and wait for responses.

[0064] In S414C, the response to the ownership check in S414B is received by each of the following seven resources (resources 12-18), which may, for example, specify whether the current owner matches or does not match. In other words, even a single bit can be used to indicate a match or mismatch in the ownership check. The response in S414C may simply specify the address space of the packet payload being checked and either the virtual currency being checked in the packet payload or the resource that made the request in S414B. In S414D, it is checked whether all the results of the ownership queries in S414B match. If all the ownership queries in S414B match according to the results received in S414C (S414D=Yes), then in S414E, resources 12 through 18 are incremented and their address space is added to the queue for the next resource (i.e., resource 19). If the ownership check in S414B does not result in a match (S414D=No), then in S414F, the packet is removed from the address space or marked for removal.

[0065] In S416B, resource 19 checks for stored instructions (if any) from the actual owner. This check may be performed by sending a query to the main memory system 153 for any virtual banknote, looking up the actual owner, and confirming whether a processing instruction has been specified. For example, the owner may specify that the virtual banknote 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 another type of special processing. After sending the query, resource 19 may increment the address space and add it to the queue for the next resource (i.e., resource 20). In some embodiments, the owner's instructions for a virtual banknote 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. For example, the owner may specify that the virtual banknote should not be transferred without multi-factor authentication, or without the owner first updating the cursory information to authorize the transfer.

[0066] In S418B, the 20th resource initiates anti-spoofing measures if instructed by the response to the query from the 19th resource in S416B. Anti-spoofing may be performed by initiating a multi-factor authentication check and then having another resource (not shown in Figure 4C) await authentication. 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 two characters in a response confirming the transfer. Details of waiting for and processing responses to the anti-spoofing check are not shown in Figure 4C because there is not enough space to adequately illustrate any further processing that may be involved. 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).

[0067] In S420B, the next resource (i.e., resource 21) checks the type of SFIOI. In S420C, 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 that process the SFIOI may vary based on how many different actions can be performed based on the SFIOI. In S422B, the SFIOI is processed by one or more of the 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 the transfer of the SFIOI to the source, or simply confirming the ownership query to the source. The ownership query confirmation may be performed by default without further querying. This is because the ownership confirmation is performed in S414B, and the SFIOI has already been answered, or has been deleted or marked for deletion if one or more of the ownership query results are negative. Other types of processing are also possible, such as updating processing instructions or transferring ownership records to reflect when an owner moves specific virtual currency from one custodial account to another, or from one device to another.

[0068] The method for performing aggregated security checks in the central system's memory system, as shown in Figure 4D, 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 confirm whether suspicious funds have been withdrawn from or added to an account. Since suspicion can be relative to people, places, and times, different thresholds and analyses may be applied to look for different patterns.

[0069] In S430, an update to the record of the transferred cryptocurrency is received. The update to the record may be stored in both the history of the cryptocurrency and the history of the initiating party and the counterparty. Different algorithms may be applied to the history of the cryptocurrency and the history of the initiating party to check for different pattern features. In S431, the aggregate amounts of the transferee and transferor for the most recent period are determined. The aggregate amounts may be the total amount of transfers between the transferee and transferor for the past 60 seconds, 5 minutes, 30 minutes, 1 hour, 24 hours, and / or other periods. In S432, the aggregate amounts are compared to a threshold to determine whether the aggregate amounts are higher than the threshold. The comparison in S432 may include comparisons of different aggregate amounts and different thresholds, and the thresholds may differ for each party, such as being based on the average, highest, or lowest amount owned by the parties in the most recent period. Thus, it may be determined that it is suspicious for $800 of $1,000 (hereinafter, "dollars" means "US dollars") in the owner's name to be taken out of the owner in 3 to 4 transactions per day, but it may be determined that it is not suspicious for $800 of $10,000 in the owner's name to be taken out of the owner in 3 to 4 transactions per day. Accordingly, the central systems described herein, such as the central system 150, may check the history of the sender and / or recipient of the virtual banknotes for each transaction and may flag the sender and / or recipient of the virtual banknotes if they are involved in transactions of an unusually large amount or an unusually large number of transactions. If one or more total amounts are higher than the corresponding threshold (S432=Yes), the corresponding parties may be added to the blacklist or graylist in S433. If there are no total amounts higher than the corresponding threshold (S432=No), additional checks may be performed. A blacklist may also list parties who present virtual currency they do not possess or counterfeit virtual currency, and / or parties who present information about a trading partner or virtual currency that does not match the trading partner (e.g., VN_info), or parties who have not agreed to the transfer of virtual currency. A blacklist may also list parties who are prohibited from receiving virtual currency, and a greylist may list parties under surveillance.The blacklist may include parties identified as having submitted inaccurate identifiers to the central system 150 regarding the origin of virtual currency in ownership inquiries, parties identified as having submitted fraudulent transfer SFIOIs to the central system 150, parties that were the target of detected impersonation attacks, parties identified as having attempted to alter virtual currency, or other parties for which the central system 150 has determined there are grounds to prohibit them from receiving ownership of virtual currency. The blacklist may identify information such as currency reader programs and wallet programs that processed virtual currency reported as lost or stolen, and is not limited to listing only the unique identifiers of parties.

[0070] The greylist may include parties under government or regulatory surveillance for suspicious activity, such as potential criminal activity; parties located in specific locations or geographical areas, such as specific countries; parties that are relatively new to the central system 150; or parties using relatively new unique party identifiers. The greylist may be updated based on certain activities, such as SFIOI queries specifying unique identifiers for virtual currency or SFIOI queries specifying mismatched party identifiers. For example, a count and / or list may be included in the greylist in case a party submits an inaccurate SFIOI, and if two inaccurate SFIOI submissions occur within a relatively short timeframe, such as two hours, the party identifier may be understood to have been tampered with, and the party identifier may be moved from the greylist to the blacklist.

[0071] A requester may be placed on a blacklist or greylist depending on whether they are shown to be involved in potentially fraudulent activity or are strongly suspected of being so. All or a subset of requests received by the Verification Service may be cross-referenced with the blacklist to determine whether a requesting party is repeatedly providing false information, and if the Verification Service finds, or is suspected of, intentionally providing false (e.g., unfair) information, the requesting party may be banned from trading.

[0072] Furthermore, the virtual currency blacklist may include recovered virtual currency, and virtual currency reported as stolen or lost. For example, virtual currency may be recovered when one or more counterfeiting attempts involving the same unique identifier are detected. The virtual currency greylist may include virtual currency that is under surveillance after being in the possession of a party being monitored by government or regulatory authorities for suspicious activity such as potential criminal activity. For example, if a party is under investigation by a tax authority, the tax authority may order the central system 150 to greylist all virtual currency currently in the possession of that party. In this case, the movement of virtual currency may be specifically recorded in a file kept for that person. In S434, 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 greylist. As another example, a transfer from a party at 2 a.m. local time may trigger addition to the blacklist or greylist. In S435, if the timing or location triggers a condition (S434=Yes), the party is added to the blacklist or graylist; otherwise, the process shown in Figure 4D terminates.

[0073] In the method of processing received SFIOIs in the security gateway system shown in Figure 4E, the method in Figure 4A is divided into four sections as 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. As is known from recent processing, a graphics card can contain many processors that operate nearly in parallel, considering its inherent task of rendering graphic data of many pixels simultaneously. The use of many processors is also applied to a variety of other tasks. The security gateway system 156 of the central system 150 may be expected to receive tens of thousands of SFIOIs at times per minute and operate continuously. Therefore, tasks performed on the security gateway system are performed in essentially parallel to different incoming packets. A graphics card can be used as long as the processing it provides is adequately applicable to the SFIOIs.

[0074] In Figure 4E, the processors are divided into four groups. One of the simplest ways to ensure efficient processing, if not the simplest, is to ensure that all processors do not specifically wait for a response to a query they sent, and do not 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. By using a status space like that shown in Figure 4B, it is possible to ensure that each address space is processed efficiently. As an example, the 3200 processors in a graphics card may be divided into four groups of 800 processors each. These processors may process address space 800 at a time. The parallel aspect of processing that leverages the graphics card arises from applying the groups to different groups of address space simultaneously, so the first group can process address spaces 2401-3200, the second group can process address spaces 1601-2400, the third group can process address spaces 801-1600, and the fourth group can process address spaces 001-800. Each group of processors can increment its address space by 800 at a time once its current processing is complete. Naturally, all processor groups do not need to have the same number of processors, for example, if a task performed by one group may be faster than a task performed by another group. Rather, to increase 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.

[0075] In the memory configuration of the security gateway system that processes received SFIOIs in Figure 5A, a security gateway system like the security gateway system 156 in Figure 1C includes various electronic components, including an SFIOI memory 5561 and a status memory 5562 that is physically separated from the SFIOI memory 5561. 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 5562 is intended to store status updates when a processor, core, or thread processes an SFIOI in the SFIOI memory.

[0076] One aspect of the technical challenges addressed herein is the program / erase cycles of the security gateway system 156. Status updates may require writing two or more status updates to status memory 5562 for each SFIOI written to SFIOI memory 5561. However, since writes to status memory 5562 may be limited to one byte or one word per instance, each potential status update may be written to a different bit, byte, or word in status memory 5562. Thus, a thread can determine whether prerequisite processing has been performed by first reading status memory 5562 and referring to the status of any already updated bytes or words.

[0077] As a simple example, thread #7 checks the status of byte #6 updated by thread #6, and if the status indicates that thread #6 has processed the SFIOI, thread #7 can read the portion of the SFIOI that it has processed. When 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. As is obvious, this processing by thread #7 may be extremely fast, such as processing 40k or more SFIOIs per minute, and this may also be true for other processors, cores, and threads processing SFIOIs in the security gateway system 156.

[0078] In the memory configuration for the security gateway system processing received SFIOIs shown in Figure 5B, the SFIOI memory 5561 is shown to include the first SFIOI memory 5561-1, the second SFIOI memory 5561-2, ... up to the 40000th SFIOI memory 5561-40k. The status memory 5562 is shown to include the first status memory 5562-1, the second status memory 5562-2, etc. up to the 40000th status memory 5562-3. Each processor, core, or thread first checks the corresponding status in the status memory 5562, and then performs specific processing on the SFIOIs in the SFIOI memory 5561 before updating the corresponding status in the status memory 5562. As stated above, the security gateway system 156 according to this disclosure is intended to process a large number of SFIOIs, such as 40,000 or more per minute. Therefore, the SFIOI memory 5561 may be the first bay of the security gateway system 156, and may, for example, be allocated SFIOIs that arrive in one minute. The second bay of the security gateway system 156 may be substantially identical to the first bay, and may be allocated SFIOIs that arrive in the next minute at this exemplary timing. The bays may cycle periodically, such as every 5 minutes, 10 minutes, 15 minutes, 30 minutes, or 60 minutes. Furthermore, bays may be allocated SFIOS to process within a certain 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.

[0079] As is clear from Figures 5A and 5B, the status memory 5562 is physically separated from the SFIOI memory 5561, and the processor, core, or thread moves back and forth between the two during processing. However, each processor, core, or thread processes only a specific part of the SFIOI in the SFIOI memory 5561, rather than the entire SFIOI, and operates by checking and writing only individual bytes or words in the status memory 5562.

[0080] In the memory configuration for the security gateway system processing received SFIOIs shown in Figure 5C, memory management includes the use of an integrated SFIOI memory and status memory 5563 for memory space for SFIOIs and memory space for status in the security gateway system 156. In other words, the integrated SFIOI memory and status memory 5563 includes a first area for storing SFIOIs and a second area used to track the processing status of SFIOIs. 256 bytes of a page may be reserved for specific uses in processing by the processor, core, or thread of the security gateway system 156. 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 memory and status memory 5563 may be used for status. The status may be updated by writing at the bit level, byte level, or word level. For example, since the default status of the status space may be set to 0 (zero) and may be updated to 1 (1) in a status update, a byte or word of the status space in the integrated memory 5563 of the SFIOI memory and status memory 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 memory 5563 of the SFIOI memory and status memory before processing a particular part of the SFIOI and then updating another part of the status space. A processor, core, or thread may organize the memory pages of the security gateway system 156 to efficiently use them so that individual physical memory pages are logically partitioned. Of course, the partition does not have to be exactly half of the entire area of ​​the memory page or other predefined addressable memory unit.

[0081] In the memory configuration of the security gateway system processing received SFIOIs shown in Figure 5D, the integrated memory 5563 for SFIOI memory and status memory is shown including a first portion 5563-1, a second portion 5563-2, ..., up to the 40,000th portion 5563-40k. Naturally, the bays of the security gateway system 156 are not limited to 40,000 pages or other units of memory sections, nor are they limited to switching to a new bay every minute or every 40,000 SFIOIs. Rather, a person skilled in the art in the many areas required to implement a central system comprising the security gateway system 156 described herein will recognize that efficient processing is ensured in various ways by efficiently using memory in units used during implementation (e.g., 512-byte pages), but the numbers are merely illustrative. The most efficient way to perform this processing may be to use predefined memory units that are the same size as or larger than each SFIOI and provide the memory space necessary for updating the status of each SFIOI. In this way, SFIOIs are stored on a one-to-one basis in a predefined addressable memory space.

[0082] Figure 6 shows an example of an SFIOI format. The SFIOI format can be one of the most important aspects of securely implementing an NDC. For example, the security gateway system 156 can execute only responses to instructions or queries within an SFIOI that conform to the requested format, and reject incoming packets of other types.

[0083] In Figure 6, the IP packet header is 24 bytes, i.e., it contains three 64-bit / 8-byte word equivalents. Since IPv4 packet headers are typically allocated 20 bytes, the last 4 bytes may be NULL. For larger IP addressing schemes, IPv6 packet headers are typically allocated 40 bytes. In Figure 6, the first field after the header is for the virtual currency number (VN number). If the maximum number of VN fields in the format is limited to 7, 13, 19, or other smaller numbers, the VN number field is provided as 8 bytes / 64 bits, even if the VN number only requires a few bits. The VN number may be processed to ensure that the substantial data of the IP packet terminates where it should, depending on the number of virtual currency specified by the VN number. Next, the first and second party ID fields each consist of 8 bytes / 64 bits. In this way, even if the first and second party ID fields are substantial data of less than 64 bits, each of the first and second party ID fields can be read as a whole word. In Figure 6, 16 independent fields are provided, each as a full word, to specify 16 virtual banknotes. Each thread assigned to perform security checks on virtual banknotes can read the unique identifier (ID) of the corresponding virtual banknote as a whole word, even if the unique identifier (ID) of each virtual banknote is substantial data of less than 64 bits. However, most or all of the assigned VN fields may contain substantial data. For example, the unique ID of a virtual banknote may contain a first byte for the country / region code, a second byte for the face value, and 6 bytes for the actual unique ID. The last substantial field is for the type of SFIOI, since the type of query or instruction specified in the SFIOI is only processed if the SFIOI passes preliminary security processing.

[0084] The trailing field of the SFIOI format in Figure 6 is empty and reserved for status updates at the security gateway system 156. Two words totaling 16 bytes are sufficient to track the status of 16 security checks with different bytes for each security check, and three words totaling 24 bytes may be sufficient to track the status of 24 security checks. A 256-byte format for SFIOI is also sufficient for processing at the security gateway system 156 by keeping the number of unique IDs allowed for virtual currency in the packet below an appropriate limit, but this disclosure primarily uses an example of a 512-byte format. The SFIOI format may match the size of a memory unit other than a flash memory page.

[0085] The first party ID field can contain the requester ID (requester_ID). The second party ID field can contain the counterparty ID (counterparty_ID). The VN ID field can contain the VN information (VN_info) for each virtual banknote specified by its unique ID. Although not shown in Figure 6, the format may include a notifier type field that indicates whether the notification is made by the requester or the counterparty. The notifier type (Notifier_type) can also indicate whether the notifier is a trusted system.

[0086] The SFIOI format can specify that 8 bytes are allowed for each party identifier in a 512-byte packet. The party identifier may be formatted to implicitly specify which country or region is the source of each party identifier, so that a single party identifier can be used for NDCs tracked by different central systems. The entire bit or byte may be used exclusively to specify the bank or similar entity from which the end user obtained the unique identifier, so that the end user's identifier may be held by the bank or similar entity without requiring a complete profile managed by the central system 150.

[0087] Examples of SFIOI format types may allow parties to: inquire whether a trading partner possesses virtual currency; instruct the transfer of ownership of virtual currency to a trading partner; instruct subsequent special processing or cancellation of special processing; instruct the loss or theft of virtual currency; and provide updates to the metadata status of virtual currency that has not been recently transferred.

[0088] 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 by a central system, the SFIOI may specify the amount of change to be deposited and / or withdrawn from the account corresponding to the party, 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 by a central system. A party registered to use virtual currency may have a deposit account, checking account, or savings account associated with a unique identifier. In this way, amounts less than one dollar can be deposited into or withdrawn from the associated account. As an example, if a party pays $50 for goods in a transaction and expects 65 cents in change, the change can be automatically deposited into the party's associated account and withdrawn from the seller's associated account. Associated accounts are managed outside the central system and are therefore managed by financial institutions that provide accounts as a service. The central system only needs to notify the ID management system 151 or another node that manages the identity records of the parties to initiate withdrawals or deposits with the financial institutions. In some embodiments, parties registered with the central system may be required to have associated accounts, but the government and / or central bank may encourage account opening among those who do not have such accounts (for example, by providing incentives to financial institutions).

[0089] In some embodiments, the format of the virtual currency may offer variable denominations, as described in the Federal Reserve's technical proposal published in February 2022. The denomination field used to specify a fixed denomination may also specify a type indicating a variable denomination, which could serve as an alternative to specifying the amount of coins.

[0090] As long as virtual currency has a unique identifier, it can be tracked using the SFIOI format. Therefore, as long as virtual currency has a unique identifier that can be used for tracking purposes, virtual currency can be a complete dataset containing image data, a partial dataset containing logical data supplemented by templates when visualization of virtual currency is requested, an encrypted dataset such as cryptocurrency, or any other type of dataset.

[0091] Financial institutions and other types of organizations may also be provided with the ability to issue party IDs as described herein. For example, financial institutions may be provided with four- or five-digit unique identifiers so that the unique identifier can be 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, the central system does not need to store the identity information of the parties, but instead can rely on financial institutions to know who a party ID corresponds to. At least in the United States, financial institutions store party IDs, and if 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, the central system may provide banks with unique IDs for the parties involved and allow the banks to decide which parties to assign unique IDs to.

[0092] In some embodiments, a party may be provided with a function to automatically deposit received virtual currency into a related account, for example, if they receive virtual currency from an unknown party. From a security standpoint, since the unknown party may know which virtual currency has been transferred to the party, a function to automatically, or at least quickly, transfer virtual currency to a related account may help deter impersonation by an unknown party. Furthermore, once the virtual currency has been transferred to a financial institution and deposited into a related account, the financial institution only needs to hold the virtual currency and issue a credit as an update to the party's ledger balance, thereby allowing the party to begin collecting interest. In some embodiments, party IDs can be used to track cashier's checks, traveler's checks, stablecoins, and other fixed-denomination representations of the underlying country's currency, as long as they are uniquely identified.

[0093] The type of an SFIOI may be specified by a field required by the SFIOI format, for example, a full-byte field or a 2-bit or 3-bit field. Since the tracking described herein can be extended to many other uses, the type field may contain a full byte so that, even if only one or a relatively small number of types are used for the NDC tracking described herein, up to 256 different types can ultimately be specified using the same format.

[0094] In the Internet network router configuration shown in Figure 7A, the network router system restricts communication to the central system 150 to non-sequenced packets (i.e., single packets) SFIOIs sent as UDP / IP packets (or non-sequential TCP / IP packets). The network router system in Figure 7A can be extended to various applications. For example, the SFIOI format examples described herein can be adapted to all sorts of other applications, such as when an entity wants to prevent a server from receiving connection requests, allowing a server to send a single packet request to initiate a communication connection with a requesting device. Other examples include tracking real estate, loans, etc. As shown and described in Figures 7A, 7B, 7C, 7D, 7E, and 7F, the SFIOI packets may be subject to other basic safety checks before reaching the security gateway system 156.

[0095] Other basic safety requirements may be implemented within the Internet, such as at the edge of the Internet closest to the security gateway system 156. For example, one or more network routers within the Internet provided by a network service provider may be configured and programmed to ensure that packets addressed to IP addresses corresponding to the central system described herein are exactly 512 bytes and / or are non-sequential UDP / IP packets or non-sequential TCP / IP packets and not sequential TCP / IP packets. Alternatively, these checks may be provided after processing by the last Internet router in the Internet and before the packet reaches the security gateway system 156. For example, a modified safety system based on an Internet router may intercept packets destined for one or more specific IP addresses and perform one or more preliminary checks, such as compliance with exact size requirements or prohibition of TCP / IP packets. However, such preliminary checks delay processing by the modified safety system because each check substantially doubles the original basic processing requirement for the Internet router (i.e., checking the destination IP address and routing the packet according to the routing table). On the other hand, modern high-end internet routers handle a massive volume of packets per second or minute, equivalent to or exceeding the volume expected of the central system 150. Therefore, one or a very small number of modified safety systems based on modifications to the high-end internet router can perform one or more of the most basic safety checks before packets reach the security gateway system 156. This helps to repel DoS attacks, and in particular, the number of modified safety systems can be dynamically scaled to minimize disruption to the central system 150 when a DoS attack is anticipated.

[0096] The modified network router or switch may use DDR4 random access memory (RAM) instead of flash memory to temporarily store packets while they are being processed. For example, after storing a packet in DDR4 RAM, the destination IP address is read out and compared with the routing table, and if the routing table has been modified to indicate that packets destined for that destination IP address are subject to a preliminary safety check, the preliminary safety check is performed. The safety checks in the modified router or switch may be very basic, such as verifying that the packet is of a certain size or below a threshold, or verifying that the packet is sent over UDP or non-sequential TCP. In other embodiments, most routers of a network service provider may be configured to simply send packets addressed to a specific destination IP address to a service node that performs safety checks, and then pass those packets to the specific destination IP address. The service node may include one or more modified routers or other forms of high-speed processing environments that add one or a few safety checks to packets destined for a specific IP address, requiring that the packet meets expected formatting requirements. For example, a service node may be offered as a standalone service, similar to a picket system, that filters packets destined for one or more destinations that require the packets to conform to a specific format, such as a 512-byte format.

[0097] Furthermore, since one or a few network routers are located in the network closest to the security gateway system 156 (logically and / or physically), one or a few network routers may be specifically programmed to perform packet checking over the internet. Additional network routers may be configured to dynamically adjust to perform packet checking when instructed, for example, if a network service provider detects that the IP address of the security gateway system 156 is under a DoS attack. For example, in the default configuration, basic safety requirements are performed by the three network routers closest to the security gateway system 156 in the network (logically and / or physically), but if a DoS attack is detected, the next nine, 27, or 97 closest network routers may be dynamically adjusted to begin detecting and deleting packets that are too large or too small, or packets addressed to the wrong type of IP address.

[0098] As an addition or alternative, one or more additional network routers may be kept in a de-service state within or just outside the central system and dynamically deployed to the service to begin assisting with basic safety checks on packet size and type when a DoS attack is detected. The additional network routers may be inserted between the security gateway system 156 and the internet and may be dynamically activated when instructed to perform packet checking. For example, in the default configuration, basic safety requirements are performed by the three network routers (logically and / or physically) closest to the security gateway system 156 in the network, but when a DoS attack is detected, an additional three, or 27, or 97 additional network routers may be dynamically spun up and assigned traffic destined for the security gateway system 156 to begin detecting and deleting packets that are too large or too small, or packets addressed to the wrong type of IP address.

[0099] In Figure 7A, the specialty internet service provider (ISP) 7140 is a dedicated internet service provider. For example, a government or private company might want to set up a specialty ISP 7140 for last-mile routing to a central system that provides a security gateway system 7156. The specialty ISP 7140 can also provide dedicated packet routing for one or more other service providers, a central system, etc.

[0100] In Figure 7A, specialty ISP 7140 includes a first Internet network router 7141, a second Internet network router 7142, and a third Internet network router 7143. Each of the Internet network routers in Figure 7A may be configured to perform one or more safety checks on packets addressed to one or more predetermined Internet protocol addresses. One or more safety checks are added to the core function of the Internet network router, which routes packets at extremely high speeds. Therefore, imposing safety checks on packets addressed to one or more predetermined Internet protocols slows down the routing of packets processed by specialty ISP 7140 compared to other Internet traffic.

[0101] Various logical configurations can be used to ensure that an Internet network router operates correctly for some or most traffic. For example, Internet protocol addresses treated as last-mile destination services by an Internet network router may be aggregated so that one Internet network server maintains a list of Internet protocol addresses for which special safety procedures are performed. In other words, the Internet network router in Figure 7A may be specifically designated to perform one or more safety checks on traffic to one or more Internet protocol addresses that are last-mile routers. Furthermore, in the event of a DoS attack, one Internet network router may request assistance from one or both other Internet network routers to initiate traffic processing and perform the same safety checks on the same one or more Internet protocol addresses that are subject to special treatment. There are no requirements regarding the maximum or minimum number of Internet network routers that can be used to implement one or more safety procedures by default. Nor are there any requirements regarding backup Internet network routers that can be dynamically deployed to implement one or more safety procedures in the event of a DoS attack.

[0102] In the Internet network router configuration of Figure 7B, since the Internet network router in Figure 7A is located in the central system 7150, the Internet network router becomes a receiver of traffic to one or more Internet protocol addresses in the central system 7150. Because the Internet network router in Figure 7B is dedicated to the central system 7150, it does not provide routing services to third-party Internet protocol addresses. In Figure 7B, one Internet network router is assigned to perform one or more safety checks, and the other two Internet network routers may be dynamically activated or deployed to handle traffic and implement safety checks when a DoS attack is detected.

[0103] In some embodiments based on Figures 7A and 7B, two or more Internet network routers may be provided in a chain, in which case each of the two or more Internet network routers performs different safety checks. For example, the first Internet network router may check the size of each packet for a listed Internet protocol address and delete packets that are larger or smaller than 512 bytes, or packets that do not fall within the range of 512 bytes. The second Internet network router may check the header of each packet for a listed protocol address and verify that the packet is sent according to UDP / IP rather than TCP / IP. In this way, packets may be processed by multiple Internet network routers, each subject to different basic safety checks, thereby reducing the burden on the security gateway system 7156.

[0104] In some embodiments based on Figures 7A and 7B, a separate controller (not shown) may coordinate the Internet Network Routers, for example, by increasing the number of Internet Network Servers that handle traffic to a specific Internet Protocol address and perform safety checks when a DoS attack is detected. The separate controller may be configured to monitor a set of Internet Network Routers, or it may be completely isolated from the Internet or the public. The number of Internet Network Routers brought in to handle the increased traffic due to a DoS attack is not limited to two, but can be any number, such as 27, 97, or 997, which are logically and / or physically closest to the target Internet Protocol address. Furthermore, the Internet Network Routers are not necessarily invoked simultaneously, but may be invoked in stages. For example, in the first stage, two Internet Network Routers may be assigned to assist with safety checks for the target Internet Protocol address, and in the second stage, eight additional Internet Network Routers may be assigned to assist with safety checks for the target Internet Protocol address.

[0105] Based on the embodiment shown in Figure 7A, Specialty ISP 7140 can provide safety services for dedicated Internet Protocol addresses. While the safety checks are initially associated with the NDC and designed for traffic destined for the central system 150, Specialty ISP 7140 can provide similar services to one or more other government or private sector providers. In other words, Specialty ISP 7140 can provide safety services as an independent service, not limited to the central system 7150.

[0106] In the method of filtering packets before they reach the Internet Protocol destination address shown in Figure 7C, the packet is received at S710, and the destination Internet Protocol address (destination IP) and routing policy are read at S720. At S730, it is determined whether the destination IP is flagged, such as if it is specifically mentioned in the routing table or if it is part of a group of Internet Protocol addresses that are subject to special handling and are flagged in the routing table. If the packet is not flagged (S730=No), the packet is routed normally at S740. If the packet is flagged (S730=Yes), the format parameters to be checked are checked at S760. If the packet is compliant (S760=Yes), the packet is routed normally at S740. If the packet is not compliant (S760=No), the packet is deleted at S770. The method in Figure 7C may also be performed by a modified safety system within the Internet network. The modified safety system may also be a modified router or switch, which is simply modified to check one or more parameters of packets destined for destination IPs that are flagged in the routing table. Any such router or switch should be positioned as the most logical and / or physically closest router or switch to a destination IP in the Internet network, or as one of the most logical and / or physically closest routers or switches.

[0107] In the security gateway system of Figure 7D, in a communication system for filtering packets before they reach an Internet Protocol destination address, the first modified safety system is shown as MSS7148 and the second modified safety system is shown as MSS7149. MSS7148 and MSS7149 can perform safety checks of the type described in the manner of Figure 7C. MSS7148 and MSS7149 may reside within an Internet network, such as a dedicated Internet service provider network. Alternatively, MSS7148 and MSS7149 may be provided as a dedicated picket system for a central system as described herein. In other embodiments, MSS7148 and MSS7149 may be provided as a dedicated picket system for a group of end-user systems, such as a central system as described herein, and for other organizations that may benefit from safety checks performed on specific packets before they reach a destination IP address.

[0108] In the security gateway system of Figure 7E, in a method for distributing safety checks for packets addressed to an Internet Protocol destination address, the first MSS 7148 performs a method that includes demodulating the first received signal, storing the packet from the demodulated signal in a register, checking the size of the packet, modulating the packet with the second signal, and forwarding the packet via the second signal if the packet satisfies the size requirements of the destination IP address. The security gateway system 7156 of the central system 7150 performs a method that includes demodulating the second signal, storing the packet from the demodulated signal in flash memory on a one-to-one basis or similar, and executing a safety subprogram to ensure that the packet satisfies the assumed format and safety controls implemented by the security gateway system 7156.

[0109] In the security gateway system of Figure 7E, in a method for distributing safety checks for packets addressed to an Internet Protocol destination address, the first MSS 7148 performs a method that includes demodulating the first received signal, storing the packet from the demodulated signal in a register, checking the header information from the packet, modulating the packet with the second signal, and forwarding the packet via the second signal if the header information from the packet satisfies the destination IP address requirements. The security gateway system 7156 of the central system 7150 again performs a method that includes demodulating the second signal, storing the packet from the demodulated signal in flash memory on a one-to-one basis or similar, and executing a safety subprogram to ensure that the packet satisfies the assumed format and safety controls implemented by the security gateway system 7156.

[0110] There are many use cases for securely implementing NDCs using the technologies described herein. One security challenge addressed herein is the vulnerability that arises when exchanging virtual currency for another virtual currency, allowing the sender or an accomplice of the sender to impersonate the recipient and instruct the central system via SFIOI to return ownership of the virtual currency to the sender or accomplice.

[0111] As described herein, the central system described herein can initiate anti-spoofing (e.g., multi-factor) communications to the recipient's recorded address. Furthermore, to circumvent this scenario, the recipient can provide new virtual banknotes to a financial institution in exchange for deposits into the financial institution's account, such as by automatically exchanging virtual banknotes from an unknown party with the central system or by depositing virtual banknotes into a current account or savings account (modified for virtual banknotes). Low-denomination virtual banknotes can also be integrated into high-denomination virtual banknotes in the central system. These and other mechanisms, made possible by the teachings herein, can be used to securely circumvent all or almost all forms of fraud that cannot be securely provided by today's technology. As an example, tracking virtual banknotes in the central system described herein allows parties to quickly transfer virtual banknotes to financial institutions, thereby preventing previous owners from fraudulently impersonating owners to regain control of the virtual banknotes.

[0112] In another use case, if a trading partner pre-transmits a unique identifier for virtual currency provided by the party initiating the transaction to a central system, the unique identifier may be encrypted within the SFIOI. Since the unique identifier can only be decrypted by the central system, the central system can respond to the trading partner by indicating whether the virtual currency belongs to the party initiating the transaction and can verify the face value of the unique identifier. This can occur even if the trading partner does not have an underlying unique identifier, so the trading partner cannot possess the unique identifier for the virtual currency presented for payment until the transaction takes place. Therefore, by providing both an unencrypted and an encrypted unique identifier with the virtual currency, the trading partner can send the unencrypted version in advance for authentication before accepting the virtual currency for payment of the transaction.

[0113] Furthermore, in many communications, the use of encryption mechanisms such as SSL may be assumed for 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.

[0114] While the security mechanisms of digital currencies have been described in relation to virtual banknotes, the teachings herein are not limited to their application to virtual banknotes or any specific NDC (National Digital Currency) certified 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.

[0115] 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 a plurality of algorithms for imposing safety checks on the packets, wherein the packets are required to conform to a predefined format that specifies requirements for fields at predetermined relative positions in the payload of an acceptable packet; each algorithm processes the packet by checking whether the data in the fields at predetermined relative positions in the payload of the packet conforms to the predefined format; the packets are individually stored in memory units of the same size in the security gateway system; each of the plurality of algorithms is executed by a different thread; and each of the threads imposes at least one safety check on the data of each packet processed by the thread until each packet processed by the thread passes all required safety checks, or until each packet processed by the thread fails any of the safety checks and the processing of the packet by the thread is deemed complete; A main memory system isolated from the public by the security gateway system, which pre-stores records of all instances of the digital assets to be tracked for a centralized tracking system, and updates the records in response to instructions from the public that have passed the safety check. A centralized tracking system, including [the following].

2. The centralized tracking system according to claim 1, further comprising a ledger storage system that is physically separated from the main memory system, isolated from the public by the security gateway system, stores a record of the current ownership of instances of the tracked digital assets, and verifies whether the ownership listed in the packet is correct for at least one of the tracked digital assets listed in the packet.

3. The centralized tracking system according to claim 2, wherein the plurality of algorithms in the security gateway system transmit packets to the ledger storage system for ownership verification.

4. The packets received by the security gateway system are pre-filtered before they are received by the security gateway system in order to ensure compliance with the predefined format required for processing the packets in the centralized tracking system. The packets received by the security gateway system are subsequently filtered by the plurality of algorithms to ensure that they conform to the predefined format. At least one of the pre-filtering before the security gateway system or the post-filtering at the security gateway system includes a size check to ensure that each packet conforms to a specific size required by the predefined format. The centralized tracking system according to claim 1.

5. The centralized tracking system according to claim 1, wherein the plurality of algorithms are executed in parallel to process different packets simultaneously.

6. The aforementioned packets are limited to individual non-sequence packets. Each instance of the tracked digital asset is assigned a unique identifier used to track the tracked digital asset. The centralized tracking system according to claim 1.

7. A security gateway system interfaces with the public via the internet, wherein the security gateway system comprises memory and a processor, and the interface with the public Storing packets received via the Internet into the memory, wherein the packets are individually stored in memory units of the same size in the security gateway system, the packets are required to conform to a predefined format that specifies requirements for fields at predetermined relative positions in the payload of an acceptable packet, and each algorithm processes the packet by checking whether the data of the fields at predetermined relative positions in the payload of the packet conforms to the predefined format. Executing a plurality of algorithms for imposing safety checks on each packet received via the Internet, wherein each of the plurality of algorithms is executed by a different thread, and each algorithm is executed by the thread until all required safety checks have been passed for each packet processed by the thread, or until each packet processed by the thread fails to pass any of the safety checks and the processing of the packet by the thread is deemed complete. The security gateway system isolates the main memory system from the public, To update the records of all instances of the digital asset to be tracked, which are pre-stored in the main memory system, in response to instructions from the public that have passed the safety check, A centralized tracking method, including...

8. The method according to claim 7, further comprising rejecting connection requests from the public in the security gateway system.

9. The method according to claim 7, further comprising isolating the ledger storage system from the public by the security gateway system, wherein the ledger storage system is physically separated from the main memory system, stores records of current ownership of instances of the tracked digital assets, and determines whether the ownership listed in the packet is correct for at least one tracked digital asset listed in the packet.

10. The method according to claim 9, further comprising the plurality of algorithms in the security gateway system transmitting packets to the ledger storage system for ownership verification.

11. The packets received by the security gateway system are pre-filtered before they are received by the security gateway system in order to ensure compliance with a predefined format necessary for processing the packets in the centralized tracking system. Each packet received by the security gateway system is subsequently filtered by the plurality of algorithms to ensure that it conforms to the predefined format. At least one of the pre-filtering before the security gateway system or the post-filtering at the security gateway system includes a size check to ensure that each packet conforms to a specific size required by the predefined format. The method according to claim 7.

12. The method according to claim 7, wherein the plurality of algorithms are executed in parallel to process different packets simultaneously.

13. The aforementioned packets are limited to individual non-sequence packets. Each instance of the tracked digital asset is assigned a unique identifier used to track the tracked digital asset. The method according to claim 7.

14. The centralized tracking system according to claim 1, wherein each of the plurality of algorithms is implemented by a different thread dedicated to the algorithm and is executed on a multicore processor.

15. The method according to claim 7, wherein each of the plurality of algorithms is implemented by a different thread dedicated to the algorithm and is executed on a multicore processor.

Images