CN109691016B

CN109691016B - Distributed transaction processing and authentication system

Info

Publication number: CN109691016B
Application number: CN201780055275.7A
Authority: CN
Inventors: 拉尔斯·戴维斯
Original assignee: Kalypton International Ltd
Current assignee: Kalypton International Ltd
Priority date: 2016-07-08
Filing date: 2017-07-07
Publication date: 2024-01-26
Anticipated expiration: 2037-07-07
Also published as: AU2017293405A1; IL264136B1; CN109691016A; WO2018007828A2; TWI688914B; KR20230117473A; JP2019525685A; US20200186355A1; IL264136B2; AU2022224731A1; SG11202006519WA; GB201611948D0; IL264136A; MX2019000331A; WO2018007828A3; EA201990251A1; KR20190038561A; ZA201900836B; TW201812674A; MA45587A

Abstract

A data transaction recording method, comprising: at an apparatus associated with a first entity: determining first seed data; generating a record of a first data transaction between a first entity and a second entity; determining second seed data by combining at least the first seed data and a record of the first data transaction; generating a first hash by hashing the second seed data, the first hash comprising a history of data transactions involving the first entity; and storing the first hash of the record for the first data transaction in memory.

Description

Distributed transaction processing and authentication system

Technical Field

The present invention relates to a system and method for executing transactions on a large scale, safely and near real time in a single embodiment.

Background

Transaction processing relates to a wide range of distributed computer-based systems, and in particular to multiple transaction parties performing transactions in the payment arts, while also relating to transactions at other financial assets and goods, entity access control, logical access to data, management and monitoring of devices that make up the internet of things (IoT), and the like.

When creating a transaction system, engineers must make difficult tradeoffs. This includes choosing between speed and flexibility, throughput and consistency, security and performance, consistency and scalability, etc. Such trade-offs generally affect the overall system. The payment processing system exhibits the effects of the above trade-offs. The payment process may require 600 to tens of thousands of transactions to be processed in one second, however it can only be partially processed and the details stored for further processing during a system's workload suspension. This often results in the need to check for missing records, repeat transactions, and credit problems due to account overdrawing between the time of the transaction and the time of processing the transaction. These questions are not limited to payments.

ACID (atomicity, consistency, isolation, and durability) is a model of database consistency, and each database transaction must succeed when the following requirements are met: when the entire transaction is rolled back (atomicity), the consistent state of the database is maintained (consistency) and does not interfere with each other (isolation) and must be durable (persistence) even if the server is restarted.

This model is generally considered incompatible with the availability and performance of large systems, including, for example, existing bank payment networks and other "big data" transaction systems. Instead, these systems rely on BASE consistency (basically available, soft state, and final consistency). The model considers that the database is sufficient to eventually reach a consistent state. The banking systems operate in this mode, which is why they often need to suspend any transactions and perform checkchecks to achieve a consistent state. The concept that a trade-off must be made in a large number of transactions is the spirit of CAP theory, which states that it is not possible for a distributed computer system to meet (C) consistency, (A) availability, and (P) partition fault tolerance simultaneously. The best solutions currently involve excessive limitations and exclusions to meet the emerging and existing needs.

The problem of how to reconcile data generated by the internet of things is of increasing concern, as engineers believe that the trade-offs that must be made when constructing networks and transaction systems will have an impact. One of the effects is the communication security problem between the devices and servers that together make up the internet of things. Another effect is the inability to ensure that the data collected by the device is actually related to the particular event detected by the device.

Cloud-based information storage systems also exhibit the effects of these trade-offs, which often results in a large number of servers and systems that can only guarantee final consistency.

Thus, there is a need to provide ACID consistency to large systems known to benefit from BASE consistency only.

Summary of the invention

Overview of the invention

According to one aspect, there is provided a data transaction recording method, comprising: at an apparatus associated with a first entity: determining first seed data; generating a record of a first data transaction between the first entity and a second entity; determining second seed data by combining at least the first seed data and the record of the first data transaction; generating a first hash by hashing the second seed data, the first hash comprising a history of data transactions involving the first entity; and storing the first hash of the record for the first data transaction in memory. According to another aspect, a computer readable medium comprising an encoding portion is provided, which when executed causes a computing device to perform the method.

According to another aspect, there is provided a licensing apparatus for: receiving a first hash from a device associated with a first entity, the first hash comprising a history of data transactions involving the first entity; combining the first hash with a license hash to provide a license input; generating a second license hash by hashing the license input; and storing the second license hash in memory.

According to another aspect, there is provided a directory means for: receiving a first hash from a device associated with a first entity, the first hash comprising a history of data transactions involving the first entity; combining the first hash with a directory hash to provide a directory input; generating a second directory hash by hashing the license input; and storing the second directory hash in a memory.

According to another aspect of the present invention, there is provided a method of accessing a first service from a device, comprising: providing an identifier of the device to a requesting server; authorizing an access request by the device to the first service based on the identifier; the device is allowed to access the first service from a first host server where the first service resides, the access being made through the requesting server. According to another aspect, an apparatus is provided for performing the method. According to another aspect, a computer readable medium comprising an encoding portion is provided, which when executed causes a computing device to perform the method.

According to another aspect, there is provided a method of migrating data, comprising: providing a request to switch first data from a first data store to a second data store; determining an identifier of the first data store from a directory server based on an identifier included in the request; migrating the first data from the first data store to the second data store. According to another aspect, an apparatus is provided for performing the method. According to another aspect, a computer readable medium comprising an encoding portion is provided, which when executed causes a computing device to perform the method.

According to another method, there is provided a communication method including: transmitting a first communication from a first entity to a second entity, the first communication comprising two or more data fields, each field comprising an individual tag; and transmitting a second communication from the first entity to the second entity, the second communication comprising two or more data fields, wherein the order of the fields in the second communication is different from the order of the fields in the first communication. According to another aspect, an apparatus is provided for performing the method. According to another aspect, a computer readable medium comprising an encoding portion is provided, which when executed causes a computing device to perform the method.

According to another aspect, there is provided a method of communicating over unstructured supplementary service data, USSD, comprising: opening a USSD dialogue between the first device and the second device; generating, at the first device, ciphertext for use in communicating in the conversation; encoding the ciphertext at the first device; the encoded ciphertext is sent from the first device to the second device for decryption at the second device. According to another aspect, an apparatus is provided for performing the method. According to another aspect, a computer readable medium comprising an encoding portion is provided, which when executed causes a computing device to perform the method.

According to another aspect, there is provided a method of communicating between a first device associated with a first entity and a second device associated with a second entity, comprising: generating, at the first device, a first PAKE conversation between the first device and the second device using a first shared secret; receiving a registration key from the second device and a second shared secret; the first shared secret, the registration key, and the second shared secret are hashed to provide a third shared secret that is used to generate a second PAKE conversation. According to another aspect, an apparatus is provided for performing the method. According to another aspect, a computer readable medium comprising an encoding portion is provided, which when executed causes a computing device to perform the method.

According to another aspect, there is provided a method of accessing a service, comprising: providing a credential and a context of the credential; and authenticating access to the service according to the credentials and the context. According to another aspect, an apparatus is provided for performing the method. According to another aspect, a computer readable medium comprising an encoding portion is provided, which when executed causes a computing device to perform the method.

According to another aspect, there is provided a method of communicating between modules in a computer system, the method comprising: transmitting the shared memory channel from the first module to the agent; transmitting the shared memory channel from the agent to a second module; wherein the agent includes a switching module for transferring data between the first module and the second module by bypassing a kernel of the computer system; data is transferred from the first module to the second module. According to another aspect, an apparatus is provided for performing the method. According to another aspect, a computer readable medium comprising an encoding portion is provided, which when executed causes a computing device to perform the method.

The first seed data includes a starting hash. The starting hash is a result of a hash operation on a record of a previous data transaction relating to the first entity. The starting hash comprises a random hash. The random hash includes at least one of a signature from the device, a date and/or time the random hash was generated.

Providing the second seed data further includes: combining a first zero-knowledge proof and a second zero-knowledge proof with the first seed data and the record of the first data transaction, wherein the first zero-knowledge proof comprises a proof that the starting hash comprises a true hash of the previous data transaction involving the first entity; and the second zero-knowledge proof comprises a proof for a second hash comprising a true hash of a previous data transaction involving the second entity. Providing second seed data, further comprising: combining a third zero-knowledge proof with the first seed data, the record of the first data transaction, the first zero-knowledge proof, and the second zero-knowledge proof. The third zero-knowledge proof is generated from random data. The third zero-knowledge proof is a repetition of the first zero-knowledge proof or the second zero-knowledge proof. The third zero-knowledge proof is constructed using a second record of the first data transaction corresponding to the second zero-knowledge proof.

The first data transaction includes at least two phases, and providing second seed data includes: combining the first zero-knowledge proof with a record of a first phase of the first data transaction; and combining the second zero-knowledge proof with a record of a second phase of the first data transaction. Providing the second seed data includes: constructing a third zero-knowledge proof from the record of the second phase of the first data transaction; and combining the second zero-knowledge proof and the third zero-knowledge proof with the record of the second phase of the first data transaction. The first data transaction includes at least three phases, and providing second seed data further includes: combining the first zero-knowledge proof with a record of a third phase of the first data transaction; and combining the second zero-knowledge proof with the record of the third phase of the first data transaction.

The first data transaction includes at least three phases, and providing second seed data further includes: combining the first zero-knowledge proof with a record of a third phase of the first data transaction; and combining the second zero knowledge proof with random data. The first data transaction includes at least three phases, and providing second seed data further includes: combining the first zero-knowledge proof with a record of a third phase of the first data transaction; and combining the second zero-knowledge proof with a record of a fourth phase of the first data transaction; wherein the fourth phase of the first data transaction is a repetition of the third phase of the first data transaction.

The first data transaction includes at least three phases, and providing second seed data further includes: combining a third zero knowledge proof with a record of a third phase of the first data transaction.

The first zero-knowledge proof is constructed by the device associated with the first entity and the second zero-knowledge proof is constructed by the device associated with the second entity.

Constructing the first zero-knowledge proof and the second zero-knowledge proof includes using a key exchange algorithm. The key exchange algorithm includes a PAKE algorithm.

The method further comprises the steps of: transmitting the first hash to a device associated with the second entity; receiving a second hash from an apparatus associated with the second entity, wherein the second hash comprises a hash of a previous data transaction involving the second entity; and generating a record of a second data transaction between the first party and the second party; determining third seed data by combining the record of the second data transaction with the first hash and the second hash; generating a third hash by hashing the third seed data, the third hash comprising a history of data transactions involving the first entity and a history of data transactions involving the second entity; and storing the third hash of the record for the second data transaction in the memory.

Providing the third seed data further includes: combining a third zero-knowledge proof and a fourth zero-knowledge proof with the record of the second data transaction, the first hash, and the second hash, wherein the third zero-knowledge proof comprises a proof that the first hash comprises a true hash of the first data transaction; and the fourth zero-knowledge proof comprises a proof that the second hash comprises a true hash of the previous data transaction involving the second entity. The previous data transaction involving the second entity is the first data transaction.

The method further comprises the steps of: each of the hashes is associated with an identifier of the first entity and/or the second entity. The method further comprises the steps of: recalculating the first hash; and comparing the generated first hash with the recalculated second hash to determine a match. The method further comprises the steps of: when the comparison is unsuccessful, further data transactions are canceled. The method further comprises the steps of: a system hash corresponding to the first data transaction is generated at a system device.

Providing the second seed data further includes: the system hash is combined with the record of the first seed data and the first data transaction. The system hash is a result of a hash operation performed on a record of a previous data transaction on the system device.

Providing second seed data, further comprising: receiving a license hash from a licensing device; and combining the license hash with the first seed data and the record of the first data transaction to provide the second seed data.

The method further comprises the steps of: at the licensing means: receiving the first hash; combining the first hash with the license hash to provide a license input; and generating a second license hash by carrying out hash operation on the license input.

Providing second seed data, further comprising: receiving a directory hash from a directory means; and combining the directory hash with the first seed data and the record of the first data transaction to provide the second seed data.

The method further comprises the steps of: at the directory server: receiving the first hash; combining the first hash with the directory hash to provide a directory input; and generating a second directory hash by carrying out hash operation on the directory input.

Providing second seed data, further comprising: generating a key hash from an encryption key for the first data transaction; and combining the key hash with the first seed data and the record of the first data transaction to provide the second seed data. The encryption key includes a public key or a private key.

Upon completion of the first data transaction, a combination of the first seed data and the record of the first data transaction is performed. The memory is located at a remote device. The method further comprises the steps of: at the remote device, the first hash is compared with corresponding hashes received from other devices. The method further comprises the steps of: other devices connected to the device are notified to expect to receive the first hash.

The method further comprises the steps of: the hash chain is stored in the memory. The method further comprises the steps of: the hash chain is transferred to a second memory located on a device configured to restrict access to the transferred hash chain. The method further comprises the steps of: modifying or deleting a hash in the hash chain by: regenerating object hash in the hash chain; confirm that the record is not modified; recording the regenerated hash; modifying or deleting the record; generating a new hash for the record by hashing the combination of the object hash and the modified/deleted record; and recording the new hash. The method further comprises the steps of: and generating system hashes by using the new hashes.

The apparatus includes a server. The device comprises a user device. The user device includes at least one of a desktop computer, a notebook computer, a smart phone, a smart tablet computer, or other internet of things enabled device. The user device is to store the first hash in a memory on the device. The user device stores the first hash in memory on the device only when it is offline from the corresponding server. The apparatus is further configured to transmit the first hash to an apparatus associated with the second entity. The apparatus is further configured to transmit a signed, encrypted copy of the record of the first data transaction to the apparatus associated with the second entity, wherein the signature includes an indication of a destination server for the record. The apparatus is for signing the record with a specific offline public key. The device is configured to sign the record using a key belonging to the device. Only the destination server is able to decrypt the encrypted copy of the record of the first data transaction. The apparatus is configured to: when the device resumes connection with its corresponding server, the encrypted record of its offline data transaction and the associated hash are transferred to its corresponding server. The apparatus is further for transferring a copy of its saved record of data transactions involving other entities to its corresponding server for transmission to the server corresponding to the other entity. The sending includes notifying all servers to which the record applies to expect to receive the record. The apparatus is configured to generate a unique internal transaction number to identify a portion thereof in the first data transaction.

The authorizing includes: and confirming whether the user device is authorized to access the first service according to the identifier. The confirmation includes: and confirming that the user meets at least one standard according to the identifier. The first standard is stored in the first host server or the request server; and the second criteria are located at a different server. The authorizing includes: a signature of a communication between the requesting server and the first host server is verified.

The authorization is performed in the request server. The authorizing includes: determining at the request server whether the device is previously authorized to access the first service.

The authorization is performed in a directory server. The authorizing includes: the request server requests authorization for the device from the directory server. The allowing includes: the directory server communicates an identifier for the first host server to the requesting server. The data authorizing the identifier is stored only on the directory server.

The method further comprises the steps of: requesting access to a second service; authorizing the device to access the second service based on the identifier; the device is allowed to access the second service through the request server. The second service is located at the first host server. The second service is located at a second host server.

Authorizing, in a first directory server, the device to access the first service; and authorizing the user device to access the second service in a second directory server.

The method further comprises the steps of: requesting access to a third service; authorizing the device to access the third service according to the identifier; the device is allowed to access the third service.

The second service is located at the first host server, the second host server, or a third host server. The device is authorized to access the third service in a third directory server.

Providing the identifier includes the device enabling communication with the requesting server through an encrypted tunnel. The method further comprises the steps of: data received at each respective server is cached. Each host server provides more than one service.

The device comprises at least one of a personal computer, a smart phone, a smart tablet computer, or a device capable of realizing the internet of things.

The migration includes, at the directory server: designating a start time stamp (timestamp) for the data in the second data store; and assigning an end timestamp to the data in the first data store.

The method further comprises the steps of: instructing a requesting server to seek through said directory server said user at said second data store, wherein said requesting server attempts to access data through said first data store after said end timestamp. The data in the first data store includes a first account registration with respect to a first account provider; and the data stored in the second data includes a second account registration with respect to the new account provider. The migration includes transferring information about the first account registration from a current account provider to the new account provider. The information includes at least one of a registration, balance, configuration, and/or payment instructions. The migration includes: an authentication code is validated, the authentication code indicating that the first registration should be switched from a current account provider to the new account provider. The first account registration includes a first user credential; and the second account registration includes a second user credential. The first user credential is registered at a first server and the second user credential is registered at a second server. Receiving, by the first account provider, a communication directed to a user using the first user credentials; the communication designation is routed to the second account provider using the second user credentials. The method further comprises the steps of: data transactions with the first registration provider utilizing the first credentials are reversed to the second registration provider utilizing the second user credentials. The method comprises the following steps: the user is determined to use the first user credentials during the data transaction. The server transmitting the communication must be licensed to access the second user credentials. The first user credentials and the second user credentials are the same.

The method further comprises the steps of: a random field is added to the second communication. Each field comprising two or more characters, the method further comprising blending different characters in at least one field.

The method further comprises the steps of: the fields are decrypted and ordered in the second communication by the second entity prior to processing the second communication. The method further comprises the steps of: discarding, by the second entity, fields that the second entity cannot handle. At least one of the first entity and the second entity comprises a server. At least one of the first entity and the second entity comprises a personal computer, a smart phone, a smart tablet computer, or a device that can implement internet of things.

The encoding includes encoding the ciphertext as a 7-bit or 8-bit string. The method further comprises the steps of: when the ciphertext is longer than the space allowed by the USSD-dialogue: cutting the ciphertext into two or more portions; and transmitting the two or more portions, respectively. For decrypting at the second device, including reassembling the portion into a complete ciphertext at the second device.

The method further comprises the steps of: authenticating the first device and the second device. The authentication includes utilizing an algorithm that provides privacy and data integrity between two communicating computer applications. The authentication includes utilizing transport layer security TLS. Utilizing TLS further includes generating a first session key.

The method further comprises the steps of: encrypting the negotiation of the PAKE protocol with the first session key, thereby generating a second session key; and encrypting further communications in the session between the first device and the second device using the second session key.

The method further comprises the steps of: authenticating the first entity and the second entity. The authentication includes utilizing an algorithm that provides privacy and data integrity between two communicating computer applications. The authentication includes using TLS. The method further comprises the steps of: a second PAKE session is generated between the first device and a third device using a fourth shared secret. The fourth shared secret includes an authentication code for the first device generated by the third device.

The first shared secret includes an authentication code generated by the second device for the first device. The authentication code is transmitted to the first device along with an identifier for the first device. The identifier includes a telephone number or serial number of the first device. The first shared secret includes a personal account number, PAN, of a bank card associated with the first entity. The first shared secret includes an encoded serial number of a bank card associated with the first entity.

Authenticating access to the service includes: access to a portion of the service is authenticated based on the credentials and/or the context. The credentials include a first credential associated with a device and a primary user of the device. The credentials also include a second credential associated with a device and a secondary user of the device. Authenticating access to the service according to the credentials, comprising: and authenticating access to different services for the primary user and the secondary user based on the first credential and the second credential, respectively. The device comprises a bank card and the different services have different spending limits for the primary user and the secondary user. The credentials are selected according to the context. The services include a plurality of services selected according to the context. An administrator or user can modify, add or cancel the context or credentials. The credentials include at least one of a password, a PIN, and/or other direct authentication credentials. The context includes at least one of a device providing the credentials, an application on the device, a network to which the device is connected, a geographic location of the device, and/or a service being accessed.

The method further comprises the steps of: batching a plurality of requests into batch information in a buffer memory of the first module; queuing the batch of information to be transferred to the second module; setting at least one system flag authorizing system functions; checking the at least one system flag at the second module; and processing the batch information at the second module.

The method further comprises the steps of: at least one shared memory channel is established between the first module and the second module. The method further comprises the steps of: the second module is responsive to the first module through the at least one shared memory channel. The method wherein the at least one shared memory channel receives and compiles the bulk information and delivers ownership of the memory to the second module. The method wherein the at least one shared memory channel receives bulk information over a network stack of the computer system. The at least one shared memory channel includes an HTTP gateway. The HTTP gateway is used as a web service.

The communication uses a cryptographically authenticated key exchange protocol. The method further includes utilizing a zero-copy network connection in a network stack of the computer system. The method further includes utilizing a user-mode network connection in a network stack of the computer system.

The method further comprises the steps of: the data is serialized such that components of the data transmission from the first module are combined into a single data stream and then separated into the components at the second module. The serialization is abstracted at the edges of the modules.

The buffer memory of each module has a configurable buffer threshold. The first module and the second module are located on the same computing device. The first module and the second module are located on different computing devices.

The data transferred from the first module to the second module carries a revision ID. The method further comprises the steps of: verifying whether the version ID is up-to-date for the data transferred from the first module to the second module. The method further comprises the steps of: when any one of the data is updated, it is re-verified whether the version ID is up-to-date. When the version ID is not verified, the data transmission fails.

At least one of the first module and the second module includes at least one data service module, wherein each data activity within the computer system is performed by the at least one data service module. The at least one data service module is configured to communicate with a data store implemented by a core database store. The at least one data service module is the only component of the computer system that directly accesses the data store. The core database store includes at least one distributed database. The at least one distributed database has independent read and write access channels. The data store provides an interface to at least one heterogeneous database. The data store provides a plurality of interface types. The plurality of interface types includes at least one of a structured query language interface, an interface of cells and columns of tables, a file interface, and a graphical interface layer on the core database store. All writes to the data storage layer are managed by a single shared module that controls all or a portion of one or more data transactions.

The method further comprises the steps of: at least one redundant backup of the shared module is operated. All data changes flow through the single shared module in a serial fast sequence. The single shared module uses a hot-standby redundancy model that presents itself as a cluster of data transactors, where the cluster of data transactors is a collection of modules in a hierarchy and each module is used to control data transactions when a master module fails. The method further comprises the steps of: the data is partitioned in a module or data store based on rules configured by the domain. The method further comprises the steps of: hash operations are performed on the recorded target data of the data transaction or the recorded target data of the parent data transaction. The hash operation has the same radix as the number of data divisions. The target data is hashed by at least one of the enumerated geographical areas, surnames, and/or currencies.

The method further comprises the steps of: at least one data transmission is performed at the data split by the at least one data service module. The method further comprises the steps of: at least one data transmission is accomplished via the at least one data service module by the multi-module. The method further comprises the steps of: at least one data transmission on the at least one data service module is continued on a data storage node in the data store.

The computer system includes a plurality of data service modules, and each data service module manages a memory/process database engine that includes cached representations of all hot data for a corresponding instance. The computer system includes a plurality of data service modules, and each data service module includes a plurality of heterogeneous or homogeneous database engines.

The method further comprises the steps of: the system is versioned by multi-version concurrency control to manage concurrency of access to the data store, such that all data reads are consistent and corresponding data writes are reflected. The method further comprises the steps of: managing concurrency of access to the data store using pessimistic consistency entails writing a data record to the data store and confirming that the data record was written prior to any subsequent data transaction accessing the data record.

The computer system further comprises an application layer, and wherein the application layer is unable to conduct a data transaction until the at least one data service module confirms that it has written a record and completed a data transfer.

All optional features of aspects 1 to 26 refer to all other aspects. Variations can be made to the described embodiments, for example, the features of the disclosed embodiments can be combined in any way. Drawings

Drawings

Exemplary embodiments of the present invention will now be described with reference to the drawings, in which like reference numerals refer to like parts throughout.

Fig. 1 is a drawing illustrating the modular concept of Tereon.

Fig. 2 is a diagram illustrating an example of a Tereon system architecture.

Fig. 2a is a diagram illustrating how Tereon abstracts its services and devices into functional domains and contexts, devices, components, and protocols.

Fig. 3 is a diagram illustrating communications initiated over a TLS connection through an intermediate proxy.

Fig. 4 is a diagram illustrating the use of shared memory and information to proxy memory.

Fig. 4a is a diagram illustrating a shared memory and a semaphore switching module (semaphore hand-over).

Fig. 5 is a diagram illustrating a hash chain for four accounts.

Fig. 6 is a diagram illustrating a hash chain for two accounts on the same system.

Fig. 6a is a diagram illustrating a hash chain for three accounts on the same system interleaved at the transaction stage.

Fig. 7 is a diagram illustrating the dendritic (dendrimeric) nature of the license hash.

Fig. 8 is a diagram illustrating a hash chain for four devices off-line for a period of time.

Fig. 9 is a diagram illustrating reverse lookup functions implemented for two servers.

Fig. 10 is a diagram illustrating the establishment of communication between teleon servers.

Fig. 11 is a diagram illustrating a communication in which a user has migrated to another server.

Fig. 12 is a diagram illustrating how a directory service directs a requesting server to two different servers.

Fig. 13 is a diagram illustrating a scenario in which a server needs to obtain credentials from three servers to construct a multi-faceted (multi-faceted) credential.

Fig. 14 is a drawing illustrating a relationship between a user and a bank.

Fig. 15 is a drawing illustrating a process of transferring accounts.

Fig. 16 is a diagram illustrating a process of changing registered mobile phone numbers.

Fig. 17 is a diagram illustrating maintenance of a previously registered mobile phone number so as to access two currencies.

Fig. 17a is a diagram illustrating the maintenance of a previously registered mobile phone number to access two currencies on separate servers.

Fig. 18 is a drawing illustrating a workflow (workflow).

Fig. 19 is a drawing illustrating an alternative workflow.

Fig. 20 is a drawing illustrating an alternative workflow.

FIG. 21 is a drawing illustrating an example computing system.

Overview

The present invention relates to a new method of processing transactions that does not take into account or are limited by the above alternatives. The present invention provides a method of verifying and processing transactions in real time that is capable of verifying and processing transactions at rates that are orders of magnitude higher than existing systems, and settling, processing, and completing the transactions in real time.

Real-time settlement is not limited to financial transactions. It can be applied to any transaction that requires, or benefits from, part or all of real-time authentication, authorization, processing, and completion. These can include access control, record verification, record and file exchange, command and control instructions, and the like.

The method comprises seven main fields:

and a method for writing very large-scale ACID-compliant transactions to arbitrary database products.

And one embodiment of a hash chain, provides record authentication across multiple private ledgers (private ledgers) on a very large scale within the boundaries of a single real-time conversation, and provides complete mathematical proof.

Rather than implementing a "hub and spoke" architecture that creates a major scalability challenge, a directory service that supports transactional service providers of mesh networks.

And an extensible architecture that allows merchants or user devices to update the applications (or apps) they use, thereby processing transactions wirelessly and seriatim.

As a data service layer supporting various transaction types between apps and a common database structure transformation matrix.

And a method for compiling and providing a set of point-to-point (ad hoc) credentials that allow a service or device to access a set of services or functions.

A method for generating secure real-time communication in any protocol including NFC (near field communication) and USSD (unstructured supplementary service data).

In particular, the system of the present invention provides a method to implement real-time transactions as the amount of transactions increases and to do so at zero incremental cost.

Detailed Description

Tereon is an electronic transaction and authentication engine. It may be implemented as a mobile and electronic payment processing system. But can also be used in other implementations, for example as part of an IoT communications system.

The Tereon provides transaction capabilities to any IP (internet protocol) enabled device, as well as any device that can interact with the IP enabled device. All that is required for this is that each device has a unique ID. The scope of use cases of Tereon includes access and management of IoT devices to medical records, or even payments using usual e.g. mobile phones, payment terminals, or ATM (automated teller machines). In one initial example embodiment, tereon supports mobile phones, cards, retail terminals, and any unique reference ID. The Tereon provides the functions required to enable customers and merchants to make payments, receive payments, transfer funds, receive funds, refund, receive refunds, deposit funds, withdraw funds, view account data, and view small statements of past transactions. Tereon supports cross-currency and cross-border transactions. Thus, a customer can have one account with one currency, but can make a transfer payment with another currency.

In the initial implementation of Tereon, whether an end user is able to perform a particular transaction is determined by the application that it uses at the point in time. The merchant or merchant terminal may begin some transactions and the client device may begin other transactions.

When using Tereon for payment, transactions can be distinguished into the following modes: making and receiving payments, mobile client to mobile merchant, mobile client to online merchant portal, mobile merchant in which mobile client to client is not, customer account to merchant account in account portal, NFC-Tereon card client to mobile merchant, NFC or other card client to card merchant, transferring and receiving funds, customer account to customer account in account portal, mobile client to mobile client point-to-point, mobile client to card client point-to-point, card client to mobile client point-to-point, card client to card client point-to-point, mobile client to non-user point-to-point, card client to non-user point-to-point, non-user to mobile client point-to-point, and non-user to card client point-to-point. Non-users may refer to persons who have not previously registered for payment services, such as money transfer recipients without a bank account.

System architecture (System Architecture)

Internally, the Tereon server includes two main components, namely a Tereon rules engine and an intelligent device application services framework (SDASF).

SDASF allows Tereon to manage any number of different devices and interfaces. Which defines how those devices and interfaces operate by allowing Tereon to use and link a list of abstraction layers and thus interconnect to Tereon.

For example, all bank cards will use a basic card abstraction layer. The magnetic stripe abstraction layer will apply to cards with magnetic stripes, NFC layers for cards with NFC chips, and microprocessor layers for cards with chip contacts. When a card uses all three, tereon will use the main card abstraction layer and three interface layers to define the card. The NFC layer itself is applicable not only to cards, but also to any NFC enabled device including mobile phones. The SDASF uses these abstraction layers to create modules for devices or interfaces.

Externally, each service and each connection to a device or network is a module. Thus, services such as point-to-point payment services, deposit services, and small statement services are all modules. The interfaces of the card manufacturer, bank, service provider, terminal, ATM, etc. are also modules. The architecture of Tereon may support any number of modules.

Modular view (Modular view)

Fig. 1 is a drawing illustrating the modular concept of Tereon. In essence, tereon is a collection of modules, most of which themselves comprise modules. Modules are defined by the context and functional domains in which they operate, and by the business logic that determines the functions they need to perform. These functions may be any type of electronic transaction, such as managing the operation of IoT devices and communication between IoT devices, managing and transacting electronic or digital payments, managing and building identification or authorization credentials on demand, or managing and running any other form of electronic transaction or device.

Tereon server

As shown in fig. 1, the modules that make up the Tereon server 102 can be viewed at two levels: the SDASF104 and the rules engine 106. The rules engine 106 itself defines the functional domains and contexts of the modules 108 (some of which are shown in fig. 1; this includes the modules defining services, protocols (not shown), smart devices, terminals, etc.), and these modules 108 in turn define the structure of the SDASF 104. The SDASF104 and its supported generated services and interfaces define the system protocols for use by the Tereon. These protocols then define rules and services that the Tereon can support, e.g., smart devices, terminals, etc., which themselves define the functional domains and contexts provided by the Tereon. The loop or iterative method is used to ensure that the definition of the modules and the functions or requirements they support are consistent with each other. This enables the module to be updated, upgraded, and replaced in situ without limiting the operation of the system.

The blocks and modules are interconnected using an abstract application programming interface (API, which itself defines the functional domains and context provided by Tereon, possibly with custom semaphore switching modules, an example of which is shown in FIG. 4a and described below, and shared memory may also be used.

Infrastructure component of architecture (Framework infrastructure components)

The infrastructure components are also modular. In the example of SDASF, the component itself includes modules.

Multi-interface (Multiple interfaces)

Each interface is constructed as a separate module connected to the kernel server. The modular structure of Tereon thus enables it to support a plurality of interfaces, including logistics and kernel systems, cards, clearing houses, merchants, mobile phones, services, service providers, storage, terminals, SMS (short message service) gateways, HLR (home location register) gateways, etc.

The database interface supports the input of Structured Query Language (SQL) and graphical analysis of stored data. The interface also supports access control to individual fields within the database. Different user roles and hierarchies of authorizations can access defined data sets and fields. Access is controlled by various security means. Access, authentication, and authorization are implemented in a range of ways that are standard by industry, including ACL (access control list), LDAP (lightweight directory access protocol), and custom role-based access, such as security of cells and columns, and access interfaces that are limited to individual roles.

Electronic commerce portal (E-commerce portals)

The Tereon may support an e-commerce portal through an API whereby the operator of the portal can generate plug-in for the portal.

Rule engine (Rules engine)

The rules engine 106 allows new services to be built by combining various abstract components of the transaction together or allows new services to support new devices. Rules define business logic for configured services, and service providers are able to customize these services for individual users.

Rules can be defined in UML (unified modeling language) or code like simple english. The engine will parse the rules and generate services from the abstract components.

The abstract nature of the components allows new service or device modules to be quickly generated. This enables Tereon to support new services or devices as needed.

The internal interface of Tereon is protocol independent, which allows external protocol modules to be interchanged without affecting functionality. For example, to couple to a banking core system, custom data exchange protocols may be used with one part of an organization and ISO20022 protocol modules with another part.

The SDASF104 enables Tereon to support multiple intelligent devices and protocols. The idea of the SDASF104 is to abstract entities into device types and protocols. The SDASF104 defines a number of protocols and each device invokes any protocol required for a particular service or function.

The SDASF104 can be extended by adding new modules to existing devices without affecting the operation of the device. This enables all services to be defined at the backoffice server using any preferred method. Once installed at the merchant terminal, the Tereon terminal application communicates with the SDASF to provide services to the customer.

Fig. 2 is a diagram illustrating an example of a Tereon system architecture 200. Wherein the drawings and description illustrate specific components by specific solutions, which are only components or languages selected in the embodiments. Custom systems can be constructed to replace these components, or to use other languages and systems that prove more effective.

Tereon server

The Tereon service 202 is a logical construct that is considered a monolithic artifact. In practice, it exists as a set of independent microservices, each of which varies in function and scope.

Communication layer

The communication layer 204 is initiated over a TLS (transport layer security protocol) connection through an intermediate proxy. This is also shown in fig. 3. TLS is a cryptographic protocol that provides communication security over a computer network, typically a TCP/IP (transmission control protocol/internet protocol) network. Each component has an ACL (access control list) that specifies which users or system programs can access or connect to a system, object, or service. This can ensure that only the vehicle can establish access, original connection, improve intrinsic security, and reduce threat files. In this example, the proxy uses an HTTP gateway platform known in the art with specialized Tereon customization.

Private DNS network

DNS206 is the basis for directory service 216. Directory service 216 is highly redundant and replicated across geographic locations. However, as will be described below, it far exceeds the structure and functionality that can be provided by existing DNS services.

Abstractions (Abstractions)

Fig. 2a is a diagram illustrating how Tereon abstracts its services and devices into functional domains and contexts, such as customer or customer activities and rules, merchant activities and rules, banking activities and rules, transmission activities and rules, device functions and rules, and the like. Fig. 1 is a diagram illustrating how Tereon affects the components and services of a system by abstracting them into functional blocks or modules.

The Tereon module is built from these abstractions. Devices, interfaces, and transaction types are abstracted into their domains and contexts. These abstractions are reusable and, where meaningful or permissible, can be connected to other abstractions. For example, rechargeable cards, credit cards, debit cards, and membership card modules can each use many common abstractions. The same is true of the payment and funds transfer module.

Protocol(s)

The Tereon-supported communication layers 204 and 212 are themselves implemented as a module. Tereon enables these modules to be used by services or components that require these protocols.

Reservation systems (Legacy systems) have difficulty handling hundreds or thousands of synchronized transactions before they have to add hardware. In contrast to newer systems, banks rely on periodic settlement systems that require checking accounts and that entail high costs of credit risk up to the clearing point. Tereon eliminates the credit risk and the need for such accounts. It provides a system that can afford to handle hundreds of thousands of transactions per second. Tereon is used to increase flexibility, support each server to process millions of transactions per second, and runs on high-end commodity hardware, rather than relying on expensive hardware. The Tereon also supports horizontal and vertical scaling in a near linear fashion without violating ACID guarantees or affecting its real-time performance.

License subsystem

The Tereon license server 210 allows components of the system to ensure that they communicate with legitimate, authorized, licensed peer systems within a single deployed instance, as well as across deployed instances (e.g., independent client platforms that communicate with each other), where a single deployed instance refers to a single instance's microservice communicating between programs on a single machine, whether or not the machine is, for example, a physical machine, a logical machine, a virtual machine, a container, or any other common mechanism for aggregating executable code, as well as across any number or type of machines. The licensing platform is implemented by a certificate authority as known in the art.

When components are installed into the system, they will communicate their installation details (organization, component type and details, license keys, etc.) and certificate signing requests to the license server over a secure, authenticated connection at prescribed, configurable intervals (e.g., monthly and one week in advance).

The certificate server compares these details to its authorized component catalog and when there is a match, grants a new certificate to the device that initiated the installation request, which is signed by a separate secure signing key (typically by a hardware security module) in the internal certificate authority (certificate authority) hierarchy, and can be used for a specified period of time (e.g., one month). All clocks in the connected system are synchronized.

The caller can use the certificate as a client certificate when initiating communication with other modules, and can use the certificate as a server certificate when acting as a recipient of the connection. The license server, which never receives the private key, does not retain details that would allow any other party to impersonate this certificate, even if it has been compromised. If desired, the caller may request two certificates, a client certificate and a server certificate, from the license server.

Each component can verify whether the server and client certificates are signed by the proxy of the trusted authorized certificate authority and can be quite trusted and not subject to man-in-the-middle attacks or monitoring even if the other claims to be. Each certificate is granted use of code metadata that limits how each module presents itself; for example as a lookup server for a particular organization. The organization determines authorized valid instances where all participants are operating.

Most certificates are granted for a fixed period of time and are not renewed after expiration. However, when few certificates leak, or are terminated or suspended, the revocation list is used and distributed to proxy services according to an asynchronous manner. An active certificate directory is maintained throughout for periodic auditing.

In addition to the advantages of two-way authentication (client referred to as itself, server in each connection referred to as the reporting party), this embodiment allows components to communicate securely with each other without requiring that each connection be established requiring communication with a remote license server, which can communicate securely without potentially degrading the overall reliability of the platform.

Site to site communication

The promotion of site-to-site communication is accomplished by authenticated and published HTTP gateway instances 212 that perform custom zero replication and optional user mode functions. In addition to site-to-site connections, this is also a platform for mobile devices, terminals, and other external parties to communicate with the instance. This applies to intrusion detection, rate limiting, protection against DDOS (distributed denial of service) attacks, hardware encryption offloading, etc. of industry standards. Functionally this is a large logical instance proxy mechanism that supports all the same functions including client/server certificates and authentication, while also using externally approved external parties' certificate authority.

Tereon data service

One of the key features of the Tereon system is the ability to process more transactions (in terms of throughput) than the previous system. This is due to the unique design that enables a highly concurrent, fast and scalable processing network capable of processing data and transactions, an extremely efficient data service layer, and algorithms and custom modules that minimize processing overhead.

The described performance features are primarily directed to extensions that are capable of performing more operations on a given computing hardware, thereby significantly reducing operating costs and power consumption. However, the design is not limited to a single system; the Tereon system can be extended to a considerable extent both vertically and horizontally, where each service can run simultaneously on a large number of devices.

To achieve a high level of performance on a single system or server, the system preferably minimizes processing overhead by avoiding unnecessary serialization, avoiding unnecessary streaming processing (stream processing), avoiding unnecessary memory duplication, avoiding unnecessary transitions from user to kernel mode, avoiding unnecessary background switching between programs, and avoiding random or unnecessary I/O. When the system is properly executed, the system is able to achieve extremely high transaction performance.

In the conventional model, server a would receive the request. It will then construct and serialize the query to server B and immediately transmit the query to server B. Server B will then decrypt (if necessary), deserialize, and interpret the query. Next, it will generate a response, serialize, and if necessary encrypt the response, and transmit the response back to server a or another server. Kernel and context switching (context switch) occurs several tens of times in each piece of information, a single piece of information is converted multiple times in various forms, and memory is copied between multiple job buffers. These kernel and program context switches impose a significant processing overhead on each piece of processing information.

Communication architecture

The teleon achieves throughput by conventional means of the reorganization system processing data and communication. When possible, tereon bypasses the operating system kernel to avoid the processing overhead imposed by the kernel and to avoid security issues that often occur with standard data management models.

Each data activity within the system is performed by the data services layer 214. This is an extended service oriented data service layer, which is the only component of the system that has direct data platform access. Thus, all data activity on the system must pass through it.

The data services layer 214 communicates with the data storage layer 220 via a separate dedicated read and write access channel 226. The data store layer 220 is executed on the kernel database store 224, which itself comprises at least one distributed database. These databases do not need to provide assurance of ACID; which is managed through the data storage layer.

All writes to the data store layer 220 are managed by a single shared transactor, all data changes are streamed in a serial rapid sequence to maintain causality. The transactor design uses a hot-standby redundancy model that itself appears as a cluster of data transactors 222. When a transacting party fails or stalls for any reason, one of the other transacting parties will take over immediately.

Although the data platform supports partitioning all data domains, the support is not shown in the figures. When a single data storage layer (supported by unrestricted data nodes) is found to be barred in any case, or barred due to administration, the data may be partitioned in a forced or declarative manner to store different transaction parties to different data clusters. For example, a site may have four data platforms, with customers being divided by geographic or jurisdictional standards, or with accounts 1-5 beginning transaction parties being divided into one cluster and 6-0 beginning transaction parties being divided into another cluster. There may be some branches to this that can be handled, but this depends on whether the platform is supported.

Fig. 3 illustrates communications on the communication layer 204 that route communications to the data service layer 214 or from the data service layer 214. When the module 350 needs to communicate with another module 360, a connection with the proxy 370 is first initiated, the client certificate is passed for authentication in step 302, and then in step 304 it is checked whether the construction agent certificate is valid and trusted. The module 350 passes the information to the agent 370 in step 306. Agent 370 establishes an associated connection with target module 360 at step 308; it first authenticates itself at 308 and verifies whether the module's credentials are valid and trusted at step 310. Next, agent 37 passes the initiator (the validated details of module 350. Agent 370 passes back to the target (the details of module 360 and its response) at step 316 before receiving the module's response at step 314. Thereby, a channel is established between module 350 and module 360 through agent 370, where the two modules mutually authenticate and identify with high degree of confidence and encrypt all communications and data if necessary. Agent 370 relays the information from module 350 at step 318 to target module 360 at step 320 and relays the response of the target module at step 322 to module 350 at step 324.

These connections use a liveness detection mechanism (keep-alive) and dialog sharing (e.g., module 350 "closes" the connection to target module 360 through proxy 370 and reopens the end-to-end connection without requiring actual construction) based on the caller and recipient's certificate details. The communication agent 370 may be an HTTP gateway, or other suitable module or component.

Traditionally, such architectures typically have had significant running costs and used large amounts of memory. In order for the module 350 and the target module 360 to communicate, it is conventionally necessary to serialize the payload, encrypt the payload, stream it to the proxy 370, where the proxy 370 will decrypt the payload, deserialize and interpret the content, re-serialize the payload, and encrypt it for the target module 360 before it is passed to the target module 360, and encrypt it for the target module 360. Next, the target module 306 will decrypt the content, deserialize, and interpret the content.

Tereon uses a variety of techniques to reduce average and maximum latency, reduce memory loading, and improve single platform performance on commodity hardware. This achieves monolithic, intra-program performance while maintaining all security, maintenance, and deployment advantages of the microservice. This does not affect the high level of security and control that such a system must provide.

As shown in fig. 3, tereon may use a batch information model on the communication layer. The transfer of information, such as information transferred from the module 350 to the agent 370 in step 306, may be batch information. However, tereon may implement more.

In addition to bulk information, fig. 4 is a diagram illustrating how two server modules communicate with each other through a proxy module (custom switch module) to negotiate a shared memory channel between them. Steps 402 to 412 are similar to steps 302 to 312 of fig. 3, except that the attributes of the services can also be checked in steps 302 to 312 to confirm that they match the client requirements, when required.

Examples of modules 450 through 460 can use TLS, or conventional TLS HTTPS, preferably with user mode and zero replication of the HTTP gateway for caller transactions.

When modules 450 and 460 are local, then after establishing a connection from steps 402 to 412 through proxy 470, the caller and recipient may optionally request a direct connection to each other through the shared memory request, and thus have optional requests therein, which deviates from the method shown in fig. 3. When the caller and receiver request a direct connection to each other, after negotiation, the shared channel is transferred from block 460 to agent 470 at step 414 and from agent to block 450 at step 416, and both modules begin using a direct-to-direct program mechanism from the point, which re-uses the semaphore and shared memory. This is illustrated by the information between module 450 and module 460 in steps 418, 420, 422.

In the Tereon model, most desirably for a task, the module 450 batches multiple requests in the local memory buffer, queues the information for the module 460, and beats (trip) the semaphore. Module 460 checks the flag, processes the direct shared memory, and responds in shared memory. The connection uses a keep-alive mechanism (keep-alive) and a shared memory according to the details of the caller's certificate and the recipient's certificate, and the shared memory and semaphore for communication.

By using the above method, communication can avoid the overhead of serializing and streaming (assuming it is contained within the machine) to a single caller destination of secure ACL control. It does not require encryption; the connection is verified, authenticated, and authorized at the time of setup and cannot be hacked, and the program can share a large-scale proprietary memory structure where appropriate.

When possible, the proxy 470 and Tereon code modules (such as modules 450 and 460) support zero-copy network connections as well as user-mode network connections (HTTP proxy may provide a costly solution to avoid kernel context switching for network packets when compiled using the necessary TCP/IP libraries). This is facilitated by the network driven specific code used by agent 470 and the Tereon code module. This minimizes memory usage for small packet requests and responses; these include a large number of Tereon operations, most of which fit into a single TCP packet (TCP packet).

Fig. 4a is a diagram illustrating how a teleon system implements a customized set of semaphore switching modules 408a that may also use shared memory for efficient data exchange between any two components of the teleon system (e.g., HTTP gateway 406a and micro-services 410a that provide functionality within the teleon. In fig. 4a, the data services layer 214 is embodied by the micro-services 410 a. However, micro-services may represent any kind of service module.

The network stack 404a (including a loopback virtual device) receives and aggregates requests from the connection server 402a, and then instead of copying the requests into the target memory of the user mode, simply grants ownership of the memory to the recipient, in this example the HTTP gateway 406a. This is advantageous under very heavy loads (e.g., millions of requests per second) when bandwidth saturation begins to occur in the memory.

The custom Tereon upstream (upstream) HTTP gateway module 406a allows local instances (one HTTP gateway instance on each container or on each entity, logic, or virtual machine in relation to HTTP gateway instances) to selectively use shared memory and information passed from the gateway to proxy memory and vice versa for upstream connections. The HTTP gateway 406a does not serialize the request and communicates through conventional mechanisms, instead the HTTP gateway 406a uses the shared memory communicated to the recipient when configured as an upstream provider for the shared memory.

In this case, the shared memory may have been set up using another HTTP gateway, an HTTP gateway instance, or other element that acts as a proxy. The use of HTTP gateways may be particularly effective.

Instead of using a communication hook (hook) provided by the operating system kernel, each data exchange module bypasses (bypass) the kernel; thus, the throughput of the system is increased by avoiding core overhead and the unsafe problem of data being transferred in and out by the services provided by the cores is solved. Within Tereon, modules are used, for example, to efficiently exchange data directly from system components to data services layer 214, and from data services layer 214 to system components.

Another advantage of this architecture is that the efficiency of the HTTP gateway 406a is improved by using a switching module 408 that allows the HTTP gateway 406a to pass all incoming data to the micro service 410a, including, for example, the data service layer 214 or other components, and all outgoing data from the micro service 410a or data service layer 214 to the HTTP gateway 406a. Instead of using the default HTTP gateway's data and information switching, which is itself efficient, the semaphore switching module may also use a shared memory, allowing data to pass directly to the data service layer 214, bypassing the kernel, and from the data service layer 214 to the HTTP gateway 406a. This not only increases the throughput of the system; there is also the additional advantage of protecting common vulnerability areas in systems using HTTP gateways.

The modules that provide the shared memory channel, or the modules that communicate with the shared memory channel, may both batch and serialize, or deserialize and separate requests. The modules that execute a job are essentially the functions of the modules, and the processing overhead that the modules incur in their normal operation. For example, in one case, a module that is itself receiving a large amount of information (which may or may not be a request) may pass its information to a shared memory module, which itself will batch and serialize that information for the recipient, as the overhead of batch and serialization may prevent the module from efficiently processing the information when loaded. In another case, the module may batch and serialize the message to a particular recipient before the batch is transferred to the recipient over the shared memory channel.

In yet another case, the module that delivers the information to the recipient module may rely on the module providing the shared memory channel for batching and serializing the information, however, the module that receives the batch information itself is able to deserialize and separate the information. The problem of which module implements batch and serialization, or deserialization and separation jobs is essentially which option provides the best level of performance for the execution of the module. The order of batching and serialization depends on the type of information and the functionality provided by the communication module.

The Tereon uses the HTTP gateway 406a to masquerade as a web service (web service), thereby avoiding the potential problem of network operators organizing non-standard services. Of course, when needed, teleon can masquerade as any other service, thereby easily interoperating with known network security configurations.

Based on this design, the system performs a modular approach throughout the architecture, where the system uses modules designed to develop available resources and avoid kernel overhead when possible. As a further example, a networking system, modules used by Tereon when possible, support user-mode network connections or zero-copy network connections in the network stack 404 a. This avoids the heavy overhead of using networking. The modular design also allows the Tereon to run on multiple types of systems, where similar custom modules provide similar functionality and can be custom made for each operating system or hardware configuration.

The manner in which the medium is described in fig. 3 and 4 allows for a centralized control point for all communications, either in-machine or out-of-machine. Which is a single control point for evaluation and security control, monitoring and auditing, and for special rules or redirection. This ensures that the system can be flexibly deployed even when it is in operation, without causing downtime or significant risk. It can also easily facilitate load balancing and redundancy without requiring any client awareness or complexity.

When the module 350 of fig. 3 wants to talk to the target module 360, the use of the intermediary allows the target module 360 to achieve load balancing across "n" machines and to be able to move across any number or type of machines without requiring reconfiguration of all potential clients, but simply reconfigure the intermediary.

The system uses a PAKE (cryptographically authenticated key exchange) protocol for providing two communicating parties with the ability to mutually authenticate their key exchanges. For other well known public key exchange protocols such as the Diffie-Hellman key exchange protocol, this is not possible, resulting in a protocol that is vulnerable to man-in-the-middle attacks. When the PAKE protocol is used correctly, man-in-the-middle attacks can be avoided.

In the case of a Tereon communicating with an external system (e.g., an external device or server), it adds an extra layer to the communication system. Many protocols for key exchange are theoretically vulnerable to man-in-the-middle attacks. Once the connection is established, the system uses the PAKE protocol to establish a second secure session key after using the certificate and signed information to confirm that the communication is between two known entities, thereby making the communication immune to man-in-the-middle attacks. Thus, the communication will encrypt all communications using the TLS session key, and then the session key of the PAKE protocol.

When using a device with a non-destructible identity string for communication, TLS may be omitted if necessary, while the PAKE protocol is used as the primary session key protocol. This may occur, for example, where the device is a small hardware sensor that constitutes a set of components of the internet of things.

Communication method

The Tereon data service layer 214 provides n+1 or more redundancy and optionally duplication of multiple sites according to a key-value store (key-value store) with graphics functionality and provides complete ACID guarantees by coordinating transaction parties (devices or modules that execute, manage, or control all or a portion of one or more transactions). The data services layer 214 is encapsulated in a data domain service, providing zero copy functionality and unlimited read expansion, in-memory caching, and very high levels of write performance in addition to the functionality of shared memory. This remains in data clusters of variable size and with large memory caches. In a very unique case, key-value storage can be used directly around the data service.

The data services layer 214 provides high-performance, traditional SQL-type functions and graphics processing to support functions such as funding flow analysis. The data services layer 214 is coupled with a module communication architecture with high performance (providing platform efficiency and performance), thereby providing an extremely efficient design that has exceeded 280 everything per second in testing on commodity server hardware (using a 10Gbps network connection to bind).

By implementing the following architectural priorities, the system can significantly reduce the number of kernel and program context switches required to transfer information within and between processing systems:

a) Zero-copy network connections can be used to minimize the cost of transmission from the network edge to the service.

b) The network connection of the user mode may be used to minimize the cost of transmission from the network edge to the service.

c) Where serialization is required (mainly when crossing machine or server boundaries), efficient serialization is used, such as protocol buffers or Avro, rather than high overhead serialization, such as Simple Object Access Protocol (SOAP). This abstracts at the edge of each server so that a given server can easily talk to a peer server on another continent over the internet, despite the lower performance and efficiency.

d) Servers have configurable buffer thresholds that will attempt to batch requests to minimize program context switching and maximize cache consistency for any given server. For example, when server a arrives with 10,000 requests within 20ms, the platform targets a 20ms buffer window that requires server B to assist with 10,000 requests, so it gathers 10,000 requests as a single request and then queues asynchronous information for server B, marking the semaphore. Server B may then quickly process 10,000 requests, providing a single response to server a. This may be configured with optimal efficiency with respect to maximum response time.

Indeed, reducing the number of kernel and program context switches has led to a tremendous improvement in the performance level of the platform. Because of the bulk information delivery, the Tereon model does not trigger multiple kernel and program context switches for each information block, but rather triggers multiple kernel and program context switches for each information block. Based on the test, by using this model, the performance difference between the conventional model and the Tereon model is 1:1000, and is larger for many job loads.

However, the module and its advantages are not limited to a single system. For example, the Tereon system uses efficient serialization and batching even if there is a server a and a server B that are not on the same machine. The Tereon model can significantly improve network and processing performance, whether coupled with an optional zero-copy or user-mode network connection.

Tests have shown that these design elements have demonstrated that local server-to-server operations return tens of millions of information requests and responses per second (in batch, shared memory mode), and that at low speeds, they operate millions of times per second on high speed network lines (e.g., 10Gbps bonded).

Since these transactions can all be processed in real-time and checked immediately, there are many advantages-especially for banks, ioT, medical, ID management, transportation, and other environments where proper data processing is required. In particular, such systems do not currently check transactions in real-time. Instead, transactions are checked after a period of time, sometimes in batches. This also illustrates the reason that, for example, financial transactions are typically conducted in batches and after hours a separate verification process is conducted. By using the Tereon system, the bank is able to check all financial transactions in a way that was previously unrealizable. This enables the bank to avoid generating a reconciliation account (reconciliation accounts) for unchecked financial transactions, or to avoid failing to accurately achieve that all transactions required have completed reconciliation at the time of processing.

Transaction and data partitioning

All atomic activities in a Tereon system are transactions-they succeed or fail as a whole, which is also a fundamental requirement for any system that follows the assurance of a transaction ACID. This section briefly describes its implementation, and the details of the method adopted by Tereon for transaction and data partitioning, thereby mitigating the impact of partitioning on ACID guarantees to implement transactions.

As above, various data activities within the Tereon platform are performed by the Tereon data services layer 214, which instance itself may operate as a set of micro services 410 a. This is an extended service-oriented system, which is the only component in the system that has direct data platform access, and thus all data activity must pass through it. These data services are extended so that parallel transactions within the system can be completed through different data service instances, using instance cache data MVCC (multi-version concurrency control) to ensure consistent data reads at all times.

Data activity occurs to the data service instance through atomic information, the information comprising the entire data job; for example, a job may be related to reading several related records and attributes, or updating or inserting data according to the data or task combination relied upon. The data service instance executes the job as a two-phase commit transaction of the data store across all background transactions.

The Tereon model guarantees data consistency by the following technique:

a) Any one set of read data carries a version ID.

As an optimistic transaction, all writes (updates and dependent inserts) verify that this version ID is up-to-date for all relevant data. This means that if one source reads three records to obtain various account attributes (e.g., permissions, balances, and currency data), the data cluster has a consistent version ID. If either of these values is later updated, or relevant dependent data (e.g., a financial transfer) is written, the version ID is again validated as up-to-date, and if it differs, e.g., a change in monetary assumption, or a change in exchange rate, the writing as a whole fails entirely. If appropriate, the downstream service is re-read and the data is evaluated for changing transactions in any substantial way. If not, the transaction is re-committed. Likewise, if a transaction fails, the transaction is repeated until a configurable number of retries is exceeded and a hard error (hard fail) is issued. Under normal circumstances, hard errors are almost impossible.

In most real world scenarios, even though the transaction volume and account diversity are quite large, no failed optimistic transactions occur. In rare cases, data is never corrupted and the processing overhead is minimal. Assuming that the platform used is a permanent historical database (in special cases, out-of-specification deletions may be required), the MVCC/optimistic model also fully protects the deleted records.

b) The platform is written for a given data partition (this is a concept separate from the horizontal extension of the data services).

Many data service instances may write to and read from one data partition, and a single data service instance may be stored in and read from multiple data partitions in its entirety. All reads and writes occur through a single master transaction instance 222, with one or more redundancy operation backups if necessary. However, only a single instance is continuous activity. This ensures that the validity of transactions and causes and effects is maintained in all cases (e.g., no skew during a network break (split) or during a short communication delay). This transactor confirms whether all optimistic transactions are valid and continuously updates the cache manager in the data service instance, which is of background importance to the effort.

c) Optional data partitioning

Limiting to a single transactor may limit the extensibility of extremely large Tereon instances (e.g., a single organization may manage multiple Tereon instances by region). The concept of data partitioning is that a terron data service cluster may divide data across transaction parties 222 or data stores 224 based on terron rules configured by domain. As a heterogeneous multi-component hash strategy, the Tereon platform currently supports the following partitioning rules:

i) The target data for a given element or any superior element (e.g., a hash from the details of the parent record) is hashed. The radix of the high performance hash (cardinality) is equal to the partition number.

The system does not currently provide rebalancing, so in the current embodiment, although rebalancing will be provided in future implementations, hashing must be performed in advance (although multi-part rules including hashes of the original date and time may still be used to increase partitioning at present).

ii) the data configures a hash of the target data for a given element or any superior element, e.g., by enumerated geographical area, by surname A-K or L-Z, by currency, etc.

Hashing for data supports ranges of alphabetic and numeric, unicode (Unicode), and other character codes, integer ranges, floating point ranges, enumeration sets.

iii) Combinations of the above.

For example, in one embodiment, two letters a and B may refer to two separate data sets that collectively span an entire geographic area, where the numerals 1 and 2 refer to two partitions of the area. For example, a single partitioning rule may support partitioning between 1AB and 2AB at the top level by data rules such as geographical area, then further partitioning between a and B by account hashing.

d) A single job implemented through a single data service instance may span multiple data partitions and be completed by multiple transaction parties and maintained on a large number of data storage nodes.

This presents significant complexity for data integrity. However, since all components of the transaction are bound in a two-phase commit package (wrapper), the integrity of the data is guaranteed. For all persistent nodes and participants, the transaction as a whole succeeds or fails and provides guarantees of all the same versions.

The end result of this architectural design fusion is that the system has complete transaction security, high redundancy, and high scalability, both vertically and horizontally. Although write transactions (in most cases including small portions of activity) may be limited by the transaction necessity of a single transactor per partition, adding rule-based partitions, and in particular upper level data elements, provides great flexibility in expanding the system to a conceptually wireless degree, even before considering branching (bifurcating) instances.

Implementation of the Tereon data store

The Tereon infrastructure is capable of handling over one million ACID assurance transactions per second. This is achieved by abstracting or implementing the data storage layer 220 on a distributed database or database 224 by using a high performance key/value distributed database for a storage layer (storage tier) with separate read and write access channels 226 (this can be at any level of depth, from abstraction through the Tereon data service to direct database usage to the storage tier). The use and configuration of Tereon for data storage is unique.

The data service layer communicates with the data storage layer through its customized data exchange module. The database itself need not provide any ACID guarantees at all, which is handled by the data store layer 220. The database itself need not provide the graphics functions as they obviously slow down the writing process. The data storage layer 220 provides an interface to the heterogeneous data layer and provides the required interface functions to the different parts of the system. Thus, the write function provides a fast cell and table column structure, while the read interface provides a graphical interface enabling it to traverse distributed data storage in microseconds.

The data store layer provides an SQL interface as well as a graphical interface layer on the kernel data store database 224 and provides many important architectural advantages that separate the Tereons. In practice, the instance manages the database engine and the data cache representation of all current transactions, the state of each current transaction, and other information that is information of the current state of the instance in the RAM portion or other flash memory of the machine, or of the machine, when the instance is running.

This enables the Tereon data service to make most face-to-face read jobs easier at extremely high rates (millions of discrete queries per second per instance with thermally related data cached locally), an order of magnitude beyond the achievable performance level being external or off-board requests serialized and issued to external database systems. When the data is not in the intra-program cache, it will be retrieved from the key value store.

The MVCC version system is used to manage concurrency, and the attribute of the data layer is that the data is never deleted (except in the case of forced deletion for compliance), where the system maintains a complete history of each record change for the lifecycle of the data system. This makes simple operations such as "as of" queries and auditing any platform changes possible.

The data layer is written using a single shared transaction party, all data changes must flow through and be handled within the serial flash sequence. This can ensure that transactions are efficient, consistent, and minimize change concurrency overhead, which is a heavy burden for most database platforms. The transaction party design uses a hot-standby redundancy model. When the transaction part program changes, it notifies all active query engines (in this case present in the Tereon data service) and updates the in-memory cache as appropriate.

Regardless of the size of the data store, the design provides microsecond delays for reading, writing, and searching. It also provides a modular structure that allows for the upgrade and replacement of components without affecting their operation. This data store is abstracted from the implementation of the foundation (unrerling) and can be replaced with other stores in the Tereon data service.

When the data storage layer is set to use pessimistic ACID guarantees 226, then an additional step is added to confirm that a record has been written before entering the next transaction, which adds a short delay, but provides absolute guarantees for ACID consistency and data integrity.

This design has the advantage of providing ACID guarantees since the application layer cannot continue until the data layer confirms that the record has been written and the transaction is completed.

This means that problems due to final consistency can be eliminated, for example in banks, payments, and other transaction types where causal relationships have to be maintained. The need for a reconciliation account (reconciliation accounts) to compensate for the difference when a bank system finds a non-matching program is also eliminated by the ACID assurance design. Real-time processing also means that the time delay of creating the collation process on the final consistency system is eliminated.

The design of the platform provides an extremely high level of redundancy and reliability on commodity hardware, and extremely high scalability (both vertically and horizontally). Possible constraint theory about transactor systems has led to the construction of partitions in data services to overcome these limitations, but in most cases the platform is never used.

Lookup/directory service

The teleon system has a directory service 216, which is a directory of credentials and information in the system that identifies which server the device or user 218 is registered with, or which server provides a particular function, resource, facility, transaction type, or other type of service. Because the directory service stores different types of credentials for a particular user, the directory service is capable of performing multiple user 218 authentication methods. For example, the user 218 may authenticate using a mobile phone number, email address, geographic location, PAN (primary account number), etc., and cache data so that authentication does not have to be performed each time.

Directory service 216 provides an abstraction layer that separates the user's authentication ID from the underlying service, server, and actual user account. This provides an abstraction between the credentials that the user 218 or merchant can use to access the service and the information that is required by the Tereon to execute the service itself. For example, in a payment service, directory service 216 would simply link an authentication ID, such as a mobile phone number, or a currency code with a server address. Also, there is absolutely no way to determine whether the user 218 has a bank account or which bank the user 218 uses.

The system architecture enables Tereon to provide a number of novel services or features beyond existing systems.

The Tereon system architecture is beneficial because it allows for a scalable and redundant system. Banking core systems tend to provide modules dedicated to individual channels such as card management, e-commerce, mobile payment. This strengthens islanding (silos) and increases the complexity of IT systems. Complexity is one of the reasons that banks cannot update their services and systems on a regular basis.

The purpose of Tereon is to support all devices and all use cases using a module architecture with a high degree of configurability and customization. The core of which is the SDASF104 and business rules engine 106 discussed above, as well as a high level of abstraction. It is this that together with the extensible architecture gives the Tereon flexibility.

The Tereon enables operators to offer and support many transaction types using standard carrier-grade systems. The Tereon can support any transaction, whether or not the transaction requires authentication.

Special procedure

The special program 208 desirably uses the functions of the data service. However, there may be instances where the special requirements do not justify the change or expansion, and thus are used within a special program for directly retrieving a database (data library) from the data. This can include, for example, graphics function programs such as AML (back money), CRM (customer relationship management), or ERP (enterprise resource planning) functions.

Multi (Multiple) service

The modular architecture of Tereon enables multiple types of services and devices to be supported, since each service is a module. For example, in payment, the architecture enables Tereon to support a variety of payment types and devices, including banks, rechargeable cards, credit services, credit unions, debit services, employee plans, electronic wallets, loyalty programs, member programs, micropayment, prepayment, student services, ticketing, SMS notification, HLR queries, and the like.

Multi-endpoint device (Multiple end-point devices)

The modular structure of Tereon supports almost any endpoint device for direct or indirect communication, including magnetic stripe cards, smart cards, feature phones, smart phones, tablet computers, card terminals, point-of-sale terminals, ATM, PC, display screens, electronic access controls, e-commerce portals, bracelets, and other wearable devices, etc.

Multiple databases

A further advantage of the modular architecture is that the system is not limited to one database. Rather, it is possible to connect with multiple databases, each database having database-specific modules, whereby the databases may be used for specific purposes or data records across multiple heterogeneous databases may be used in combination.

In addition to providing the advantages of authorization and authentication, the implementation of license server 210 is novel in use by certificate authority for licensing purposes. Replacing modules trust each other (claim), using simple authentication in shared databases, or continually delegating to individual license servers (with required performance and reliability overhead) when establishing connections is the most common implementation mode for such distributed module-based systems. In Tereon, the licensing subsystem ensures that the connections between modules are substantially secure and that trusted verified metadata (metadata) for the participants is maintained with minimal performance and reliability overhead.

Embodiments also limit the scope of potential vulnerabilities in instances where license servers leak: in conventional deployments, such damage is significant to the reconstruction of the earth policy for all components. In the Tereon model, there is a time-based exposure that requires a new intermediate signed certificate (when not protected by the hardware security module). All pre-injury granted existing certificates will be retained and renewed according to a normal schedule. The new certificate will be authorized at the new authorization center and any other malicious certificates will be rejected as being compromised. Such exposure window control favors the worst case. The data held by the license server is completely unprivileged information outside the hardware security module that ideally holds the signed certificate private key.

The design of the teleon may also choose to combine an endpoint device, such as a mobile phone or IoT device, with a miniaturized teleon server that communicates with other teleon servers as part of such a server network. They will still communicate with the Tereon license server 210 and possibly with the Tereon server(s) operated by one or more operators to sort the data and coordinate the activities. However, the distinction between endpoint devices and Tereon servers can be abstract, with any distinction being based solely on the use case in which the device and server are located.

Hash chain

A major drawback of blockchain (blockchain) is that the blockchain stores an audit of all previous transactions (i.e., is able to determine the transaction history in the blockchain and use it for authentication purposes). This means that the blockchain approach cannot be extended indefinitely, as the blockchain size eventually becomes too large to manage in a realistic timeframe, while the size of each block limits the maximum transactions per second that the blockchain can register.

A second disadvantage is that the transaction history is available to anyone accessing the blockchain and provides the ability to determine the parties to the transaction. This results in any intentional activity where privacy and/or confidentiality are the most important requirements, using blockchains presents a significant challenge in privacy and regulatory aspects.

Another disadvantage is that the blockchain can only hash the transaction result or last record and cannot verify the actual procedure or step of the transaction itself.

The hash chain disclosed herein attempts to overcome these problems by using a specific hashing method to maintain the privacy of records between transaction parties and thereby provide a distributed authentication network that contains all users of Tereon, whether they are running on an open or private network.

This is achieved by continuously building a distributed hash chain that operates in real-time across public and private networks without revealing the underlying communication content to any third party. This is in direct contrast to standard models of distributed hashes or ledgers (ledgers) where each party must view and accept each communication content, whether or not they are a party to the communication.

When the hash chain uses a protocol that contains zero knowledge proof, the steps of the transaction and the information or results generated by these steps may be authenticated.

Embodiments may result in the communication parties generating the same intermediate hash, or they may generate unique intermediate hashes for the same communication. The structure also allows parties to migrate to new hash algorithms when existing algorithms are discarded, and does not affect the integrity of the hash chain. This is in direct contrast to the algorithmic difficulty of updating or upgrading existing solutions such as blockchain.

The Tereon generates a hash audit chain for each party (account) of the transaction, where:

the Tereon generates a hash associated with the record and stores the hash for the record. Once the act of generating records is completed, the Tereon will generate a hash using the steps of generating records, and the information or results generated by those steps;

The Tereon uses the previously recorded hash as part of the currently recorded data; and

the first hash in any record chain is a random hash that includes the signature of the server, the date and time the hash was generated by Tereon, and, if necessary, a random number.

When the records belong to actions involving two or more parties, and each party should record the side of the action, then for each party in the action, tereon will:

sharing the hash of each party of the record with one or more other parties;

using the hash to form part of the record of the recipient, the Tereon will generate a record hash for the record of the recipient;

an intermediate hash is generated that includes hash records from other one or more parties.

Sharing the intermediate hashes with one or more other parties such that each party encapsulates a portion of the other parties in action (sharing is not necessary because these intermediate hashes are identical when the parties use the correct protocol);

the action record comprises an intermediate hash;

generating a final hash, stored in the action and used as part of the next record; and

the hash value of each transmission or an intermediate hash value generated using a protocol with zero knowledge proof is associated with the ID or Tereon number of the transmitter.

As described below, tereon may provide ACID guarantees and real-time conversational transactions, as well as the processing speed required. Furthermore, the popularity of blockchains means that developments in this area have not been considered.

The blockchain can only hash the transaction record after the transaction is completed. Also, there is no guarantee that the record passed to the blockchain is actually a true record of the transaction itself. Blockchains are limited because their underlying hash structure is designed for static collection of data, not dynamic real-time transactions, and it relies on honest actions by most operators. The blockchain itself also presents further limitations that only provide final consistency; instead of determining ACID consistency by the temporal order of transactions, the order in which transactions are incorporated into the tiles is determined, and when two or more tiles comprising slightly different sets of transactions are found at approximately the same time, the fork (fork) in the blockchain is managed by a consensus model.

Fig. 5 is a diagram illustrating the dendritic (dendritic) nature of a hash chain involving four accounts 502, 504, 506 and 508. The accounts may be located on the same server or may be located on different servers. Each system may support one or more servers, and each server may support one or more accounts. The location of the account is not critical. Fig. 5 also illustrates five transactions that occur between paired accounts. Two of the transactions occur between accounts 502 and 504, two of the transactions occur between accounts 502 and 506, and one of the transactions occurs between accounts 506 and 508. In the figure, each block is a step with respect to the account at the top of the column. The steps relate to an invisible action or transaction, such as a search within an account, or a transaction between an account and another invisible account or system. It does not matter what these transactions or actions are. Importantly, they involve the teleon system record in the audit.

In step 510, the tereon system performs h502, the previous hash of the account. As described above, the first hash is a random hash having a signature of the server, a date and time when the hash was generated by Tereon, and a random number if necessary. The Tereon adds the hash to the record of the transaction or action that occurred at step 510 and uses it as a seed h512 for computing the hash for the transaction. The record at this stage contains h502 and h512.

In step 512, the system exchanges a hash h510 with the server holding the account 504. It adds the hash h504 for the transaction of the account 504 to the record, generates an intermediate hash h512i, adds it to its record, and then exchanges for an intermediate hash h514i from the account 504 (as generated in step 514, below). Next, the hash is added to its record and a hash h512 is generated.

The hash h512 now contains information that verifies the hash chain of the account 502 in step 512 and the account 504 in the intermediate stage of step 514. The record contains h510, h512i, h514i, h504, and h512.

In step 514, the system exchanges hash h504 with the server holding account 502. It adds the hash h510 from the account 502 to the record, generates an intermediate hash h514i, then adds it to its record, and swaps for the intermediate hash h512i from the account 502. This hash is then added to its record and a hash h514 is generated.

The hash chain now contains information that verifies the hash chain of account 502 at step 512 and account 504 at step 514.

The process performs further transactions between accounts 502, 504, 506, and 508 to generate hashes for each transaction in exactly the same manner as described above. For example, at step 534, the system takes the previous hash h528 generated for account 502 at step 528, adds this to the record of the (invisible) transaction or action for the audit record, and generates a hash h534 of the transaction. The hash chain now contains information to verify the hash chain of accounts 502 up to step 534, accounts 504 up to step 526, accounts 506 up to step 530, and accounts 508 from the intermediate hash of accounts 508 that generated h530 at step 530. The record contains h534 and h528. The Tereon generates a hash h528 from the record containing h530i at step 528, h530i itself being generated from h524 at step 530. Hash h524 contains information from verifying account 508 up to the intermediate hash of account 508 used to generate h524 in step 524.

Checking up

If the fraudster has changed the previous transaction record, to ensure that the transaction cannot occur, the last "N" transactions are first checked. Thus, for example, before the Tereon performs the transaction represented by step 522, it may first recalculate the hash of step 516, step 512, etc., and so on until the previous "N" transactions of account 502. The audit trail (audit trail) has sufficient information to recalculate the final hash of the transaction. Likewise, the system holding account 504 may recalculate the hash of step 526, step 520, etc. For the transaction of step 522, teleon does not need to recalculate any hashes of account 506.

In the hash chain, when the recorded hash does not match the recalculated hash, this indicates that the record is not authorized to be changed and the operator can immediately investigate the problem or block further transactions.

System hash chain

A system hash may also be added to each record. This would be a hash of the record, where the seed would be a hash of the previous action on the system, whether or not the action was related to the account to which the record being recorded belongs. When adding system hashes, hash chains within each account are provided, as well as hash chains of the overall system.

Fig. 6 is a diagram illustrating the dendritic nature of a hash chain for two accounts 602 and 604 on the same system, the "system account" of the system that records all system events is 606. Regardless of where the record exists, the system generates a new hash of the record for each action that generated the record. These are system hashes h606, h608, h612, etc.

The management function also generates records that the system assigns to management accounts, whether or not these relate to manual input or automation functions.

In step 608, the tereon generates a record hash of the invisible actions or transactions in the account 602 (the record for the account 602 contains the hash h602, i.e., the hash for the previous record of the account), where the account 602 triggers an entry (entry) in the audit record of the system and h606 is used for the new system hash h 608. The system then records the hash for the record for the transaction and calculates a hash h610 of the account 602 at step 610.

If the computational performance of the system allows, the operation of a stronger variation (variation) mirror account hash may be used for the system hash.

In step 610, tereon exchanges hash h602 with system account 606 for hash h 606. It adds the hash h606 from the system account 606 to its record and generates an intermediate hash h610i. It generates it after completing an invisible action or transaction at account 602, where account 602 triggers an entry (entry) in the audit record of the system and Ha Xijia to its record. The Tereon then exchanges the intermediate hash with the intermediate system hash h608i. This sum h608 is then added to the record and a new account hash h610 is generated.

In step 612, the tereon exchanges the hash h608 generated in step 608 with the accounts 602 and 604. It adds h610 and h604 generated in step 610 to its record and generates an intermediate hash h612i. It exchanges their intermediate account system hashes h614si and h616si with accounts 602 and 604, and the intermediate hash h614i corresponds to account 602 and h616i corresponds to account 604. Next, a new system hash h612 is generated. The system then records this hash.

In step 614, the tereon exchanges the hash h610 generated in step 610 with the system account 606. It adds the hash h608 from the system account 606 generated at step 608 to its record, generating an intermediate account system hash h614si. It generates the transaction (and swaps intermediate transaction hashes h614i and h616 i) after it completes the transaction with account 604, adds it to its record, and swaps it into intermediate system hash h612i. Next, this is added to its record along with h608 and an account hash h614 is generated.

In step 616, the teleon exchange system account 606 and the hash h604. It adds the hash h608 from the system account to its record, generating an intermediate account system hash h616si. It generates the transaction (and swaps the intermediate transaction hashes h614i and h616 i) after it completes the transaction with account 602, adds the hash to its record, and then swaps it to the intermediate system hash h612i. Next, this is added to its record along with h608 and an account hash h616 is generated.

At step 612, one option is for the system to send an intermediate system hash h614si to account 604 and to transfer the intermediate system hash h616si to account 602. This means that the last record hashes h614 and h616 for those accounts will contain the records of the three middle system hashes h614si, h614si and h612i and thus provide an additional layer of certainty.

The system hash chain now contains both sides (sides) of each individual transaction as well as the entire transaction as a whole, thereby greatly reinforcing the hash chain.

When the Tereon manages transactions between accounts on different systems, the procedure is the same as steps 608 and 610 for each system.

Hash of license server

The above hashes relate to those generated on separate Tereon systems and between systems. Since these systems interact with each other, they will eventually join a hash tree (hash tree) that contains information that validates transactions on all these systems. However, this will only grow at the rate at which these systems interact with each other. Further, the system may even build another layer to ensure that each server will immediately join the global hash tree. This fully separates the hash chain from the blockchain.

When the blockchain operator sets up a private blockchain, the blockchain is isolated from all other blockchains. Since users cannot rely on blockchains of large networks to validate transactions, their effort in overall processing speed is totally lost due to the security issues they may provide. One of the claims of blockchain for security is that an attacker needs to invade nodes of the blockchain network to compromise its security (it is sufficient to invade nodes between 25-33% or so to compromise the blockchain). By definition, a single private blockchain reduces the number to 1.

Under the hash chain, even a private Tereon server or network may benefit from the hash chain generated by the public Tereon server and network. Operating a private Tereon server or network does not mean that the operator has to make a compromise on the authentication strength of the Tereon system, as the system will still be a component of the global hash chain. In short, except for transactions related to the license server, its transactions will remain entirely private to the system.

For this purpose, each server must interact with the license server, whether or not it interacts with other Tereon servers. When a teleon server operates in a closed-loop system, and only when the loop (loop) includes multiple servers, it will only interact with other teleon servers within the loop.

By adding the license server hash, each server will join the global server hash chain once interacting with the license server and must do so every day. The license server hash is generated essentially by a two-party transaction between the Tereon server and the license server. In addition to the system hash of each server now also contains information derived from the license server hash, the license server transaction does not affect any underlying data transactions between the Tereon servers and vice versa.

Fig. 7 is a diagram illustrating the dendritic nature of license hashing. In this simple example, system server 702 is a closed loop system with which system servers 704 and 706 will be interconnected. All three system servers must interact with license server 708 periodically.

In its first interrogation (interaction) with license server 708, each server generates its first hash from its public key, the date and time the server was earliest licensed, and the random data set.

In step 710, tereon uses its hash h708 to generate an intermediate license hash h710i, adds this to its record, and swaps it with an intermediate system hash h712i from the server 702. This hash is then added to its record, and then a license hash h710 is generated and the license hash h710 is added to its record.

In step 712, tereon uses its hash h702 to generate an intermediate system hash h712i, adds this to its record, and swaps it with the intermediate license hash h710i from license server 708. This hash is then added to its record and a system hash h712 is generated and the system hash h712 is added to its record.

In step 714, tereon generates an intermediate license hash h714i using the hash h710 generated in step 710, adds this to its record, and swaps it with an intermediate system hash h716i from the server 704. This hash is then added to its record and a license hash h714 is generated and the license hash h714 is added to its record.

In step 716, tereon uses its hash h704 to generate an intermediate system hash h716i, adds this to its record, and swaps it with the intermediate license hash h714i from license server 708. This hash is then added to its record and a system hash h716 is generated and it adds the system hash h716 to its record.

In step 718, tereon generates an intermediate license hash h718i, adds this to its record, and swaps it with an intermediate system hash h720i from server 706. This hash is then added to its record and a license hash h718 is generated and the license hash h718 is added to its record.

In step 720, tereon uses its hash h706 to generate an intermediate system hash h720i, adds this to its record, and swaps it with the intermediate license hash h718i from license server 708. This hash is then added to its record and a system hash h720 is generated and the system hash h720 is added to its record.

The three license server to Tereon server transactions generate the following results:

the hash h712 generated at step 712 contains information verifying the following state:

a hash chain of license server 708 up to intermediate hash h710 i; and

and a hash chain of server 702 up to hash h 712.

The hash h716 generated at step 716 contains information verifying the following state:

a hash chain of license server 708 up to intermediate hash h714 i;

a hash chain of server 702 up to intermediate hash hk702 ii; and

and a hash chain of server 704 up to hash h 716.

The hash h720 generated at step 720 contains information verifying the following states:

a hash chain of license server 708 up to intermediate hash h718 i;

server 702 up to intermediate hash h (hash chain of k702 ii;

a hash chain of server 704 up to intermediate hash h716 i; and

and the hash chain of server 706 up to hash h 720.

The hash h718 generated at step 718 contains information verifying the following state:

a hash chain of license server 708 up to hash h 718;

server 702 up to intermediate hash h (hash chain of k702 ii;

server 704 up to hash h (hash chain of k704 i; and

and the hash chain of server 706 up to hash h 720.

Thus, the information contained by the permissions and system hashes enables them to verify transactions on the servers in the network, whether or not those servers are interconnected or closed-loop.

The Tereon may implement a layer similar to a lookup directory service that will operate in a manner similar to a hash chain generated by a license service.

Off-line transaction (off-line transactions)

With this approach, offline transactions can now have the same effectiveness as online transactions, as the need to have a continuous communication link between the device and its server is eliminated. Accordingly, devices such as sensors, portable payment terminals, etc. can communicate between them and connect with their servers at predetermined intervals to download and upload data. The system will run uninterrupted between connected and unconnected environments.

Hash chains allow devices to verify and audit transactions between themselves when they cannot communicate with their individual servers, using business rules to determine if they can participate in offline transactions. When the device is again connected to these servers, those audit and transaction records will simply be checked against the servers.

Fig. 8 is a diagram illustrating one example of a hash chain involving four devices temporarily offline from respective Tereon servers. Three of the devices 802, 804, and 806 are visible (the fourth device 808 interacts with the hash chain at step 828).

To support offline transactions between devices, the device itself will generate hashes of its participation in each transaction. When the device is brought back online and communicates with its server, the device transmits a hash for the transaction to its server.

If the device that initiated the transaction is in an offline state, it will generate a hash for its transaction and store the hash. It will also transmit its hash to its partner device (the device with which it is transacting) and the partner device will transmit its hash to the first device. This is achieved in the same way as the hash chain described above. The devices may communicate between themselves over any bi-directional channel, e.g., bluetooth, NFC, local Wi-Fi, etc. They may even disclose bar codes for each transaction stage on the screen for others to read. Each device will also transmit a signed encrypted copy of the transaction record to another device, where the signature will also contain the destination server for the record. Only the destination server is able to decrypt the record.

Once the device regains communication with its Tereon server, the device will transmit its offline transaction and its associated hashed encrypted record to the server. Copies of other transactions it holds, such as records from its counterpart, are also transferred to the server, which in turn transfers those records and their associated hashes to the server with which those counterpart devices are registered. Each device will generate its own unique internal transaction number (e.g., a transaction number generated by a monotonic counter) that is used to identify its portion in the transaction. If the transaction is online, the server to which the device is connected will also generate a unique transaction number, which will be used by both the device and the server.

The device may combine its unique internal transaction number with a time and date stamp, information about the device clock bias, and other information to preserve the causal relationship of each transaction. When their respective servers receive the transaction information, they will be able to reconstruct the order of the transactions, preserving the causal relationship of online and offline transactions to all devices.

Returning to fig. 8, in step 812, the device 802 hashes the record containing the transaction of hash h802, the previously recorded hash, and hash h810 from server 810, thereby generating h812. This hash is then passed to server 810, where it is part of the record used to calculate h814 in step 814. The device 802 is online at this point, indicating that it is connected to its Tereon server 810. In step 814, tereon adds this and h812 to the record using h810, i.e., the previous hash for server 810, and then calculates h814. The record contains h810, h812, and h814.

As above, when the operator has configured Tereon to include the system hash, it will add this to the record before computing hash h814. The record will then contain h812, h810, the system hash in between if relevant, and h814.

At step 816, the device 802 is now in an offline state because it cannot connect to the server 810. It performs transactions with the device 804, and the device 804 is also offline with its separate Tereon server. The devices 802 and 804 follow the hash procedure outlined above, thereby generating an intermediate hash h816 from the device 802, an intermediate hash h818 from the device 804, a hash h816 from the device 802, and a hash h818 from the device 804 at step 818. Devices 802 and 804 now sign their hashes using their offline public keys and pass them along with an encrypted copy of the transaction's record to the other device. This is the first offline transaction after device 802 loses contact with server 810 and is the first offline transaction from which device 804 loses contact with its server. The administrator may configure the system so that the application will transfer up to the most recent n transactions to the only device with which the offline transaction was made.

This process is repeated for further transactions in the chain between device 802 and device 804 and between device 804 and device 806. In these transactions, devices 802 and 804 do not need to exchange their hashes and records of previous transactions because they already hold one copy, respectively.

The device 802 will continue to operate in this manner until it reestablishes contact with its server 810 at step 830. The device 802 now uploads all encrypted records of its offline transaction and its associated hash, in this example h816, h822, and h826 generated at steps 816, 822, and 826, respectively. It also uploads the encrypted transaction records and hashes it maintains for devices 804, 806, and 808. The server stores these and uploads them to the servers corresponding to devices 804, 806, and 808, respectively. The server 810 registers this upload as a transaction and generates a hash h832 at step 832. The device 802 clears the records of the hashes from the devices 804, 806, and 808, as well as the individual transaction records, and generates a hash h830 at step 830.

Device 802 maintains a hash and encrypted record of the transaction between devices 806 and 808, the result of which is hashes h820 and h808 at step 820. In this example, because how many offline transactions occurred is unknown, h808 is used to refer to the hash generated by the means 808 for the transaction.

Server 810 will check the offline records it receives from device 802, as well as those records it receives from devices 804, 806 and 808, as well as any other servers containing those transactions. Because this relates to the servers sending records for transactions involving device 802, server 810 will know from which servers it will receive records. Device 802 will not expect to receive a record from device 808 because device 802 did not conduct a transaction with device 808. If the device 804 or 806 is transacting with an offline device connected to other servers, the server 810 may receive additional records from those other servers.

To order and number the transactions, the server 810 will use the time and date stamps and signatures on the transaction records and mark them as offline transactions.

There are many variations of the offline mode. The first is done offline Ha Xixia without intermediaries and only needs to use the hashes of the previous transactions of the devices. Although this loses a layer of certainty, it still has good effect. The second is to hash only the offline transaction generating means. This slightly simplifies the online transaction, but also loses a layer of certainty. A third variation is to simply sign the records of the offline transaction using the device's key, rather than signing the records using a particular offline public key. Both the server and the device will know which transactions are online and which are offline, as they will be recorded in the audit trail of the account. However, by executing a separate key and a series of transaction numbers on the device, the display of offline transactions relative to online transactions becomes less important.

A fourth variation is for each server, when it receives records of offline transactions from the devices to which it is connected, notifying all servers that apply those records to expect records from those servers. For example, in fig. 8, assume that device 804 is later connected to its server, and that device 806 performs a transaction with another device (not shown). Once the device 804 is connected to its server, the server will transmit the record regarding the device 802 to the server 810. The device 80 does not conduct transactions offline with any other device, and does not maintain records of the offline for any other device. On the other hand, server 810 communicates its records for device 804 to the server corresponding to device 804, and notifies the server that it can expect to receive copies of the same records from device 806 (during the transactions of steps 826 and 828, device 802 communicates these to device 806). Likewise, once device 806 connects to its server, the server transmits its records for device 802 to server 810, transmits records for device 804 to the server corresponding to device 804, transmits records for device 808 to the server corresponding to device 808, and transmits records for other devices to its separate server. It will also notify the server corresponding to device 802 (server 810) as well as the server of device 804 to expect records from the servers corresponding to the other devices.

The use of hash chains does not impose ever increasing overhead on Tereon. One action rarely involves more than two parties, and when it does exceed two, then the action is typically a one-to-many transfer, which itself is a collection of simple one-to-one transfers. One-to-many transitions are also typically a series of one-to-one transitions, simply a set of two-way actions.

Modifying records

When a user modifies a record, tereon does not overwrite (overwrite) the original record. Instead, tereon will simply generate a new record containing the modified record, and this will be the version referenced by Tereon until the record is modified again; modification is an action. This is the case for all financial and transaction records where the outcome of a transaction, such as a payment, effectively modifies the previous transaction outcome; this also occurs if the operator uses a subset of Tereon to manage other record types, such as e-mail, medical records, etc. By doing so, tereon will keep a copy of each version record.

In some cases, the operator is required to completely wipe out the records, or to modify the original records, in a court or law-related operation. In this case, tereon will delete or modify the original recorded content, and possibly also the related recorded content. The Tereon may be implemented without invalidating the subsequent hash.

When Tereon has to delete or modify the history, it will:

re-generating a hash of the record to confirm that the record has not been modified or changed prior to the Tereon deleting or modifying the record, and recording the re-generated hash

Recording the deleted or modified content of the record and the reason for the deletion or modification in a new field in the original record

Delete or modify related fields in the record and add date and time of delete or modify

Generating a new hash for the record; and

the new hash is recorded.

Based on this, tereon will not need to modify the hash chain in any way. All hashes of valid records generated from the original hashes of deleted or modified records remain valid. Because the deletion or modification is an action, the system hash will contain a new hash of the record that was deleted or modified. In this way, fraudulent activity can be easily identified by finding hashes of any records that do not match the recalculated hashes.

Hash chain with zero knowledge proof

The hash chain provides an additional layer that enables both sides of the transaction to prove to each other that they have hashed the hash-related record. This is achieved by including a key exchange algorithm within the hash chain that allows one party to prove to a second party (verifier) that the hash of the record is a true hash of the record.

Any algorithm that allows both parties to negotiate a public key may be used and zero knowledge proof need not be used. However, the PAKE (password authenticated key exchange) algorithm using zero knowledge proof is most efficient to use here. Since each party will generate the same intermediate hash, the use of the correct PAKE protocol and zero knowledge proof at the intermediate stage eliminates the necessity of exchanging hashes.

Using an algorithm such as the PAKE algorithm allows both parties to generate the same hash using zero knowledge proof, each party can be further. By using zero knowledge proof that may contain and use information that constitutes a transaction to generate a "proof," each party may generate the same intermediate hash. This eliminates the necessity of intersecting each other with an intermediate hash. This also represents the steps of generating records and the information or results caused by these steps are referred to as components of the hash chain program. If more than two participants are involved, the Tereon may use a protocol and a change in the group of zero knowledge proofs to enable each party to generate a common hash.

The PAKE algorithm, which allows each party to generate the same hash, typically performs two or three passes of information before they can generate an intermediate hash. If the transaction only requires two phases to complete (e.g., request and accept/validate), then each party will only generate one intermediate hash. If a transaction requires three phases and the algorithm generates one hash in two phases, each party will exchange four sets of information, repeat the third phase twice and generate two hashes, the first hash after the first two steps in the transaction, and the second hash after the third step is repeated.

An example of such a zero knowledge proof is the Schnorr NIZK proof. As shown in the specification for the Schnorr NIZK proof, such a zero knowledge proof may be extended simply by adding additional information to the information sent as part of the proof and the information used to generate the hash as part of the proof.

Another method, such as a method of adjusting generation of a public key in SPEKE (simple cryptographic index key exchange) protocol, may be used and is negligible based on the above.

It is also trivial to extend the key exchange protocol to enable each party to generate a public key from the transaction data. Also, for brevity, no description is provided herein.

To generate a public hash, each party simply generates a hash of the public key. Because the public key is generated using this information in the process, a hash is generated that will contain information that can verify the transaction information.

Two-phase transaction

Referring again to fig. 5 for an illustration of the principles of operation, fig. 5 is a diagram illustrating the dendritic nature of the hash chain with respect to four accounts 502, 504, 506 and 508. The accounts may be on the same system, or possibly on separate systems. The location of the account is not critical. The transaction at steps 512 and 514 takes two phases.

Two pass PAKE

In the first pass of step 512, account 502 takes the previous hash h510 generated for this account in step 510, adds it to the first phase of the transaction's information, constructs a first zero knowledge proof, and passes it to account 504. Zero knowledge proves the information accompanying the first phase of the information that makes up the transaction and hash h 510.

In the second pass, the account 504 takes the previous hash h504 for the account, adds this to the second phase of information for the transaction, constructs a second zero knowledge proof, and passes it to the account 502. The second zero knowledge proof accompanies the second phase of the information that constitutes the transaction and the information of hash h 504.

Accounts 502 and 504 now independently construct hashes h512i514i, which is an intermediate hash for both accounts. Both accounts 502 and 504 add this hash to their records. Account 502 generates a hash h512 of its transaction record at step 512 and account 504 generates a hash h514 of its transaction record at step 514.

Three pass PAKE

In this example, the transaction at steps 512 and 514 takes two phases, where the PAKE algorithm allows each party to be able to construct a common hash after three passes.

The first pass and the second pass are performed as above. In the third pass, account 502 obtains the information that account 504 passed in the second pass, uses the information to construct a third zero knowledge proof, and passes it to account 504. The third zero knowledge proof is also accompanied by the information that constitutes the second phase of the transaction information and hash h 504.

Now, accounts 502 and 504 independently construct hashes h512i514i. Both accounts 502 and 504 add the hash to their records. As in the two pass PAKE approach, account 502 generates a hash h512 of its transaction record at step 512, and account 504 generates a hash h514 of its transaction record at step 514.

In both cases, the chain contains information that verifies the hash chain in account 502 up to step 512, and for account 504 up to step 514. Both accounts 502 and 504 hold intermediate hashes h512i514i, and their record hashes. However, the intermediate hash here is different from the intermediate hash exchanged between systems in the previous example using zero knowledge proof. The intermediate hash here is a hash of the transaction between accounts 502 and 504, common to accounts 502 and 504. The hash is a hash of the transaction and is generated as part of the transaction. It occurs simultaneously with the transaction. Hash h512 is a hash of the transaction record of account 502 that will contain its private information, while hash h514 of account 504 is a hash of its transaction record. Thus, accounts 502 and 504 may prove the actual steps in the transaction between them and the transaction record.

Three-phase transaction

As another example, illustrated using FIG. 5, assume that the transaction at steps 528 and 530 involves three separate phases, rather than two phases.

Two pass PAKE

In the first pass, account 502 takes the previous hash h522 generated for this account at step 522, adds this to the first phase of information for the transaction, constructs a first zero knowledge proof, and passes it to account 506. Zero knowledge proof accompanies the first phase of information that constitutes the transaction and the information of hash h 522.

In the second pass, account 506 takes the previous hash h524 generated for the account at step 524, adds this to the second phase of information for the transaction, constructs a second zero knowledge proof, and passes it to account 502. The second zero knowledge proof accompanies the second phase of information that constitutes the transaction and the information of hash h 524.

Since the PAKE algorithm allows each party to construct a public hash after two passes, the accounts 502 and 506 can now independently construct the hash h528i530i. However, the transaction still has a third phase to execute.

In this example, the system starts at the third stage of the transaction and simply uses the PAKE algorithm to perform the second set of transfers. The second pass of the second set of passes may simply use random data. Alternatively, the last phase may be repeated, similar to PAKE using two-phase transactions and three passes.

For the latter, a third pass (the first pass of the new PAKE algorithm) is performed, where account 502 takes signed h528i530i, adds this to the third phase of the transaction's information, uses the information to construct a third zero knowledge proof, and transfers this account 506. A fourth pass (the second pass of the new PAKE algorithm) is performed, where account 506 takes signed h528i530i, adds this to the third phase of the transaction's information transferred by account 502, uses the information to construct a fourth zero knowledge proof, and transfers this to account 502. Because all three phases of the transaction are involved, accounts 502 and 506 can now independently construct hashes h528i2530i2. This is the second public hash generated in the transaction, and is now the hash of the transaction between accounts 502 and 506. Accounts 502 and 506 both add this hash to their records, account 502 generates its transaction record's h528, and 506 generates its transaction record's hash 530 h.

This process is performed for further transactions between accounts 502, 504, 506 and 508 to generate hashes for each transaction in exactly the same manner as shown above.

Three pass PAKE

As above, the first transfer and the second transfer are performed. In a third pass, account 502 uses the information of the third phase of the information that constitutes the transaction to construct a third zero knowledge proof and communicates it to account 506. Zero knowledge proves information accompanying the third phase of information that constitutes the transaction.

Now, accounts 502 and 506 independently construct hashes h528i530i. Accounts 502 and 506 both add this hash to their records. Account 502 generates a hash h528 of its transaction record at step 528 and account 506 generates a hash h530 of its transaction at step 530.

In the example above with respect to FIG. 5, where the system generates an intermediate hash or transaction hash using zero knowledge proof, hash h530 contains information verifying all hashes of accounts 502 through h528i, all hashes of accounts 504 through h526i, all hashes of account 508 to the intermediate or transaction hash of account 508 generated when account 506 generated h524, and all hashes of accounts 506 through h530. However, while it verifies all hashes in its transaction network, account 506 only holds transaction records of transactions that have been done with other accounts, systems, or servers. Even though its hash contains information that account 502 or account 504 may use to verify the hash of those transactions, nothing is known about the transaction record content of the transaction between accounts 502 and 504.

Importantly, the steps used by both parties to exchange to validate a transaction use an independent algorithm that generates the same intermediate hash. Thus, the transaction that generated the record becomes a component of the hash chain program, and the program that generated the hash chain object (entry) is the same as the program that validates the transaction. Another approach is to generate a hash of a transaction as part of the transaction, and the hash and its accompanying information become an audit of the transaction. They are integral and identical. Using the blockchain, the initiator of the transaction completes the transaction and sends its record to the blockchain for later auditing, thereby adding another step to the program instead of being integrated into the transaction.

Since the transaction itself becomes a contemporaneous component of the audit trail provided by the hash chain, it becomes impossible to want to obtain transactions whose details are not captured and verified by the audit trail. Most audit trails are "after event" because completed transaction records are typically passed to the audit system after the transaction is completed. In this case, the audit received record is different from the transaction generated record. Thus, computer recordings are often considered to be biography (news). Integrating zero knowledge proof with the correct PAKE or similar protocol means that the audit trail is generated by the transaction and that the transaction and its records become part of the audit trail. This has a profound impact on real-time transactions, since it is now audited and reported in real-time.

The procedure of constructing a hash using zero knowledge proof can be applied to any scenario where a hash is generated in a hash chain. It can be used for system hashing, license server hashing, or even by offline hashing as shown in fig. 8. It is important that the hash pertains to transactions between two or more entities, whether or not those entities are participants, devices, or systems. Nor does the program preclude the use of standard hashes. Thus, a system may use zero knowledge proof generated hashes for transactions between accounts, whether the device is online or offline, but use standard hashes for system hashes and license hashes. The second system may use zero knowledge proof for all hashes, while the third system may use only standard hashes.

Multi-pass PAKE with multiple transaction phases

In the above example, it is described how to use a transaction in relation to two or three phases under a PAKE requiring two or three passes to enable both sides of the transaction to generate a public key, but the system is not limited to the above example. In practice, the same approach will apply to a system that supports multiple phases of transactions to use PAKEs that require different multiple passes. The simple use of a single by a system requires the use of many PAKEs to cover all phases of a transaction. It repeats the last phase any number of times to generate the required PAKE transfer to generate the last public key, thereby generating the transaction hash.

System hash chain using zero knowledge proof

Turning to fig. 6, a hash chain of hashes that may be generated using zero knowledge proof and classical hashes is shown. Two accounts 602 and 604, and system hashes h606, h608, h612, etc., are shown on the same system account 606. Regardless of where the record exists, the system generates a new hash of the record for each record-generating action. As above, transactions between accounts will generate intermediate or transaction hashes for each account using zero knowledge proof. The system hash will include a system hash for each record as it is generated.

Assume that the transaction between accounts 602 and 604 at steps 614 and 616 involves three separate phases, where the PAKE algorithm allows each party to be able to construct a common hash after three passes.

In a first step of the transaction, account 602 hashes with system account 606, the previously recorded hash h610, is exchanged with system hash h608 generated in step 608. It adds this system hash and its hash h610 to the first phase of the transaction information generated at step 610, constructs a first zero knowledge proof, and passes it to account 604. Zero knowledge proof accompanies the first phase of information that constitutes the transaction, hash h610, and hash h608.

In the second step of the transaction, account 604 is hashed with the system account, h604 is exchanged with the system hash h608 generated in step 608. It adds this system hash and its previously recorded hash h604 to the first phase of the transaction's information, constructs a second zero knowledge proof, and passes it to 602. Zero knowledge proof accompanies the information of the second phase of the information that constitutes the transaction, hash h604, and hash h608.

In the third step of the transaction, the system account 606 adds h610 and h604 to its record and generates an intermediate system hash h612i.

In a fourth step, account 602 uses the information that constitutes the third phase of the transaction to construct a third zero knowledge proof and communicates it to account 604. The third zero knowledge proves information accompanying the third phase of information that constitutes the transaction.

In a fifth step, accounts 602 and 604 independently construct hashes h614i616i. Both accounts 602 and 604 add this hash to their records. Hash h614i616i is the hash of the transaction.

In a sixth step, account 602 exchanges h614i616i and h612i with system account 606, adds h612i to its record, and generates a hash h614 of its transaction record in step 614. The account 604 exchanges h614i616i and h612i with the system account 606, adds h612i to its record, and generates a hash h616 of its transaction record at step 616, and the system account 606 adds two copies of h614i616i to its record, and generates a new system hash h612 at step 612.

The transaction record of account 602 at step 614 contains hash h610, hash h604, system hash h608, transaction hash h614i616i, intermediate system hash h612i, the information of the transaction, its transaction record, account ID, and hash h614.

The transaction record of account 604 at step 616 contains hash h610, hash h604, system hash h608, transaction hash h614i616i, intermediate system hash h612i, the information of the transaction, its transaction record, account ID, and hash h616.

(because transactions are started and ended in different states, respectively, the record of transactions for account 602 will be different from the transaction record for account 604, and each account has different account details and ID.)

The system hash h612 contains hashes of both sides of the individual transaction, as well as the transaction as a whole, thus greatly reinforcing the hash chain.

If the Tereon manages transactions between accounts on different systems, the process is slightly different because each system will exchange its system hash and intermediate system hash with the accounts it manages. Otherwise, the method described above with reference to FIG. 6 is the same, except that there are not accounts 602 and 604 and a system account 606, the figure will show a system account 606 with an associated account 602, and a second system 605 with an associated account 604. The system hash resulting from the transactions occurring at steps 614 and 616 will represent the system transaction at step 612, as well as the equivalent transaction on the second system 605 corresponding to the account 604. In fact, in a system that contains multiple accounts that can be transacted simultaneously, the system will generate a hash for each interaction that generates records.

Although fig. 6 is a hash showing a sequence and an intermediate hash, this is not the case. Fig. 6a shows three accounts 602a, 604a and 606a, all of which interact with an account on an external server along with a system account 608 a. The phases of the transaction are staggered, thereby illustrating what may happen when the transactions are occurring simultaneously on the system. For simplicity, these are all shown on the same server.

In the example above, at step 612a, account 602a exchanges its hash h602a with system account 608a to obtain h612a. The system account 608a will now generate the intermediate hash h616ai shown in the example above. The subscript "i" is used to clearly indicate that each transaction will relate to three system hashes, the original hash before the transaction, the system hash at a particular stage of the transaction (the middle hash), and the system hash at the end of the transaction. The subscript "i" denotes an intermediate hash. Based on the reasoning above, the final system hash will be h616a. This tag does not clearly illustrate what happens under multiple concurrent or interleaved transactions. Instead, each system hash, whether generated during or after a transaction, is a system hash, albeit in increments on the previous hash. If three transactions occur such that account 602a begins, then account 604a begins, account 606a begins, account 602a ends, and account 606a ends before account 604a ends, the order of the hashes may look similar to what follows if no other transactions or actions occur on the server or any other account, the graph being slightly different from the previous graph.

Account 602a exchanges its hash h610a with the system to obtain h612a. The system now uses hash h610a to generate the next system hash h616a (this is initially labeled h628ai, once the transaction for account 602a is completed, hash h628a is the last system hash for the transaction).

The account 604a exchanges its hash h614a with the system to obtain h616a. The system now uses hash h614a to generate the next system hash h620a.

Account 606a exchanges its hash h618a with the system to obtain h620a. The system now uses hash h618a to generate the next system hash h624a.

Once account 602a generates its intermediate or transaction hash, hash h622a is exchanged with system hash h624a. The system now uses hash h622a to generate the next system hash h628a.

Once account 606a generates its intermediate or transaction hash, it will exchange hash h626a with system hash h628a. The system now uses hash h626a to generate the next system hash h632a.

Once account 604a generates its intermediate or transaction hash, it exchanges hash h630a with system hash h632a. The system now uses hash h630a to generate the next system hash h636a (not shown).

The hash chain allows the system to process transactions, audit transactions, and simultaneously authenticate data transferred or generated by the transactions. These steps now occur simultaneously. It is not necessary to assume that the device reports the transaction honest to the auditing system. The transaction generates an audit, and the audit generates the transaction.

This changes the nature of the transaction performed by the programmed device. Any programmed device, including IoT devices, can now verify and rely on transactions and data transferred between itself and any other device because the transactions and their auditing and authentication are concurrent.

It is not necessary to assume that the device communicates the correct record of the transaction to the audit system, as the transaction and audit are generated as part of the consent program, and this concurrent nature changes the quality of the evidence of the audit trail. Each device may rely on information sent by other devices without the need to make assumptions about the integrity of the other devices. The transmitted and received data are processed data, also authenticated and audited data.

When combined with a lookup service, devices that have not previously interacted with can now also authenticate each other, determine each service or function to perform, and then communicate with each other and rely on the communication to perform tasks according to programming content without any human intervention.

The hash chain allows programmed devices, including IoT devices, to run online as well as offline. When offline, the device contains a timestamp, information about the clock skew (skew) of the device, the unique transaction ID of the device (e.g., generated by an internal monotonic counter), and other synchronization information in the transaction information, which then enable the servers to reconstruct an accurate timeline when they eventually receive a record of offline transactions from the device or third party server to preserve the causal relationship of each transaction. The hash chain allows the server to rely on the contents of the transaction record both in online and offline modes.

When combined with a communication security model that protects inter-device communication, devices as well as servers may communicate in a manner that is not affected by man-in-the-middle attacks. Tereon allows IoT and other programmed devices to communicate securely and rely on data transferred between those devices.

One example is a network of IoT and other programmed devices that operate as a set of industrial sensors and controllers. The security model allows these devices to communicate securely between them and through the use of a look-up directory service and to interact with new devices as they are added to the original collection. The teleon does not need to reconfigure so that the device recognizes the new device and trusts the new device. The hash chain enables devices to trust the content and timing (timing) of the communication between them and allows operators to rely on the generated and transmitted data without any human assessment of the authenticity of the transmitted data. The third party cannot interfere with the data, and the audit and authentication chain of the data occurs simultaneously with its transmission.

When combined with the security model, the lookup service enables devices to generate ad hoc connections that they can trust and authenticate without any human intervention. Once a device is authorized and its details are added to the lookup service, other devices may be connected to the device as needed. If a device is injured in any way, all access to the device may be disabled by the same lookup service.

The system provides additional advantages brought by its hash chain and its lookup service. Since all devices are individually authorized and audited, the system can instruct specific devices to download updates to those device software when needed, which can only be accomplished through a secure trusted source. The lookup service will specify, for example, services, interfaces, and data formats that are provided and used by a particular device. Thus, if a device wishes to connect to another device to access a particular service, but does not have the necessary software to support the necessary interface or format, then it or the device to which it is connected, or both devices if necessary, may communicate with the system server to download the necessary software or configuration to enable the two devices to communicate with each other. A determination is made as to whether the device is to save software after the end of the communication between the devices, through the services performed by one or more of the devices, and the capabilities of those devices. Hash chains indicate that even if they delete software (they can re-install the software when they communicate again), both devices will still keep a complete audit and record of the communication between the devices, which can be uploaded later to another device or server, if necessary. The facility extends to any type of device, e.g., from a fully autonomous IoT device to any other programmed device, e.g., a payment device.

Distributed recording of hash chains

To provide a distributed replication of the entire hash chain, the Tereon system can upload its hash chain to a central group of servers, such as a license server, a lookup server, or other group of servers, for all transactions that occur between the last connection to the server and the current connection. The same teleon system may then download the corresponding hash chains of the other teleon systems. This provides a hash chain distributed ledger (ledger) for all transactions of all teleon systems, but does not require the overhead of recalculating each hash chain for each transaction. However, it does introduce additional storage overhead to the Tereon system. The central server may be global, such as a server for license and lookup servers, or they may be industry, regional, or other limitations. By constraining the scope of the copies of the hash chain, the computational and storage overhead of this variation can be reduced.

Not limiting the scope of the central server, but a system that downloads hash chains uploaded through other systems. Thus, a hash chain from one bank can only be downloaded by another bank, which is limited by whether the bank is in the same area as the uploading bank, or whether transactions have been made with other banks. Similarly, a hospital's system can only download hash chains uploaded by hospitals in the same area. Flexibility is not limited.

The hash chain used in Tereon has very valuable properties. It provides a local ledger (ledger), but has distributed authentication. It keeps the transaction information private to the relevant users and services in the transaction, but it distributes the hash-provided identity authentication across all servers, services and devices. The hash generated using zero knowledge proof is illustrative of this. The hash generated using zero knowledge proof illustrates this. Only the systems involved in a particular transaction can retain the information of the transaction. However, all systems and devices that subsequently interact with these systems generate hashes that contain early hash information about these systems.

Distributed authentication is critical because it provides an incapacitating barrier to potential fraudsters wishing to conceal a tampered recording.

Using blockchains, a fraudster need only control 25% to 33% of the servers to conceal the tampered record and alter the blockchain to record the tampered record as a valid record. After completion, the process is almost impossible to reverse.

Using the Tereon hash chain, a fraudster needs to control each Tereon server, each Tereon service and each Tereon device, and recalculate each hash in the chain on each server and device. This is computationally unrealizable.

The hash chain enables at least the same degree of economic savings and efficiency as blockchains as predicted by supporters of blockchains. The difference is that the Tereon hash chain is actually enabled; and blockchains cannot be implemented due to their design and limitations inherent in the design.

The advantage of this system is that a fraudster will not be able to delete or modify records from the database without re-computing all the hashes related to the records, as well as the linked hashes. While in theory this is possible if the Tereon operates without any system hash and without any connection to the license server, if any linked chain involves a transaction with one party on another server or device, the fraudster would need to recalculate all hashes on the other server or device. The difficulty of doing so increases exponentially with the additional servers or devices that interact with the hash chain after the date and time of the original recording.

The hash chain enables an organization to guarantee the authenticity of data collected, generated, or managed by any device, to guarantee the original content and integrity of records, and to guarantee the integrity and content of any transaction based on previous records. This may apply to any device or transaction, from payment devices to medical devices, traffic sensors, weather sensors, water flow detectors, etc.

This has clear regulatory advantages because ledgers (ledgers) in various places are the responsibilities of each individual organization, they learn from and rely on other organizations in a way that provides common strength and clearly defines responsibilities and accountability. The hash chain generates a technical tool to implement and support the management of information and transactions.

Furthermore, when the hash chain is a component of a payment system, the architecture is consistent with the current manner of payment and provides advantages over or equal to cryptocurrency such as bitcoin, since the terson handles legal currency. It provides a "bitcoin beater" for sophisticated payment service providers and central banks.

The hash chain is an exciting part of the Tereon system and can provide very secure and fast authentication.

One of the unique functions of Tereon is to generate comprehensive real-time logs and audit trails. The transaction record of Tereon contains the key strokes (keystoke) required for the transaction (except for the actual authentication credentials such as PIN and password), and all legal and business requirements data and metadata about the transaction. When those records are stored between multiple service providers, it is important that those records are made tamper-resistant, and that the transaction sequence before and after the transaction is made tamper-resistant.

The blockchain cannot do so. It can accept a record only after it has been generated, but before it is authorized. The blockchain generates (acetate) a number of records, generates a block, and then adds it to the blockchain. It relies on the fact that the blockchain contains itself all information about previous transactions. As the blockchain adds additional blocks, it relies on the existence of these blocks to verify records within the blockchain as well as all previous records. As the file size increases, this can lead to expansion problems, and if there is inconsistency, the entire branch will lose identity.

The cureon's hash chain uses a hash strategy to isolate any suspicious records for investigation without breaking the authentication of subsequent transactions, as opposed to using a blockchain or derivative thereof. It also avoids the expansion problem by customizing the design for any record type, whether static records or real-time transactions.

The hash, including the intermediate hash, may provide the administrator with the necessary information to quickly traverse the hash chain to determine and verify the hash and its individual records. The same is true of the record itself.

If any transaction or action occurs, this indicates that the previous hash has been verified, so that the user and system can trust the output of the new transaction. Thus, tereon can trust the cumulative total in each account before doing the transaction. The validity of the hash chain confirms that the cumulative total is correct.

It is this ability that isolates the effect of modifying, deleting or tampering with records, distinguishing hash chains from blockchains and derivatives thereof. By definition, any modified or tampered record that is successfully hidden in the blockchain will affect the recalculation of the entire blockchain. Because each blockchain must be modified, there is no way to detect and modify tampering or spurious records other than demographics through the entire blockchain community. Thus, security researchers have identified this feature as a major drawback of blockchain designs. And cannot be changed.

For a hash chain, tampering with the record does not affect the rest of the hash chain unless an attacker can recalculate all subsequent hashes. Since the hash before any tampering is valid, any transaction based on these hash values, as well as the values associated with these hashes, will remain valid.

The dendritic hash chain representation server for offline transactions may register offline transactions performed by the offline device even if the device is lost or damaged before reconnecting to the server.

The hash chain provides complete support for validating offline transactions, and blockchains and derivatives thereof are not available. The node that operates the blockchain replica must be online to verify the block. While the bitcoin wallet may create a transaction offline, it cannot verify the transaction until it is online and pushes a record of the transaction to the node. Even so, the transaction is not validated until one of the nodes wins the contention to generate the next chunk in the blockchain and adds the record to the chunk.

Directory service

Existing systems, such as payment networks for transportation systems, e.g., EMV (Europay, masterCard, visa), and other conventional systems use hub and spoke architecture such that all transactions go through a central facility (central utility), which means a single point of failure or vulnerability, as well as expensive extended costs.

The Tereon system is point-to-point, in that one server communicates directly with another server, which is also the reason that a secure hash chain is so important, since hash chain authentication occurs between all elements of the peer-to-peer network.

As before, the Tereon system has a directory service 216, which is a directory of credentials and information in the system, in that it stores many different types of credentials associated with a particular user, can be used to identify to which server a device or user 218 is registered, or which server provides a particular service or function, and can implement a variety of authentication methods for the user 218. For example, user 218 may authenticate using their mobile number, email address, geographic location, PAN (main account number), etc., and cache all content, thus not necessarily authenticating each time.

Directory service 216 provides an abstraction layer that separates the user's authentication ID from the underlying service, server, and actual user account. This provides an abstraction between the credentials that the user 218 or merchant can use to access the service and the information that the Tereon needs to execute the service itself. For example, in a payment service, directory service 216 can link an authentication ID, such as a mobile phone number, or possibly a currency code, with a server address. There is absolutely no way to determine whether the user 218 has a bank account or which bank the user 218 uses.

Directory service 216 acts as an intermediary between the services such that service providers cannot see each other, thereby providing user data security. Each service will define a set of fields (variables) and values that are specific to the service. However, each service will have a specific field and value identifying the service.

When a transaction is completed with an unknown party, the Tereon server associated with the user 218 sends the URN to the directory service 216, and the directory service 216 returns the IP address of the Tereon server of the payment service provider for the service requested by the user 218. This allows transactions to be completed directly between the user 218 and the service provider on a point-to-point basis. In addition, the Tereon server keeps the IP address in a cache so that no subsequent transaction needs to use directory service 216.

This abstraction provides security and privacy for users and their service details, flexibility in adding and modifying basic services without affecting the published user credentials, and the ability to segment and support multiple services, each of which can be kept isolated from others if desired. Any field in the data service does not contain the data necessary to initiate the transaction and no user data is stored in directory service 216 other than the user's authentication ID.

However, the teleon directory service 216 is not so limited. It supports multiple credentials. Thus, the user 218 may use any number of credentials as the payment ID. Such as mobile phone numbers, PANs, email addresses, etc. The Tereon can support as long as the credentials are unique.

Directory service 216 may support multiple services. This is where the concept of a multi-sided voucher or "psyche paper" is formed. When a service provider checks a credential on the directory service 216, it can only see if the credential is registered for its service, and the Tereon server registration for the service credential. The service provider cannot see any details of any other services that the user 218 may have access to or register with.

For example, a mobile phone or card may become a library card credential for a library, a bus or train may become a transportation ticket, a security key for entering a room or facility, an internal payment device for a corporate canteen, a theater ticket, and a standard payment device for a supermarket. It may also be a driver's license, a medical card or an identification card to prove the entitlement to the service, a photo ID may be displayed on the merchant's device if the service requires it, etc. There are few, if any, restrictions on the types of credentials that a device can be.

While it is difficult to mask the original appearance of the card (which may be achieved when the card contains an OLED cover or a color electronic paper cover, for example, the service may instruct the card to display the information needed to get up and a particular voucher or service), tereon changes the appearance of the phone application to reflect the nature of the voucher and service.

A reverse lookup function may be implemented for each server. The function will allow the server to check if the server with which it communicates is authorized and authenticated. The functionality is not necessary because every communication between the teleon devices, whether cards, terminals, mobile phones, or servers, must be signed. However, there may be situations where an operator needs or wishes to reverse the lookup with additional security. Here, the directory service 216 will contain fields such as a service, a terron server domain address, a terron server number, a terron server operator, a lifetime, a terminal authentication ID, etc. Here, the service tag will look up back with reference to the server instead of the transaction service.

Fig. 9 shows an example with two servers, server 202a and server 202 b. The user 218 registers with the server 202b and accesses the service through the terminal connected to the server 202 a.

In step 902, the user 218 uses his own device to identify himself to the terminal, which automatically identifies himself to the terminal. If the user uses the smart device, the terminal will also pass its identity (identification) to the user's device. ( If the user 218 uses a card, the terminal can only pass its identity to the user's device when the device is a microprocessor card. In this case, the card will communicate with the server 202b to which the user is registered through an encrypted tunnel (tunnel) to transfer the ID of the terminal to the server 202b. )

In step 904, server 202a retrieves the identity provided by the user device and checks the ID against its maintained list. User 218 has never been previously involved because it did not save the ID. Server 202a now contacts directory service 216. Directory service 216 checks the signature on the communication of server 202a and checks to see if it is valid. Directory service 216 queries the ID for the service tag of the requested service (the signature of server 202a confirms that the server is authorized to make the service request), and responds with the cache time identifying the information of server 202b and the survival information.

Server 202a now contacts server 202b to confirm that the user's device is registering with server 202b at step 906. The server 202a also communicates the ID of the terminal to the server 202b.

If server 202b does not do so, it may issue a similar request to directory service 216 to query the server with which the terminal is registered, step 908. It may also confirm that the terminal has registered the requested service with the server 202 a. Directory service 216 responds with information identifying server 202a, as well as the time of caching of the survival information.

At step 910, server 202a and server 202b now communicate directly with each other in order to perform the required transaction. This may be any transaction, including payment to open a door.

The Tereon server itself contains the information necessary to open the transaction and will only communicate with other authorized and authenticated servers or devices.

Once the servers have communicated with the directory service 216, they will cache the data until the data expires in its own mini directory service.

In this case, it is obvious that communication of the connection is established between the Tereon servers 202a and 202 b. In this regard, fig. 10 shows the same.

In step 1002, the user 218 uses his own device to identify himself to the terminal connected to the server 202a, and the device automatically identifies himself to the terminal. If the user uses the smart device, the terminal will also pass its identity (identification) to the user's device.

At step 1004, server 202a takes the identity provided by the user's device and checks the ID against its maintained list. The data it holds is valid and thus server 202a contacts server 202b to confirm that the device is still registered with the requested service. The server 202a also passes the ID of the terminal to the server 202b. The server 202b confirms that the device is registered with it. The cache of server 202a contains valid data about the ID of the terminal, thereby contacting server 202b to confirm that the terminal is still registered with it. Server 202b acknowledges this.

At step 1006, server 202a and server 202b now communicate directly with each other in order to perform the required transaction.

If the cached data on the server expires, the server simply contacts directory service 216 as before. If the user 218 has migrated to another server, the communication is slightly different. This is illustrated in fig. 11. The difference is that the first communication with server 202b based on the now outdated cache information will force server 202a to look up new data in directory service 216.

In step 1102, the user 218 uses his own device to identify himself to the terminal connected to the server 202a, and the device automatically identifies himself to the terminal. If the user uses the smart device, the terminal will also pass its identity (identification) to the user's device. Server 202a takes the identity provided by the user's device and checks the ID against its maintained list. It saves the ID and checks to see if the cached data reveals that the ID is registered with the server 202b.

Server 202a now contacts server 202b to confirm that the user's device registered the service with server 202b, step 1104. The server 202a also passes the ID of the terminal to the server 202b. Server 202b no longer registers with the response ID.

Server 202a now contacts directory service 216 at step 1106. Directory service 216 checks the signature on the communication of server 202a and checks to see if it is valid. Directory service 216 queries the ID for the service tag of the requested service and responds with information identifying server 202c and the cache time of the survival information.

Server 202a now contacts server 202c to confirm that the user's device is registered with server 202c for the same service, step 1108. Server 202a also passes the terminal's ID to server 202c and uses the new details for the ID of the device from the user to update its cache.

If server 202c has not already done so, it may make a similar request to directory service 216 to query the server to which the terminal is registered, step 1110. It may also confirm that the terminal has registered the requested service with the server 202 a. Directory service 216 responds with information identifying server 202c and a cache time for the survival information.

At step 1112, server 202a and server 202c now communicate directly with each other in order to perform the required transaction.

Directory service 216 will always keep a complete trail of old and new user IDs that user 218 has registered with, as well as the dates on which these IDs were assigned to user 218.

The server 202c holds only information on the registered IDs from the date on which the IDs are registered. The server 202b will keep data about the duration of its service ID.

The abstraction layer provided by directory service 216 further evolves as it fragments the service. Thus, in the above example, the server 202a can only request information identifying the server that has registered the user's device for the desired service.

The server 202a must sign each communication with the device and the signature will identify the service of the relevant communication. If a server can provide multiple services, each service will have a private key and it will use the keys to sign the associated communication.

The Tereon servers themselves, in the above case servers 202a and 202b, contain lookup information that identifies the user's account data from the provided labels or information. Thus, only server 202b contains data that maps the ID of the user's device to the user's account; the information in directory service 216 is simply a pointer to server 202 b. The user's device can easily register different services with different servers. Enabling the Tereon server to find the correct server is a combination of the user's device ID and the credentials defining the service.

Once server 202a and server 202b communicate and communicate the service tag, user ID, and any other related transaction data (e.g., age, currency, quantity, etc.), server 202b queries the related user data and executes the side of its transaction. Server 202a never sees the user's data. What it sees is the user's authentication ID, and transaction data passed through the server 202 b.

Likewise, the server 202b never sees account information that identifies the terminal to which it is connected. It sees only the terminal ID, and the transaction data communicated through the server 202 a.

Psychic paper-multi-sided document

One of the more attractive effects of the directory service architecture is its ability to create ad hoc multi-faceted credentials for a particular service when needed. Because the directory service is able to provide those credentials, it is not necessary to consider the service ahead of time when generating the directory service. This is known as "psychrometric paper".

The ad hoc multi-faceted credentials represent credentials that a user's device may need to become a particular service, and only so. It conveys exactly the information that authenticates, authorizes, or benefits from the service, and is all that the service provider sees.

For example, the user 218 has registered a number of different services, such as a payment service from a bank, and a library borrowing service from a local library. Since he has to provide his birth date when registering Tereon he can automatically obtain an age verification service.

Fig. 12 is a diagram illustrating how directory service 216 directs a requesting server (server 202 a) to two different servers (servers 202b and 202 c) based on the services that user 218 has requested. If desired, two or more separate directory services may be used to provide separate services. Importantly, the transaction data is part of the summary and is separate from the underlying account data.

The user 218 needs to verify the age, for example, to purchase alcoholic beverages at a bar (service 2). In this example, steps 1202 through 1210 are performed as steps 902 through 910 in fig. 9, although between servers 202a and 202c, and not between servers 202a and 202 b. Once, at step 1210, server 202a and server 202c communicate directly with each other. In this example, server 202a wants to verify whether user 218 is over 21 years old. Server 202c simply confirms whether it is over 21 years old.

When the operator requires additional confirmation due to laws or regulations, the server 202c may transmit an image of the passport type of the user 218 for display on the terminal so that the operator can see that he or she is indeed talking to the user 218. The server may also transmit questions for the user 218 to answer in order to provide additional confirmation of the true identity, although the necessity of doing so is small because the user 218 has identified himself to the server 202 a. The operator does not see the actual age of the user or any personal information that is not necessary, as this is not necessary. All that is required by the operator is to know that the user 218 is large enough to purchase the alcohol beverage. When the user 218 makes a payment using his device, the terminal connected to the server 202a will contact the server 202c again, but this time in order to pay for the service (service 1).

The user 218 now goes to the local library to borrow a book (service 3). In step 1212, the user 218 identifies himself to the terminal in the library using his device, which automatically identifies himself to the terminal. The terminals in the library are connected to the server 202b. When the user uses the smart device, the terminal will pass its identity to the user's device.

In step 1214, server 202b retrieves the identity provided by the user device and checks the ID against its maintained list. It holds the ID but the cache has expired. Server 202b now contacts directory service 216. Directory service 216 looks up the ID for the service tag of the requested service and responds with information identifying server 202c and the buffering time of the real-time information.

Server 202b now contacts server 202c to confirm whether the user's device registered with server 202c for the service it performed at step 1216. Server 202b also passes the ID of the terminal to server 202c and updates its cache with new details of the ID from the user's device.

If server 202c has not done so, it may make a similar request to directory service 216 to query the server with which the terminal is registered, step 1218. It may also confirm that the terminal has registered the requested service with the server 202b. Directory service 216 responds with credentials that identify server 202b.

Server 202b and server 202c now communicate directly with each other in step 1220 to perform the required transaction. Server 202b wants to know if user 218 can borrow a book (service 3), and server 202c confirms that user 218 is registered with the library borrowing service (which is a service provided by the Tereon operator to the library). If the user 218 needs to pay the fee to borrow the book using his device, the terminal will contact the server 202c again, but this time in order to pay the service (service 1).

Server 202c does not need to provide any services to the library. The user 218 may easily register with another server, such as server 202d (not shown), in which case server 202d will confirm to server 202b that the user 218 may borrow books. Importantly, in the first instance, server 202a only confirms that user 218 is over 21 years old. It does not know whether he can borrow books, nor if the user 218 can pay by Tereon. Likewise, the server 202b knows that the user 218 can borrow books, but does not know whether he exceeds a certain age or whether he can pay by terreon.

The requesting server may also make multiple requests to individual servers if it is desired to set a set of credentials for a particular transaction. For example, assume that user 218 wants to borrow a movie with age restrictions. In this example, the requesting server will make two separate requests, one to verify the user's age and the other to verify whether to register to borrow movies from the library. The Tereon will aggregate individual authenticated credentials to build the credential set required for the library.

The structure of directory service 216 allows for the separation of servers that communicate individual credentials. Thus, the requesting server may query any number of servers in order to obtain the individual credentials it needs to build a credential set necessary to determine whether it can communicate to the user 218 the particular service.

Fig. 13 is a diagram illustrating a scenario in which server 202a needs to obtain credentials from three servers 202c, 202d, and 202e to construct a multi-faceted credential to provide services to user 218. For example, service 2 on server 202d may be renting a movie, which would require age verification as a first credential from server 202c, a member credential from server 202d, and sufficient funds credentials from server 202 e.

The relationship is not necessarily one-to-one, i.e., each of the three servers maintains one and only one credential relationship. Any of the three servers may each deliver more than one credential to server 202a. They may pass only one credential to the server 202a. The number of credentials is not critical. It is important that the server 202a can contact multiple external servers to obtain the credentials it needs to enable the user 218 to access the service.

It may be that the server 202a where the user 218 accesses the terminal has maintained certain credentials that it needs in order to deliver certain services to the user 218. However, for data protection purposes, the user 218 does not want to provide certain details to the server 202a (e.g., age, etc.). If server 202a only needs to do to verify whether user 218 is beyond a certain age, or whether it is allowed to order certain merchandise, it may simply contact servers that will either acknowledge or negate those issues. This is very useful for e-commerce websites, which can confirm certain facts or parameters without knowing the exact details. In essence, the directory service 216 may act as a provider of zero knowledge proof or as a confidential notary. The Tereon may prove or refute facts or parameters to the server 202a without disclosing the facts.

Thus, credentials for a particular service may include credentials from servers 202a, 202c, 202d, 202e, as well as other servers. The credentials may be on one server or may be distributed among multiple servers.

This is very powerful as it allows individuals and organizations to prove that they are entitled to service without revealing information that need not be disclosed. Similarly, for the example of an e-commerce web site, user 218 may register a name and address on the web site. However, his bank holds his payment credentials, the government server registers authorization to purchase the restricted item, the present subway company holds travel authorization, and the server of the health authorization center can confirm his age.

The method of integrating a set of ad hoc credentials for a service is not only applicable to users and their devices. It may also be well suited for standalone sensors, devices, and services, e.g., ioT devices that need to connect to different services at different times. When these credential sets are needed, they can simply aggregate the credentials needed for these services.

Account switch (Account switching)

The major problem with using new systems is often postponed because it is difficult to transfer data from legacy systems (legacy systems) to new systems without loss or service interruption. The same problem affects system upgrades, and operators often choose to keep the original hardware and software configuration, rather than upgrades and updates, as they consider the data to be lost in any upgrade or update.

Directory service 216 overcomes these problems by providing a mechanism to seamlessly move data, account and configuration information from one server or data store to another. One obstacle to supporting real-time transfers between institutions is the problem of how to capture and process uncertain (in-the-air) payments. The industry currently has an account transfer system that takes a total of 18 months, 7 days for initial changeover, and 18 months for any payment or transfer to be received. This can also be used to switch a set of data from a data store to another data store.

Directory service 216 provides an abstraction layer that separates the user's authentication ID from the underlying service, server, and actual user account. Thus, user 218 can maintain his or her authentication ID while changing the services with which his or her device is registered and the underlying server.

The account switching program will be described with reference to an example. In the example, user 218 deposits to bank a. Fig. 14 is a diagram illustrating the relationship of a user to bank a and his Tereon server 202 a. Bank B also supports Tereon on server 202B, although user 218 is not yet a customer. User 218 determines to move his account from bank a to bank B.

Fig. 15 is a diagram illustrating the process by which user 218 transfers his account from bank a to bank B. In the example, the user 218 has no overdraft and is not loaned from bank A.

At step 1502, the user 218 opens the bank B account and registers the card with the bank and its Tereon server 202B as well as the mobile phone.

At step 1504, the teleon server 202B of bank B looks up the user's mobile phone number and the card's PAN on the teleon directory service 216 and detects that both are registered with bank a.

At step 1506, the teleon server 202B of bank B now contacts the user 218 to confirm whether he wants to move his registration to bank B, and the user 218 confirms this by entering an additional authentication code specifically transmitted to him for this purpose.

In step 1508, bank B's Tereon server 202B now contacts bank a's server 202a and notifies it that user 218 has requested to transfer his account and ID to bank B and has confirmed this.

At step 1510, bank a's Tereon server 202a now communicates a request to user 218 to confirm whether he wants to move his account, and user 218 confirms his movement request.

At step 1512, the teleon server 202a of bank a now confirms this with the teleon server 202B of bank B and notifies the server 202B of the user's account registration, balance, configuration, payment instructions, etc. The server 202B of bank B sets up these accounts in exactly the same way as the accounts on bank a, or as close as possible, to provide authorized services.

For example, user 218 has three separate monetary accounts at bank A, which allows him to hold GBP, USD, and EUR. However, bank B only provides accounts for GBP and USD, but it may receive and pay EUR from or to any account. The server 202B of bank B notifies the user 218 when the user opens an account and determines to convert the EUR to GBP. Bank B will then instruct bank a to send the EUR as GBP.

At step 1514, the teleon server 202B of bank B now notifies the directory service 216 that the user's ID is now registered with its server 202B.

At step 1516, bank B's Tereon server 202B notifies bank a's server 202a that it has registered the user's ID in directory service 216 and instructs bank a to transfer the balance to bank B.

At step 1518, bank A confirms to directory service 216 that it no longer manages the user's ID. The directory service 216 sets a start date and time for the new ID registered to bank B and an end date and time in a field for the old registration of bank a. Bank a now sets up its directory service to notify any server that attempts to pay to the user 218 who is no longer holding the user account and instructs the server to look up the user's details in directory service 216. It does this by entering a date and time in the end date field. Bank B will now receive all payments to user 218 that were originally directed to bank a.

Directory service 216 may now capture an undetermined (in-the-air) payment for the user's old account after user 218 has switched to the new account. In a similar manner, tereon may also capture deferred payments generated from old accounts. Once the balance is transferred, these will appear in the new account, which task takes minutes instead of days, weeks or months.

At step 1520, bank a transfers the balance to bank B. Bank B notifies bank a that funds have been received.

At step 1522, bank a closes the user's account, informing the user 218 of this, and transferring the balance to the new bank.

At step 1524, bank B notifies user 218 that a balance has been received from bank A.

If user 218 overdraw one or more of bank a's accounts and bank B agrees to receive his business, bank B will transfer the balance to bank a in steps 516 and 520 and the user will be overdraw in bank B's corresponding account. User 218 may also determine to transfer funds between bank a's accounts before they transfer the accounts to bank B in order to clear any overdraw.

For payment, the Tereon numbering system distinguishes users, organizations, accounts, service types, and transactions. They all have separate numbering systems. These features allow the directory server to manage the process of the user 218 moving his account to a new service provider in real time. The structure of directory service 216 and the ability to process transactions in real time allows users to change accounts in minutes without requiring days.

As above, directory service 216, and all transactions, are processed in real-time, eliminating the problem of uncertain (in-the-air) transactions, such as uncertain (in-the-air) payments. For Tereon, a transaction cannot enter the undetermined (in-the-air) state. They are either completed or cancelled.

The Tereon also supports account portability, a concept of bank account portability, which is a feature that increases market competitiveness, but which banks and regulatory authorities consider impossible to achieve. Because Tereon does not directly use the details of the account, but uses separate credentials to identify each payor and payee, it inserts an abstraction between the user 218 and the user's bank account details. It is the abstraction provided by directory service 216 that makes account switching and portability easier to implement.

Changing credentials

Directory service 216 allows operators and users to replace existing ID credentials with new credentials and to reuse past credentials without confusion with transactions of previous users of IDs. The abstraction layer provided by directory service 216 allows Tereon to do this.

If the user 218 transfers his or her account to another server, the user 218 can either hold specific credentials, e.g., a PAN, or the server can issue new credentials to the user 218. In the latter case, the original server may reuse the credentials almost immediately. Because each credential has a time and date stamp reflecting when it was issued to the user 218, the new user 218 for a particular credential can use the credential almost immediately.

Each credential has a time and date stamp for determining when to issue to a particular user on a particular server. Since each transaction also holds a time and date stamp, each Tereon server holds credentials for each transaction, tereon simply uses these components to route the transaction to the correct destination. For example, user 218 may purchase something from a merchant using credential a, e.g., a mobile phone number, and then move to another bank after a few days when he or she needs to use another credential B, e.g., a new mobile phone number. The user 218 then brings the item back to the merchant because it is defective. The merchant need only find out the transaction and refund. Although the original transaction used credential a, the server report of credential a indicates the time and date stamp of the change in the credential. The merchant's server looks up credential a and finds that user 218 using credential a at the time of the transaction now uses credential B. The server now contacts the server of credential B and when it confirms that user 218 of credential B is using credential a at the time of the transaction, the server then begins refunding.

Since the security model of Tereon requires all communications to be signed, user a can determine that user B is not spoofed. The server 202B can sign its communication only if there is a valid license from the license server, and the user B's device can sign its communication only if the server 202B is valid, since the device's license will be issued and checked. The user will not be able to complete the transaction unless the user B knows the correct credentials to authorize the transaction, or access the application on the device.

In another example, the user may have entered the mobile phone number of the contact in his or her phone directory and now want to make an abrupt P2P transfer to the contact. The teleon searches the record for the number and finds that the contact has changed the phone number (if the contact is a teleon user) as above. It uses the correct server to confirm that the user using the new number used the old number registered on the previous server. The teleon also supports the functionality that one of the contacts can set his or her account, thereby allowing the directory server to update the user's mobile phone number or other teleon credentials when some approved contacts attempt to transact with them through old credentials. In this example, the aunt's new her new mobile phone number will be seen by her aunt's new her, who has set her account to update all family members the next time her aunt accesses the contact list.

Fig. 16 is a diagram illustrating an example of a server 202a, a server 202b, and a directory service 216. Here, the old user has moved his account from server 202a to server 202b. Server 202a is a server of bank a and 202B is a server of bank B.

The old user initially uses mobile phone number 1 as his ID. After transferring its account, it continues to use mobile phone number 1 for a period of time. Communication between the user 218, directory service 216, and servers 202a and 202b is as above and shown in fig. 15. The entries in the directory service show that user 218 uses server 202a from date-time 1 to date-time 3, and that user uses server 202b from date-time 2. The slight overlap is used to ensure that all undetermined (in-the-air) payments can be captured and that there is no time difference on the server where the user has no ID registration. (by ensuring that the server to which the account is migrated can control all date and time and ID entries of the migration, thus avoiding overlapping date-time entries, which is the manner in which the system is migrated.)

At some point in time, the user 218 decides to change the mobile phone number. He registers his new mobile phone number 2 as his ID on server 202b and deregisters mobile number 1. Server 202b notifies directory service 216 of the change, now showing that the user begins using mobile phone number 2 as his ID at date-time 4, and mobile phone number 1 is no longer the ID of server 202b at date-time 5.

Thereafter, the new user generates an account at the server 202a and registers the mobile phone number 1 as its ID at the date-time 6. The new user may have obtained the old mobile phone of the old user or the mobile phone operator has released the number for reuse. Server 202a notifies directory service 216 that it has registered an ID (after checking that the ID is available), whereby directory service now shows that mobile phone number 1 is registered with server 202a from date-time 6.

In the example shown in fig. 16, if the old user uses a card issued by bank a's server 202a, once user 218 has transferred his account to bank B202B, the bank may issue a new card to user 218 with credentials, such as a PAN, registered with it. User 218 initiates the card upon receipt of the card and bank B's server 202B notifies bank a's server 202a that the user's original credentials are no longer in use. Bank B registers new credentials with the Tereon directory service 216. User 218 may request that the original credentials be retained, in which case bank a may have charged a small fee if bank a agrees to the request. Thus, tereon supports portability of a card number or PAN.

The user may determine to stop using the card originally issued by bank a at some point in the future, thereby releasing the credentials. Bank a may not be able to reuse the PAN credentials after bank B releases the credentials, or for the whole six months after the user has transferred his account to bank B; the specific time depends on the permission of the banking regulatory authorities. After time, it may use the credentials because directory service 216 contains not only a list of mobile numbers, PANs, or other credentials; it also contains a list of registration dates for these credentials, and the dates they have expired or been released one by the user.

The account switching method allows the system to capture an undetermined (in-the-air) payment. It also provides a very flexible and robust way in which transactions followed by previous transactions can be guided in accordance with their credentials. Early transaction refunds are one example of the real world. Merchants refunding the old ID will be able to refund to the correct account because directory service 216 can indicate the correct ID to the server even if the original ID is subsequently reused. EMV and current mobile lookup techniques assume that the numbers are never reused. Unfortunately, however, the numbers may be reused.

This is illustrated in fig. 16. Assuming a certain point in time between date-time 1 and date-time 2, the old user uses the device to purchase items from the merchant with mobile phone number 1 as his ID. Thereafter, the item has a defect and the user wants to refund.

If the user 218 then goes to the merchant for refund between date-time 1 and date-time 2, the teleon system will direct the merchant's system to pay the refund to the user's account on the server 202a (because the user has not closed his account).

If the user 218 goes to the merchant for refund between date-time 2 and date-time 4, the teleon system will direct the merchant's system to pay the refund to the user's account on server 202b, although the payment for the item was originally from server 202a.

The account switching method will also take into account the new ID of the user. If the user 218 then goes to the merchant for refund after date-time 4 and uses his mobile phone number 2 as his ID, the Tereon system will direct the merchant's system to pay the refund to the user's account on server 202b even if the payment for the item was originally from server 202a and even if the user was originally using mobile phone number 1 as his payment ID.

The same applies to PANs, email addresses, and any other reusable credentials. (obviously, the inability to reuse biometric credentials.)

The system allows the credentials to be segmented to any degree of granularity (granularity). One example in payment involves currency or currency codes, where a user may use different IDs for different currencies on the same or different servers.

Fig. 17 is a diagram illustrating an example of the server 202b, the server 202c, and the directory service 216. User 218 has migrated his account from server 202b to server 202c in a manner similar to that of fig. 16 and under communication between management servers as in fig. 15.

The user 218 initially uses the mobile phone number 1 as his ID. After migrating his account he continues to use mobile number 1 for money 1 and money 2 transactions for a period of time. The entries in directory service 216 show that user 218 uses server 202b from date-time 1 through date-time 3, and that user uses server 202c from date-time 2. The slight overlap is to ensure that all undetermined (in-the-air) payments can be captured and that there is no time interval for the server to have no user registration ID.

At some point in time, user 218 decides to use the new mobile device to conduct a transaction for currency 2. He registers the new mobile phone number 2 as his ID with the server 202c for the transaction of currency 2. Server 202c notifies directory service 216 of the change, now showing that the user starts to use mobile phone number 2 as his ID for all transactions with currency 2 at date-time 4, and mobile phone number 1 is no longer the ID of the transaction with currency 2 at date-time 5.

Fig. 17a is a diagram illustrating another example of a server 202b, a server 202c, and a directory service 216. In the figure, user 218 has migrated his money 1 account from server 202b to server 202c in a manner similar to that illustrated in FIG. 16, and under communication between the management servers as illustrated in FIG. 15.

After migrating the account, the user continues to use mobile phone number 1 for a period of time to conduct money 1 and money 2 transactions. An entry (entry) in directory service 216 shows that user 218 performs a transaction in two currencies using server 202b from date-time 1 through date-time 3, and performs a currency 1 transaction using mobile phone number 1 as its ID for server 202c from date-time 2. The directory service entry (entry) also shows that the user continues to use mobile number 1 as his ID for server 202b for money 2 transactions.

At some point in time, user 218 decides to use the new mobile phone for money 2 transactions. He registers the new mobile phone number 2 as an ID with the server 202b to conduct a transaction of currency 2. The server 202b notifies the directory service 216 of the change, after which the user uses mobile phone number 2 as an ID for all money 2 transactions, starting from date-time 4, and mobile phone number 1 is no longer an ID for any transaction with money 2 from date-time 5.

Before date-time 4, user 218 uses his mobile number 1 as the ID for all transactions. Directory service 216 simply directs transactions to server 202b if the transaction uses currency 2 and to server 202c if the transaction uses currency 1. The fact that the user has registered the same ID on both servers is not critical, as it is a complete set of credentials that govern to which server the transaction is directed. The merchant system that first uses currency 1 and the user's transaction after date-time 2 will never know that the user has previously used server 202b to conduct the currency transaction. Likewise, the merchant system will not know that the user is doing the money transaction with the same ID at server 202b unless the system is added to the user's money 2 transaction.

The teleon does not simply switch the user 218 from one network to another. As before, the usual method of switching users cannot handle an uncertain (in-the-air) payment. As the inventors call, the most advanced account switching systems currently available require a manual process of 18 months to capture such payments before the user can maintain independently. During 18 months, both the bank and the user must struggle to ensure that they transfer all existing payment instructions from the old account to the new account. The Tereon completely circumvents this requirement.

At present, banks cannot reuse any payment credentials. The terreon account switching mechanism eliminates this limitation, whereby the bank can reissue the PAN and account number after a certain period of time has elapsed, as allowed by the regulatory body.

Although the account switching function is described, the method has many applications beyond basic account switching. For example, when a banking core system fails, a failover (failover) may be provided to a backup service provider, thereby providing a method to migrate data from one system to another by converting from one data format to another without any loss of information.

Another example is to increase the portability of the number in a mobile telephone system (number portability). Currently, if a user switches his or her mobile phone number from one provider to another, the first provider must reroute all calls to the new provider. If the user then switches to the third provider, the first provider must route the call to the second provider, which in turn must route the call to the third provider. This is inefficient and expensive and therefore operators must support number portability. The Tereon eliminates the necessity of repeated routing of calls.

If the operator uses Tereon to support portability of the number, multiple operations are not required. When the user decides to transfer his or her number from the first operator to the second operator, the second operator only needs to inform the directory server that it now supports the mobile phone number. The first operator forwards the call to the number to the directory server, which routes the call to the second operator. Whenever the user forwards his or her number, the new operator will inform the directory server of the change and the directory server will simply route the call to the operator serving the number. (if the user has a globally unique bank account, such as IBAN, tereon will support portability of the bank account in the same manner as mobile phone number portability is supported.)

A similar example is where an operator migrates IoT services and devices from one server to another in order to upgrade a teleon system that cannot be satisfied by simple migration, such as a physical machine, a logical machine, a virtual machine, a container, or any other commonly used mechanism that contains executable code.

Another example is to operate as a system migration tool. This would be the case, for example, when an operator would like to migrate a service and an account registered by the device from one version of the Tereon system to an upgraded version. The operator simply sets up the old server to transfer the device registration, account, and system configuration to the new server, and the system will perform the transfer. Each account will be transferred along with its data and audit log and the server updates directory service 216 as the transfer proceeds. Now, when devices on site, whether payment devices, traffic sensors, ioT devices, etc., wish to communicate with their servers, directory service 216 will redirect them to either the old or new server simply based on whether they contact the server before or after transferring the account.

The above examples illustrate how Tereon improves the portability of the credential and supports ad hoc multi-faceted credentials. This has a profound effect and brings Tereon into almost any network where it is necessary to manage credentials.

Scalable architecture

The workflow for existing transaction systems is static in nature. After implementation, they are difficult to change and the services or operations supported by the system remain unchanged.

So far, when a payment provider pushes out a service, the payment mode of the service remains static. If it is desired to modify a service, the provider can only support the service by pushing out an alternative or modified service and issuing a new card or application. This is also one of the reasons for the inability to repair the system, although the serious drawbacks of EMV are well known, as this would mean to recall all existing EMV cards, reprogram and launch the EMV payment infrastructure, and then issue a new card. This requires the coordination of thousands of issuers with recipients.

The Tereon uses the SDASF to put all functions to the back-end, and the back-end can guide the merchant device in real time throughout the process. This enables the service provider to create new services with the same granularity as individual users.

The extensible architecture is an architecture that resides within the Tereon system and allows new services to be added without requiring reconfiguration of the Tereon system. The extensible architecture works in conjunction with directory service 216 to provide a number of advantages to the Tereon system.

Flexible information structure

A portion of the extensible architecture is provided by a flexible information structure in which any data or record type may be provided with variable length fields, whereby the Tereon system may modify the length of the fields to operate with legacy or incompatible systems.

The extensible architecture allows for the addition of additional layers of security to the communication infrastructure by changing the standard order of the programs. In many industries, payment is one example, and communications use a fixed information structure. This allows the communication to be exploited by criminals even if encrypted. Structured messages are vulnerable to depth attacks. While organizations and other parties may still protect the integrity of information by using Hashed Message Authentication Codes (HMACs), HMACs do not have absolute confidentiality that information should have.

The extensible architecture can provide a design that enables any transaction processing system to eliminate the problems of static systems. It provides flexibility to be able to operate with existing systems and services and allows a provider to update existing services and build new services without having to reissue the infrastructure or issue new end devices such as cards. The architecture is flexible enough to enable a provider to build services customized to individual individuals. This will be described below.

Fuzzy processing (Obfuscation)

One of the theoretical risks faced by any system with structured message formats is that the reuse of the information format will provide sufficient material for a brute force attack by a hacker. This is true for systems that do not use some form of random seed to properly run the encryption algorithm. However, this should be overcome.

The extensible architecture enables operators and users to get rid of the need to transfer structured messages between devices and servers. Alternatively, blurring may be performed on the information.

Each transaction communication in Tereon will include two or more fields and tags for those fields. Not every communication is in a fixed order field, the order may be changed randomly. Since each field will always be accompanied by an identification tag, it must be ensured that the device at each end of the communication will decrypt the field and then sort the field before processing the field.

For example, using the excerpt (excerpt) in the example provided by the JavaScript object notation (JSON) file (although the system can be or use other formats), the following three versions are the same:

·{"version":1,"firstName":"John","lastName":"Smith","isAlive":true,"age":25}

·{"version":1,"firstName":"John","isAlive":true,"lastName":"Smith","age":25}

·{"age":25,"firstName":"John","isAlive":true,"lastName":"Smith","version":1}

an attacker does not know which ciphertext, if any, it has contains information that is known and has the same order. The exact pattern of blurring, if any, will depend on the format used and the serialization protocol used, but the principle remains the same.

The blurring mode has additional advantages. The content of the predefined communication can be extended without disrupting the communication protocol. If the device receives fields that cannot be processed, those fields and values are discarded. Thus, one or more random fields and value pairs (value pairs) of system discard may be included, but this adds additional uncertainty to the communication.

The following three communications are identical:

·{"version":1,"firstName":"John","nonce":5780534,"lastName":"Smith","isAlive":true,"age":25}

·{"whoknows":"698gtHGF","version":1,"firstName":"John","isAlive":true,"lastName":"Smith","age":25}

·{"age":25,"firstName":"John","isAlive":true,"lastName":"Smith","whatis this":"Jor90％hr,""version":1}

in each of the above communications, the device will discard unknown field and value pairs (value pairs).

The field names may be further obscured by mixing different characters in a random fashion for each communication. The device processes these fields into a standard (Canonical) form.

Thus, the following three communications are identical:

if version 2 information, which may contain additional fields, is transmitted, any device that only understands version 1 will reject the information, or if backward compatibility (backwards compatibility) is ensured, process the fields it understands and discard the remainder. This may be enhanced by providing a field that can indicate which versions are backward compatible with some fields.

Thus, vulnerabilities to deep attacks are eliminated. The information structure may also be maintained in a manner with variable length fields. Again, this achieves similar results. Also by using HMACs, the integrity and confidentiality of the information can be protected. If the end-organization's kernel system needs information in a structured format, once the server is reached, the Tereon will simply reconstruct the information and reformat it using the format required by the organization's kernel system. Thus, the scalable architecture can overcome the security issues of legacy systems, and still operate with such systems.

The extensible framework supports any data or record type, with security and flexibility as described above.

Abstract workflow (workflow) component

In existing solutions, payment procedures can be defined in software and implemented, tested, and released. The payment transaction structure is currently fixed and cannot be altered without expending a lot of effort to recall and replace or reprogram the device, terminal and server.

This is not the case for Tereon. Instead, it builds a payment flow for the individual components, each interacting with its connected components. These components essentially lay out the workflow (workflow) of the program. Functions can be updated and added without affecting the payment procedure. Thus, the program component is abstracted from the device, and thus, after a transaction is defined, can be adapted to any number of devices, whether cards, card terminals, mobile phones, or web portals.

Each component passes instructions and information to the next component according to the instruction results it receives. The instructions may be transactional or they may contain controls such as how the next component functions (e.g., request a PIN if optional, provide a set of choices, display specific information, and expected or allowed responses).

Thereby, a capability is provided to change existing payment services and to build new services without the need to reprogram or replace existing terminals. Currently, after a payment service provider runs a payment system, the payment service provider cannot easily change the system without replacing the endpoint. Existing systems are static in nature. This replaces them with dynamic systems.

The extensible architecture enables operators to plan workflows (workflows) for specific transactions using these components. It is able to construct a workflow (workflow) comprising decision trees and the like. The operator may modify an existing workflow (workflow) by simply rearranging existing components, by adding new components that provide new functionality, or by removing components. To achieve this in existing systems, the server as well as the terminal need to be reprogrammed and the card itself may need to be replaced.

This example is shown in fig. 18 to 20. The components themselves are represented as tiles through the terminal screen in order to visualize the function of each component. However, the components are equally applicable to mobile transactions, web portal transactions, and card termination transactions. To change the existing workflow (workflow), the order and connection of components can be simply changed. To generate a new workflow, the required components will simply be connected together in the order required.

The normal payment procedure will generate separate payment procedures for contactless, contact, and mobile payments. Thus, as shown in FIG. 18, the component 1804 typically appears to the left of the chain, after the component 1802 of "completing a transaction in time".

However, by moving the component further to the right, and inserting two decision components 1902 and 1904 further in the chain, as shown in fig. 19, the operator can generate a single payment flow, which can manage contact, contactless, and mobile payments in a single payment flow.

The operator can realize more. The operator wishes to add in the program, thereby providing a special seasonal offer (offer) after the system identifies the customer. As shown in FIG. 20, the component 1804 can be moved further to the right at any time and a new component 2002 inserted in its original location, the component 2002 automatically providing customer proposal before the merchant needs to enter quantity and PIN. For example, an operator may configure the component to run on the first 24 days of christmas and provide a different component from then on to the first few days of new year. Thus, the payment procedure for christmas and new year holidays will be dynamically changed without the need for operator recall and reprogramming of the device. The component will simply command a display device, such as a mobile phone or card terminal, to display the offer to the customer. The operator can easily disable the PIN requirements through the configuration component 1804. Likewise, if the component does not require the functionality of the PIN, the operator may update the component to contain the functionality.

The operator may further and construct a complete decision tree, enabling the customer to choose from a range of offers, when desired by the operator. When the proposed season ends, the operator can simply remove the new component, whereby the program reverts to the original structure.

It should be noted that the operator does not need recall means to change the program at any time. It simply reconfigures the program at the backend and then implements the change at the time and date it was selected.

The architecture that provides for the internal management and operation of the Tereon server may be configured in exactly the same way, where the components of the architecture interact with the context of access, thereby managing the way users and administrators can access information and access information, and what tasks they can perform.

Dynamic services

The extensible architecture enables organizations to quickly generate and implement new services. The operator defines these services simply by linking the required blocks together and defining any relevant information. The architecture does not require the use of programmers to write service code, but rather, services are implemented by allowing marketing and IT departments to write definition files defining workflows (workflows), by using a graphics system to "draw workflows", or by any other program defining workflows (workflows). After checking the workflow (workflow), the operator implements the workflow simply by linking defined steps or blocks together, and the teleon makes the service available to all qualified users.

For example, the operator needs to use the block to accept payment for any value and the subsequent block to request the PIN. However, if an operator wants to provide an access control system, the same operator can create a tile that allows PIN-less access to one set of rooms while using the tile to request a PIN to access another set of rooms.

This means that unlike existing systems, the system allows an organization to design and implement new services, or to modify or remove existing services, without the need to replace devices issued to users, even if the organization has pushed out the transaction system. If the device knows and can operate any one of the steps, the device will use those steps to support any service defined by the organization. When an organization defines a service, the system will immediately make the service available to the target user or users.

Abstraction device

The extensible architecture further employs abstraction principles to abstract the device itself. The architecture defines program components for each class of device that are related to device functions. The program component interacts with the functional component. Depending on the available functionality, the program component will instruct the functional component to perform tasks such as outputting content and inputting content.

Granularity (Granular)

The Tereon may individually identify the device, the user, and the account, and may access a context within the user access service using the device. Thus, the operator can configure components and options within those components to trigger actions according to the context within the independent user access service. The Tereon effectively allows the operator to customize the service for each user, each user device, and the context in which the user uses the device to access the service.

For example, one user may see three offer options in one transaction, another user may see only one offer he or she receives automatically, while a third user may not see the offer at all.

If the program is related to access records, such as patient records, then when the user accesses a medical facility or home domain, the user can access his or her records and manage access rights. However, if the user (or others) accesses those records that are far from these domains, the user may only see a subset of those records, or may not access those records at all (depending on the background setting of the service).

If the user accesses the service using the card terminal, the component will instruct the card terminal to display the relevant information. If the user uses a mobile phone or other screen device to access the same service, the component will instruct the screen to display the relevant information. In this way, the abstraction layer of the extensible architecture becomes device independent. It may use any suitable display and access point to control user-system interactions.

The same applies to the services provided. Each user's account will have a default service level for the provider. If the operator adds new services or modifies existing services for one or more users, the user's account will have those services. The key to the service would be the combination of its provider label, the user's account number, and the user's device registration label. This creates a short dendritic path for the user's service definition and rules.

For example, the sender may use a mobile phone that is set with rules to allow interaction or automatic transmission. The recipient may have set his device to receive the automatic transmission. In this case, the sender's device will simply transmit automatically through the steps. The service tag does not contain any information about whether the transmission is interactive; service information stored in the servers of the sender and the receiver.

If the recipient sets the device to accept the interaction or automatic transmission, the sender's device will query the sender as to which mode to use. The recipient may have set his device to accept automatic transmissions between certain times and interactive transmissions at other times. Here, the receiver's Tereon server will simply inform the sender's server of the transmission mode that should be used, depending on the receiver's period.

If the sender or the receiver's device accepts only interactive transmissions, they will perform the transmission if the receiver is online simultaneously with the sender by the following steps. If the recipient has only one card, the recipient needs to go to the merchant's terminal to perform one side of his transaction. If the receiver is offline, the sender completes his steps, but the receiver must then complete his steps in the transaction before the Tereon completes the transmission, e.g., accept the transmission and enter his PIN. Prior to this, tereon will save the transmission in a third party escrow (escrow) facility, similar to the way the transmission is handled to non-Tereon users.

Dynamic interface (Dynamic interfaces)

The extensible architecture results in context-dependent services such as offers to assist a user in finding his or her seat, a particular merchant's program, etc. during an activity. It allows an organization to customize the services and experiences each user has when interacting with Tereon, the extent to which the services are available depends on the context, buttons that may appear, options available, etc.

The number of services each user and each merchant can interact is entirely dependent on the overlap between services that an individual user can access and services that the merchant can provide.

For example, if a merchant can provide payment, deposit, and withdrawal services, when a user arrives at the merchant and can only access the payment at that merchant, the user and merchant will only see the functions regarding the payment, i.e., payment and refund. If the user comes to the same merchant and the user has access to payment, deposit, and withdrawal, the user is able to see all of the functions. If the merchant does not currently have sufficient funds to support deposit or withdrawal, the user will only be able to see the payment function on his or her device or the merchant's terminal when the user with the full service comes to the merchant. Merchants will no longer appear on any searches for merchants that provide deposits or withdrawals. It may also be the case that a user cannot access certain services at certain merchants, but may access those services at another merchant. The architecture will also handle the above scenario.

The dynamic interface complements the use of multi-faceted credentials and enables the device and its associated application to become something similar to "psychic paper" as above. In this case, the device only provides the available services, and the interface is only applicable to those available services, regardless of which various services the user may register. This is similar to a payment device for one service, a transportation ticket for another service, a door key for another service, etc. The service provider does not need to issue a separate device to access its services and reduces the complexity and cost of providing and upgrading the services.

The extensible architecture enables the device to change its appearance and change the presentation of credentials and services within the device or required in order to use the device's context. Thus, for example, it may modify the screen of a stand-alone ATM, such as an ATM in a grocery store, to present look and feel at the operator when the user accesses the ATM, and to present only services to which the user has subscribed.

Interaction with other layers

The ability of the extensible architecture to interact with other components within the Tereon system is an essential feature of the extensible architecture. In addition to background security, which itself includes a broader security model, the extensible architecture instructions may be embedded within transaction information transmitted through a hash chain (associated with a hash chain with zero knowledge proof).

Offline mode (Off-line mode)

The Tereon provides three off-line modes; the user is offline, the merchant is offline, both are offline.

In the first two cases, the Tereon completes the real-time transaction in the opposite direction through the square (square); i.e. the user communicates with his Tereon server via the merchant terminal and the Tereon server of the merchant. Neither the merchant nor the user experiences a service degradation. The Tereon uses a PAKE protocol or a similarly functioning protocol to generate a secure path through three sides of a square (square) for the relevant device.

In the third case, when both devices are all offline, the immediate impression is that terreon cannot check in real time whether the user or merchant has sufficient funds to support the transaction and thus the terreon cannot overcome the credit risk generated. But this is not the case.

By using features of the extensible architecture and versions of the hash chain, tereon can ensure that the system can still check funds. Both the user and the merchant are able to perform all functions. The user will need to use a mobile phone or microprocessor card but neither the user nor the merchant will experience a fallback to the service they accept. Both the merchant device and the user device will store encrypted details of the transaction between them, as well as a random sample of previous offline transactions that the merchant has made. The merchant device sets the maximum number of copies of each transaction that are transferred to the user's card or phone.

The Tereon will use a combination of business logic, security models, and hash chains to avoid any user using a combination of offline devices and online devices to pick up more than the amount in the account. The account supports the offline device only when the account provides credit functionality. While the regulatory authorities of the service provider may require credit permission to be provided, offline logic does not require credit (credit).

If a device is not authorized to operate offline, it will not be able to conduct transactions with any other device while it is offline. Its security and authentication model will block because its signature recognizes it as supporting only online transactions, and the device will not be able to process any transactions affecting the value of any account it registers for.

If the device supports an offline transaction, the service provider will make an amount limit (a portion of the credit or account balance, which is always updated while the device is online), i.e., an offline limit. The device can only authorize transfer or payment of funds from the account equivalent to the value of the account or the off-line limit. Of course, the service provider may authorize the device to accept the transfer or funds, and may limit the acceptance limit (offline acceptance limit). If the user accesses the account directly through the web portal or using another online device while the first device is offline, the amount the user can authorize transfer or payment from the account is the account balance minus the offline limit.

Once the device containing the relevant records is online, the Tereon checks for all offline transactions. Of course, it will receive multiple copies of some transactions, thereby validating the previous content.

Thus, if the server receives an offline transaction record from a third party server regarding payment or transfer to the offline device, it will process the transactions and add the funds to the account balance once a sufficient copy of the transaction is received. Likewise, if the server receives an offline transaction record from a third party server relating to payment or transfer of offline devices, once a sufficient copy of the transactions is received, it will process the transactions and subtract the portion of funds from the account balance and remaining offline limits

Although the above description relates to payment, the same mode of operation may be applicable to any type of transaction system, as is readily contemplated. For example, interactions between IoT devices or other industry components. By creating a workflow (workflow) containing modules that can be rearranged, inserted, or deleted, the operator can reconfigure the device to operate in a new manner without requiring recall, reprogramming, and reinstallation.

The operator may reschedule devices in the field, change their way of operation, and even let the devices control other devices and modify their workflows (workflows) based on any changes in the operating environment that those devices detect when they are running.

IoT devices may also modify each other's workflows (workflows) by modifying the components of the modules that make up the workflows (workflows), if desired. A security model that manages communications between devices would enable the communications to resist man-in-the-middle attacks, while a lookup service would enable the devices to identify and authenticate each other.

The offline mode allows devices to operate automatically or semi-autonomously and interoperate with each other, authenticate and confirm any transactions between devices, and interact with the operator's system only when needed.

The background security model described below extends to any type of device, such as IoT devices. Any device may communicate with any other device as long as the device is authorized to operate and as long as the device's services are listed in the associated lookup service, and each device will use a hash chain to enable it to trust and verify transaction and data communications between devices, including instructions to modify the device's workflow, upgrade the device's system, or simply pass or verify data between systems. Each device will maintain a complete audit of its own transactions.

Secure

The Tereon system uses a number of unique security models to overcome the problems and limitations of security models and protocols in conventional transaction processing systems. For example, the security model eliminates the need to store data on the device. This is a major problem with existing systems.

Secure USSD

USSD (unstructured supplementary service data) is commonly used as a communication channel for many transaction types, including payments from or to functional handsets. The Tereon implements the secure use of USSD.

Most embodiments require the user to enter a USSD code or select an action from a numbered menu. A series of unencrypted messages are often used. This leads to cost problems, as well as problems of reduced security and user experience.

The Tereon does not send information in the form of 7 or 8 bit text that presents security problems, and the Tereon uses USSD and similar channels in a new way. The Tereon simply bases it on a short-burst (short-burst) communication channel of the conversation.

Unlike existing systems, tereon does not modify information to accommodate USSD. Conversely, for each encrypted communication in a transaction session, tereon would encrypt the communication as if it were communicating over TCP/IP (i.e., GPRS, 3G, 4G, wiFi, etc.) to generate ciphertext, which would then be encoded into a 7-bit string of base 64. Then, tereon checks the length of the ciphertext. If it is longer than the space allowed in the USSD message, the ciphertext is cut into two or more parts and transmitted separately using USSD. In another aspect, tereon reassembles the parts into a complete string, converts it back to ciphertext, and then decrypts it.

The Tereon can use this method to first identify and authenticate each party using TLS (transport layer security protocol). This will generate a first session key. The Tereon may then use this negotiation of the session key encryption PAKE protocol, which generates a second session key that the parties will use to encrypt all further communications in the session.

Some feature handsets support WAP (wireless application protocol). When WAP is used through USSD, tereon will simply use the WAP protocol stack as a means of communication across USSD. Thus, the wireless transport layer security protocol (WTLS) layer, which provides only an additional level of authentication, is relatively weak to encrypt than the TLS and advanced encryption standard 256 (AES 256) used by Tereon by default, whereby Tereon will use AES256 to encrypt communications in any transaction.

This also illustrates how Tereon protects other communication channels (e.g., NFC, bluetooth, etc.) that are considered to be lacking in security. By carefully constructing the information dialog, the nature of USSD and other "unsecure" channels can be completely altered.

Security model for active devices (and the Internet of things)

Security models for active devices, such as mobile phones, card terminals, etc., operate in a manner similar to card security models (see description below). Since the security algorithm was broken some time ago, the SIM was not used. Instead, a registration key is used, which is encrypted and stored on the device along with a unique key generated at the network. On the mobile device, tereon may perform a lookup using the key to check if the IMSI (international mobile subscriber identity) reported by the mobile device is authentic.

When the user executes an application for the first time (the user may have multiple applications as desired), the application will request a one-time authentication code that the Tereon server generates for the user's account, as well as the mobile phone number or serial number of the device (if the application cannot first determine the number). The user may also register his or her application with multiple Tereon servers, where each server generates a unique one-time activation code for each account or service operated by the server in order to provide the service to the user.

Once the user enters the one-time activation code, the application uses the code as a shared secret (shared secret) between it and the server to generate a first PAKE session (after the application and the Tereon server verify each other, if necessary, using TLS or similar protocols). Once the first PAKE session is established, the Tereon server will send the encrypted and signed registration key and the new shared secret to the application. Both the server and the application will use the one-time activation code, the registration key, and the shared secret to generate a new shared secret by generating all three hashes.

Each time a server communicates with an application, they will create a shared secret by hashing a previous shared secret with messages previously communicated with each other in online communication. Each time an application and a server communicate with each other, they will generate a hash of the transaction content, i.e. a transaction hash, which has been exchanged in a previous exchange. They all use this transaction hash to generate a new shared secret.

They will both create a shared secret by hashing the previous shared secret and messages previously communicated with each other in online communication.

If the user loses his or her device, or he or she needs to re-register the application or change devices, the Tereon server will generate a new one-time authentication code as well as the registration key. The new shared secret that the server will pass to the application will be generated from a hash of the previous information exchanged between the server and the application.

This key forwarding allows the application and the Tereon server to always provide a new shared secret for each PAKE session. Thus, if an attacker can crack a TLS session (which would be very difficult because both the server and the application would sign their message), the attacker still needs to crack the underlying PAKE session key. If a party manages a technology, this will provide the party with keys that are applicable only to conversations. The process of generating a new key for each communication means that the party will need to repeat the technique for each communication, a task that is computationally almost impossible to accomplish.

Since the application authenticates to a particular service in any session, the user's application will only interact with the service. The server will not be aware of any other services to which the user's application registers. In practice, an application program resembles a "psychic paper" which is an identification device that provides only the credentials required for a service, regardless of the number of services that a user may register. It may look like a payment device for a service, a transportation ticket for another service, a door key for another service, etc. The service provider does not need to issue a separate device to access its services, thereby reducing the complexity and cost of providing and upgrading the services.

The security model has an additional advantage. If the user loses his or her device, the user can obtain a new device with exactly the same number. An old device with an application will not work and a new device will work after registration is completed because it will have a valid key and registration code. Although there may be a time difference between the missing device and reporting the loss, no one can make any transaction because no one would have the necessary password and PIN, or any other authentication token.

The user or administrator of the Tereon system may also configure the application to require a password before the user can access the application. The password is checked using a Tereon server. If so, the Tereon server will instruct the application to run (through always signed and encrypted communications). If the password is invalid, the Tereon server will instruct the application to request a new password a limited number of times. The Tereon server will then lock the user's application and the user needs to contact the administrator to unlock the application and re-register the device.

Each credential is timed. This means that the user has specific credentials assigned to him or her during a defined period of time, and that all transactions that occur during the period of time using the credentials are linked to the user. If a user subsequently alters the credentials, the original credentials may be assigned to another user. However, the lookup server will continue to link transactions and credentials according to a combination of credentials and time periods during which these credentials are registered.

The same model may be adjusted to ensure communication between devices in the "internet of things". Each device may be identified herein using a certificate or a hard-wired serial number. This will be the first shared secret that the device exchanges on the first contact when hashing the date of the transaction, or with previous information sent between the devices. And, two numbers, one for identifying the device and replacing the open serial number of the PKI (public key infrastructure) certificate, and one for cryptographically protecting the serial number as a shared secret will be used. Alternatively, a single serial number may be used as the ID and first shared secret and the new key will be uploaded over the secure communication channel (see discussion regarding the communication layer in the system architecture).

The mobile security model of Tereon has another advantage. The operator can use it to set access rights to individual services and has specific purpose devices and networks that enable the services to succeed to configure the level of access. For example, this means that the provider may specify that an administrator may view the system log through a secure public network, but only access the system management functions through an internal network, and specify that only through a fixed device, not through a mobile device.

While this function has some application on payment (which determines access to system management functions within defined networks and devices), it is also true for other services that require limited access to sensitive or privileged content, so users can accurately control who can see certain data, which data can be seen by these third parties, and where they achieve access.

The security model enables an organization to guarantee the privacy and security of any data collected, generated, or transmitted by any device. This may apply to any device or transaction, from payment to medical devices, traffic flow sensors, weather sensors, water flow detectors, etc.

Card security model

EMV cards and mobile phones emulated using host cards store the PIN on-chip or in a secure element on the phone. Contactless cards and mobile phones emulating those cards also store most of the card details in a clear, or easily readable, form. The card terminal checks the PIN entered by the user against the PIN stored on the card. This is where many weaknesses in the EMV system are revealed and makes the EMV vulnerable to many well-documented attacks.

The Tereon stores the authentication key only on the card and checks the entered value against the value stored on the Tereon service (in a secure area of the database that is not disclosed to an administrator who only sees if the value matches the actual value). It authenticates based on the service and the specific function, resource, facility, transaction type, or other type of service provided by the service. The Tereon uses two security models, one of which is a subset of the other.

Most cards will display a PAN (long number). The teleon does not use the number to identify the account. Instead, it uses a PAN in the same way as a mobile phone number; it is just one access credential. Each card has an encrypted PAN. The card also has an encrypted registration key that identifies the card as valid for each service it registers with much the same way that the registration key on the mobile device authenticates the device. If there is no detailed information of the address associated with the encrypted PAN string registered on the Tereon service, the encryption code will have a prefix (prefix) that points only to the lookup directory service of the country where the Tereon service of the merchant needs to request.

When the user presents the card to the terminal, the terminal will read the encrypted PAN and use it and the encrypted registration key to authenticate the card with the registered terminal of the card. Once the user's terron service has verified and authenticated the card and the merchant's terron service, the user's service communicates the PAN in unencrypted form to the merchant's terron service, whereby it can be registered in the cache as well as in encrypted form. Thus, if the user later explicitly enters a PAN through, for example, an e-commerce portal or merchant terminal, the service will know which other service to contact.

If the card reader is not able to read the card for any reason, the user or merchant may type in a PAN and the merchant's Tereon service will use the PAN to obtain the address of the user's Tereon service. The user may instead enter his or her email address, mobile phone number, or any other unique credential as long as the credential is registered with the user's account. The PAN of the card is just one of many credentials that the user can use.

Once the merchant's Tereon service verifies the card, the merchant's terminal will set TLS and then set a PAKE session with its Tereon service through its hash key (each time the terminal communicates with its service, hash its previous key and its registration key to generate a new shared secret for the PAKE session). The merchant program will continue until the merchant's terminal needs to request a PIN (if the user's terron service needs the transaction's PIN as determined by the payment service provider and placed in the terron service's business rules engine). The user's Tereon service will generate a PAKE session with the merchant service, then transfer the one-time key to the merchant service, and transfer the encrypted information to the terminal by first creating another PAKE session using TLS.

The merchant's terminal will receive the key and decrypt the information to display the text (text) selected by the user, which indicates that the terminal is authorized by the merchant service. The user enters his or her PIN which communicates with the user service through the PAKE dialogue of the terminal. This process only occurs if the user has to enter his or her PIN at the merchant terminal. The merchant terminal never sees the PIN explicitly because it is entered into the merchant terminal in a secure application accessed from the user's Tereon service and encrypted using the user's service in a secure signed key exchange with the second one-time key sent to the terminal. All communication will typically be through the merchant's service, and direct communication between the terminal and the user's Tereon service may also be established where the terminal supports this functionality.

If the card is a microprocessor card (chip and PIN, contactless or both), the card may also have a shared secret that is initially generated at the time of its issuance.

The microprocessor card will also establish a dialog using the PAKE and its registered Tereon service (or a service for the service). The session will be with a session established by the card terminal (which may be a mobile tablet computer, or PoS card terminal) with its Tereon service. This immediately eliminates the critical vulnerabilities presented by existing terminals and chips and PIN cards, which are vulnerabilities of the existing infrastructure that interfere with and disrupt the PIN verification process through some "man-in-the-middle" or "wedge" attacks.

The card will use this channel to generate a key that will be sent to its service and the service will send the key to the merchant's terminal to encrypt the PIN. When the card is to store the balance of the last online transaction, it will also use the channel to facilitate the offline transaction, the key will seed a series of keys to be used for the offline transaction and the records of some third party offline transactions.

The security model of Tereon does not require the issuer to issue a new PAN if the card is lost or stolen.

Context-based security

Most security protocols use some credentials and build on some underlying assumptions. It is these assumptions that may lead to errors and thus loss of security. The Tereon system does not rely on any underlying assumption except that the communication network without this system is not secure and cannot be trusted, and the environment in which the device operates may also be unsafe.

The Tereon system further looks at a set of credentials and provides a background of the credentials. This provides additional security and ensures that an organization can enable one of its employees or members to use their own devices (sometimes referred to as carrying their own devices (BYOD)) in some or all cases.

The Tereon may use not only the user password, PIN, or other direct authentication credentials; it will also use the device's detailed information, the applications on the device, the device's network of access to Tereon, the device's geographic location at and during the session, and the services or information that the user accesses using the device.

The Tereon obtains the credentials and controls access to the information based on the context set by or against the credentials, granting the appropriate level of access to the credentials.

For example, an administrator attempting to access deep administrative services on a private device that is not authorized by Tereon will be prevented from accessing these services, whether the administrator is in the workplace or not and the network at the workplace. However, the same administrator may have access to view certain system logs on the same device.

The second example relates to a background security model managing services that can be seen by a secondary user. The user has a telephone or card that provides multiple functions, such as deposit, withdrawal, and payment without a number of restrictions (of course, only the highest credit limit or available funds). Users often visit a coffee shop and always buy a cup of coffee as well as almond croissants. Today, the user gives his card to his son and sets a total cost limit of 40 pounds for the card. The user's use of his son also sets a second PIN, who brings the card to the same cafe to buy coffee. Typically, because he has historically purchased 6 almond buns in an accumulation, today the Tereon system typically provides a free almond buns to the user and the cafe uses the Tereon push offer (offer) to the customer. However, when the user's son enters his PIN, the Tereon system detects that the person being paid is the user's son (which does not know the father's PIN), and because the son is allergic to nuts, thus preventing today's proposal (offer), the father has linked the son's PIN to his son's profile. The merchant did not see any notice about the free almond croissants and Tereon knows that the user's son could not eat nuts. Whereas the merchant can see only payment for a cup of coffee.

The user also allows the son to withdraw cash up to 10 pounds, but is unable to deposit funds. Thus, when the user's son enters a business that can provide withdrawals of up to 10 pounds, he will see the options on the business's terminal.

In addition to access control, context-based security provides further functionality. Depending on the context in which the user proposes or uses the device, the device will only provide the credentials necessary for the context; it becomes a "psychrometric sensing paper". In this way, directory service 216 provides functionality that may support context-based security.

Context-based security does not require separate credentials and devices to be provided for a particular context. The single device can now be a library card voucher for a library, a transportation ticket on a bus or train, a security key for entering and exiting a room or facility, an internal payment device for a corporate canteen, a theatre ticket, a standard payment device for a supermarket, a driver license, a NHS card, a certification to be entitled to a service ID card, and if desired, a photo ID can be displayed at a merchant device, etc.

Since Tereon provides dynamic, real-time transaction and settlement, an administrator or user can modify, extend, and even cancel the allowed contexts or credentials in real-time. The modification is reflected immediately in the teleon server providing the service or the look-up directory service 216, or both. The lost device no longer has a period of risk of causing financial or identity exposure. The change will take effect immediately once the user or administrator cancels or modifies the credential or background.

One-touch transaction

The Tereon realizes one-key transaction authorization and access method, and eliminates the security defect in the existing system. For example, no PIN or NFC payment is currently very dangerous because no authentication is provided. The user is still responsible for all payments until the card issuing authority cancels the phone or card credentials of the contactless EMV system. Even if the issuer cancels the device, the customer still has to try to prove that he does not activate the payment. How does a customer prove if payment never requires PIN authentication? This leaves a tremendous vulnerability that allows anyone to pick up contactless cards or phones and make payments by simple touch. The device remains active until the device is disabled.

The Tereon supports inductive (tap-and-go) payments in one of three modes, each depending on the operating context. One of these modes provides a one-touch transaction that uses one method to identify individuals. If both the user and the service provider agree that the provided authentication level is satisfactory, the system will provide a one-touch authentication method, i.e. the device will display a large button on the screen, or configure a large area for the user to touch. Other modes are completely non-touch modes, such as an existing contactless transaction in which the user does not enter credentials, and a mode in which the user enters his or her standard payment credentials after the devices recognize each other.

The button or region itself provides authentication through the touch screen. Each person presses the screen in a unique way, depending on both the location of the press and the pattern of presses (pressure pattern) they use. If the individual intends to use this function, the Tereon will require the individual to press a button or area multiple times until the individual's signature is learned. The screen is logically divided into discrete cells, and Tereon will see the proximity and pattern of cells the user touches during training, and possibly also the pressure pattern when the user presses the screen and any device movements. It will use and monitor the data to construct a profile that is used to authenticate the user.

Fig. 21 is a block diagram illustrating an embodiment of a computing device 2100 in which a set of instructions may be executed in the computing device to cause the computing device to perform any one or more of the methods discussed herein. In alternative implementations, the computing device may be connected (e.g., networked) to a Local Area Network (LAN), an intranet, an extranet, or other device in the internet. The computing devices operate in a client-server network environment at the capacity of a server or client, or as peers in a point-to-point (or distributed) network environment. The computing device may be a Personal Computer (PC), a tablet computer, a set-top box (STB), a Personal Digital Assistant (PDA), a mobile telephone, a network device, a server, a network router, switch or bridge, a processor, or any machine capable of executing a set of instructions (sequential or otherwise) that specify operations to be taken by that computer. Furthermore, while only a single computing device is illustrated, the term "computing device" shall also be taken to include any collection of machines (e.g., computers) that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example computing device 2100 includes a processing device 2102, a main memory 2104 (e.g., read Only Memory (ROM), flash memory, dynamic Random Access Memory (DRAM) such as Synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory 2106 (e.g., flash memory, static Random Access Memory (SRAM), etc.), and a secondary memory (e.g., data storage device 2118) in communication with each other via a bus (bus) 2130.

The processing device 2102 represents one or more general-purpose processors, such as a microprocessor, central processing unit, or the like. In particular, the processing device 2102 may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, a processor implementing other instruction sets, or a processor implementing a combination of instruction sets. The processing device 2102 may also be one or more special purpose processing devices such as an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), a network processor, or the like. The processing device 2102 is configured to execute processing logic (instructions 2122) to perform the operations and steps herein.

The computing device 2100 may further include a network interface device 2108. The computing device 2100 may also include a video display unit 2110 (e.g., a Liquid Crystal Display (LCD) or Cathode Ray Tube (CRT)), an alpha and numeric input device 2112 (e.g., a keyboard or touch screen), a cursor control device 2114 (e.g., a mouse or touch screen), and an audio device 2116 (e.g., a speaker).

The data storage 2118 may comprise one or more computer-readable storage media (or more specifically, one or more non-transitory computer-readable storage media) 2128 on which are stored one or more sets of instructions 2122 embodying one or more of the methods or functions herein. The instructions 2122 may also reside, completely or at least partially, within the main memory 2104 and/or within the processing device 2102 during execution thereof by the computer system 2100, the main memory 2104 and the processing device 2102 also constituting computer-readable storage media.

The various methods as above may be implemented by a computer program. The computer program comprises computer code for instructing a computer to perform the functions of one or more of the various methods described above. The computer program and/or code for performing the method can be provided on an apparatus, such as a computer, one or more computer readable media, or more generally, a computer program product. The computer readable medium may be transitory or non-transitory. The one or more computer-readable media may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, or a propagation medium for data transmission, e.g., for downloading code over the internet. Alternatively, the one or more computer-readable media may take the form of one or more physical computer-readable media such as semiconductor or solid state memory, magnetic tape, removable computer diskette, random Access Memory (RAM), read-only memory (ROM), rigid magnetic disk and optical disk such as CD-ROM, CD-R/W or DVD.

In an embodiment, the modules, components, and other features herein may be implemented as discrete components or integrated as part of a personalization server in the functionality of a hardware component, such as ASIC, FPGA, DSP or similar device.

A "hardware component" is a tangible (e.g., non-transitory) physical component (e.g., a set of one or more processors) that is capable of performing certain operations and is configured in a manner that is a certain entity. A hardware component may include specialized circuitry or logic permanently configured to perform certain operations. The hardware component may be or include a special purpose processor such as a Field Programmable Gate Array (FPGA) or ASIC. A hardware component may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations.

Thus, the term "hardware component" should be understood to include tangible entities that may be physically constructed, permanently configured (e.g., hard wired), or temporarily configured (e.g., programmed) to perform in some manner, or to perform certain operations herein.

For example, the machine may be a physical machine, a logical machine, a virtual machine, a container, or any other commonly used mechanism for containing executable code. The machine may be a single machine, or it may be multiple machines connected or distributed, whether or not the machines are of the same type or of multiple types.

Furthermore, the modules and components may be implemented as firmware or functional circuitry within a hardware device. Further, modules and components may be implemented in any combination of hardware devices and software components, or in software alone (e.g., code stored or otherwise embodied in a machine readable medium or transmission medium).

Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "transmitting," "receiving," "determining," "comparing," "allowing," "maintaining," "identifying," or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data represented as physical quantities within the computer system's registers or memories, or other information storage, transmission or display devices.

It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other implementations will be apparent to those of skill in the art upon reading and understanding the above description. Although the invention has been described with reference to specific embodiments, it is to be understood that the invention is not limited to the described embodiments, but may be modified and varied within the spirit and scope of the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It is therefore intended that the following claims be interpreted with reference to the full scope of equivalents to which such claims are entitled.

All optional features of the various aspects refer to all other aspects. Variations can be made to the described embodiments, for example, the features of the disclosed embodiments can be combined in any way.

Claims

1. A data transaction recording method, comprising: when a first data transaction occurs between a first entity and a second entity, at an apparatus associated with the first entity:

determining first seed data;

determining second seed data by combining at least the first seed data and a record of the first data transaction when the first data transaction occurs between the first entity and the second entity;

generating a first hash by hashing the second seed data, the first hash comprising a history of data transactions involving the first entity, wherein generating the first hash is concurrent with completing the first data transaction; and

the record of the first data transaction and the first hash of the record of the first data transaction are stored in memory simultaneously.

2. The method of claim 1, wherein,

the first seed data includes a starting hash.

3. The method of claim 2, wherein,

The starting hash is a result of a hash operation on a record of a previous data transaction relating to the first entity.

4. The method of claim 2, wherein,

the starting hash comprises a random hash.

5. The method of claim 4, wherein,

the random hash includes at least one of a signature from the device, a date and/or time the random hash was generated.

6. The method according to any of the preceding claims, wherein,

providing the second seed data further includes:

combining a first zero-knowledge proof and a second zero-knowledge proof with the first seed data and the record of the first data transaction, wherein,

the first zero-knowledge proof comprises a proof that the initial hash comprises a true hash of a previous data transaction involving the first entity; and

the second zero-knowledge proof comprises a proof that the second hash comprises a true hash of a previous data transaction involving the second entity.

7. The method of claim 6, wherein,

providing second seed data, further comprising:

combining a third zero-knowledge proof with the first seed data, the record of the first data transaction, the first zero-knowledge proof, and the second zero-knowledge proof.

8. The method of claim 7, wherein,

the third zero-knowledge proof is generated from random data.

9. The method of claim 7, wherein,

the third zero-knowledge proof is a repetition of the first zero-knowledge proof or the second zero-knowledge proof.

10. The method of claim 7, wherein,

the third zero-knowledge proof is constructed using a second record of the first data transaction corresponding to the second zero-knowledge proof.

11. The method of claim 6, wherein,

the first data transaction includes at least two phases, and providing second seed data includes:

combining the first zero-knowledge proof with a record of a first phase of the first data transaction; and

combining the second zero-knowledge proof with a record of a second phase of the first data transaction.

12. The method of claim 11, wherein,

providing the second seed data includes:

constructing a third zero-knowledge proof from the record of the second phase of the first data transaction; and

the second zero-knowledge proof and the third zero-knowledge proof are combined with the record of the second phase of the first data transaction.

13. The method of claim 11, wherein,

the first data transaction includes at least three phases,

and providing the second seed data further comprises:

combining the first zero-knowledge proof with a record of a third phase of the first data transaction; and

combining the second zero-knowledge proof with the record of the third phase of the first data transaction.

14. The method of claim 11, wherein,

the first data transaction includes at least three phases,

and providing the second seed data further comprises:

combining the second zero-knowledge proof with random data.

15. The method of claim 11, wherein,

the first data transaction includes at least three phases,

and providing the second seed data further comprises:

combining the second zero-knowledge proof with a record of a fourth phase of the first data transaction;

wherein the fourth phase of the first data transaction is a repetition of the third phase of the first data transaction.

16. The method of claim 11, wherein,

the first data transaction includes at least three phases,

and providing the second seed data further comprises:

combining a third zero knowledge proof with a record of a third phase of the first data transaction.

17. The method of claim 6, wherein,

18. The method of claim 17, wherein,

constructing the first zero-knowledge proof and the second zero-knowledge proof includes using a key exchange algorithm.

19. The method of claim 18, wherein,

the key exchange algorithm includes a PAKE algorithm.

20. The method of claim 1, further comprising:

transmitting the first hash to a device associated with the second entity;

receiving a second hash from an apparatus associated with the second entity, wherein the second hash comprises a hash of a previous data transaction involving the second entity; and

generating a record of a second data transaction between the first entity and the second entity;

Determining third seed data by combining the record of the second data transaction with the first hash and the second hash;

generating a third hash by hashing the third seed data, the third hash comprising a history of data transactions involving the first entity and a history of data transactions involving the second entity; and

the third hash of the record for the second data transaction is stored in the memory.

21. The method of claim 20, wherein,

providing the third seed data further includes:

combining a third zero-knowledge proof and a fourth zero-knowledge proof with the record of the second data transaction, the first hash, and the second hash, wherein

The third zero-knowledge proof comprises a proof that the first hash comprises a true hash of the first data transaction; and

the fourth zero-knowledge proof comprises a proof that the second hash comprises a true hash of the previous data transaction involving the second entity.

22. The method of claim 20, wherein,

the previous data transaction involving the second entity is the first data transaction.

23. The method of claim 1, further comprising:

each of the hashes is associated with an identifier of the first entity and/or the second entity.

24. The method of claim 1, further comprising:

recalculating the first hash; and

the generated first hash is compared to the recalculated second hash to determine a match.

25. The method of claim 24, further comprising:

when the comparison is unsuccessful, further data transactions are canceled.

26. The method of claim 1, further comprising:

a system hash corresponding to the first data transaction is generated at a system device.

27. The method according to claim 26, wherein:

providing the second seed data further includes:

the system hash is combined with the record of the first seed data and the first data transaction.

28. The method of claim 26, wherein,

the system hash is a result of a hash operation performed on a record of a previous data transaction on the system device.

29. The method of claim 1, wherein,

providing second seed data, further comprising:

receiving a license hash from a licensing device; and

The license hash is combined with the first seed data and the record of the first data transaction to provide the second seed data.

30. The method of claim 29, further comprising: at the licensing means:

receiving the first hash;

combining the first hash with the license hash to provide a license input;

and generating a second license hash by carrying out hash operation on the license input.

31. The method of claim 1, wherein,

providing second seed data, further comprising:

receiving a directory hash from a directory means; and

the directory hash is combined with the first seed data and the record of the first data transaction to provide the second seed data.

32. The method of claim 31, further comprising: at the directory server:

receiving the first hash;

combining the first hash with the directory hash to provide a directory input;

and generating a second directory hash by carrying out hash operation on the directory input.

33. The method of claim 1, wherein,

providing second seed data, further comprising:

generating a key hash from an encryption key for the first data transaction; and

The key hash is combined with the first seed data and the record of the first data transaction to provide the second seed data.

34. The method according to claim 33, wherein:

the encryption key includes a public key or a private key.

35. The method of claim 1, wherein,

upon completion of the first data transaction, a combination of the first seed data and the record of the first data transaction is performed.

36. The method of claim 1, wherein,

the memory is located at a remote device.

37. The method of claim 36, further comprising:

at the remote device, the first hash is compared with corresponding hashes received from other devices.

38. The method of claim 36, further comprising:

other devices connected to the device are notified to expect to receive the first hash.

39. The method of claim 1, further comprising:

the hash chain is stored in the memory.

40. The method of claim 39, further comprising:

the hash chain is transferred to a second memory located on a device configured to restrict access to the transferred hash chain.

41. The method of claim 39, further comprising:

modifying or deleting a hash in the hash chain by:

regenerating object hash in the hash chain;

confirm that the record is not modified;

recording the regenerated hash;

modifying or deleting the record;

generating a new hash for the record by hashing the combination of the object hash and the modified/deleted record; and

recording the new hash.

42. The method of claim 41, further comprising:

and generating system hashes by using the new hashes.

43. An apparatus associated with a first entity, the apparatus comprising a processor configured for performing the method of any of the preceding claims.

44. The apparatus of claim 43, wherein,

the apparatus includes a server.

45. The apparatus of claim 43, wherein

The device comprises a user device.

46. The apparatus of claim 45, wherein,

the user device comprises at least one of a personal computer, a smart phone, a smart tablet computer, or a device that can implement the internet of things.

47. The apparatus of claim 46, wherein,

the user device is to store the first hash in a memory on the device.

48. The apparatus of claim 47, wherein,

the user device stores the first hash in memory on the device only when it is offline from the corresponding server.

49. The apparatus of any one of claims 43 to 48,

the apparatus is further configured to transmit the first hash to an apparatus associated with the second entity.

50. An apparatus according to claim 49,

the apparatus is further configured to transmit a signed, encrypted copy of the record of the first data transaction to the apparatus associated with the second entity, wherein the signature includes an indication of a destination server for the record.

51. The apparatus of claim 50, wherein,

the apparatus is for signing the record with a specific offline public key.

52. The apparatus of claim 50, wherein,

the device is configured to sign the record using a key belonging to the device.

53. The apparatus of any one of claims 50 to 52, wherein,

Only the destination server is able to decrypt the encrypted copy of the record of the first data transaction.

54. The apparatus of claim 48, wherein,

the apparatus is configured to: when the device resumes connection with its corresponding server, the encrypted record of its offline data transaction and the associated hash are transferred to its corresponding server.

55. The apparatus of claim 54, wherein,

the apparatus is further for transferring a copy of its saved record of data transactions involving other entities to its corresponding server for transmission to the server corresponding to the other entity.

56. The apparatus of claim 55, wherein,

the sending includes notifying all servers to which the record applies to expect to receive the record.

57. The apparatus of claim 43, wherein,

the apparatus is configured to generate a unique internal transaction number to identify a portion thereof in the first data transaction.

58. A licensing apparatus, comprising:

a transceiver configured to:

receiving a first hash from an apparatus associated with a first entity, the first hash comprising a history of data transactions involving the first entity, wherein the first hash is generated while the data transactions are completed and a record of the first hash is stored concurrently with a record of the data transactions; and

A processor connected with the transceiver and the processor, and configured to:

combining the first hash with a license hash to provide a license input;

generating a second license hash by hashing the license input; and

the second license hash is stored in a memory.

59. A directory apparatus comprising:

a transceiver configured to:

combining the first hash with a directory hash to provide a directory input;

generating a second directory hash by performing a hash operation on the directory input; and

the second directory hash is stored in a memory.

60. A computer readable medium comprising an encoded portion that, when executed, causes a computing device to perform the method of any of claims 1-42.