ZONES

BACKGROUND

[0001] Consumers are conducting electronic transactions with increasing frequency. Because of fraudulent individuals who are able to obtain financial information about the consumer and their financial accounts, the consumer is at risk for having such fraudulent individual access and steal their assets and/or personal information using fraudulent electronic transactions. Accordingly, there is a need in the arts to thwart the fraudulent individual’s attempt to obtain such consumer identity and account information.

SUMMARY

[0002] Systems and methods of providing secure electronic-based transactions to a consumer are disclosed. An exemplar embodiment employs a system that compares a distance between a determined location of a personal electronic device of the consumer with the location of an electronic transaction. An example embodiment accesses a predefined distance. This predefined distance may be represented as a radius, or a secured zone, around the personal electronic device of the consumer. Then, if the determined location of the electronic transaction is within the predefined distance from (within the secured zone ol) the personal electronic device of the consumer, the electronic transaction is permitted.

[0003] Alternatively, or additionally, a predefined location is associated with the predefined distance. An exemplary embodiment employs a system that compares a distance between the predefined location with the location of the electronic transaction. Then, if the determined location of the electronic transaction is within the predefined distance from (within the secured zone of) the predefined location, the electronic transaction is permitted.

[0004] In some embodiments, the predefined distance is stored securely in blockchain information that is uniquely associated with the particular consumer who is accessing their financial information to conduct an electronic transaction. Since a blockchain is not accessible by a fraudulent individual, the fraudulent individual will never have access to the predefined distance that is necessary for verification of the electronic transaction. Various other information that may be used to verify an electronic transaction may optionally be secured within the consumer’s blockchain information.

[0005] The predefined distance is a variable value that can be user-defined. For example, if the consumer is travelling in a foreign country, the consumer may choose to decrease the length of the predefined distance for the duration of their travels. Thus, the consumer can feel that any electronic transactions that they perform, such as accessing an automated teller machine (ATM) for cash in the local country currency, may be performed in a secure and reliable manner. Further, in the event that their ATM card is lost or stolen, they will appreciate that their card will be impossible to use for a fraudulent electronic transaction. Further, in the event of a lost or stolen ATM card, the consumer can immediately modify the predefined distance that has been securely stored in their blockchain information to a different predefined distance, such as a few inches or feet, or even no distance. (Then, if their misplaced ATM card is later found by the consumer or if their lost ATM card is returned to the consumer, the consumer can again change and securely store the predefined distance into their secure blockchain information so that they may continue to user their ATM card.)

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Example embodiments are described in detail below with reference to the following drawings:

[0007] FIGURE 1 is a block diagram of an embodiment of a transaction authorization system; and

[0008] FIGURE 2 is a block diagram of another embodiment of a transaction authorization system;

[0009] FIGURE 3 is a block diagram of another embodiment of a transaction authorization system;

[0010] FIGURE 4 is an example graphical user interface (GUI) that may be presented to the consumer during the transaction verification and authorization process;

[0011] FIGURE 5 is a map-based version of a presented GUI; and

[0012] FIGURE 6 is a block diagram of an example transaction authorization system.

[0013] FIGURE 7 is an example flow diagram of an overview of the logic described herein for conducting a transaction using secured zones as conducted by an electronic transaction verification sy stem.

DETAILED DESCRIPTION

[0014] FIGURE 1 is a block diagram of an embodiment of a transaction authorization system 100. The non-limiting illustrated embodiment of the transaction authorization system 100 comprises at least one electronic transaction verification system 102 that is in communication with a electronic mobile device 104 that is presumably in the personal possession of a consumer conducting an electronic transaction and that is in communication with an electronic transaction device 106.

[0015] The electronic transaction verification system 102 manages consumer blockchain information 108 that is uniquely associated with the consumer who is conducting the electronic transaction. The blockchain information 108 is conceptually illustrated as residing in a single block. One skilled in the art understands that in practice, the consumer blockchain information 108 resides in a distributed system of other electronic devices that are communicatively coupled to the electronic transaction verification system 102 via the communication network 110. When a transaction verification and authorization process is underway, the electronic transaction verification system 102 accesses these distributed locations so that the particular consumer information residing in the consumer blockchain information 108 may be accessed and used for transaction verification and authorization.

[0016] Further, the electronic transaction verification system 102, during any particular electronic transaction, manages the verification process whereby an ongoing electronic transaction is verified and/or is authorized for the consumer. In practice, the electronic transaction verification system 102 manages consumer blockchain information for thousands of, or more, individual consumer. Embodiments of the transaction authorization system 100 has the capability of concurrently managing the transaction verification and authorization process for thousands of, or more, electronic transactions.

[0017] The electronic transaction verification system 102 and the consumer’s electronic mobile device 104 are communicatively coupled together via the communication system 110. The electronic transaction device 106 is also communicatively coupled to the electronic transaction verification system 102. Here, there is no need for the electronic transaction device 106 to be communicatively coupled to the electronic mobile device 104. Further, if the consumer is using an optional transaction device 112, such as an ATM card or the like, to facilitate the electronic transaction, the transaction device 112 does not need to be communicatively coupled to the consumer’s electronic mobile device 104 or to the electronic transaction verification system 102 for completion of the transaction verification and authorization process. Such embodiments are inherently less complicated in architecture and/or operation and may be implemented at a lower cost.

[0018] During a transaction, location information defining the location of the electronic mobile device 104 is determined and is communicated to the electronic transaction verification system 102. Also, location information defining the location of the electronic transaction device 106 is determined and is communicated to the electronic transaction verification system 102. Alternatively, or additionally, identity information that identifies the electronic transaction device 106 may be used to access a database wherein the location information of the electronic transaction device 106 may be accessed and then provided to the electronic transaction verification system 102.

[0019] Once the locations of the electronic mobile device 104 and the electronic transaction device 106 are determined, the electronic transaction verification system 102 determines a distance between the electronic mobile device 104 and the electronic transaction device 106. The electronic transaction verification system 102 then compares the determined distance between the electronic mobile device 104 and the electronic transaction device 106 with a predefined distance, interchangeably referred to herein as a secured zone. If the determined distance between the electronic mobile device 104 and the electronic transaction device 106 is less than or equal to the predefined distance, then some embodiments of the transaction authorization system 100 determine that the electronic transaction may be verified and/or authorized. In some embodiments, if the transaction authorization system 100 determines that that the determined distance is not less than or equal to the predefined distance, then transaction authorization may be withheld, may be delayed, and/or may be conditional upon an explicit authonzation from the consumer.

[0020] The location of the electronic mobile device 104 may be monitored on a real time basis. Accordingly, as the consumer moves from one location to another, the secured zone effectively moves along with the changing location of the consumer and is thus dynamic.

[0021] The predefined distance, in some embodiments, is securely stored as part of the consumer blockchain information 108. During the transaction verification and authorization process, the electronic transaction verification system 102 accesses this secure predefined distance. In some embodiments, the consumer has to authorize the electronic transaction verification system 102 to access the predefined distance from their secure consumer blockchain information 108 during the electronic transaction.

[0022] FIGURE 1 illustrates that the electronic mobile device 104 is in communication with (is communicatively coupled to) the communication network 110 via a wireless signal 114. For example, the electronic mobile device 104 may be communicatively coupled to a cell tower of a wireless system. As another non-limiting example, the electronic mobile device 104 may be communicatively coupled to a Wi-fi node that is part of the communication network 110. In other situations, the electronic mobile device 104 may be communicatively coupled to the communication network 110 via a wire-based connector, such as when the electronic mobile device 104 is a personal computer, laptop device, personal assistant or the like where the consumer is using the wire connector to connect their electronic mobile device 104 to the communication network 110.

[0023] FIGURE 1 further illustrates that the electronic transaction device 106 is in communication with (is communicatively coupled to) the communication network 110 via a wireless signal 116. In other situations, the electronic transaction device 106 may be communicatively coupled to the communication network 110 via a wire-based connector, such as when the electronic transaction device 106 is part of a networked system that is managed and controlled by a financial institution or other institution.

[0024] The communication network 110 is illustrated as a generic communication system. In one embodiment, the communication network 110 comprises a cellular telephone system, such as a radio frequency (RF) wireless system. Accordingly, the electronic mobile device 104 and/or the electronic transaction device 106 includes a suitable transceiver. Alternatively, the communication network 110 may be a telephony system, the Internet, a Wi-fi system, a microwave communication system, a fiber optics system, an intranet system, a local access network (LAN) system, an Ethernet system, a cable system, a radio frequency system, a cellular system, an infrared system, a satellite system, or a hybrid system comprised of multiple types of communication media. Additionally, embodiments of the transaction authorization system 100 may be implemented using other types of communication technologies, such as but not limited to, digital subscriber loop (DSL), X.25, Internet Protocol (IP), Ethernet, Integrated Services Digital Network (ISDN) and asynchronous transfer mode (ATM). Also, embodiments of the transaction authorization system 100 may be configured to communicate over combination systems having a plurality of segments which employ different formats for each segment that employ different technologies on each segment.

[0025] In operation, the consumer initiates an electronic transaction at the electronic transaction device 106. The electronic transaction device 106 communicates with the electronic transaction verification system 102 to initiate the transaction verification and authorization process. Alternatively, or additionally, the transaction verification and authorization process may be initiated by the consumer who uses their electronic mobile device 104 to start the electronic transaction. [0026] Then, in an example embodiment, the electronic transaction verification system 102 is provided and/or obtains location information that defines the location of the electronic transaction device 106, and therefore that defines the location of the ongoing electronic transaction. Then, the electronic transaction verification system 102 accesses or obtains current location information (in real time or near-real time) for the consumer’s electronic mobile device 104. Presumably, the consumer is in the immediate vicinity of and/or is in possession of their electronic mobile device 104. If the determined distance between the electronic mobile device 104 and the electronic transaction device 106 is within the predefined distance, then embodiments of the transaction authorization system 100 may infer that the consumer is the authorized person who is conducting the ongoing electronic transaction. Therefore, the electronic transaction may then be permitted to go to completion by the transaction authorization system 100.

[0027] On the other hand, if the determined distance between the electronic mobile device 104 and the electronic transaction device 106 is greater than the predefined distance, then embodiments of the transaction authorization system 100 may infer that the consumer is not the person who is conducting the ongoing electronic transaction. That is, embodiments may infer that a fraudulent individual is attempting to conduct the electronic transaction. Therefore, the electronic transaction may then be prevented from going to completion by the transaction authorization system 100.

[0028] In the various embodiments, the consumer has the ability to control the value of the predefined distance that is used during the transaction verification and authorization process. The user may specify this value, in any suitable metric, prior to the initiation of the electronic transaction. The user-defined predefined distance may be expressed as a radius distance. Here, the distance between a determinable location of the electronic transaction device 106 and the electronic mobile device 104 is readily comparable to a radius distance value.

[0029] In some embodiments, the consumer is permitted to enable or disable operation of the transaction authorization system 100. Alternatively, or additionally, the consumer may be allowed to activate or deactivate the security zone. Here, the transaction verification and authorization process may be based on other or additional information, such as the secure information residing in the consumer blockchain information 108.

[0030] Alternatively, or additionally, the predefined distance may be specified by any authorized third part)'. For example, a particular predefined distance may be specified by a credit card company for credit card-based electronic transactions. Here, if the consumer is using their credit card for an electronic transaction, the predefined distance specified by the credit card company is used during the transaction verification and authorization process. If another type of financial instrument is used by the consumer, a different predefined distance is used for the transaction verification and authorization process.

[0031] Alternatively, or additionally, other geometry forms may be used define the predefined distance. For example, a square, an oval, or other geometric shape, or polygon may be used. An outline of a know n structure, such as a shopping mall or other location where an electronic transaction is likely to occur, may be used. In some embodiments, a plurality of different predefined distances may be used, wherein one of a plurality of predefined distances is selected depending upon the particular situation of the electronic transaction. For example, but not limited to, a radius value may be used when the consumer is conducting the electronic transaction at an ATM device. In a situation where the consumer is at a shopping mall, the predefined distance defined by the extents of the shopping mall may be used to verily and authorize point of purchase transaction occurring within the shopping mall. Any suitable geometry that defines the predefined distance are contemplated by the various embodiments.

[0032] FIGURE 2 is a block diagram of another embodiment of a transaction authorization system. One skilled in the art appreciates that the actual location of the consumer’s electronic mobile device 104 may not be determinable or may not be determinable with any reliable degree of accuracy. However, the electronic mobile device 104 may be in communication with another intermediate device 202 wherein the location of that device is known and/or is determinable. For example, the electronic mobile device 104 may be wirelessly communicating with a cell phone tower, a Wi-fi node, or the like (the intermediate device 202) via wireless signal 204. The intermediate device 202 may then use a wireless signal 206 (or a wire-based connector) to communicatively couple the electronic mobile device 104 to the communication network 110.

[0033] Here, since the electronic mobile device 104 is communicatively coupled to the electronic transaction verification system 102 via the intermediate device 202, and since the location of the intermediate device 202 is known and/or may be determinable, the location of the intermediate device 202 may be used as a proxy location for the consumer and/or for the consumer’s electronic mobile device 104 for the transaction verification and authorization process. [0034] Further, in some embodiments, once the nature or characteristic of the intermediate device 202 is determined, a different predefined distance may be used to perform the transaction verification and authorization process. For example, the electronic mobile device 104 may be provisioned with a global positioning system (GPS) that can be used to precisely determine the location of the electronic mobile device 104. However, at times, the GPS system may be turned off, may be inactive, or may be inoperable. In such a situation, since the exact location of the electronic mobile device 104 cannot be obtained from the onboard GPS, then a proxy location can be determined from the location of the intermediate device 202. To illustrate, the consumer may be travelling in an automobile, an aircraft or other vehicle where determination of a location of the electronic mobile device 104 is not practical. The transaction may be occurring at an electronic transaction device 106 that is part of the vehicle. When then transaction authorization system 100 determines that the ongoing transaction is occurnng, and that the location of the consumer is being approximated by the determined proxy location of the intermediate device 202, then a different predefined distance may be used for the transaction verification and authorization process. For example, if the intermediate device 202 is a cell tower, the predefined distance may need to be adjusted and enlarged as compared to situations where the location of the transaction authorization system 100 can be accurately determined. In the case of an aircraft, a relatively small predefined distance may be used as compared to the predefined distance that is used to verify and authenticate an ATM or point of purchase transaction since a reasonable inference may be made that the consumer is on board the aircraft. Conversely, if the consumer’s electronic mobile device 104 does not have an operable GPS, a relatively large predefined distance may be used as compared to the predefined distance that is used to verify and authenticate an ATM or point of purchase transaction.

[0035] In some situations, the electronic transaction verification system 102 may be in communication with the electronic mobile device 104. The consumer may use a suitable secure interface to specify their current location as the proxy location for their electronic mobile device 104. Preferably, in such situations, additional levels of security and/or authorization (such as personal identification numbers, pins, passwords, and other forms for identity verification) are used to ensure that the user-specified proxy location is not being provided by a fraudulent individual.

[0036] FIGURE 3 is a block diagram of another embodiment of a transaction authorization system. In this example non-limiting embodiment, a known location is used as the proxy location for the transaction verification and authorization process. Here, the known location is compared with the determined location of the electronic transaction device 106. For example, the consumer may be at a shopping mall or other location, area, geographic region, or the like. To illustrate, the user may be attempting to obtain cash at an ATM, may be attempting to make a payment or obtain cash at a bank, and/or may be attempting to purchase a product or service at a store (interchangeably referred to herein in as a point of purchase transaction). As another example, the consumer may be at an event (such as a stadium, a farmer’s market, or other venue) where a vendor is using a portable electronic transaction device 106 to conduct the electronic transaction.

[0037] Embodiments of the transaction authorization system 100 determine a location proximate to the ongoing electronic transaction that is associated with a known location 302. The known location 302 is associated with a predefined distance. The transaction verification and authorization process may then be performed based on the known location, the associated predefined distance, and the determined location of the electronic transaction device 106.

[0038] FIGURE 7 is an example flow diagram of an overview of the logic described herein for conducting a transaction using secured zones as conducted by an electronic transaction verification system such as site 102 in FIGURE 1. In block 701, the logic receives notification of an initiated consumer transaction such as initiated at electronic transaction device 106 or by the consumer’s electronic mobile device 104. In block 702, the logic determines a location of the electronic mobile device or a proxy for this device if, for example, a location of the mobile device 104 is not accessible or cannot be determined accurately. This location may be a known location (such as a shopping mall) or an intermediate device location such as a cellular network tower.

[0039] In block 703, the logic of the transaction verification system determines a predefined distance between the device (or its proxy, including a known location) and the transaction device. In example embodiments, determining this predefined (consumer specific) distance is accomplished using block chain information that is specific and private to the consumer, i.e., secure, such as described in detail in U.S. Patent Application Number 16/660,759, filed October 22, 2019, entitled “APPARATUS, SYSTEMS AND METHODS FOR STEMMED BLOCKCHAIN OPERATION WITH SECURED PARTICIPANT IDENTIFIERS,” which is incorporated here by reference in its entirety. Other blockchain systems and protocols may be similarly incorporated. [0040] In block 704, the secured zone (the predefined distance) may be modified by the consumer or by the transaction verification system. For example, the secured zone may be made smaller or enlarged based upon data such as the nature of the transaction device, the type of transaction, the location or nature or characteristic of the known location or intermediate device, and the like. In addition, the secured zone may be adjusted at other times such as “on demand” by the consumer, at set times, or by the transaction verification system itself.

[0041] In block 705 the logic determines whether the determined location of the device or its proxy is within the determined secured zone (the predefined distance). If so, the transaction is authorized in block 706. If not, the transaction is rejected in block 707, and the verification system may notify the consumer. Alternatively, the transaction may be “suspended” until the consumer is able to verify it by some alternative means.

[0042] In an example embodiment, the consumer may initiate a communication with the electronic transaction verification system 102 and specify their current location and/or specify the known location. For example, the consumer may indicate that they are in a particular venue such as a stadium. As another non-limiting example, the consumer may specify that they are currently in a particular city, town, or other identifiable region. The user- specified location may then be used for any occurring electronic transactions while the consumer is at or is nearby the user-specified location. Preferably, in such situations, additional levels of security and/or authorization (such as personal identification numbers, pins, passwords, or answers to particular questions) are used to ensure that the user-specified proxy location is not being provided by a fraudulent individual.

[0043] Alternatively, or additionally, information pertaining to past electronic transactions that have been previously verified and authorized is stored within the secure blockchain information 108. After some duration, embodiments of the transaction authorization system 100 may leam that the consumer is frequently located at a particular known location. One skilled in the art appreciates that there are likely to be a plurality of such known locations that the consumer frequents. Once the location of the electronic transaction device 106 is determined, the determined location of the electronic transaction device 106 can be compared with the plurality of known locations that the consumer is frequently at. Since the consumer blockchain information 108 is secure, it is not possible for a fraudulent individual access the secure consumer blockchain information 108 to leam about these known locations that are associated with the consumer. [0044] As noted herein, the predefined distance may be represented using any suitable geometry. For example, if the known location 302 is associated with a building or other predefined region, the predefined distance may be represented using the geometry of the known location. For example, but not limited to, if the known location is a building that has one or more stores or is a field where a farmer’s market in typically held, the predefined distance may be represented using a rectangle 304. Any suitable geometry may be used for the predefined distance that is associated with a known location.

[0045] FIGURE 4 is an example graphical user interface (GUI) 402 that may be presented to the consumer during the transaction verification and authorization process. In this non-limiting example of an ongoing transaction verification and authorization process, the consumer receives a message from the electronic transaction verification system 102 that is presented on a display 404 of their electronic mobile device 104, here conceptually illustrated as the well-known cell phone or smart phone. The GUI 402 indicates that an electronic transaction is occurring, presents information about the transaction, and a provides a query requesting that the user authenticate the transaction and/or to take immediate security measures in the event that they are not conducting the electronic transaction. Any suitable GUI 402 that communicates information to the consumer during an ongoing electronic transaction is contemplated by the various embodiments.

[0046] In some embodiments, if a particular electronic transaction is denied by the transaction authorization system 100, an alarm or other suitable notification is sent to the consumer’s electronic mobile device 104 or another device that is being used by or that is accessible to the consumer. Accordingly, the consumer may be informed that a potentially fraudulent electronic transaction has been denied, and that they should take corrective and/or precautionary actions to safeguard their property. Any suitable visual, haptic, and/or auditory warning or alarm may be generated and communicated to the consumer’s electronic mobile device 104 or another suitable device. Further, the warning or alarm can be communicated to other entities, such as a bank or other financial intuitions, or even the consumer’s spouse, friend or other close personal contact.

[0047] The GUI 402 is configured to permit the consumer to input any information back to the electronic transaction verification system 102 via actuation of one or more of the controllers 406 residing on the surface of the electronic mobile device 104. Any suitable GUI 402 that enables the consumer to input information during an ongoing electronic transaction is contemplated by the various embodiments. Some embodiments may require the consumer to input confidential and secret information that is known only to the consumer. Information corresponding to or matching with the input provided by the consumer may be securely stored in the consumer blockchain information 108. In response to receiving the information from the consumer, the electronic transaction may then be verified and/or authenticated, thereby permitting the electronic transaction to move to completion.

[0048] In the various embodiments, the electronic transaction device 106 was generically and conceptually described as a device that the consumer is interacting with or is using to conduct an electronic transaction. Embodiments of the transaction authorization system 100 are configured to facilitate electronic transactions with any electronic transaction device now known or later developed. Non-limiting example of electronic transaction devices 106 include automatic payment systems such as toll road collection points, an Internet of things (IoT) device, a credit card reader, a robot device, an artificial intelligence (AI) device, or even a web site. The various electronic transaction devices 106 may be stationary in a fixed location or may be mobile.

[0049] For example, the consumer may wish to make an electronic transaction for payment of a house mortgage or automobile payment to their local bank. In one instance, the consumer may go to the local bank and use one of their automated devices to conduct the electronic transaction payment. Since the consumer is in physical proximity of the bank’s electronic transaction device 106, a relatively short first predefined distance may be used during the transaction verification and authorization process. On the other hand, the consumer may log onto a website of the local bank. Here, a proxy location of the bank website may be used, and a location of the consumer’s personal computer (such as their home) may be used to determine the distance between the consumer and the bank’s web site. Here, a greater second predefined distance, selected based on the known characteristics of the bank’s electronic transaction device 106, here the internet web site, to conduct the transaction verification and authorization process. Enhanced security for such example electronic transactions is provided when various information used during the transaction verification and authorization process is securely stored in the consumer blockchain information 108 associated with that particular consumer.

[0050] In the various embodiments, any suitable currency type and/or currency denomination now known or later developed may be used. In some embodiments, the consumer may select which particular currency from a plurality of different currencies are to be used for all of, or a part of, the electronic transaction. For example, but not limited to, the transaction authorization system 100 may permit payment using bank funds available at a local or remote financial institution, foreign currency funds available at an overseas institution, an electronic payment system (such a PayPal or Google money), credit available from a financial organization (such as a credit card, home or personal equity line of credit, etc.) credits available from the vendor who is a participant in the electronic transaction, an electronic wallet or the like, or a form of crypto-currency, digital tokens, or the like.

[0051] FIGURE 5 is a map-based version of a presented GUI 502. In such embodiments, the GUI 502 may be presented as a map or other geographic based graphic. The map may show current location 504 of the electronic mobile device 104, a location of the electronic transaction device 106 being used for the electronic transaction (shown as a red dot in the center of the circular secure zone), locations of other potential electronic transaction device that are within the secure zone that might be used by the consumer to conduct an electronic transaction (shown as a red dot), and the predefined secure zone 506. Here, the consumer will intuitively understand the nature of the predefined distance relative to their electronic mobile device 104 and the electronic transaction device 106. In some situations, the map information may prompt the consumer to change the value of the predefined distance.

[0052] FIGURE 6 is an example block diagram of an example computing system that may be used to practice embodiments of a electronic transaction verification system 102 described herein. Note that one or more general purpose virtual or physical computing systems suitably instructed or a special purpose computing system may be used to implement an electronic transaction verification system 102. Further, the electronic transaction verification system 102 may be implemented in software, hardware, firmware, or in some combination to achieve the capabilities described herein.

[0053] Note that one or more general purpose or special purpose computing systems/devices may be used to implement the described techniques. However, just because it is possible to implement the electronic transaction verification system 102 on a general purpose computing system does not mean that the techniques themselves or the operations required to implement the techniques are conventional or well known.

[0054] The computing system 600 may comprise one or more server and/or client computing systems and may span distributed locations. In addition, each block shown may represent one or more such blocks as appropriate to a specific embodiment or may be combined with other blocks. Moreover, the various blocks of the transaction authonzation system 100 may physically reside on one or more machines, which use standard (e.g., TCP/IP) or proprietary interprocess communication mechanisms to communicate with each other.

[0055] In the embodiment shown, computer system 600 comprises a computer memory (“memory”) 601, a display 602, one or more Central Processing Units (“CPU”) 603, Input/Output devices 604 (e.g., keyboard, mouse, CRT or LCD display, etc.), other computer- readable media 605, and one or more network connections 606. The consumer blockchain information 108 is shown residing in memory 601. In other embodiments, some portion of the contents, some of, or all of the components of the electronic transaction verification system 102 may be stored on and/or transmitted over the other computer-readable media 607. The components of the electronic transaction verification system 102 preferably execute on one or more CPUs 603 and manage the transaction verification and authorization process, as described herein. Other code or programs 607 and potentially other data repositories, such as data repository 608, also optionally reside in the memory 601, and preferably execute on one or more CPUs 603 (and/or processors 603a). Of note, one or more of the components in FIGURE 6 may not be present in any specific implementation. For example, some embodiments embedded in other software may not provide means for user input or display.

[0056] In a typical embodiment, the electronic transaction verification system 102 includes one or more engines or components 609-612 that concurrently manage a plurality of ongoing electronic transactions for a plurality of different consumers. In some embodiments, multiple engines are available to manage various functions during a transaction verification and authorization process. An example engine is a location determination engine 609 that receives location information for the electronic mobile device 104 and/or the electronic transaction device 106 for the determination of the respective locations. A distance comparison engine 610 manages the comparison of the distance between the electronic mobile device 104 and the electronic transaction device 106 with the predefined distance. A user identity information engine 611 manages confirmation of a consumer’s identification during the transaction verification and authorization process. An authorization and notice engine 612 manages the authorization process one a valid electronic transaction has been identified, and/or generation of notifications to the consumer, such as if the electronic transaction has been authorized or denied. Embodiments may include other engines not described herein that manage other operations pertaining to the transaction verification and authorization process and/or that pertain to other functions occurring at the electronic transaction verification system 102.

[0057] In at least some embodiments, the electronic transaction devices 106 are external to the electronic transaction verification system 102 and are available, potentially, over one or more networks 110. Other and/or different modules may be implemented. In addition, the electronic transaction verification system 102 may interact via the network 110 one or more third-party information provider systems 613, such as purveyors of information used in consumer blockchain information 108. Also, of note, the consumer blockchain information 108 may be provided external to the electronic transaction verification system 102 as well, for example in a distributed architecture at a plurality of devices or the like accessible over one or more networks 110.

[0058] In an example embodiment, components/modules of the electronic transaction verification system 102 are implemented using standard programming techniques. For example, the electronic transaction verification system 102 may be implemented as a “native” executable running on the CPU 603 (and/or the processor 603a), along with one or more static or dynamic libraries. In other embodiments, the electronic transaction verification system 102 may be implemented as instructions processed by a virtual machine. A range of programming languages known in the art may be employed for implementing such example embodiments, including representative implementations of various programming language paradigms, including but not limited to, object-oriented (e.g, Java, C++, C#, Visual Basic.NET, Smalltalk, and the like), functional (e.g., ML, Lisp, Scheme, and the like), procedural (e.g., C, Pascal, Ada, Modula, and the like), scripting (e.g., Perl, Ruby, Python, JavaScript, VBScript, and the like), and declarative (e.g., SQL, Prolog, and the like).

[0059] The embodiments described above may also use well-known or proprietary, synchronous or asynchronous client-server computing techniques. Also, the various components may be implemented using more monolithic programming techniques, for example, as an executable running on a single CPU computer system, or alternatively decomposed using a variety of structuring techniques known in the art, including but not limited to, multiprogramming, multithreading, client-server, or peer-to-peer, running on one or more computer systems each having one or more CPUs. Some embodiments may execute concurrently and asynchronously and communicate using message passing techniques. Equivalent synchronous embodiments are also supported. Also, other functions could be implemented and/or performed by each component/module, and in different orders, and in different components/modules, yet still achieve the described functions.

[0060] In addition, programming interfaces to the data stored as part of the electronic transaction verification system 102 (e.g., in the data repositories 108) can be available by standard mechanisms such as through C, C++, C#, and Java APIs; libraries for accessing files, databases, or other data repositories; through scripting languages such as XML; or through Web servers, FTP servers, or other types of servers providing access to stored data. The electronic transaction verification system 102 may be implemented as one or more database systems, file systems, or any other technique for storing such information, or any combination of the above, including implementations using distributed computing techniques.

[0061] Also, the example electronic transaction verification system 102 may be implemented in a distributed environment comprising multiple, even heterogeneous, computer systems and networks. Different configurations and locations of programs and data are contemplated for use with techniques of described herein. In addition, the electronic transaction verification system 102 may be physical or virtual computing systems and may reside on the same physical system. Also, one or more of the modules may themselves be distributed, pooled or otherwise grouped, such as for load balancing, reliability or security reasons (such as the blockchain information 108). A variety of distributed computing techniques are appropriate for implementing the components of the illustrated embodiments in a distributed manner including but not limited to TCP/IP sockets, RPC, RMI, HTTP, Web Services (XML-RPC, JAX-RPC, SOAP, etc.) and the like. Other variations are possible. Also, other functionality could be provided by each component/module, or existing functionality could be distributed amongst the components/modules in different ways, yet still achieve the functions of the transaction verification system 102.

[0062] Furthermore, in some embodiments, some or all of the components of the electronic transaction verification system 102 may be implemented or provided in other manners, such as at least partially in firmware and/or hardware, including, but not limited to one or more application-specific integrated circuits (ASICs), standard integrated circuits, controllers executing appropriate instructions, and including microcontrollers and/or embedded controllers, field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), and the like. Some or all of the system components and/or data structures may also be stored as contents (e.g., as executable or other machine-readable software instructions or structured data) on a computer-readable medium (e.g., a hard disk; memory; network; other computer-readable medium; or other portable media article to be read by an appropriate drive or via an appropriate connection, such as a DVD or flash memory device) to enable the computer-readable medium to execute or otherwise use or provide the contents to perform at least some of the described techniques. Some or all of the components and/or data structures may be stored on tangible, non-transitory storage mediums. Some or all of the system components and data structures may also be stored as data signals (e.g., by being encoded as part of a carrier wave or included as part of an analog or digital propagated signal) on a variety of computer-readable transmission mediums, which are then transmitted, including across wireless-based and wiredriable- based mediums, and may take a variety of forms (e.g., as part of a single or multiplexed analog signal, or as multiple discrete digital packets or frames). Such computer program products may also take other forms in other embodiments. Accordingly, embodiments of this disclosure may be practiced with other computer system configurations.

[0063] Exhibit I is an example business environment that utilizes one or more of the embodiments of the transaction authorization system 100. Embodiments of the transaction authorization system 100 are envisioned to be used by a limitless number of different types of transactional systems now known or later developed.

[0064] Exhibit II is a conceptual operational scenario of a non-limiting embodiment of the transaction authorization system 100. An image of a map-based GUI is conceptually illustrated in Exhibit II.

[0065] All of the above U.S. patents, U.S. patent application publications, U.S. patent applications, foreign patents, foreign patent applications and non-patent publications referred to in this specification and/or listed in the Application Data Sheet are incorporated herein by reference, in their entireties.

[0066] From the foregoing it will be appreciated that, although specific embodiments have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. It should be emphasized that the above-described embodiments of the transaction authorization system 100 are merely possible examples of implementations of the invention. Many variations and modifications may be made to the above-described embodiments. All such modifications and variations are intended to be included herein within the scope of this disclosure and protected by the following claims. For example, the methods and systems for performing discussed herein are applicable to other architectures Also, the methods and systems discussed herein are applicable to differing protocols, communication media (optical, wireless, cable, etc.) and devices (such as wireless handsets, electronic organizers, personal digital assistants, portable email machines, game machines, pagers, navigation devices such as GPS receivers, etc.).

EXHIBIT I

VOPY CCC Protocol

As Accepted, Secy re, and Regulated Protocol for the World's Financial Transactions

Abstract

The world of cryptocurrency extends far beyond the speculative dimension as its associated technology has laid a practical foundation on the actual integration In different Industries especially the surging demand in every day transactions, However, the all-time low TPS (Transactions Per Second) and high transaction cost of bltcoins have made it a less favourable means of payment. Hence, VOPY aims to he the disruptive force to facilitate the exchange of goods and services in the B2C and S2B marketplace with its proven and cutting-edge technology,

VOPY Is creating a well-constructed payment model - VOPY CCC (Collaboration-Communication Connectivity) Protocol that utilizes permissioned hlockchain to enable the paying and receiving of crypto tokens by consumers and merchants are carried out in a decentralised manner whereas high security is guaranteed. With third-party disintermediation, complicated proceeding procedures and excessive handling costs for big banks and payment processors can he eliminated. The adoption of VOPY smart contract can facilitate the execution of agreement in any transactions which unlock now value of market participants and expand the scope of microtransaction.

Vopy Solution

To develop the world's first accredited and regulated protocol for global financial transactions through:

- Establishment of Multi-Tenancy Architecture: Providing a safer ground for swift transaction by supporting different tenant (payment gateways) available to ail customers

- Full Engagement of Market Participants: Setting up the best ecosystem to cater the needs of market participants and allow them to give a full play to their roles

- introduction of VOPY Tokens (Stable Coin): Enabling the purchase, delivery and trading of bard assets to become more cost efficient with less reliance on third parties with this tokenised approach

- Implementation of Traceability Protocol: Solving the critical card fraud problem across In-store, online and mobile payments powered by certified patent in the field of Diagnostic Solution The ICO mechanism provides VOPY with a way to Introduce our native VOPY Token and make it possible for public to participate In the ever-growing VOPY network. Carrying on the mission to revolutionize giobai transaction through the CCC Protocol, our main proceeds will be channelled towards the growth of token's utility and future expansionary campaigns, progressively expanding its usability and scalability for all token hoiders. With the promising real-world application of this "digital gold”, users can expect to find the best solution for all kinds of transaction.

Background:The Blockchain revolution

In 2008, the Sitcom whitepaper was published, introducing the world to b!ockchain computing - the technology which has the capacity to facilitate the secure, rapid and transparent exchange of value without the need for third parties, in the same way the internet enables the secure, rapid and decentralised exchange of information through its networks.

Blockchain technology enables individuals and corporations to freely and rapidly transact with one another regardless of geographic constraints. Smart contracts, stored on blockchain technology, reduce transaction costs associated with traditional contracts and offer exciting new opportunities for innovation in supply chain and risk management by creating agreements that are self-executing.

On the blockchain ecosystem, digital tokens can represent two types of assets: fungible assets, where every digital token is identical and interchangeable like a currency; non-fungibie assets, where each token is unique and therefore be utilised to represent scarce and non* interchangeable assets.

Digital tokens can present new global payment methods for hand assets such as metal and other commodities, as well as secure, tirade and store information on the production and supply of finite resources such as VOPY , and traded through new digital and borderless marketplaces.

This tokenlsed approach enables the purchase, delivery and trading of hard assets to become more cost efficient with less reliance on third parties and existing banking systems, which in turn reduces overall systemic risks and ensures a more predictable long-term growth.

As such, programmable digital tokens have emerged as an alternative channel for companies to raise finds and as an entirely new asset class for Investors. The issuance of digital tokens as a mechanism to raise capital is commonly referred to as a Token Generating Event (''IGE'' }.

Despite the advent of b!ockchain innovation and infinite benefits it brings to users, tbe untapped potentials of cryptocurrency as a means of payment is locked in a seesaw battle between privacy and transparency _,, fungi bifty and traceability, speedy versus highly-secured transaction which give rise to multi-faceted problems as listed in the following section.

The Problem

One of the most prominent benefit of cryptocurrency is being able to cope with different forms of transaction across the world without any hassle; however, the unsatisfactory transaction speed, the less associated with all-time high volatility and transaction fee, coupled with the poorly-thought-out architecture made the transaction of goods and services Impractical.

Inadequate Transaction Speeds

As cryptocurrencies continue their rise in popularity, it is the critical time to discuss whether these digital coins have the potential of becoming the new mainstream mode of payment and creating added-value in facilitating B2B transactions.

According to the latest statistics compiled by hovwnuch.net ¹ , traditional payment networks like Visa can process up to 24,000 TPS compared to an average of 20 and 7 TPS If the same transaction is made with Ethereum and Bitcoin respectively. Although e-commerce businesses are gradually being integrated into the domain of cryptocurrency, the nature of the crypto-payments protocol has yet to be proven as an efficient payment solution for mass transactions due to the foilowing constraints:

1. Delays caused by a lack of hash power

According to the data retrieved from CrushCrypto Weekly ² , on 12th of November 2017, there was a significant shift of mining power from Bitcoin to Bitcoin Cash given the higher profit the latter can provide to Its miner, and hence It takes longer for Bitcoin biockchain to process the transaction with the diminishing hash power.

II. Delays caused by a lengthy verification process

To avoid any fatal cryptocurrency attacks ranging from "51% attacks" to “Finney attack", It takes up to 6 confirmations of the respective blocks to ensure the safety of the transaction.

III. Delays caused by limited capacities

With the restriction caused by the block size limit of 1MB for Bitcoin, there is a limit to the number of transactions that can be confirmed at once, making it less efficient than mainstream payment methods. At the end of 2017, statistics show that more than 200,000 transactions sit unconfirmed in the Bitcoin mempool despite the high transaction costs users are willing to pay.

Hence, speeding up the payment process will be essential to the future of cryptocurrency to meet the increasing demand of internal and external transactions, or else, it cannot compete with other instant payment platforms. High Volatility

The Inconsistent rise and fall in the price of Siteoln and other cryptocurrendes have been very problematic, and makes them unfavourable a® a medium of exchange. The price of Bitcoln fluctuated from USDS 17,000 at its highest to USDS 14,000 at its lowest. Hence, the fluctuation of cryptocurrency cannot match up to the stability of fiats to facilitate the transaction of goods and services.

High Fees for Microtransactions

Much of everyday life Is made up of microtransactions. Despite the intention of crypto function as "Digital Cash", It Is not cost-effective for an average person conduct a small transaction like payment for a cup of coffee via the Bitcoin network as one would be subjected to Increasingly higher transaction fees.

The concept can be illustrated in the following analogy: a fixed amount of 5 BTCs is charged per transaction regardless the value of goods and services. In this scenario, a transaction fee only accounts for 0.5% of an item which caste $1000 but up to 50% of a $10 purchase. Therefore, the disproportionalty-high Bltcoln transaction cost is not favourable for microtransactions.

However, as shown in the following graph, the Bltcoln transaction fee rises and falls in response to the network transaction volume despite its uniform charge to goods at all values. Therefore, during a busy network day, buyers are subjected to higher transaction costs to incentivlse mining. This further discourages microtransactions in the Bltcoln network.

Incompatibility of Proposed Architecture with Existing Payment Gateway

While cryptocurrency showcases blockchain's fundamental versatility, many crypto-based companies do not build a strong and appropriate architecture to support the existing operational system, which leads to poorly-established product with low usability and accessibility to facilitate value transaction.

1. Imperfect Market Product

There are three critical stages a crypto product has to go through in order to prove its feasibility and executive capacity in its target market: 1. Proof-of-Concept (POC);

2. Prototype; and

3. Minimum Viable Product (MVP)

However, statistically, it is rare for a new crypto innovation to satisfactorily present a complex idea In a desired product and be fully implemented in a ready market to end-users. As a result, many do not manage to get past the prototype stage.

II. Misconfigured Consensus Protocol (POW requires excessive time)

While Bitcoin and other cryptocurrencies have been classified as fast and reliable means of exchange which create ideal platforms needed for fast transactions, many crypto networks fail to identify corresponding consensus mechanisms to process the transactions efficiently. If Proof- of-Work (POW) is applied to confirm transactions, it takes an average rate of 20 minutes for block formations. The complexity of algorithms varies depending on the total power of the network, which may further lengthen the transaction time and fee as it requires additional manpower to mine and arrange blocks.

III. Vulnerable Bitcoin Wallet Design

Cryptocurrency participants rely on hot and cold wallets to keep their assets safe while performing transactions. However, hackers can utilise the design flaws of both wallets and end up with irreversible and irrecoverable loss of assets of crypto users. The biggest hack in the history is the $530M+ heist of XEM currency in January 2018, Coincheck ³ , a Japan-based currency exchange, was susceptible to large scale hack due to Its insecure hot wallet infrastructure without the precautionary ground of multi-signature private keys and hence paved the way for hackers to unlock the digital wallet with a single private key. On the other hand, cold wallets are easily exposed to M!TM attack as a malware can replace the code responsible for generating the receiver's address as its own address for money transferal. The problem was further reinforced by a report generated by Ledger in February 2018 addressing its high vulnerability ⁴ . low Accessibility

Despite tech-sawy enthusiasts talking about cryptocurrency in the technology sector, only 8 % of Americans have engaged in cryptocurrenties activities ⁵ . The path to its mainstream adoption in today's world is principally restricted to:

1. Complicated cryptocurrency system which requires users to equip themselves with adequate knowledge and conduct their own due diligence

2. lack of industry standards to legitimise cryptocurrency exchanges which prevent participants from partaking In the highly unsecure crypto platforms

3. tow liquidity in the form of insufficient market participants on both buy and sell sides and limited exchanges available, which lead to a low trading volumes

Conclusion

Despite a myriad of functionalities embedded in Bitcoin technology and its infinite potential to be applied on all forms of transaction, the "store of value" in Bitcoin is still for from scalability, bound to Its high cost and lengthy duration, weak infrastructure and vulnerabilities. With no proven technologies and consensus algorithm, a highly efficient and secure transaction cannot be achieved.

Design Approach: VOPY CCC Protocol

With the advancement of biockchain, businesses and enterprises are increasingly opting to integrate biodkchain network to facilitate their business developments. Nonetheless, even though the whole point of biockchain Is to create a misted environment among everyone, in a broader sense, to share valuable data -despite the secure and tamperproof distributed ledger - the highiy-accessib!e consensus protocol Is vulnerable to attacks.

Therefore, VOPY employs a permissioned biockchain under Its VOPY CGC (Collaboration· Communication-Connectivtiy protocol with the aid of a multi-tenancy framework. The permissioned biockchain is a blend of public and private biockchain which maintains the replicas In sync through a protocol referred to as consensus, as well as enables the execution of decentralised peer*to*peer transactions but is designed with a higher degree of security to deploy certain restrictions while (I) configuring the networks, and (il) controlling the activities of the various participants in their desired roles.

In VOPY'S application, It determines who may act as transaction validators on Its network, while also creating a "Manager Per Tenancy" that gives permission for the transactions. All the transactions are safeguarded and proceeded under KMA and KYC processes. On the other hand, such application reserves a high level of trust and mobility between users since users can transfer tokens within each other internally In a tenancy and between different tenancies under "Mufti _* Tenancy”.

Multi-Tenancy Architecture

Bitcoln is a highly promising and powerful Innovation with an unbeatable core technology and software applications. For entrepreneurs and enterprises that are developing their businesses online, they are always looking to accept Bitcoln as a payment option, ranging from a personal customised wallet to business-ready packages which can Include automated notifications, recurring payments and personalised invoices.

However, Bitcoin's desirability factor remains low because of the non-systematic, insecure and immature payment infrastructure in the existing Bitcoln payment gateway, magnified by insufficient support and integration that discourages users form paying via Bitcoins.

Therefore, VOPY utilizes a novel Multi-Tenancy Architecture to support different tenants (payment gateway integration 'with ΑΡI' to Bitcoln, Litecoin, Ether, Mastercard, and in the future, Amex and Visa) the launch of this sendee and available to all customers is based on Commercial agreement ony. The example above Is example only, Vopy intend to be open to any interested parties that want to use the Vopy CCC, This is combined with the Vopy blockchain to create safer and faster transactions.

VOPY seeks to act as a mediator that links both payment gateways and merchant accounts, streamlining exchanges and making crypto-payments a more user-friendly experience via these aspects:

I, Enhanced Performance and Capacity

VOPY aims to enable the platform to hold billions of tenants, which can handle a myriad of transactions, each with different modes of payment simultaneously.

II, Greater Security VOPY seeks to ensure tenants have soie access to their own private data and thus multiple transactions be made concurrently without interference from each other

III. Expanded Configurable Features

VOPY will provide a customised API and dashboard for tenants to create functions that facilitate payment and oversee payments data of the entire process. It can increase payment success rates, reduce fraud and respond to customers' requests.

Therefore, the customised multi-tenancy architecture powered by optimal application of blockchain technology enhance the run-time accessibility, dynamics and management of the transactions from SME to MNCs, which make crypto payment possible around the world and getting involved with the seamless integration of credit card's payment piatform.

VOPY Traceability Protocol

To make the utmost convenience for customers to buy goods and services free from demographical and time-tag constraints, the VOPY system embodiments provide seamless integration of credit card payment gateway to make the cashless payment instantly. Also, retailers benefit because they do not have to check a customer's credit rating.

However, with millions of credit cards in circulation today, credit fraud is an inherent part of doing business owing to the loopholes of credit card architecture and design. Reported cases of credit card stolen and ID theft are recorded annually, resulting in the unauthorized use by unscrupulous individuals. Therefore, VOPY is implementing the Traceability Protocol powered by certified patent In the field of Diagnostic Solution to solve the critical card fraud problem across in-store, online and mobile payments:

I. Smart Identification of Any Possible Frauds

By migrating credit card payment system into VOPY's portal, the user will be able to define "safe zones" with the built-in OPS system. For example, if a transaction is attempted in Russia by a registered customer who is currently located in London, the transaction will be automatically declined by the portal. Conversely, if the user activates the “follow me safe zones" option In the portal during his/her travel in other country, any purchase made In the respective country will be legitimately authorized and will not be conceived as fraudulence.

II. Dual Protection from multiple attacks

To mitigate the risk exposed to cyberattack, VOPY will use cold wallet to handle all transferred funds, implement multi-factor authentication, as well as encrypted the credit card with chip and pin that add another layer of security. On top of it, VOPY will delay outbound transfer of funds by 24 hours so that users can read and accept alerts via mobile application to authorize the transfer. Market Participants

Participants In VOPY’s Protocol

VOPY is building a multifunctional platform where users will be abie to engage in B2B and B2C activities with cryptocurrency and crypto token. Its plan Is to establish a "Go-To" platform for all kinds of cryptocurrency with the seamless integration of credit card payment gateways. To elaborate the functionalities of VOPY's Platform, anyone ranging from International business magnate to everyday grocery shopper can use VOPY's platform to fulfil their 82B and B2C purposes and make transactions with native VOPY Tokens and other cryptocurrencies, The participants of VOPY's ecosystem are illustrated as follows:

I. Consumers ~ The ultimate goal of VOPY's solution Is to create and maximize the purchasing power of any person by empowering them with the ability to use their cryptocurrency when making real-world purchases from any store that accepts credit card (Mastercard / Visa).

II. Payment Merchants ~ VOPY's Solution is in place to allow different credit card payment gateways uniformly plug into its existing hassle-free infrastructure to deal with billing agreements, payments to consumer disputes and merchant onboarding, which reduce the individual handling time and cost of each payment merchant,

Ill, Business Owners -VOPY alms at expanding the business owners' customer base by offering a great set of user-friendly features including the POS interface, API, customised function, as well as automatic conversion of fiat and crypto currencies which makes worldwide transactions possible to all business natures,

IV. White-Label Solution - VOPY introduces the white-label turn-key solution to turn potential competitors into partnership / customers. With VOPY's wholesale pricing, economies of scale, simple integration and customised branded card in your own corporate identity ~ inclusive of brand, logo and documentation, the all-in-one service provides a compelling force for business merchants to use VOPY’s service instead of investing to build their own.

Benefits brought by VOPY*s Protocol

In the 21 ^st century in an age of internet and now with the introduction of new layer of Distributed Biockchain Network being augmented the transaction of data In the business network has gone borderless. In the past, wire transfers and ACH transfers are the two most common ways for businesses or clients to pay each other; nonetheless, the former is cost-intensive that the banks have to deal with each other directly for each individual transfer whereas the latter is time- consuming which executes credits and debits in batches that prolongs the processing time.

To eliminate the complicated procedures and lengthy handling time while retaining high security and transparency in the 828 and 82C transactions, VOPY has built a reputable and robust platform powered by distributed ledger and smart contract to allow the complete spectrum of crypto-related transactions that can benefit all B28 and 82C participants In the following respects;

I. Scalability gains from increased time and cost efficiency

With the CCC protocol under VOPY alms at Increasing the transaction capacity and speed via the multi-tenancy and reduce the cost of transaction fees without the participation of intermediaries, it scales up the usability of crypto payment into different forms of transaction from microtransaction to block trade in 82B and B2C domains.

II. Transparency gains from reconciliation In DLT (Distributed ledger Technology)

In DIT technology, all or part of the reconciled data would be shared across other market participants to enhance market transparency or with the relevant business parties to facilitate information flow. In this regard, payment disputes or information disparities can be prevented within corporates and clients. III. Versatility and Security gains from automation in Smart Contract

Smart Contract in blockchain can facilitate, execute or enforce the performance of an agreement in any transaction between 2 parties. For example, reaching a certain payment date and executing an order and payment on a sale and purchase contract, the same mechanics are applicable In other contracts flexibly. On the other hand, automation of contract can eiiminate the need for human intervention in executing a transaction and thus reducing the probability of human error and attack.

The World's First SmartCommodity

Whereas many ERC20 tokens are available, the market has so far shown no Introduction of token to migrate with blockchain that is specifically engineered for KYC, AML and fast transaction in the context of credit card payment. Hence, the ERC2Q based digital token - VOPY Token is being Introduced to cater the increasing needs of using cryptocurrency as a means of payment in all levels of transaction.

Description of VOPY Tokens

Each of the VOPY Token can be exchanged for 1 metric ton of 62% Fe {the "VOPY •ore"). The VOPY Tokens represent VOPY -ore with a maximum of 3.5% Alumina, 8% Moisture and 4% Silica.

Functionalities of VOPY Tokens

I. Incentivized Reward System

Similar to the reward system offered by many credit cards, VOPY Token will be issued as a reward to customers that make purchases with credit card. For instance, for every $100 spent on the card, the user will automatically receive certain amount of VOPY Token.

II. Higher Crypto Volume, lower Volatility

VOPY ecosystem will accept deposits from top 3-5 cryptocurrendes (Bitcoin, Ethereum etc) and only VOPY Tokens will be linked to credit card. Trading volume of tokens can be increased as the schema encourages conversion to VOPY Tokens. Simultaneously, since users will receive VOPY Tokens for every purchase that they make, the exchange for other currencies from VOPY will further boost up the trading volume. EXHIBIT II