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 to U.S. Provisional Patent Application No. 63 / 148,335, filed February 11, 2021, U.S. Provisional Patent Application No. 63 / 173,631, filed April 12, 2021, U.S. Provisional Patent Application No. 63 / 209,989, filed June 12, 2021, U.S. Provisional Patent Application No. 63 / 240,964, filed September 5, 2021, U.S. Provisional Patent Application No. 63 / 294,732, filed December 29, 2021, and U.S. Provisional Patent Application No. 63 / 304,684, filed January 30, 2022, the entire contents of which are incorporated herein by reference. [Background technology]

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

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

[0004] [Figure 1A] FIG. 1 is a diagram showing an overview of the NDC life cycle. [Figure 1B]FIG. 1 shows tracking of NDC. [Figure 1C] FIG. 1 is a diagram showing a central system (hereinafter sometimes abbreviated as "CS") for tracking NDC. [Figure 2A] FIG. 1 illustrates a method for processing short, formatted inquiries and instructions (hereinafter referred to as "SFIOI") for NDC. [Figure 2B] FIG. 1 illustrates a method for processing SFIOI. [Figure 2C] FIG. 1 illustrates a method for processing SFIOI. [Figure 2D] FIG. 1 illustrates a method for processing SFIOI. [Figure 2E] FIG. 1 illustrates a method for processing SFIOI. [Figure 2F] FIG. 1 illustrates a method for processing SFIOI. [Figure 3A] FIG. 1 illustrates the flow of NDC cloud-based transactions. [Figure 3B] FIG. 1 is a diagram showing a system for storing records of NDC virtual notes (hereinafter sometimes abbreviated as "VN"). [Figure 4A] A diagram showing how the security gateway system processes a received SFIOI. [Figure 4B] FIG. 2 is a diagram illustrating a processing configuration of a security gateway system. [Figure 4C] A diagram showing how the security gateway system processes a received SFIOI. [Figure 4D] FIG. 1 illustrates a method for security checking in a memory system of a central system. [Figure 4E] FIG. 1 illustrates a method for security checking in a memory system of a central system. [Figure 5A] A diagram showing the memory configuration of a security gateway system that processes a received SFIOI. [Figure 5B] A diagram showing the memory configuration of a security gateway system that processes a received SFIOI. [Figure 5C] A diagram showing the memory configuration of a security gateway system that processes a received SFIOI. [Figure 5D] A diagram showing the memory configuration of a security gateway system that processes a received SFIOI. [Figure 6] FIG. 13 is a diagram showing an example of the format of SFIOI. [Figure 7A] A diagram showing the arrangement of Internet network routers. [Figure 7B] A diagram showing the arrangement of Internet network routers. [Figure 7C] FIG. 2 illustrates a method for filtering packets before they reach an Internet Protocol destination address. [Figure 7D] FIG. 1 illustrates a communication system for filtering packets before they reach an Internet Protocol destination address. [Figure 7E] 1 illustrates a method for distributing safety checks for packets addressed to an Internet Protocol destination address in a security gateway system. [Figure 7F] 1 illustrates a method for distributing safety checks for packets addressed to an Internet Protocol destination address in a security gateway system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

[0006] If centralized tracking is used to implement a national digital currency (NDC), many aspects of security must be addressed. The central system that tracks the NDC must interface with the public and must be kept secure from all possible forms of threats. There is a widespread belief in the technological world that nothing connected to the public via the Internet is secure. In other words, the central system must be accessible to any individual in the world with an Internet connection, but must be able to filter or reject any possible threat posed by any individual in the world with an Internet connection. One aspect of security that could be a starting point to challenge this thinking is for governments to define what is acceptable in the central system and take measures to block and eliminate anything that falls outside of what is defined as acceptable.

[0007] In the overview of the NDC life cycle shown in FIG. 1A, virtual banknotes (VN) are transferred between a central system 150 and electronic communication devices (ECDs) controlled by the parties, such as by initial allocation of the virtual banknotes to financial institutions after their creation in step A. NDC virtual banknotes may be defined data sets, each assigned a unique identification (ID), denomination, and source of the virtual banknote, although other information may be included. The central system 150 and any other central system described herein are centralized tracking systems. Thereafter, in steps B, C, D, E, the virtual banknotes are transferred between multiple electronic communication devices (device 101, device 102, device 103, device 104) controlled by different parties. Then, in step F, the virtual banknotes are returned to the central system 150 for temporary or permanent redemption, etc. The devices (e.g., device 101, device 102, device 103, device 104) used to communicate the virtual banknotes are electronic communication devices such as computers and cell phones. The virtual banknotes may be packetized and communicated over a packet-switched network that switches packets according to the Transmission Control Protocol / Internet Protocol (TCP-IP) and / or User Datagram Protocol (UDP-IP). The central system 150 of FIG. 1A may create, distribute, track, and / or redeem the virtual banknotes.

[0008] In the NDC trace shown in FIG. 1B, the transaction requester and / or the trading counterparty send short, formatted inquiries and instructions (hereinafter referred to as "SFIOI") to the central system 150 to inquire about the ownership of the virtual banknote or to give instructions to transfer the ownership of the virtual banknote. For example, the trading counterparty can pre-verify to the central system 150 that the transaction requester owns the virtual banknote, and the central system 150 can transfer the virtual banknote based on the instructions in the SFIOI. The format of the SFIOI is defined by the source of the virtual banknote. The use of a pre-defined format allows electronic communication devices used by the public to ensure compliance, and the SFIOI packets may be pre-filtered before the packets are received at the Internet Protocol address of the security gateway system 156, and may be post-filtered by an algorithm executed in the security gateway system 156 to ensure that the packets conform to the pre-defined format.

[0009] The central system 150 may generate and send a multi-factor push notification to the electronic communication device to confirm the transfer or inquiry purportedly initiated by the electronic communication device. It is assumed that the electronic communication device initiating the transaction or transfer notification is in the possession of the transaction requester so that the transaction requester can reasonably anticipate multi-factor authentication in real time. Since the notification may be provided to the communication address of record of the owner of record, the transaction requester may be separately notified by the central system 150 to provide or confirm consent to the transfer of the virtual note only if the transaction requester is the owner of the virtual note. In some embodiments, the counterparty may be verified by the central system that the transaction requester is the owner of the virtual note without the central system having to confirm to the transaction requester that the virtual note is being transferred, such as when the transaction requester provides verification information to the transaction requester that uniquely identifies the transaction requester. Because the risk that a counterparty can infer that any particular party is the record owner of any particular virtual note is extremely low, and because central system 150 can impose severe penalties for inaccurate SFIOIs, a counterparty's presentation of verification information to central system 150 enables central system 150 to assume that the transaction requester has consented to the transfer of the virtual note.

[0010] The SFIOI may be sent to a predefined hostname or IP address of central system 150. Transfers of virtual notes may be reported to central system 150 by one or both of the transaction requesters upon sending the virtual note and upon receiving the virtual note.

[0011] Grey lists may be maintained for virtual notes for a variety of reasons, including the frequency of transfers by the transaction requester, the frequency of activity by the transaction requester (e.g., handling of large numbers of virtual notes), and many other reasons. Grey lists may also be maintained for parties, such as transaction requesters, that are subject to special monitoring. In some embodiments, a transaction requester may be prohibited from reacquiring ownership of a virtual note after transferring ownership of the virtual note for a predetermined minimum number of intervening different owners, such as two or five, or within a predetermined time frame, such as 48 hours.

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

[0013] In the central system for tracking NDC shown in FIG. 1C, a security gateway system 156 is used as an interface between the public and other elements of the central system 150. The central system 150 includes a security gateway system 156, an identity management system 151, a ledger storage system (LSS) 152, a main memory system 153, an artificial intelligence and analytics system 154, and a backup memory system 155. The arrows in FIG. 1C indicate that in some cases, communication between elements of the central system 150 may be limited to mostly or entirely one-way communication. In an embodiment based on FIG. 1C, communication from at least the public may be limited to the security gateway system 156. Intermediary service providers with a large customer base who wish to send encrypted communications may be granted access to a nearby facility adjacent to the security gateway system 156 so that appropriate encryption can be provided to the endpoints at the nearby facility and then decrypted and fed directly to the security gateway system 156.

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

[0015] The ledger storage system 152 is used to keep a record 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 an inquiry at the SFIOI passes the security check at the security gateway system 156. The ledger storage system 152 is updated from the main memory system 153 as virtual banknotes are transferred through the SFIOI. The ledger storage system 152 may be used to quickly track and verify ownership of virtual banknotes by storing records of the virtual banknotes hierarchically in alphabetical, numerical or alphanumeric order. In this way, the records of the virtual banknotes may be searched 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 a record of the current ownership of each instance of the tracked digital asset (e.g., NDC virtual banknote). In some embodiments, the security gateway system 156 may in all or almost all cases confirm to the ledger storage system 152 the ownership of virtual banknotes listed in the SFIOI, to the extent that it may always or almost always be an important safety check for the SFIOI to verify that the sender of the SFIOI has accurate knowledge of the ownership of all virtual banknotes listed in the SFIOI.

[0016] The main memory system 153 includes one or more databases, solid state storage (SSD), and / or other forms of memory suitable for storing millions, billions, or even trillions of data items, such as unique identifiers for virtual banknotes, electronic wallet programs, currency reader programs, parties, electronic communication devices, etc. 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 banknotes 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 only public interface for the central system 150 of FIG. 1C.

[0017] The central system 150 provides a number of internal security measures. For example, the ledger storage system 152 is effectively isolated, or at least can be isolated, from the identity management system 151. The main memory system 153 and the identity management system 151 can communicate with one-way communication with no or minimal interaction. The artificial intelligence and analysis system 154 may only be provided with access to the main memory system 153 and may be completely closed off from the public and available only to approved government officials and approved researchers. The backup memory system 155 may also be completely closed off 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, such as by being implemented in a civilian data center that is underground and shielded from electromagnetic pulses (EMP). Updates to the main memory system 153 and backup memory system 155 equipment may be limited to updates performed locally, and the main memory system 153 and backup memory system 155 may be completely isolated from the public, insofar as they may be used to store records relating to virtual banknotes based on instructions provided via the SFIOI processed by the security gateway system 156.

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

[0019] The security gateway system 156 may provide access to law enforcement, post office, banking and similar entity systems, and other government agencies, such as the offices of secretaries of states, through dedicated and / or otherwise secure lines or communication channels, or through one or more call centers. The security gateway system 156 acts as a controlled access point with only publicly exposed Internet Protocol addresses for the central system 150, and restricts any access to other elements of the central system 150 such that there is no direct access from the public to the other elements. The security gateway system 156 functions to shield the main memory system 153 and other components of the central system 150 from the public. Any communication that does not fit the specific format of the SFIOI may be discarded without exception.

[0020] The security gateway system 156 can execute complex software that systematically performs comprehensive safety checks on the SFIOI received at the central system 150. Software capable of performing comprehensive safety checks on the security gateway system 156 can quickly and efficiently process a large amount of suitable SFIOI and detect and remove others. The full set of flexible software sub-applications can be adapted to any of the various formats established for SFIOI used in any central system the same or similar to those described herein. Each of the software sub-applications contains instructions for various algorithms, each performing a different task or tasks than the other software sub-applications. In other words, each of the software sub-applications is unique and specialized for a different task compared to the other software sub-applications. The sub-applications or cores of a multi-core processor do not execute or process an entire packet of SFIOI, instead the sub-applications process different portions of each packet. The software sub-applications may be provided as software programs or as pre-programmed dedicated multi-core processors implementing the software programs. Multiple types of software sub-applications may be provided as safety programs in the security gateway system 156 and are capable of detecting various types of corruption of the SFIOI so that a corrupted SFIOI is detected and not processed in the same manner as an uncorrupted SFIOI.

[0021] Mandating 512 bytes or other size 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 the virtual note corresponds to the provider of security gateway system 156. In another example, security gateway system 156 may check whether each virtual note specified in the SFIOI actually belongs to party #1 named as the owner in the SFIOI. Security gateway system 156 may check to ensure that NULL fields are NULL, that header information such as hop count is exactly as expected (e.g., 0), and that fields assigned to one or more virtual notes are as expected (e.g., #8 and #9 are NULL if the virtual note number (VN number) is identified in the SFIOI or specifies no virtual note).

[0022] Thirty-two bits (four bytes) is more than enough to uniquely identify the U.S. population with a unique identifier for the NDC. Eight bits (one byte) is more than enough to uniquely identify each country with a unique identifier for the NDC. Sixteen bits (two bytes) is more than enough to uniquely identify each bank or similar entity in the U.S. with a unique identifier for the NDC. The unique party identifier may be available through a financial institution such as a bank or similar entity. The unique identifier for the bank or similar entity may be part of the unique identifier for the party. A unique party identifier assigned by a bank or similar entity may require more than four bytes, for example five bytes, to accommodate a bank or similar entity with a very large customer base of more than 500,000. One advantage of having a bank or similar entity assign a unique party identifier for the NDC is that the party profile may be maintained at the bank or similar entity rather than maintained at the central system 150. Similarly, a unique party identifier for the NDC for an individual who does not have a bank account may be provided through a local branch of the national postal service. National postal service branches may be equipped with digital fingerprint pads that any individual with a finger can use to uniquely identify themselves. The postal service may retain the fingerprints, names, and / or other information provided by unbanked parties while using the digital fingerprint pads to verify existing identities and transmit the unique party identifier to the identity management system 151.

[0023] The processing environment of security gateway system 156 can logically store large amounts of pre-filtered SFIOIs in flash memory pages on a 24 / 7, one-to-one basis. A set of coordinated software safety sub-applications may be executed by a single multi-core processor in security gateway system 156 on SFIOIs arriving at security gateway system 156. The safety sub-applications can be executed on SFIOIs stored in flash memory pages in a first-in, first-out (FIFO) sequence. Each safety sub-application performs its assigned type of safety processing in the same manner for each SFIOI it is allowed to process. The processing of each page is highly coordinated by staggering the safety sub-applications to execute in a predetermined order on each page until all safety sub-applications have processed the SFIOIs on the page.

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

[0025] The SFIOI and central system 150 technology, including security gateway system 156, may also be used for other purposes, such as updating passport holder travel records, tracking other information such as real estate ownership and associated mortgages, automobile ownership and associated automobile loans, digital entertainment and computer software ownership, digital rights management (DRM) related to digital entertainment and computer software, and private company stock ownership and associated private company debt.

[0026] The security gateway system 156 of the central system 150 includes multiple nodes, each of which may be capable of processing tens of thousands (e.g., 40,000 or more) of legitimate SFIOIs per minute. The safety sub-applications described herein may be configurable to process uniform formats that specify data sizes other than 512 bytes or 256 bytes. Incoming SFIOIs may be stored in a sequential address space (i.e., flash memory pages) with 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 a flash memory page.

[0027] The set of safety sub-applications performs a different safety processing for each SFIOI they receive as a condition of responding to any inquiry or executing any instruction. To perform its function, each safety sub-application processes only one or more specific bytes in the same relative location on each page, and does not process bytes that are expected to contain no substantive data unless it is tasked with verifying that they do not contain any substantive data.

[0028] Processing in the security gateway system 156 can be visualized as a fourth dimensional process. A 512-byte page is a two-dimensional memory with 64 64-bit word lines. Each safety sub-application moves incrementally between the pages in the third dimension, processing the same byte or word in each page. The safety sub-applications are staggered in time as a fourth dimension to avoid collisions of simultaneously trying to read and write from the same byte or word. Additionally, ownership checks of the fourth type of safety sub-application necessarily involve a timing offset. This is to prevent the core that sent the pair from hanging waiting for a response, with one set of cores sending pairs to the ledger storage system 152 and another set of cores processing the response from the ledger storage system 152.

[0029] The status update system may use the same memory pages used to store the SFIOI. The status update system is used to synchronize the safety sub-applications when processing a large amount of SFIOI. Tracking the NDC may require a large number of write cycles to the memory used to store the SFIOI. If the same memory cells, or the same type of memory cells, are used to update the status 10-20 times during processing of each SFIOI, the number of write cycles to the status memory cells will be many times the number of write cycles to the memory cells used to store the SFIOI. This means that when the status memory cells wear out, the entire memory may wear out 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 cells 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, the SFIOI may be stored in a 512-byte page on a one-to-one basis, but, for example, the eight 64-bit NULL processing words at the end of the SFIOI may not be written to the page. Alternatively, memory cells at the end of the page may be used to track the status of the safety sub-application, allowing the safety sub-application to check the appropriate status word / byte before performing a safety operation on the SFIOI and to update a different status word / byte after performing the safety operation. The status checking and status update 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 memory cells used to store the substantive data of the SFIOI, thereby extending memory life by at least 1000% compared to repeatedly writing status updates to the same byte 10 or more times for status updates during processing of each SFIOI.

[0030] Even if avoiding hangs waiting for responses from the ledger storage system 152 is the main or one of the main reasons why all safety processing is not implemented linearly by standalone cores of a multi-core processor, requiring proof that the purported owner named in each SFIOI is the actual owner can be an important safety measure. Other hangs may be mandated if checks such as owner-specific processing instructions, blacklists and greylists are performed.

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

[0032] Hundreds or thousands of multi-core processor and flash memory pairs may be uniformly installed in any security gateway system 156. The multi-core processor and flash memory pairs may be used in groups in rotation. Each safety sub-application may check (read) one assigned status field before processing to ensure that the safety sub-application is cleared to process 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 the update before performing safety processing on the SFIOI. The set of safety sub-applications may check each SFIOI for at least the following items: ○ Verify that the SFIOI was received by the correct central system 150 An exemplary algorithm includes checking the status and, if approval to proceed, reading one or more bytes of the VN origin field, comparing that value to an expected value, such as 187, and updating the status depending on the comparison. Confirm that the payload size of the SFIOI satisfies the expected number of VNs specified in the SFIOI. For example, if a field indicates that the SFIOI specifies six virtual notes, and the six virtual notes are expected to be listed in words 8, 9, 10, 11, 12, and 13, the sub-application may check words 14, 15, and 16 to ensure that the values ​​of these words are NULL before proceeding. Check that one or more NULL words or NULL bytes are actually NULL Confirmation that one or more NULL bits, such as the bit following the Party ID in a Party ID dedicated word or the bit following the VN ID in a VN ID dedicated word, are actually NULL Verifying that the alleged owner of virtual banknotes is actually the owner An exemplary algorithm includes checking the status and, if approved to proceed, reading one or more bytes in 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 of the ownership check of the VN#1 ID and updates the status field accordingly. Checking the owner's instructions and, if required by the owner's instructions, initiating an outgoing connection from the security gateway system 156 to perform multi-factor authentication to a predefined communication address. An exemplary algorithm includes checking the status and, if approved to proceed, reading one or more bytes in the Party #1 ID field and, upon request of the owner, sending the read data and page number to the ID management system 151 to initiate multi-factor authentication. Another sub-application receives the response from the ID management system 151 and updates the status field accordingly.

[0033] After performing the safety check, the Safety Sub-application may mark the appropriate status fields per 512-byte page or per sector to inform subsequent Safety Sub-applications whether they should perform any processing before proceeding. For example, if any Safety Sub-application detects an error in any SFIOI, the Safety Sub-application may update the status of all update fields to indicate that no further processing is required for the SFIOI of that page by any sub-application. This may be done by simply indicating that all necessary processing has already been performed so that subsequent Safety Sub-applications may skip the SFIOI in which an error was detected.

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

[0035] In the method of processing the SFIOI of the NDC of FIG. 2A, when the central system receives the SFIOI, the method starts in S211. In S212, the central system reads the batch number, sender information, trading partner information, and virtual banknote information (VN information) in the SFIOI. The batch number can specify how many VN information fields are in the SFIOI, so that the central system can know where the substantive data of the VN information field ends. The sender information and trading partner information can 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 can include unique identifiers of one or more VNs specified in the SFIOI. In S213, the central system converts the sender information and / or trading partner information as necessary. That is, if the sender information and / or trading partner information are not of a universal type used by the central system, the central system can convert the sender information and / or trading partner 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 is for the last virtual banknote specified in the SFIOI. If the virtual banknote is not 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 transmits a response to the inquirer or instructor in S219. In addition, if the central system determines that the VN information does not match the current owner indicated in the SFIOI (S215=No), it may delete the SFIOI in S218 and transmit a response to the inquirer or instructor at any time in S219.

[0036] In the SFIOI processing method of FIG. 2B, the sender sends a transfer SFIOI that is received by the central system in S221. Normally, a transfer SFIOI from a proper sender should be accepted by the central system. However, if the central system is programmed to acknowledge receipt of the virtual banknote from the purported recipient, the central system can execute the remaining part of the method shown in FIG. 2B. In S222, the central system caches the VN information of the SFIOI and starts a first timer. The first timer can be, for example, 2 minutes, 5 minutes, or any other relatively short period during which the central system assumes that the recipient has received the virtual banknote and can acknowledge receipt to the central system. In S223, the central system waits for the first time to elapse. When the first time has elapsed, the central system checks whether the recipient has acknowledged receipt of the virtual banknote in S224. If the recipient has acknowledged receipt of the virtual banknote (S224=Yes), the central system updates the record of the virtual banknote in S226 and clears the cache. If the recipient has not acknowledged receipt of the virtual banknote (S224=No), the central system sends an inquiry to the recipient and starts a second timer in S225. The second timer may be the same as or longer than the first timer. For example, the second timer may be longer than one day in case the recipient is asleep or otherwise busy. The central system waits for the second time to elapse in S227. The wait in S227 may be a precautionary measure and is not necessary, such as when it is assumed by default that the virtual banknote has been received. Once the second time has elapsed, the central system determines whether the recipient has acknowledged receipt in S228. If the recipient has not acknowledged receipt after the second time has elapsed (S228=No), the central system notifies the sender and recipient of the transfer cancellation in S229 and clears the cache. If the recipient acknowledges receipt after the second period of time has elapsed (S228=Yes), the central system updates its record of the virtual note and clears its cache at S226.

[0037] The method for verifying a transfer SFIOI of a virtual banknote for NDC of FIG. 2C starts 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 banknote, an identifier that identifies a recipient of the virtual banknote, and an identifier that identifies a source of the virtual banknote. In an embodiment based on FIG. 2C, three independent processes may occur before the electronic history of the virtual banknote 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, a blacklist of parties and a greylist of parties are retrieved. For example, the central system 150 may store the blacklist and greylist. Apart from the blacklist and greylist, other forms of monitoring may be imposed, such as transactions involving large amounts of virtual banknotes or transactions involving parties involved in many other transactions within a relatively short period of time. For example, a virtual note sender and / or virtual note recipient's history may be flagged if they have started using virtual notes relatively recently or are using a relatively recent unique identifier to identify themselves. At S254, the party information is compared to a party blacklist and a party greylist. This comparison may be a simple pattern match to see if the submitted recipient information matches any of the entries in the party blacklist or party greylist. At S255, action is taken if the comparison at S254 results in a match. Actions may include notifying a third party, such as a government agency, in the case of a greylist match, or simply adding an entry of the transfer to records maintained for the monitored recipient. In the case of a blacklist, action may include simply informing the virtual note recipient and / or sender that the sender is not authorized to transfer virtual notes or that the recipient is not authorized to receive virtual notes.

[0038] In the second sub-process, the virtual banknote information is retrieved in S256. The virtual banknote blacklist and the virtual banknote greylist are retrieved in S257. The virtual banknote information of the virtual banknote subject to the SFIOI transfer is compared in S258 with the virtual banknote blacklist and the virtual banknote greylist. The comparison in S258 may be a simple pattern match to see if a unique identifier that uniquely identifies the virtual banknote matches an entry in the virtual banknote blacklist or the virtual banknote greylist. In S259, if the comparison in S258 results in a match, action is taken. Actions that may be taken in S259 include updating the virtual banknote record if the virtual banknote is on the greylist. Actions taken upon a greylist match also include providing the virtual banknote to the central system 150 for inspection of the virtual banknote file and initiating an inspection requirement for the virtual banknote by commanding inspection of the virtual banknote file by a currency reader program or an electronic wallet program of an electronic communication device. If there is a match with a blacklist entry, the actions taken under S259 include simply notifying the recipient and the source of the virtual note that the virtual note is ineligible for transfer.

[0039] In a third sub-process, the registered owner information of the virtual banknote may be retrieved at S260. The third sub-process may be an anti-spoofing process that is selectively applied or always applied to the virtual banknote. At S261, a notification is generated for the virtual banknote of the registered owner. The notification may be addressed to the communication address of record of the registered owner of the virtual banknote and may include a phone number for text messaging, an email address, or another form of communication address for push notification. The communication address may be obtained from records maintained by the central system 150 of the parties registered to transact virtual banknotes, or may be obtained entirely independent of the party information provided with the transfer SFIOI at S251. At S262, the notification is sent, such as via text message, email, or push notification. At S263, the third sub-process includes waiting for a positive confirmation from the registered owner to approve the transfer of ownership of record. The third sub-processing is expected by the source of the virtual banknotes, which may be delivered over a broadband Internet network within seconds of the source issuing the transfer SFIOI, even if the source is on the other side of the globe from the central system 150.

[0040] At S264, the process of FIG. 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 sub-processes, if the greylist requirements are met in the first and / or second sub-processes, and / or if a confirmation is received in the third sub-process. If the transfer is OK (S264=Yes), the electronic history of the virtual banknote is updated in S265. Additionally, 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. Additionally, both the recipient of the virtual banknote 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 of FIG. 2C may be performed whenever ownership of a virtual banknote is transferred and is separate from the inquiry process that is normally performed with a trading partner. In various embodiments based on FIG. 2C, some of the sub-processes of FIG. 2C may be omitted or replaced or supplemented by other sub-processes. The updates in the process of FIG. 2C may be performed in real time or near real time, or periodically in some aspects, but not necessarily in real time or near real time. For example, if the complete set of records of the central system 150 is stored at a central location, the complete set of records may be updated every 12 hours or every 24 hours. An intermediate system remote from the central location may accumulate updates for 12 hours or 24 hours 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 banknote, and can be used for real time ownership inquiry may be updated in real time or may be physically separate from the central location that stores the complete set of records and any intermediate systems that accumulate updates for a period of time, such as 12 hours or 24 hours. In some embodiments, the main memory system may be updated in real time and then used to update secondary ledger storage systems that store limited records such as the current ownership of virtual banknotes, etc. In some embodiments, delayed updates are provided to primary, secondary, and / or tertiary backup systems of record and not to systems of record that require updated records to provide responses to prior ownership queries.

[0042] In the method of FIG. 2D for a central system to process an ownership inquiry for one or more virtual banknotes, at S231 the central system receives an ownership SFIOI for one or more virtual banknotes. The ownership SFIOI may include a party identifier of the inquirer, a party identifier of the alleged owner, and a unique identifier for the one or more virtual banknotes. The ownership SFIOI may be received by the security gateway system 156 of the central system 150. At S232 the central system starts pre-processing of the ownership SFIOI for security purposes. At S232 the central system reads the VN number. Also at S232 the central system checks the VN number against the effective size of the VN information in the VN information field of the SFIOI. The central system may include a range of bytes of the SFIOI to be assumed based on the size of the VN number, and if the size of the effective information in the VN information field exceeds the assumed size, the ownership SFIOI may be deleted at S232.

[0043] The security check in the central system may be performed by systematically processing the incoming SFIOI via a dedicated thread, core, or processor that repeatedly performs the same task on certain fields of the SFIOI, and by masking or otherwise blanking other bits of the read word (e.g., 64-bit word) that are not read as part of the instruction. At S233, the central system retrieves the party information from the ownership SFIOI. The party information may consist of 4 to 8 bytes for each party and be provided as a party identifier in a predefined field of the packet payload of the SFIOI. The processes from S233 to S239 are performed to address aliasing, if allowed. For example, a party may be assigned a universal identifier to use with the central system, but may also associate other identifiers with the universal identifier, such as a phone number, driver's license number, email address, etc. At S234, the central system identifies and validates the country and state or region identified in the party identifier. In some embodiments, the universal identifier may also include a country code so that the central system can primarily recognize external parties registered in other central systems. If a state identification card, such as a driver's license issued by a U.S. state, is used as the party information, the state identification card may also specify which state the party identifier is from. At S234, the central system identifies and validates the country and state / region specified 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. At S235, the central system determines whether the party information is a universal party identifier type. For example, multiple countries, each tracking their own NDC, may agree on a format for a universal party ID, such as a 16-digit identifier with the first two or three digits indicating which state the party is registered in. At S235, the central system determines whether the party identifier is a universal party identifier type.For example, the universal party identifier type may include a country identifier, such as a social security number, or a state identifier, such as a state driver's license number or a state identification number. The central system may be configured to universally process the party ID, and only universal IDs may be accepted and processed. If the party identifier is a universal party identifier type (S235=Yes), then in S239, the universal ID number is retrieved from the final field and verified. If the party identifier type is not a universal ID (S235=No), then in S236, the central system identifies the ID type. For example, the ID type may specify a social network ID and an identifier for that social network, or an identifier indicating a type of carrier or service provider that provides a communication address ID and a communication account corresponding to the 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 for a currency reader program or an electronic wallet program used by a user corresponding to the party ID. In S237, the central system retrieves and validates 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, so that validation in S237 may include checking the ID number against one or more predefined parameters of the ID type, for example for the length of the ID number. In S238, the central system converts the ID number to a universal ID number for use by the central system. The conversion includes retrieving a universal ID from a database lookup table. The universal ID may be used if processing at the central system is only performed using the universal ID, even if the central system accepts other ID types in the SFIOI. In S239, the central system retrieves and validates the universal ID number after conversion in S238 or if the party information is of universal party identifier type (S235=Yes). In S239, the central system retrieves and validates the universal ID number.The universal ID number, whether converted or not, may be used to check against greylists and blacklists. Of course greylists and blacklists may be provided for both universal IDs and other types of IDs, so that parties who are prohibited from using the virtual banknote or who are subject to monitoring are identified and the transaction processed accordingly. Additionally, the party records may be updated to reflect that the virtual banknote has been provided to the party or transferred to another party, assuming the transfer is authorized based on the transfer SFIOI. At S240, 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 ownership SFIOI received at S231. The central system then responds to the requester with a simple "Yes" or "No", etc.

[0044] In the method of FIG. 2E for a central system to process a transfer SFIOI of one or more virtual banknotes, at S270 the central system receives a transfer SFIOI of one or more virtual banknotes. The transfer SFIOI may specify a party identifier of an indicator, a party identifier of a recipient, and a unique identifier of one or more virtual banknotes. At S272 the central system begins pre-processing of the transfer SFIOI for security purposes. All aspects of the pre-processing described with respect to FIG. 2D will not be repeated here, but most or all of the pre-processing described with respect to FIG. 2D is equally applicable to the pre-processing of FIG. 2E. At S272 the central system reads the VN number of the transfer SFIOI. Also at 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 expected sizes of the substantial data in the VN information for various possible VN numbers, and if the size of the substantial data exceeds the expected size the transfer SFIOI may be deleted at S272. In S273, the central system retrieves the party information from the transferred SFIOI. The processes from S273 to S279 are performed to address aliasing, if allowed. In S274, the central system identifies and validates the country and state or region specified in the party identifier. In S275, the central system determines whether the party information is 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 validates the ID number. In S278, the central system converts the ID number to a universal ID number used by the central system. In S279, the central system retrieves and validates the universal ID number after conversion in S278 or if the party information is a universal party identifier type (S275=Yes). At S280, the central system compares the virtual note(s) with the electronic history of the virtual note(s) to determine whether the current owner of the virtual note is a party listed by the universal party identifier in the transfer SFIOI received at S270.The central system then responds to the initiator, such as by ensuring that the electronic history of the virtual note is updated.

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

[0046] In some embodiments based on FIG. 2D and / or FIG. 2E, the central system 150 may store different alternate IDs in different databases such that each different set of alternate IDs is separated from all other sets of alternate IDs. For example, the central system 150 may store a first database of conversion tables for converting all telephone numbers in the United States to corresponding universal IDs used by the central system, and another database of conversion tables for converting all currency reader application identifiers to corresponding universal IDs. Of course, more than two independent database configurations may be used for conversion to universal IDs. Separating the memory configurations of the different memories used for conversion of different types of IDs may ensure the fastest possible lookups of the universal IDs whenever an alternate ID is received as part of an incoming SFIOI.

[0047] As an alternative to a lookup table that stores alternatives for the universal ID, the universal ID numbering system may be designed such that the alternative IDs are accepted from approved sources, such as major social network providers or communication service providers. For example, if an 11-digit universal ID is used for a population of up to 99.9 billion people, the last 12th digit may be used to specify whether the SFIOI is from a particular account of a major social network provider or communication service provider. For example, a user 999999999999 (11 digits) may use 99999999991 (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, and 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 people, 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 to this would be to send a unique social media identifier, email address, phone number, etc. in place of the universal ID to be looked up by the central system.

[0048] The NDC monitoring, inspection, and exchange method of FIG. 2F begins with receiving a greylisting detection notification at S290. A greylisting detection notification is generated by the central system 150 when a transfer of a greylisted virtual note or a transfer to or from a greylisted party is detected. The central system 150 may have an automated process configured to initiate the process of FIG. 2F for some or all of such notifications. At S291, the new owner of the virtual note is provided with the expected virtual note characteristics and is instructed to compare the expected virtual note characteristics with the virtual note and report the results. At S292, a determination is made as to whether there is a match. The determination at SS92 may be received as a result of a notification from the new owner of the virtual note after a currency reader program or an electronic wallet program analyzes the virtual note. If there is a match, the process of FIG. 2F ends at S293. If there is no match, the central system 150 may exchange the virtual note for a replacement virtual note of the same denomination at S294. For example, the central system 150 may instruct the electronic communication device to transfer a virtual note that does not match the characteristics of the expected virtual note, and then provide the electronic communication device with a new virtual note as a replacement. In the process of FIG. 2F, replacements may occur for a variety of reasons, including attempted tampering, successful tampering, wear-and-tear, aging, counterfeiting, passage through an owner or geographic region or country monitored by a grey list, or other explanation for why the virtual note does not contain the expected characteristics. Replacements such as S294 are typically expected due to wear, such as data loss due to packet drops during communication over the electronic communication network.

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

[0050] Data center 340 can store large amounts of data. Data stored in data center 340 and retrievable for use from data center 340 may include: Greylisting of virtual currency: A list of virtual notes currently suspected of being involved in problematic activity, including processing instructions for each virtual note on the greylist each time the virtual note is transferred. ○Blacklist of virtual currency: A list of virtual notes that have been reported lost, stolen or returned and should not be involved in transfers, including processing instructions for each instance in which a blacklisted virtual note is allegedly transferred. ○ Greylist of parties: A list of parties, electronic communications devices, currency reader programs, and electronic wallet programs suspected of engaging in problematic activity, including processing instructions each time a greylisted entry is designated as a destination or source of a transfer in the SFIOI. ○Blacklist of parties: A list of parties, electronic communications devices, currency reader programs, and electronic wallet programs that are prohibited from participating in the use of virtual banknotes for any reason, including processing instructions for each time an entry on the blacklist is designated as a transfer destination or source in the SFIOI.

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

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

[0053] Furthermore, the virtual banknote may include in its metadata fields private addresses that are not publicly available. The private addresses may be addresses that are interpretable by the central system 150 and may include private server or database addresses or specific port addresses of private server or database addresses. In this way, if the virtual banknote also sends updates of the virtual banknote records back to the private cloud, the central system 150 may perform a partial unpackaging of the updates to identify which of the private server or database addresses stores the virtual banknote records. This may serve as a complement or alternative to addressing based on the virtual banknote's unique identifier, so that even if the central system or control system uses the virtual banknote's unique identifier even in part to identify a subgroup of servers or databases used to store the virtual banknote records, the private addresses sent by the virtual banknote may be used to address another internal communication address within the subgroup that corresponds to a server, database, server port, database port, or component that cannot be reached by a public address.

[0054] In the system for storing NDC virtual banknote records of Figure 3B, the filtering / segregation system 349 filters and segregates the SFIOIs before they are received by the central system 150. The filtering / segregation system 349 may inspect each SFIOI to ensure that it conforms to the SFIOI requirements. The inspection may include a size check 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 type of information that may be derived from the SFIOI. The filtering / segregation system 349 may serve two purposes: 1) filtering all hacking attempts by ensuring that the 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 SFIOI meets the requirements; Filtering / separation system 349 may include security gateway system 156 of FIG. 1C, or may be otherwise integrated with security gateway system 156, or may be a replacement for security gateway system 156.

[0055] The method of processing a received SFIOI by the security gateway system of FIG. 4A is an overview of the security checks performed by the security gateway system 156, beginning with storing the packet payload in an address space at S402A. The packet size may be standardized for processing by the security gateway system. For example, the SFIOI packet may be 512 bytes and stored individually in a page of flash memory for processing by the security gateway system. Because packets can be sent asynchronously from anywhere in the world without initiating a connection, the sender can expect a quick response if the packet is processed and meets the security gateway system's expectations. Of course, the teachings herein are not limited to 512 byte packets or packets that are all of a uniform size, although the above details may be considered optimal in some sense. Packets may also be standardized to a fraction or multiple of 512 bytes for similar reasons regarding standardized uniform processing and storage. At 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 except the header. Insofar as the parties to a transaction can be uniquely identified in as few as four bytes and the virtual banknote specified in the SFIOI can be uniquely identified in as few as five bytes, an SFIOI specifying seven virtual banknotes may contain as few as 43 bytes of meaningful data if no other fields are provided, although other fields may be required, such as a field for the country or region issuing the virtual banknote (one byte), another field for each virtual banknote specifying its denomination (one byte for each virtual banknote unless otherwise implicitly specified in the virtual banknote identifier), another field (one byte) for the number of virtual banknotes (VN number) that are said to be identified in the SFIOI, another field (one byte) for their relative position in the total number of packets sent individually in a batch, etc. The total length of the meaningful data in a packet may be specified in the packet's header, and this header information may be compared to the actual length of the meaningful data stored in the address space.In S408A, the number of virtual notes (VN number) purportedly identified in the SFIOI is determined. The number of virtual notes purportedly identified in the SFIOI may be specified in a specific byte of the SFIOI. In S410A, from the VN number determined in S408A, the expected size of meaningful data in the packet is established, and the expected size determined in S410A is compared with the actual size determined in S404A. Of course, the security gateway system can consistently eliminate threats or potential threats as soon as they are identified, so if there is a mismatch, the packet may be removed from the address space. In S412A, the identifier of the purported owner of the virtual note specified in the SFIOI is determined. The purported owner may be identified by as few as four specified bytes in the SFIOI. In S414A, the identifier of the purported owner is transmitted together with each individual virtual note identifier for an owner check. The purported owner's identifier may be sent along with each individual virtual note identifier, in a single communication or as a batch of separate communications, to the ledger storage system 152 of FIG. 1C. Note that the ledger storage system 152 may include a record of only the current owner of each virtual note, or may include another data set that is less than the complete record of any virtual note or party stored in the main memory system 153. If stored instructions from the actual owner of the virtual note are present, then in S416A the instructions are checked. The check in S416A may be against the main memory system 153 if processing instructions from the virtual note's owner are stored in the main memory system 153, against the ledger storage system 152 if processing instructions from the virtual note's owner are stored in the ledger storage system 152, or against another memory system that stores processing instructions if separate from the ledger storage system 152 or the main memory system 153. In S418A, if the stored instructions checked in S416A indicate that anti-spoofing measures are to be taken, then anti-spoofing measures are initiated.For example, an owner of a virtual banknote may specify that multi-factor authentication is invoked each time a virtual banknote in the owner's possession is subject to a SFIOI to the central system 150. At S420A, the type of SFIOI is checked. The type may include an inquiry, a transfer instruction to another party, a transfer instruction to another account or device of the same owner, a special processing instruction, etc. At S422A, depending on the type checked, the SFIOI is processed. If the instruction is an instruction to transfer ownership of the virtual banknote, an instruction to update the ownership record of the virtual banknote may be sent to the main memory system 153 and another confirmation notice may be sent to the originator of the instruction. If the instruction is an inquiry regarding the ownership of the virtual banknote, if the purported owner identified in the SFIOI is correct, an acknowledgement response may be sent to the originator of the instruction confirming the ownership. In some embodiments, the unique identifier of the virtual banknote is encrypted, allowing a counterparty to transmit the encrypted unique identifier to the central system 150 to verify the denomination and ownership of the virtual banknote without knowing the unique identifier until the transaction actually occurs. Processing therefore also includes decoding the virtual banknote's unique identifier if the SFIOI is an ownership inquiry, which is only decodable by the central system 150, and in particular the security gateway system 156. Other processing may include notifications to other central systems that track other NDCs, and other instructions or confirmations processed by the security gateway system 156.

[0056] In the processing configuration of the security gateway system of FIG. 4B, the set of cores of the first server 41561 reference 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, and the address space may be flash memory. In this regard, the status space may be on the order of 4 bytes, whereas the address space fits into the SFIOI size of 512 bytes or other relatively large amounts. For example, within 4 bytes or perhaps 5 bytes, the status space may specify which address space corresponds to, along with the actual status of the address space. The status may specify the core that will process the address space next, and / or the core that last processed the address space. In this manner, the set of cores may sequentially reference the status space and process the packet payload of the corresponding address space when the status indicates that that core will process the packet payload in the corresponding address space. The first core (Core #1) starts processing any address space starting with the first address space (AS1), updates the corresponding status space (SS1), then starts processing the second address space (AS2), and updates the corresponding status space (SS2). The remaining cores start processing from the first address space when the first status space (SS1) indicates processing, and updates the first status space (SS1) before checking the next status space. Of course, if any processing indicates that the packet payload in the corresponding address space should be deleted or should be left alone otherwise, the status of the status space may be updated to reflect a status indicating deletion, such as "99" indicating the next processing is deletion. When processing for any address space is completed, the status of the corresponding address space should also be updated to reflect that the next processing is deletion.In this way, when all packet payloads in Bay X are periodically processed and ready to be deleted, the latest status of the corresponding status space may uniformly reflect a status indicating deletion. Once Bay X has been completely deleted, Bay X may be returned to circulation for another batch of incoming packets. After use of the bay, there may be a quiet period, such as 30 or 60 minutes, to allow the circuitry to cool, etc.

[0057] In FIG. 4B, if the core realizes that it is not yet needed, it may be triggered to delay processing. However, for a core that processes 40,000 or more packets per minute, the processing delay may be very small, such as 1 / 4 or 1 / 10 of a second or less. In 1 / 4 of a second, the core should be able to process about 170 packets. Considering the advantages in simplicity, processing and memory resources, the embodiment based on FIG. 4B may use a relatively large address space for a relatively large amount of received packets. For example, the first server 41561 in FIG. 4B can accept 200,000 or more packets for 5 minutes before new packets are switched to the second server or at least to another bay of the first server 41561. Before the central system 150 is implemented, tests may be performed to optimize which servers work for how long to receive and process packets before being rotated out of line. Also, tests may be performed to optimize how many servers are used at a time, how incoming packets are distributed to different servers, etc.

[0058] In some embodiments, the cores of FIG. 4B are replaced by individual threads that reference the status space instead of individual cores, inasmuch as a 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 a received SFIOI by the security gateway system of FIG. 4C, the resource processes the packet payload in the address space of the security gateway system 156 individually and independently. Before the method of FIG. 4C begins, a packet is received. For NDC, SFIOIs are expected to occur at a rate of tens of thousands per minute, and may be more than every minute for at least some days. Thus, when a packet is received, it is immediately written to a contiguous address space so that the packet can be processed. After all packets in a bay are processed, all address spaces in the bay may be cleared by deleting the data therein. At S402B, the packet payload is stored in the address space. The packet's header, which was added to the packet payload, may also be stored in the address space, and data may be retrieved from both the packet payload and the header and processed by the resource in the method of FIG. 4C.

[0060] At 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, a core, or a processor, and may be a resource that performs the same operation one by one repetitively on the address space in the bay. The size of the packet payload may be checked by checking 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 a 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 to the result of searching for the presence of meaningful data in the address space. The packet size data and the actual size of the meaningful data in the address space may be compared to one or more predefined threshold(s), such as a maximum size or an exact size allowed for the SFIOI.

[0061] In S406A, it is determined whether the checked size is OK. If the checked size is not OK, e.g. if the packet size data and / or the actual size of the meaningful data in the address space indicates that the packet payload is larger than the maximum size or the exact size allowed for the SFIOI, then in S406C the packet is deleted from the address space or marked for deletion. If the checked size is OK, then 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 processes the address space. In S408B, the number of virtual banknotes supposedly identified in the SFIOI is determined by the second resource (i.e. resource #2). This number may be specified in the fields required for the SFIOI, e.g. one byte, or less than 8 bits. At S408C, the second resource is incremented and the address space with the determined number of virtual notes supposedly identified in the SFIOI is added to the address queue of the next resource (resource 3) that processes the address space. At S410B, the expected size of the packet payload is determined from the number of virtual notes determined at S408B. Since the identifiers of the virtual notes should be of uniform size, the expected size of the packet payload may be pre-determined based on the number of virtual notes. Furthermore, since the number of virtual notes that can be specified in a packet can be kept below a maximum value such as seven, the potential size of the packet payload may also be minimized to, e.g., seven. At S410B, the expected size is compared to the size checked at S404B. The expected size should match the checked size, although slight discrepancies may be tolerated for reasons that are not yet clear.

[0062] In S410C, it is determined whether the comparison in S410B is 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 processes the address space in S410D. If the expected size and the checked size do not match (S410C=No), the packet is deleted from the address space or marked for deletion in S410E.

[0063] At S412B, the party identifier of the alleged owner of the virtual banknote and the party identifier of the alleged counterparty (if any) are determined by the fourth resource and sent for aggregate checks by the fourth resource. The fourth resource is incremented and the address space determined at S412B is added to the queue of the next seven resources (resources 5-11). The aggregate check of the owner and counterparty identifiers is performed by sending an internal query to another part of the central system 150, such as the ID management system 151. The aggregate check may include checking whether the party identifier of the alleged owner of the virtual banknote and the party identifier of the alleged counterparty (if any) are blacklisted or greylisted. The aggregate check may be performed in parallel with the remainder of the method of FIG. 4C such that a result that prevents execution of the response to the SFIOI at S422B is received before S422B is executed at a later time. Additionally, the address space is added to the queue(s) for the next seven resources, in the example where the maximum number of virtual notes allowed for an SFIOI is seven. However, in some embodiments, a resource processes multiple virtual note identifiers at a time, and in some embodiments, the maximum number is less than seven or greater than seven. At S414B, the alleged owner's identifier and each virtual note identifier are sent separately for ownership check by the next seven resources (resources 5-11). The ownership check may be performed by sending an internal query to the ledger storage system 152 and may include a simple comparison of whether the alleged owner of the virtual note matches the listed virtual note owners. The address space of the SFIOI for which the ownership check is being performed is added to the queue for the next seven resources (resources 12-18). To maximize the efficiency of resources used for processing in the security gateway system 156, a separate set of resources may be used for responses, eliminating resources that both send queries and wait for responses.

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

[0065] At S416B, resource 19 checks for stored instructions (if any) from the real owner. This check may be performed by sending a query to main memory system 153 for any virtual banknotes, looking up the real owner and seeing if processing instructions have been specified. For example, the owner may specify that the virtual banknote should not be transferred from his / her possession without multi-factor authentication, confirmation of the transfer via phone, email or another mechanism, or another type of special processing. After sending the query, resource 19 may increment 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 the virtual banknotes may be stored in ledger storage system 152 or in another system (not shown) provided in parallel with ledger storage system 152 that stores cursory information regarding special instructions for processing virtual banknotes in the owner's possession. 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 before allowing the transfer.

[0066] At S418B, the twentieth resource initiates anti-spoofing measures if instructed by the response to the query by the nineteenth resource from S416B. Anti-spoofing may be performed by initiating a multi-factor authentication check and then waiting for authentication at another resource (not shown in FIG. 4C). In some embodiments, multi-factor authentication may include dynamically generating a code, such as a set of two characters, and sending the code or characters to a predefined communication address, such as a phone number, of the virtual banknote's actual owner. The actual owner may be asked to enter the two characters in response to confirm the transfer. Details of waiting for a response to the anti-spoofing check and processing the response are not shown in FIG. 4C because there is not enough space to adequately show the processing that may be involved. After the anti-spoofing check, the resource(s) that performed the anti-spoofing check increments the address space of that resource and adds it to the queue(s) for the next resource.

[0067] At S420B, the next resource (i.e., resource 21) checks the type of the SFIOI. At S420C, resource 21 is incremented and the address space of the packet is added to the queue of the next resource that will actually process the SFIOI. The number of resources that process the SFIOI may vary based on how many different actions can be performed based on the SFIOI. At S422B, the SFIOI is processed by one or more next resources (resources 22+). This processing may include sending instructions to update the ownership and owner records in the main memory system 153 and confirming the transfer SFIOI to the sender, or simply confirming the ownership inquiry to the sender. The confirmation of the ownership inquiry may be done by default without further inquiry. This is because the ownership check was done at S414B and the SFIOI has already been answered or has been deleted or marked for deletion if one or more of the ownership inquiry results are negative. Other types of transactions are also possible, such as updating transaction instructions or transferring ownership records to reflect that an owner has transferred a particular virtual note from one custodial account to another, or from one device to another.

[0068] The method of aggregate security checks in the central system memory system of FIG. 4D may be performed in or by main memory system 153, in or by AI and analytics system 154, or in another element of central system 150. The method may be performed to check the initiating party and / or counterparty patterns in all transfers, such as to see if suspicious funds are being drained or replenished from an account. Suspiciousness may be relative to person, place, and time, so different thresholds and analyses may be applied to look for different patterns.

[0069] At S430, an update to the record of transferred virtual currency is received. The update may be stored in both the virtual note history and the initiating party and counterparty history. Different algorithms may be applied to the virtual note history and the initiating party history to check for different pattern features. At S431, aggregate amounts for the transferee and transferor over a recent time period are determined. The aggregate amounts may be the total amount of transfers between the transferee and transferor over the last 60 seconds, 5 minutes, 30 minutes, 1 hour, 24 hours, and / or other time periods. At S432, the aggregate amounts are compared to a threshold to see if they are higher than the threshold. The comparison at S432 may include comparing different aggregate amounts to different thresholds, and the thresholds may be different for each party, such as based on an average, maximum, or minimum amount held by the parties over a recent time period. Thus, it may be determined that $800 out of $1000 in the owner's name (hereinafter, dollars means "US dollars") being removed from the owner in three or four transactions in one day is suspicious, but $800 out of $10,000 in the owner's name being removed from the owner in three or four transactions in one day is not suspicious. Thus, a central system described herein, such as central system 150, may check the history of the virtual banknote sender and / or virtual banknote recipient for each transaction and flag if the virtual banknote sender and / or virtual banknote recipient is involved in an abnormally large amount of transactions or an abnormally large number of transactions. If one or more total amounts are higher than the corresponding threshold (S432=Yes), the corresponding party may be added to a blacklist or greylist at 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 that present virtual notes that they do not own or that are counterfeit, and / or parties that present counterparty or virtual note information (e.g., VN_info) that does not match the counterparty presented or that have not consented to the transfer of virtual notes. A blacklist may also list parties that are prohibited from receiving virtual notes, and a greylist may list parties that are under surveillance.The blacklist may include parties identified in an ownership inquiry as having submitted to the central system 150 an inaccurate identifier for the origin of virtual banknotes, parties identified as having submitted fraudulent transfer SFIOIs to the central system 150, parties that have been the subject of a detected spoofing attack, parties identified as attempting to tamper with virtual banknotes, or any other party that the central system 150 determines has cause to be barred from receiving ownership of virtual banknotes. The blacklist may identify information such as currency reader programs or wallet programs that processed virtual banknotes reported lost or stolen, and is not limited to listing only unique identifiers of parties.

[0070] The grey list may include parties that are under government or regulatory scrutiny for suspicious activity, such as potential criminal activity, parties in a particular location or geographic region, such as a particular country, parties that are relatively new to the central system 150, or parties using relatively new unique party identifiers. The grey list may be updated based on certain activities, such as SFIOI queries specifying a unique identifier for a virtual note or SFIOI queries specifying a non-matching party identifier. For example, a grey list entry may include a count and / or list of when a party submits an inaccurate SFIOI, and if the submission of an inaccurate SFIOI occurs twice within a relatively short time frame, such as two hours, the party identifier may be understood to have been tampered with and the party identifier may be moved from the grey list to the black list.

[0071] A transaction requester may be blacklisted or greylisted depending on whether the transaction requester may be shown to be engaged in potential fraudulent activity or is strongly suspected. All or a subset of requests received by the verification service may be checked against the blacklist to see whether the alleged requester has repeatedly provided false information, and the alleged requester may be banned if the verification service confirms or suspects that the transaction requester is intentionally providing false (e.g., unfair) information.

[0072] Additionally, the blacklist of virtual notes may include virtual notes that have been returned, reported as stolen, or lost. As an example, a virtual note may be returned upon detection of one or more counterfeiting attempts involving the same unique identifier. The greylist of virtual notes may include virtual notes that are subsequently monitored in the possession of a party that is being monitored by a government or regulatory agency for suspicious activity, such as potential criminal activity. For example, if a party is the subject of a tax authority investigation, the tax authority may instruct the central system 150 to greylist all virtual notes currently in the party's possession. This may result in a special record of the movement of virtual notes in a file maintained for that person. At S434, another check may be associated with a timing or location trigger. For example, a transfer from a party to an Internet Protocol address located in a high-risk area may trigger a blacklist or greylist addition. As another example, a transfer from a party at 2 a.m. local time may trigger a blacklist or greylist addition. At S435, if the timing or location caused a trigger (S434=Yes), the party is added to the blacklist or greylist, otherwise the process of FIG. 4D ends.

[0073] In the method of processing received SFIOIs by the security gateway system of FIG. 4E, the method of FIG. 4A is divided into four sections as an example of how different graphics cards or processor groups in one or more graphics cards can be assigned to different tasks in the security gateway system. As is known in modern processing, a graphics card can include a number of processors that operate almost in parallel, given the inherent task of rendering graphics data of a large number of pixels simultaneously. The use of a large number of processors has also been applied to various other tasks. The security gateway system 156 of the central system 150 may be expected to operate continuously, sometimes receiving tens of thousands of SFIOIs per minute. Thus, the tasks performed by the security gateway system are essentially performed in parallel for different received packets. As long as the processing provided by the graphics card can be appropriately applied to the SFIOIs, the graphics card can be used.

[0074] In FIG. 4E, the processors are divided into four groups. One of the simplest ways to ensure efficient processing, if not the simplest, is to have all processors not specifically wait for an answer to a query they sent, and not route the answer back to the particular processor that sent the query, so that processing for each group may end when the query is sent to another internal system. Using a status space such as that of FIG. 4B can 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. These processors may process address space 800 at one time. The parallel aspect of processing that exploits the graphics card comes from applying groups to different groups of address spaces simultaneously, so that a first group may process address space 2401-3200, a second group may process address space 1601-2400, a third group may process address space 801-1600, and a fourth group may process address space 001-800. Each group of processors can increment its address space by 800 at a time as it completes its current processing. Of course, the processor groups need not all have the same number of processors, for example if the tasks performed by one group can be executed faster than the tasks executed by another group. Rather, to increase the relative sequentiality 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 includes more processors than a second processor group executing the one or more second task sets.

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

[0076] One aspect of the technical problem addressed herein is the program / erase cycles of security gateway system 156. Status updates may require writing more than one status update 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 word at each instance, each potential status update may be written to a different bit, byte or word of status memory 5562. In this manner, a thread can determine whether prerequisite processing has been performed by first reading status memory 5562 and referencing the status of bytes or words that have already been updated.

[0077] As a simple example, thread #7 may check the status of byte #6 updated by thread #6, and if the status indicates that thread #6 has processed the SFIOI, thread #7 may read the portion of the SFIOI processed by thread #7. When thread #7 has finished processing the SFIOI, thread #7 may update byte #7 in the status memory to indicate that thread #7 has finished processing the SFIOI. Obviously, this processing by thread #7 may be extremely fast, such as processing 40k or more SFIOIs per minute, and this may be similar for other processors, cores, and threads that process SFIOIs in security gateway system 156.

[0078] In the memory configuration for a security gateway system processing received SFIOIs in FIG. 5B, SFIOI memory 5561 is shown to include a first SFIOI memory 5561-1, a second SFIOI memory 5561-2, ..., up to a 40000th SFIOI memory 5561-40k. Status memory 5562 is shown to include a first status memory 5562-1, a second status memory 5562-2, ..., up to a 40000th status memory 5562-3. Each processor, core or thread first checks the corresponding status in status memory 5562 and then performs a particular operation on the SFIOI in SFIOI memory 5561 before updating the corresponding status in status memory 5562. As mentioned above, the security gateway system 156 according to the present disclosure is expected to process a large number of SFIOIs, such as 40,000 or more per minute. Thus, the SFIOI memory 5561 may be a first bay of the security gateway system 156 and may be assigned SFIOIs arriving in one minute, as an example. A second bay of the security gateway system 156 may be substantially identical to the first bay and may be assigned SFIOIs arriving in the next minute in this example timing. The cycling of the bays may occur periodically, such as every 5, 10, 15, 30, 60 minutes, etc. Additionally, a bay may be assigned SFIOIs for processing in a certain time frame, although this is likely not a particularly best practice. Rather, load balancing or other types of implementations may be implemented dynamically such that the SFIOI memory and status memory are augmented with additional physical resources as needed.

[0079] As will be apparent, in Figures 5A and 5B the status memory 5562 is physically separate from the SFIOI memory 5561, with a processor, core or thread switching back and forth between the two during processing. However, each processor, core or thread only processes certain parts of the SFIOI, rather than the entire SFIOI in SFIOI memory 5561, and operates by checking and writing only individual bytes or words in status memory 5562.

[0080] In the memory configuration for the security gateway system processing a received SFIOI of FIG. 5C , memory management includes using a unified SFIOI and status memory 5563 for memory space for the SFIOI and memory space for status in security gateway system 156. In other words, the unified SFIOI and status memory 5563 includes a first area for storing the SFIOI and a second area used to track the processing status of the SFIOI. 256 bytes of a page may be reserved for a specific use in processing by a processor, core, or thread of security gateway system 156. For example, if a 512-byte page can store up to 64 64-bit words, with 32 of the 64-bit words reserved for the SFIOI, then memory starting at the 33rd word line of the unified SFIOI 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 one (1) in a status update, a byte or word of the status space in the unified SFIOI memory and status memory 5563 may be written to 1 in one or more bit positions when the corresponding processing is completed. Thus, during processing of an SFIOI, a processor, core, or thread may process a particular portion of the SFIOI and then read the status from word line 33 onwards in the unified SFIOI memory and status memory 5563 before updating another portion of the status space. The processors, cores, or threads may be organized to efficiently use the memory pages of the security gateway system 156 such that the individual physical memory pages are logically divided. Of course, the division need not be exactly one-half of the total area of ​​a memory page or other predefined addressable memory unit.

[0081] In the memory configuration of the security gateway system for processing received SFIOIs in FIG. 5D, the combined SFIOI and status memory 5563 is shown to include a first portion 5563-1, a second portion 5563-2, ..., up to a 40,000th portion 5563-40k. Of course, the bays of the security gateway system 156 are not limited to sections of 40,000 pages or other units of memory, nor are they limited to switching to a new bay every minute or every 40,000 SFIOIs. Rather, those skilled in the art of the many technologies required to implement a central system comprising the security gateway system 156 described herein will recognize that efficient use of memory in the units used in the implementation (e.g., 512-byte pages) will certainly provide efficient processing in a variety of ways, 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 or larger than each SFIOI and provide the memory space required for status updates for each SFIOI. In this manner, the SFIOI is stored on a one-to-one basis in a predefined addressable memory space.

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

[0083] In FIG. 6, the header of the IP packet contains 24 bytes, i.e., the equivalent of three 64-bit / 8-byte words. The header of an IPv4 packet is typically allocated 20 bytes, so the last 4 bytes may be NULL values. In the larger IP addressing scheme, the header of an IPv6 packet is typically allocated 40 bytes. In FIG. 6, the first field after the header is for the number of virtual bills (VN number). If the maximum number of VN fields in the format is limited to 7, 13, 19, or some other small number, the field for the VN number is provided with 8 bytes / 64 bits, even though the VN number only requires a few bits. The VN number may be processed to ensure that the substantive data of the IP packet ends where it should end, depending on the number of virtual bills specified by the VN number. Next, the first party ID field and the second party ID field each have 8 bytes / 64 bits. In this way, each of the first and second party ID fields can be read as a whole word, even if they are less than 64 bits of substantive data. In FIG. 6, 16 separate fields are provided as full words to specify 16 virtual banknotes. Each thread assigned to perform security checks of the virtual banknotes can read the corresponding virtual banknote unique identifier (ID) as a whole word, even if the ID is less than 64 bits of substantive data. However, most or all of the assigned VN fields may contain substantive data. For example, a virtual banknote unique ID may contain a first byte for a country / region code, a second byte for a denomination, and six bytes for the actual unique ID. The last substantive field is for the type of SFIOI, since the type of query or instruction specified in the SFIOI is processed only if the SFIOI has passed the preliminary security processing.

[0084] The last field of the SFIOI format in FIG. 6 is empty and reserved for status updates in the security gateway system 156. Two words totaling 16 bytes may be sufficient to track the status of 16 security checks with a different byte 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 the SFIOI is sufficient for processing in the security gateway system 156 by keeping the number of unique IDs allowed for virtual bills in a packet under a suitable limit, but the example 512-byte format is primarily used in this disclosure. The format of the SFIOI may be matched to the size of a memory unit other than a flash memory page.

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

[0086] The SFIOI format may specify that 8 bytes are allowed in a 512-byte packet for each Party Identifier. The Party Identifiers may be formatted to implicitly specify which country or region each Party Identifier originated from, so that a single Party Identifier can be used for NDC tracked by different central systems. An entire bit or byte may be dedicated to designating the bank or similar entity from which the end user obtained the unique identifier, such 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] An example SFIOI format type may allow a party to: inquire whether a counterparty owns a virtual note, direct the transfer of ownership of a virtual note to a counterparty, direct subsequent special processing or the cancellation of special processing, indicate a lost or stolen virtual note, and provide updates to the metadata status of virtual notes that have not been recently transferred.

[0088] In some embodiments, another field of the SFIOI may specify a total amount involved in the transaction, a change amount involved in the transaction (i.e., amounts less than one dollar), or another amount. For example, if small denomination notes have not been issued for the virtual banknote or if small denomination notes are not tracked by the central system, the SFIOI may specify a change amount to be credited and / or debited from an account corresponding to the party, depending on whether the SFIOI specifies a transfer in the transaction. In this way, the format of the SFIOI may accommodate transfers including denominations not issued as virtual banknotes or not tracked by the central system. A party registered to use a virtual banknote of a currency may have a deposit account, checking account, or savings account associated with a unique identifier. In this way, amounts less than one dollar, for example, may be credited to or debited from the associated account. As an example, if a party pays $50 for an item in a transaction and is expecting 65 cents in change, the change may be automatically credited to the party's associated account and debited from the seller's associated account. The associated accounts are managed outside of the central system, such that the associated accounts are managed by the financial institutions that provide the accounts as a service. The central system simply notifies the identity management system 151 or another node that manages the parties' identity records to initiate a debit or credit with the financial institution. In some embodiments, parties registered with the central system may be required to have associated accounts, although governments and / or central banks may encourage account openings (e.g., by offering incentives to financial institutions) for segments of the population that do not have such accounts.

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

[0090] The format of the SFIOI can be used to track virtual banknotes as long as they are equipped with a unique identifier. Thus, a virtual banknote can be a complete dataset including image data, a partial dataset including logical data that is complemented with templates when visualization of the virtual banknote is requested, an encrypted dataset like cryptocurrency, or any other type of dataset, as long as the virtual banknote is equipped with a unique identifier that can be used for tracking purposes.

[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 a four or five digit unique identifier so that the unique identifier can be written in two or three bytes. The financial institution may use that unique identifier as the first two or three bytes of the entire identifier assigned to it as the party ID. The party ID may be three bytes, four bytes or five bytes for the party, two bytes or three bytes for the financial institution, etc. In this way, the central system does not need to store the identity of the parties, but instead can rely on the financial institution to know who the party ID corresponds to. At least in the United States, the financial institution may store the party ID, and if a government agency wants to know who the party ID corresponds to, it need only ask for a warrant. Other types of organizations that may be permitted to issue unique identifiers to customers may include entities such as Coinbase, Facebook®, or other entities with large customer bases, so long as those customer bases include customers who actually trust such entities to protect their privacy as much as possible or as far as is reasonable. As an example, the central system may provide the unique IDs of the parties to the banks and let the banks decide which parties to assign unique IDs to.

[0092] In some embodiments, a party may be provided with the ability to automatically deposit received virtual notes into an associated account, such as when a party receives virtual notes from an unknown party. On the security side, the ability to automatically, or at least quickly, transfer virtual notes into an associated account may help thwart potential spoofing by an unknown party, since the unknown party may know which virtual notes have been transferred to the party. Furthermore, once the virtual notes are transferred to a financial institution and deposited in the associated account, the financial institution may simply hold the virtual notes and issue a credit as an update to the party's ledger balance, allowing the party to begin collecting interest. In some embodiments, the party ID may be used to track cashier's checks, traveler's checks, stable coins, and other items that represent a fixed denomination of the underlying national currency, so long as they are uniquely identified.

[0093] The type of the SFIOI may be specified in a field required by the format of the SFIOI, for example a full byte field, or a 2-bit or 3-bit field. Because the tracking described herein may be extended to many other applications, the type field may contain a full byte so that even if one or relatively few types are used to track the NDCs described herein, ultimately up to 256 different types can be specified using the same format.

[0094] In the internet network router arrangement of FIG. 7A, the network router system restricts communications to the central system 150 to non-sequenced packets (i.e., single packet) SFIOIs sent as UDP / IP packets (or non-sequential TCP / IP packets). The network router system of FIG. 7A can be extended to various uses. For example, the example SFIOI format described herein can be adapted to all kinds of other uses, such as for a server to send a single packet request to initiate a communication connection with a requesting device, where an entity wants to prohibit the server from accepting the connection request. Other examples include tracking real estate, loans, etc. As shown and described in FIG. 7A, FIG. 7B, FIG. 7C, FIG. 7D, FIG. 7E, and FIG. 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 but not sequential TCP / IP packets. Alternatively, these checks may be provided after processing by the last Internet router within the Internet and before the packets reach the security gateway system 156. For example, a modified safety system based on an Internet router may intercept packets sent to one or more specific IP addresses and perform one or more preliminary checks, such as compliance with precise size requirements or forbidding TCP / IP packets. However, such preliminary checks delay processing in the modified safety system, since each check essentially doubles the original basic processing requirements 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 process huge amounts of packets per second or minute, equal to or greater than the amount expected by the central system 150. Therefore, one or a small number of modified safety systems based on modifications of high-end Internet routers can perform one or more of the most basic safety checks before the packets reach the security gateway system 156. This helps to repel DOS attacks, and the number of modified safety systems can be dynamically expanded to minimize interruptions to the central system 150, especially when a DOS attack is expected.

[0096] The modified network router or switch may use DDR4 random access memory (RAM) rather than flash memory to temporarily store packets as they are processed. For example, after storing the packet in DDR4 RAM, the destination IP address may be read and compared to a routing table, and if the routing table has been modified to indicate that packets to the destination IP address are subject to a preliminary safety check, a preliminary safety check may be performed. The safety checks in the modified router or switch may be very basic, such as making sure that the packet is of a certain size or under a threshold, or that the packet is sent with UDP or unsequenced TCP. In other embodiments, most routers at a network service provider may be configured to simply send packets addressed to a particular destination IP address to a service node that performs the safety check, and then pass the packet on to the particular destination IP address. The service node may include one or more modified routers, or another form of high-speed processing environment, that add one or very few safety checks to packets destined for a particular IP address, requiring that the packets meet expected format requirements. For example, a service node may be offered as a separate service, similar to a picket system, that filters packets to one or more destinations that require the packets to conform to a particular format, such as a 512-byte format.

[0097] Additionally, one or a few network routers may be specially programmed to perform packet checks within the Internet since they are in the network closest (logically and / or physically) to security gateway system 156. Additional network routers may be configured to dynamically adjust to perform packet checks when instructed, such as when a network service provider detects that the IP address of security gateway system 156 is under DOS attack. For example, by default, basic safety requirements are performed by the three network routers closest (logically and / or physically) to security gateway system 156 in the network, but when a DOS attack is detected, the next 9, or 27, or 97 closest network routers may be dynamically adjusted to begin detecting and dropping packets that are too large or too small, or packets addressed to the wrong type of IP address.

[0098] Additionally or alternatively, one or more additional network routers may be maintained out of service within the central system or just outside the central system and dynamically brought into 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 security gateway system 156 and the Internet and configured to be dynamically activated and perform packet checks when instructed. For example, by default, basic safety requirements are performed by the three network routers that are closest (logically and / or physically) to security gateway system 156 in the network, but when a DOS attack is detected, an additional 3, or 27, or 97 additional network routers may be dynamically spun up and assigned traffic destined for security gateway system 156 to begin detecting and dropping packets that are too large or too small, or packets addressed to the wrong type of IP address.

[0099] In Figure 7A, a specialty internet service provider (ISP) 7140 is a dedicated internet service provider. For example, a government or private enterprise may wish to stand up a specialty ISP 7140 for last mile routing to a central system that provides security gateway system 7156. The specialty ISP 7140 may also provide dedicated packet routing for one or more other service providers, central systems, etc.

[0100] In FIG. 7A, the 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 FIG. 7A may be configured to perform one or more safety checks on packets addressed to one or more predefined Internet protocol addresses. The one or more safety checks are in addition to the core function of an Internet network router, which is to route packets extremely quickly. Thus, imposing safety checks on packets addressed to one or more predefined Internet protocols slows down the routing of packets handled by the specialty ISP 7140 as compared to other Internet traffic.

[0101] Various logical configurations can be used to allow an Internet network router to operate normally for some or most traffic. For example, Internet Protocol addresses that are treated as last-mile destination services by an Internet network router may be aggregated so that one Internet network server can maintain a list of Internet Protocol addresses for which special safety procedures are implemented. In other words, the Internet network routers of FIG. 7A may be specially designated to implement one or more safety checks for traffic to one or more Internet Protocol addresses for which the Internet network router is a last-mile router. Furthermore, in the event of a DOS attack, one Internet network router may request assistance from one or both of the other Internet network routers to begin processing traffic and to implement the same safety checks for the same one or more Internet Protocol addresses that receive the special treatment. There is no requirement regarding the maximum or minimum number of Internet network routers that may be used to implement one or more safety procedures as a default. There is also no requirement regarding backup Internet network routers that may be dynamically deployed to implement one or more safety procedures during a DOS attack.

[0102] In the internet network router arrangement of FIG. 7B, the internet network router of FIG. 7A is provided in a central system 7150 such that the internet network router is the recipient of traffic to one or more internet protocol addresses in the central system 7150. The internet network router of FIG. 7B does not provide routing services for third party internet protocol addresses as it is dedicated to the central system 7150. In FIG. 7B, one internet network router is assigned to implement 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, where each of the two or more Internet network routers performs a different safety check. For example, a first Internet network router may check the size of each packet for a listed Internet protocol address and drop packets that are greater than or less than 512 bytes or do not fall within a range that includes 512 bytes. A second Internet network router may check the header of each packet for a listed protocol address and ensure 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 and subject to different basic safety checks at each, thereby reducing the burden on the security gateway system 7156.

[0104] In some embodiments based on FIG. 7A and FIG. 7B, a separate controller (not shown) may adjust the Internet network routers, for example, by increasing the number of Internet network servers that handle traffic to a particular 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 may be completely isolated from the Internet or the public. The number of Internet network routers brought in to handle the increased traffic in a DOS attack is not limited to two, but may instead be any number, such as 27, 97, or 997 of the Internet network routers that are logically and / or physically closest to the target Internet Protocol address. Furthermore, the Internet network routers are not necessarily called upon simultaneously, but may instead be activated in stages. For example, in a first stage, two Internet network routers are assigned to assist in safety checking of the target Internet Protocol address, and in a second stage, eight additional Internet network routers are assigned to assist in safety checking of the target Internet Protocol address.

[0105] Based on the embodiment of Figure 7A, the specialty ISP 7140 can provide safety services for dedicated Internet Protocol addresses. Although the safety check is initially designed for NDC related traffic destined for the central system 150, the specialty ISP 7140 can provide a similar service to one or more other government or private sector providers. That is, the specialty ISP 7140 can provide the safety service as an independent service, without being limited to the central system 7150.

[0106] In the method of filtering packets before reaching an Internet Protocol destination address of FIG. 7C, a packet is received at S710 and a destination Internet Protocol address (Dest IP) and a routing policy are read at S720. At S730, a determination is made whether the destination IP is flagged, such as if the destination IP is specifically mentioned in a routing table or is part of a set of Internet Protocol addresses that are flagged in a routing table and subject to special handling. 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 complies (S760=Yes), the packet is routed normally at S740. If the packet does not comply (S760=No), the packet is dropped at S770. The method of FIG. 7C may be performed by a modified safety system in an Internet network. The modified safety system may be a modified router or switch that is simply modified to check one or more parameters of packets bound for a destination IP that is flagged in the routing table. Any such router or switch should be located as the closest, or one of the closest, logically and / or physically closest routers or switches to the destination IP in the Internet network.

[0107] In the communication system for filtering packets before they reach an Internet Protocol destination address in the security gateway system of FIG. 7D, a first modified safety system is shown as MSS7148 and a second modified safety system is shown as MSS7149. MSS7148 and MSS7149 can perform safety checks of the type described in the method of FIG. 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 picket system dedicated to 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 the central system as described herein, and other organizations that may benefit from safety checks performed on specific packets before they reach a destination IP address.

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

[0109] In the method of distributing safety checks for packets addressed to an Internet Protocol destination address in the security gateway system of Figure 7E, the first MSS 7148 performs a method including demodulating a received first signal, storing a packet from the demodulated signal in a register, checking header information from the packet, modulating the packet with a 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 including demodulating the second signal, storing the packet from the demodulated signal in flash memory, such as on a one-to-one basis, and executing a safety subprogram to ensure that the packet meets the expected format and safety controls implemented in the security gateway system 7156.

[0110] There are many use cases for how NDC can be implemented securely using the techniques described herein. One example of a security challenge addressed herein is that when exchanging a virtual note for another virtual note, an opportunity exists for the originator or an accomplice of the originator to impersonate the recipient and instruct the central system via the SFIOI to return ownership of the virtual note back to the originator or accomplice.

[0111] As described herein, the central system described herein can initiate anti-spoofing (e.g., multi-factor) communication with the recipient's address of record. Furthermore, to avoid this scenario, the recipient can automatically exchange virtual notes from unknown parties with the central system, or provide new virtual notes to the financial institution in exchange for crediting an account at the financial institution, such as by depositing the virtual notes into a checking or savings account (modified for virtual notes). Low denomination virtual notes can also be integrated into high denomination central system virtual notes. These and other mechanisms are made possible by the teachings herein and can be used to securely avoid all or nearly all forms of fraud that are not securely provided for by today's technology. As an example, tracking of virtual notes at the central system described herein allows a party to quickly transfer the virtual notes to the financial institution, so that the previous owner cannot fraudulently impersonate the owner in order to regain control of the virtual notes.

[0112] In another use case, where a counterparty pre-sends the unique identifier of the virtual banknote provided by the party initiating the transaction to a central system, the unique identifier may be encrypted within the SFIOI. As the unique identifier is only decodable by the central system, the central system can respond to the counterparty and indicate whether the virtual banknote belongs to the party initiating the transaction and can verify the denomination of the unique identifier. This can occur even if the counterparty does not have the underlying unique identifier, and therefore cannot possess the unique identifier of the virtual banknote presented for payment until the transaction occurs. Thus, both the unencrypted and encrypted unique identifiers are provided with the virtual banknote, allowing the counterparty to send the unencrypted version first for authentication before accepting the virtual banknote for payment of the transaction.

[0113] Additionally, in many communications, the transmission of virtual banknotes may envisage the use of encryption mechanisms such as SSL, etc. To the extent that alternative mechanisms for encryption may be used in processing virtual banknotes, the teachings herein should not be considered to be specifically inconsistent with the use of a particular encryption in appropriate circumstances.

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

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

Claims

1. 1. A security gateway system for interfacing with the public via the Internet, comprising: a memory for storing packets received via the Internet; and a processor for executing a plurality of algorithms for imposing safety checks on said packets, said packets being required to conform to a predefined format specifying requirements for a field at a predefined relative position in the payload of an acceptable packet, each algorithm processing a packet by checking whether data in said field at said predefined relative position in the payload of the packet conforms to said predefined format, said packets being stored separately in a memory unit of the same size of said security gateway system, each of said plurality of algorithms being implemented by a different thread and imposing at least one safety check on said data of each packet processed by said thread until each packet processed by said thread passes all required safety checks or until each packet processed by said thread fails any safety check and processing of said packet by said thread is considered completed; a main memory system, sealed off from the public by the security gateway system, that stores a record of all instances of tracked digital assets for a centralized tracking system and receives updates to said record when instructions from the public pass the safety checks; A centralized tracking system, including:

2. 2. The centralized tracking system of claim 1, further comprising a ledger-keeping system that is physically separate from the main memory system and sealed off from the public by the security gateway system, and that stores a record of 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. 3. The centralized tracking system of claim 2, wherein the algorithms in the security gateway system send packets to the ledger keeping system for ownership inquiries.

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

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

6. The packets are limited to individual out-of-sequence packets; each instance of the tracked digital asset is assigned a unique identifier that is used to track the tracked digital asset; The centralized tracking system of claim 1 .

7. interfacing a security gateway system with the public via the Internet, said security gateway system comprising a memory and a processor; storing packets received over the Internet in said memory, the packets being stored individually in memory units of the same size of the security gateway system, the packets being required to conform to a predefined format specifying requirements for a field at a predefined relative position in the payload of an acceptable packet, and each algorithm processes a packet by checking whether data in the field at the predefined relative position in the payload of the packet conforms to the predefined format; executing a plurality of algorithms for imposing safety checks on each packet received over the Internet, each of the plurality of algorithms being implemented by a different thread and imposing 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 safety check and processing of the packet by the thread is considered complete; isolating a main memory system from the public by said security gateway system; storing in said main memory system a record of all instances of digital assets being tracked for a centralized tracking system; updating a record in the main memory system if the instruction from the public passes the safety check; A centralized tracking method, including:

8. The method of claim 7, further comprising: at said security gateway system, rejecting a connection request from said public.

9. 8. The method of claim 7, further comprising: isolating a ledger storage system from the public by the security gateway system, the ledger storage system being physically separate from the main memory system, storing a record of current ownership of instances of the tracked digital assets, and determining whether the ownership listed in the packet is correct for at least one tracked digital asset listed in the packet.

10. 10. The method of claim 9, further comprising: the plurality of algorithms in the security gateway system sending packets to the ledger keeping system for ownership inquiries.

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

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

13. The method of claim 12, wherein the packets are limited to individual out-of-sequence packets; each instance of the tracked digital asset is assigned a unique identifier that is used to track the tracked digital asset; The method of claim 7.

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

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

Images