阅读说明：本技术 个人销售点（ppos）的商户交易镜像 (Personal point of sale (PPOS) merchant transaction image ) 是由 托德·雷蒙德·纽祖姆 迈克尔·道 于 2019-05-28 设计创作，主要内容包括：商户期望不将顾客PCI(支付卡行业)数据存储在所述商户的系统中,因为这会降低所述商户的成本和风险。但是,所述商户仍然希望访问顾客主账号(PAN)和其它PCI数据元素以进行顾客认证、顾客关系管理等。因此,本说明书公开了允许pPOS(个人销售点)装置创建原始交易的镜像并向所述商户提供所述镜像的系统和方法。然后,所述商户将仍然可以访问顾客PAN和其它PCI数据元素,但是因为镜像交易中不存在PCI或支付数据,所以所述商户的成本和风险得以降低。(Merchants desire not to store customer PCI (payment card industry) data in the merchant's system, as this would reduce the cost and risk to the merchant. However, the merchant still wishes to access the customer's Primary Account Number (PAN) and other PCI data elements for customer authentication, customer relationship management, and the like. Accordingly, the present specification discloses systems and methods that allow a pPOS (personal Point of sale) device to create an image of an original transaction and provide the image to the merchant. The merchant will then still have access to the customer PAN and other PCI data elements, but the cost and risk to the merchant is reduced because no PCI or payment data is present in the mirrored transaction.)

1. A method for providing a transaction image of a merchant transaction using a personal point of sale (pPOS), the method comprising:

Filtering the transaction data, wherein filtering includes identifying payment and/or customer identification data elements in the transaction;

Creating a merchant mirrored transaction from the payment and/or customer identification data elements, wherein creating includes using a data encoding function;

Verifying the merchant image transaction, wherein verifying comprises authenticating data elements in the merchant image transaction.

2. the method of claim 1, wherein the data encoding function comprises one or more of: converting, mapping, masking and randomizing the payment and/or customer identification data elements.

3. The method of claim 2, wherein the data encoding function further comprises seeding data element initialization arrays and/or modeling functions for each type of data element to be converted, mapped, masked, and randomized using local sensor data and external sensor data, wherein a local sensor switch transmits the local sensor data and an external data sensor switch transmits the external sensor data.

4. The method of claim 2, wherein the data encoding function further comprises encryption, wherein local sensor data and external sensor data are used to seed a random salt value for a particular encryption key to achieve a particular data element encryption, wherein a local sensor switch transmits the local sensor data and an external data sensor switch transmits the external sensor data.

5. The method of claim 2, wherein converting comprises using different terminology for data elements.

6. The method of claim 2, wherein mapping comprises establishing a one-to-one relationship between data elements and values and/or functions.

7. The method of claim 1, wherein identifying the payment data element comprises:

Determining the payment data element using a data pattern matching technique,

Determining the payment data elements using heuristic rule techniques,

Determining the payment data elements using artificial intelligent neural network techniques.

8. A computer program product comprising executable instructions encoded in a non-transitory computer readable medium that when executed by a system perform or control the method of claim 1.

9. An apparatus for providing a personal point of sale (pPOS), the apparatus comprising:

A reader configured to read payment and/or identity instruments, wherein the reader is further configured to filter transaction data, wherein filtering comprises identifying payment and/or customer identification data elements in a transaction;

A secure microcontroller function (MCF),

Wherein the secure MCF is configured to create a merchant image transaction from the payment and/or customer identification data elements, wherein creating includes using a data encoding function,

Wherein the secure MCF is further configured to verify the merchant image transaction, wherein verifying comprises authenticating data elements in the merchant image transaction;

A secure element configured to store and process payment and identification applications.

10. An apparatus for providing a personal point of sale (pPOS), the apparatus comprising:

A reader configured to read a payment and/or identity instrument,

Wherein the reader is further configured to filter transaction data, wherein filtering comprises identifying payment and/or customer identification data elements in a transaction,

Wherein the reader is further configured to create a merchant image transaction from the payment and/or customer identification data elements, wherein creating comprises using a data encoding function;

A secure microcontroller function (MCF),

Wherein the secure MCF is configured to verify the merchant image transaction, wherein verifying comprises authenticating data elements in the merchant image transaction;

A secure element configured to store and process payment and identification applications.

Technical Field

The described embodiments relate generally to apparatus and methods for providing e-commerce transactions and/or merchant payments in vehicles, and more particularly, to apparatus and methods for providing merchant transaction images for personal point of sale (pPOS) for card present e-commerce transactions and/or merchant payments in vehicles.

background

Today, e-commerce transactions are being treated as "card not present". This means that the customer must enter their card account number, a printed security feature on the card such as CVC/CVC2 (card verification code or card validation code), etc. This data is used and stored by the merchant to make the payment. This is the customer PCI (payment card industry) data. The merchant also pays a higher exchange rate (exchange rate) because there may be a type of fraud that is generated because the data is exposed in the transaction and on the merchant's website.

alternatively, "card-present" e-commerce transactions may overcome some of the problems or disadvantages associated with "card-not-present" e-commerce transactions. However, both "card present" and "card not present" e-commerce transactions may still cause the merchant to store customer PCI (payment card industry) data in the merchant's system, which would introduce additional cost and risk to the merchant.

It is therefore desirable to develop systems and methods that will help merchants not have to store customer PCI (payment card industry) data in the merchant's system.

Disclosure of Invention

Within the EMV payment specification, payment is allowed to be accepted using an unattended terminal (unattended terminal). Creating a device with both EMV level 1 (L1) and level 2 (L2) payment components combined with a virtual merchant creates a "card present" transaction for an online or e-commerce merchant. This device may be referred to as a personal point of sale (pPOS). (Note: EMV stands for Europay, MasterCard, and Visa).

Merchants desire not to store customer PCI (payment card industry) data in the merchant's system, as this would reduce the cost and risk to the merchant. However, the merchant still wishes to access the customer's Primary Account Number (PAN) and other PCI data elements for customer authentication, customer relationship management, and the like. Accordingly, the present specification discloses systems and methods that allow a pPOS (personal Point of sale) device to create an image of an original transaction and provide the image to the merchant. The merchant will then still have access to the customer PAN and other PCI data elements, but the cost and risk to the merchant is reduced because no PCI or payment data is present in the mirrored transaction.

The invention discloses a method for providing a transaction image of a merchant transaction using a personal point of sale (pPOS), the method comprising: (a) filtering the transaction data, wherein filtering includes identifying payment and/or customer identification data elements in the transaction; (b) creating a merchant mirrored transaction from the payment and/or customer identification data elements, wherein creating includes using a data encoding function; (c) verifying the merchant image transaction, wherein verifying comprises authenticating data elements in the merchant image transaction.

In some embodiments, the data encoding function comprises one or more of: converting, mapping, masking and randomizing the payment and/or customer identification data elements.

In some embodiments, the data encoding function additionally includes seeding (seed) data elements initialization array and/or modeling functions for each type of data element to be converted, mapped, masked, and randomized using local sensor data and external sensor data, wherein the local sensor switch transmits the local sensor data and the external data sensor switch transmits the external sensor data.

In some embodiments, the data encoding function additionally includes encryption, wherein the local sensor data and the external sensor data are used to seed a random salt (salt) value on a particular encryption key to achieve a particular data element encryption, wherein the local sensor switch transmits the local sensor data and the external data sensor switch transmits the external sensor data.

In some embodiments, converting includes using different terminology for the data elements.

In some embodiments, mapping includes establishing a one-to-one relationship between data elements and values and/or functions.

In some embodiments, the mask includes a portion of the replacement data element.

In some embodiments, identifying the payment data element comprises: (a) determining the payment data element using a data pattern matching technique; (b) determining the payment data element using a heuristic rule technique; (c) determining the payment data elements using artificial intelligent neural network techniques.

In some embodiments, the payment data elements include one or more of: credit card number, credit card data, debit account number, debit account data, closed loop stored value number, coupon coded data element, voucher coded data element, discount coded data element, digital currency data element.

In some embodiments, identifying the customer identification data element comprises: (a) determining the customer identification data element using a data pattern matching technique; (b) determining the customer identification data element using heuristic rule techniques; (c) determining the customer identification data elements using artificial intelligent neural network techniques.

In some embodiments, the customer identification data element comprises one or more of: name, address, city, state, zip code, electronic mailbox, government or state or local ID (identification) number, driver's license data element, passport data element.

In some embodiments, the method additionally comprises: (d) formatting the encrypted transaction data and transmitting the encrypted transaction data to a merchant acquirer; (e) transmitting the merchant image transaction to a merchant.

In some embodiments, the method additionally comprises: (f) synchronizing merchant mirror transaction data elements and the merchant mirror transaction with an original transaction.

A computer program product comprising executable instructions encoded in a non-transitory computer readable medium that when executed by a system perform or control the following method for providing a transaction image of a merchant transaction using a personal point of sale (pPOS), the method comprising: (a) filtering the transaction data, wherein filtering includes identifying payment and/or customer identification data elements in the transaction; (b) creating a merchant mirrored transaction from the payment and/or customer identification data elements, wherein creating includes using a data encoding function; (c) verifying the merchant image transaction, wherein verifying comprises authenticating data elements in the merchant image transaction.

The present invention additionally discloses an apparatus for providing a personal point of sale (pPOS), the apparatus comprising: (a) a reader configured to read payment and/or identity instruments, wherein the reader is further configured to filter transaction data, wherein filtering comprises identifying payment and/or customer identification data elements in a transaction; (b) a secure microcontroller function (MCF), wherein the secure MCF is configured to create a merchant image transaction from the payment and/or customer identification data elements, wherein creating comprises using a data encoding function, wherein the secure MCF is further configured to verify the merchant image transaction, wherein verifying comprises authenticating the data elements in the merchant image transaction; (c) a secure element configured to store and process payment and identification applications.

In some embodiments, the apparatus additionally comprises: (d) a second microcontroller function (MCF), wherein the secure MCF and/or the second MCF is configured to format and transmit encrypted transaction data to a merchant acquirer, wherein the secure MCF and/or the second MCF is further configured to transmit the merchant image transaction to a merchant.

In some embodiments, the apparatus additionally comprises one or more of: (e) a local sensor switch configured to initiate and/or terminate a transaction, wherein the local sensor switch transmits local sensor data to the secure element; (f) an external data sensor switch, wherein the external data sensor switch transmits external sensor data to the secure element.

In some embodiments, the secure MCF and/or the second MCF are additionally configured to synchronize a merchant image transaction data element and the merchant image transaction with an original transaction.

The present invention also discloses a device for providing a personal point of sale (pPOS), the device comprising: (a) a reader configured to read a payment and/or identity instrument, wherein the reader is further configured to filter transaction data, wherein filtering comprises identifying payment and/or customer identification data elements in a transaction, wherein the reader is further configured to create a merchant mirrored transaction from the payment and/or customer identification data elements, wherein creating comprises using a data encoding function; (b) a secure microcontroller function (MCF), wherein the secure MCF is configured to verify the merchant image transaction, wherein verifying comprises authenticating a data element in the merchant image transaction; (c) a secure element configured to store and process payment and identification applications.

In some embodiments, the apparatus additionally comprises: (d) a second microcontroller function (MCF), wherein the secure MCF and/or the second MCF is configured to format and transmit encrypted transaction data to a merchant acquirer, wherein the secure MCF and/or the second MCF is further configured to transmit the merchant image transaction to a merchant.

the above summary is not intended to represent each exemplary embodiment within the scope of the present or future claims. Additional example embodiments are discussed in the figures and detailed description that follows.

Drawings

The described embodiments and their advantages are best understood by referring to the following description taken in conjunction with the accompanying drawings. These drawings in no way limit any changes in form and detail that may be made to the described embodiments by one skilled in the art without departing from the spirit and scope of the described embodiments.

FIG. 1A illustrates a prior art process flow for a typical e-commerce component with a "cardless" transaction for which customer data is not stored (e.g., typically for a one-time payment method).

FIG. 1B illustrates a prior art process flow (e.g., typically for a repeat payment method) for a typical e-commerce component with a "cardless" transaction for customer data being stored.

Fig. 2A illustrates an e-commerce component and process flow for a "card present" transaction performed with a personal point of sale (pPOS) device in conjunction with a merchant transaction image, according to some example embodiments.

Fig. 2B illustrates an e-commerce component and process flow for a "card present" transaction performed with a personal point of sale (pPOS) device in conjunction with a merchant transaction image and synchronization of the merchant transaction image and the pPOS device, according to some example embodiments.

FIG. 3 illustrates a functional block diagram of a system for providing merchant transaction image and merchant transaction image synchronization, according to some example embodiments.

Fig. 4 illustrates a first personal point-of-sale (pPOS) device configured to provide a merchant transaction image and merchant transaction image synchronization for "card present" e-commerce transactions and/or merchant payments in a vehicle (where the merchant transaction image is created in a secure MCF (microcontroller function)), according to some example embodiments.

Fig. 5 illustrates a second personal point of sale (pPOS) device configured to provide merchant transaction mirroring and merchant transaction mirroring synchronization for "card present" e-commerce transactions and/or merchant payments in a vehicle (where the merchant transaction mirroring is created in a secure MCF (microcontroller function) and the external sensor data is provided by an external data sensor switch), according to some example embodiments.

Fig. 6 illustrates a third personal point of sale (pPOS) device configured to provide merchant transaction mirroring and merchant transaction mirroring synchronization of "card present" e-commerce transactions and/or merchant payments in a vehicle (where the merchant transaction mirroring is created in a reader), according to some example embodiments.

Fig. 7 illustrates a fourth personal point of sale (pPOS) device configured to provide merchant transaction mirroring and merchant transaction mirroring synchronization for "card present" e-commerce transactions and/or merchant payments in a vehicle (where the merchant transaction mirroring is created in the reader and the external sensor data is provided by the external data sensor switch), according to some example embodiments.

fig. 8 illustrates a process flow for a "card present" transaction performed with a personal point of sale (pPOS) device in conjunction with a merchant transaction image, according to some example embodiments.

FIG. 9 illustrates a detailed view of a "merchant transaction image" creation process (which is part of the process flow of FIG. 8) in accordance with some example embodiments.

FIG. 10 illustrates a flow chart of method steps for providing a transaction image of a merchant transaction using a personal point of sale (pPOS), according to some example embodiments.

Detailed Description

Representative devices and methods according to the present application are described in this section. These examples are provided merely to add context and aid in the understanding of the described embodiments. It will thus be apparent to one skilled in the art that the described embodiments may be practiced without some or all of these specific details. In other instances, well known process steps or device details have not been described in detail in order to not unnecessarily obscure the described embodiments. Other embodiments are possible, such that the following examples should not be considered limiting.

In the following detailed description, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration specific embodiments in accordance with the described embodiments. Although the described embodiments have been described in sufficient detail to enable those skilled in the art to practice them, it is to be understood that the examples are not limiting; such that other embodiments may be used and changes may be made without departing from the spirit and scope of the described embodiments.

To reduce the merchant's PCI (payment card industry) enforcement and auditing risks and costs and also to add additional services to the merchant, the Merchant Acquirer (MA) must implement point-to-point encryption (P2PE) on the merchant reader. However, this does not enable merchants to use the customer Primary Account Number (PAN) and other PCI data elements for customer authentication, customer verification, Customer Relationship Management (CRM), merchant loyalty programs, cross-payment type (different payment types for promotion) and payment instrument promotions, and value added account (PAN) level services.

To address the above issues, a pPOS (personal Point of sale) device may create a mirror image of the original transaction and provide the mirror image to the merchant. This enables the merchant to use the mirrored created data elements, such as the mirrored account number and other PCI data elements in the mirrored transaction data, to link back to the original customer and/or device. The creation and verification of the transaction image is a new data element unique to the customer using the pPOS device and the merchant processing the image. Mirrored transactions have no monetary value to merchants, merchant acquirers, and customers. No PCI or payment data is present in the mirror transaction. Later, there may be on-device message synchronization between the original transaction and the mirrored transaction. Here, because the local data sensor switch and the external data sensor switch are on the pPOS device that creates the new data elements and the transaction image, the only way to determine the link of the image transaction to the original transaction is on the pPOS device that creates the image.

in addition to the customer PAN, the merchant also desires to be able to make payments using identification data elements (such as biometric data and/or driver's license ID, etc.). To protect both the merchant and the customer, the above-described mirrored transaction scheme may also be extended to protect these identification data elements by also mirroring them to the merchant.

The following method may be used to create a transaction image.

(a) Different data elements are collected using the local data sensor switch and the external data sensor switch to be used as an index (index to rule) and a random element primer (using sensor switch data as random elements) that is then used to convert, map, mask and/or randomize the raw data elements into mirror transaction data elements.

(b) The ability to utilize user preference and merchant preference selections enables users and merchants to determine the selection and complexity of different functions for creating mirrored data and transactions.

(c) Each transaction has four parts: user (i.e., customer) data elements, merchant acquirer data elements, and device (i.e., pPOS device) data elements. The local sensor switch data is used to encode all data elements. External sensor switch data is added to encode specific transaction data elements.

Message synchronization on a device is the re-creation of linked/mapped data elements between the original and mirrored data elements and/or transactions. In principle, this is possible, but is not always possible because the merchant needs to connect to the pPOS device for a certain amount of time. However, pPOS devices linked to cars or phones may remain connected at all times, making message synchronization on the device possible.

How the mirror transaction? can be created using local sensor data and external data sensor data from the local sensor switch and external data sensor switch the key here is the randomization of the data created by the sensor switch (local data and external data), time, and external data this makes the new data created in the mirror transaction very unique based on the type of sensor data such as customer biometric data and/or remote data elements such as RF (radio frequency) signal strength and data elements, WiFi (wireless local area network) data elements, GSM (global system for mobile communications) data elements, bluetooth data elements, images, vehicle related data, etc. from remote data sources.

The key to how the mirror transaction can be synchronized with and/or linked back to the original transaction? is the on-device level features used to recreate the original transaction from the transaction image.

For a better understanding of the above concepts, please see fig. 1A-10.

FIG. 1A shows a prior art process flow 100A with a typical e-commerce component for "cardless" transactions where customer data is not stored (e.g., typically for a one-time payment method). As can be seen from fig. 1A, for such "cardless" transactions (e.g., typically for one-time payment methods) where customer data is not stored, the customer typically needs to enter the following customer data: name, address, payment information, etc. The payment information may include PAN (primary account number), CVC (card verification code or CVV-card verification value), EXP (credit card expiration date) of the credit/debit card. In FIG. 1A, PAN is shown as 4111-XXXX-XXXX-XXXX, CVC is shown as XXXX, and EXP is shown as MM/YY (month/year).

The customer enters customer data into the personal computer 110A or smart phone 120A. For "cardless" transactions, customer data is transmitted to merchant e-commerce (e-commerce) website 150A through HTTPS/SSL (secure hypertext transfer protocol/secure socket layer) for a secure and encrypted communication link between a browser and a web server over the internet. Since this is a one-time payment, the merchant typically does not store any PCI (payment card industry) data. The merchant e-commerce website 150A then further transmits the payment information to the merchant acquirer 160A using ISO 8583, which ISO 8583 is an international standard for exchange messaging initiated by financial transaction cards.

The key point of fig. 1A is that the merchant server and software need to protect the customer payment data through PCI requirements. Without a merchant image of the payment transaction, this is a cumbersome and expensive requirement for the merchant, and the merchant may also assume significant legal and financial responsibility if customer data is broken or stolen.

FIG. 1B illustrates a prior art process flow (e.g., typically for a repeat payment method) for a typical e-commerce component with a "cardless" transaction for customer data being stored. Fig. 1B is very similar to fig. 1A, except that the customer data is now stored by the merchant, as this is for repeated payments, but the customer data may also be stored for one-time payments.

similar to FIG. 1A, FIG. 1B shows that for such a "cardless" transaction, the customer needs to enter the following customer data: name, address, payment information, etc. Further, the payment information may include PAN (primary account number), CVC (card verification code or CVV-card verification value), EXP (credit card expiration date) of the credit/debit card. In FIG. 1B, PAN is shown as 4111-XXXX-XXXX-XXXX, CVC is shown as XXXX, and EXP is shown as MM/YY (month/year).

The customer enters customer data into the personal computer 110B or the smart phone 120B. For "cardless" transactions, customer data is transmitted to merchant e-commerce (e-commerce) website 150B over HTTPS/SSL (secure hypertext transfer protocol/secure socket layer) for a secure and encrypted communication link between the browser and the web server over the internet. In fig. 1B, the merchant stores PCI (payment card industry) data in the customer credit card PCI library (e.g., typically used for repeated payment methods). Typically, both customer data and payment data are stored. The merchant e-commerce website 150B then further transmits the payment information to the merchant acquirer 160B using ISO 8583, which is an international standard for exchange messaging initiated by financial transaction cards.

Similar to fig. 1A, the key point of fig. 1B is that the merchant server and software need to protect the customer payment data through PCI requirements. Again, without a merchant image of the payment transaction, this is a cumbersome and expensive requirement for the merchant, and the merchant may also assume significant legal and financial responsibility if customer data is broken or stolen. It should be noted that in FIG. 1B, the cost and liability increase as the stored customer credit card PCI data may be cracked or stolen from the customer's website.

Thus, both fig. 1A and 1B emphasize the merchant image that is required to perform a payment transaction, such that the merchant will only receive the image of the payment transaction and transmit the customer payment data directly to the merchant acquirer. In turn, this would free the merchant from the cost and responsibility of protecting the customer payment data on the merchant's website and the additional cost of PCI enforcement and auditing. This is of great benefit to small and medium sized merchants with limited resources and may also save significant costs to large merchants.

Fig. 2A illustrates an example of such an implementation of a merchant image for a payment transaction. In particular, fig. 2A illustrates an e-commerce component and process flow for a "card present" transaction performed with a personal point of sale (pPOS) device in conjunction with a merchant transaction image, according to some example embodiments. As can be seen from fig. 2A, for such "card present" transactions, the customer still typically needs to enter the following customer data: name, address, payment information, etc. Here, the payment information may include PAN, CVC, and EXP of the credit/debit card. In FIG. 2A, PAN is shown as 4111-XXXX-XXXX-XXXX, CVC is shown as XXXX, and EXP is shown as XXXX (month/year).

Fig. 2A shows that the customer may enter customer data directly into the pPOS240A, or indirectly into the personal computer 210A, smart phone 220A, or car 230A, and then the customer data is further transmitted to the pPOS 240A. After the pPOS240A has received the customer data and payment information, fig. 2A shows that all payment transaction data is transmitted to the merchant acquirer 260A through HTTPS/SSL (secure hypertext transfer protocol/secure socket layer) for a secure and encrypted communication link implemented over the internet between the pPOS240A and the merchant acquirer 260A web server. Fig. 2A additionally shows that payment transaction data may be encrypted by point-to-point encryption (P2PE) or end-to-end encryption (E2 EE). Thus, the merchant acquirer receives the encrypted payment transaction message with the customer PCI data. The merchant acquirer may then decrypt the PAN/PCI data through P2PE/E2 EE.

At the same time, pPOS240A also creates a merchant transaction image that is transmitted to the merchant at the merchant ecommerce website 250A. FIG. 2A shows that the merchant transaction image may include the following customer data: web session and shopping cart ID (identifier), credit/debit card PAN-9999 0001 (which may be a dummy placeholder), CVC-1234 (which is an optional value), EXP-31/12 (which is an optional value), name- @ # $! @ # (which is "data encoded") and address- $! @ #4889134124 (which is "data encoded"). Fig. 2A shows that the merchant transaction image may still be transmitted to the merchant 250A through HTTPS/SSL (secure hypertext transfer protocol/secure socket layer) for a secure and encrypted communication link between the pPOS240A and the merchant e-commerce website 250A web server over the internet. However, because the merchant receives the mirrored transaction of payment and/or customer data in a message without any PCI data, there is no longer a need to protect the mirrored data through the PCI. In turn, this would free the merchant from the cost and responsibility of protecting the mirrored data on the merchant's website and the additional cost of PCI enforcement and auditing.

Subsequently, if the merchant wishes to synchronize the merchant transaction image with the pPOS device, an embodiment of this synchronization process is shown in FIG. 2B. In particular, fig. 2B illustrates an e-commerce component and process flow for a "card present" transaction performed with a personal point of sale (pPOS) device 240B in conjunction with a merchant transaction image and synchronization of the merchant transaction image with the pPOS device 240B, according to some example embodiments.

As shown in fig. 2B, pPOS 240B may receive customer payment transaction data from personal computer 210B, smart phone 220B, or automobile 230B. Alternatively, in an embodiment, pPOS 240B may receive customer payment transaction data directly from the customer. After the pPOS 240B have received the customer payment transaction data, fig. 2B shows that the pPOS 240B may encrypt the customer payment transaction data and then transmit the encrypted customer payment transaction data to the merchant acquirer 260B. In the meantime, fig. 2B also shows that pPOS 240B may also create a merchant image of the customer payment transaction and then transmit the merchant image of the customer payment transaction to merchant e-commerce site 250B. Following these two steps, FIG. 2B further shows that, in one embodiment of the synchronization process, merchant e-commerce website 250B may interact with pPOS device 240B via on-device merchant image synchronization messages to effect synchronization of the merchant transaction image with pPOS device 240B.

FIG. 3 illustrates a functional block diagram of a system 300 for providing merchant transaction images and merchant transaction image synchronization, according to some example embodiments. In some embodiments, the system 300 may be a pPOS (personal Point of sale) device.

Fig. 3 shows that system 300 includes a data filter 303, a merchant image creator 310, and a merchant image validator 340. The data filter 303 receives transaction data from the interface 301. The transaction data includes payment and/or customer identification data elements in a transaction, such as a merchant payment transaction. The data filter 303 is configured to filter transaction data, wherein the filtering includes identifying payment and/or customer identification data elements in the transaction. Merchant image creator 310 receives payment and/or customer identification data elements from data filter 303 through interface 302. The merchant image creator 310 is configured to create a merchant image transaction from payment and/or customer identification data elements, wherein the creation includes the use of data encoding functionality. Merchant image validator 340 receives merchant image transactions from merchant image creator 310 via interface 315. The merchant image verifier 340 is configured to verify the merchant image transaction, wherein verifying includes authenticating data elements in the merchant image transaction. The functional blocks (or components) of the system 300, such as the data filter 303, the merchant image creator 310, and the merchant image validator 340, may be implemented by software, hardware, or a combination of hardware and software.

The data filter 303 may filter the transaction data, where the filtering includes identifying payment and/or customer identification data elements in the transaction. In some embodiments, identifying the payment data element may include: (1) determining a payment data element using a data pattern matching technique; (2) determining payment data elements using heuristic rule techniques; (3) the payment data elements are determined using artificial intelligent neural network techniques. In some embodiments, the payment data elements may include one or more of the following: credit card number, credit card data, debit account number, debit account data, closed loop stored value number, coupon coded data element, voucher coded data element, discount coded data element, digital currency data element. In some embodiments, identifying the customer identification data element may include: (1) determining a customer identification data element using a data pattern matching technique; (2) determining customer identification data elements using heuristic rule techniques; (3) customer identification data elements are determined using artificial intelligent neural network techniques. In some embodiments, the customer identification data element may include one or more of the following: name, address, city, state, zip code, electronic mailbox, government or state or local ID (identification) number, driver's license data element, passport data element.

the data filter 303 may filter the transaction data, where the filtering includes identifying payment and/or customer identification data elements in the transaction. In some embodiments, identifying the payment data element may be looking up (but not limited to) a credit card number, a debit account number, a closed loop stored value number, a coupon coded data element, a voucher coded data element, a discount coded data element, and/or a digital currency data element in the transaction using data pattern matching techniques. Credit accounts, debit accounts, coupons, discounts, and vouchers have a particular length, format, and number sequence. These sequences can be found by matching known patterns to data in the transaction. For example, a credit/debit account number may start with a BIN (bank identification number) and be 16 digits in length. The BIN (bank identification number) may be the first four to six digits appearing on a credit card. The bank identification number uniquely identifies the institution issuing the card. BIN may be a key in matching transactions with issuers of charge cards. The coupon code and the promotion code all have similar formats based on a series of numbers/letters and a series of numbers and letters. As another example, the closed-loop stored value number, the coupon coded data element, the voucher coded data element, and the discount coded data element all have no BIN. As another example, the digital currency may be an encryption currency and a blockchain data element.

The data filter 303 may filter the transaction data, where the filtering includes identifying payment and/or customer identification data elements in the transaction. In some embodiments, identifying the customer identification data element may include: (1) using customer data pattern matching techniques to find (but not limited to) names, addresses, cities, states, zip codes, electronic mailboxes, government/state/local ID numbers in transactions; (2) an identification tool for locating driver's license and passport data elements in a transaction using customer pattern matching techniques. For example, the data elements of the driver's license may include name, date of birth, hair color, eye color, height, weight, address, date of issue, expiration date, identification number, issuer identification number, jurisdiction version number, driving license type, restriction code, license ID, license data. As another example, the data elements of the passport may include a country of belongingness, a signature, a photograph, a date of birth, and the like.

Fig. 3 shows that the system 300 additionally includes a local sensor switch 305 and an external data sensor switch 350. Local sensor switch 305 is configured to provide local sensor data 330 to merchant image creator 310 via interface 331 and interface 335. The external data sensor switch 350 is configured to provide the external sensor data 320 to the merchant image creator 310 via the interface 321 and the interface 325. In some embodiments, the local sensor switch is configured to initiate and/or terminate a transaction. In some embodiments, the local sensor switch is additionally configured to collect user authentication data and notify the user of the device status. In some embodiments, the local sensor switch comprises a biometric sensor. Biometric sensors are used to collect user biometric data for enrollment and authentication: a user of the device and/or a transaction from the device to the merchant and/or merchant acquirer. In some embodiments, the local sensor switch comprises a touch sensor. Touch sensors are used to collect user-created data for enrollment and authentication: a user of the device and/or a transaction from the device to the merchant and/or merchant acquirer. In some embodiments, the touch pattern and sequence data can be managed by a user of the device using a touch sensor. In some embodiments, the local sensor switch is included within the pPOS device. In some embodiments, the local sensor switch is external to the pPOS device. In some embodiments, the external data sensor switch is configured to verify, manage, and/or create a transaction. In some embodiments, the external data sensor switch is configured to process external data of the device. In some embodiments, the apparatus allows external data access to the configuration and processing of the payment kernel by the merchant, merchant acquirer, payment issuer, and/or identification issuer, where the external data is processed by the external data sensor switch. In some embodiments, the external data sensor switch provides one or more of the following functions: a sensor data validation and filter; data identification by type and/or sensor and/or interface and/or communication protocol; data association between data type and sensor; data fusion between data, communication protocols, and data types.

The merchant image creator 310 may create a merchant image transaction from payment and/or customer identification data elements, where the creation includes using data encoding functionality. The data encoding function may include one or more of the following: converting, mapping, masking and randomizing the payment and/or customer identification data elements. In some embodiments, the data encoding function additionally comprises seeding data element initialization arrays and/or modeling functions for each type of data element to be converted, mapped, masked and randomized using local sensor data and external sensor data, wherein the local sensor switch transmits the local sensor data and the external data sensor switch transmits the external sensor data. In some embodiments, the data encoding function additionally includes encryption, wherein the local sensor data and the external sensor data are used to seed a random salt value on a particular encryption key to achieve a particular data element encryption, wherein the local sensor switch transmits the local sensor data and the external data sensor switch transmits the external sensor data. In some embodiments, converting includes using different terminology for the data elements. In some embodiments, mapping includes establishing a one-to-one relationship between data elements and values and/or functions. In some embodiments, the mask includes a portion of the replacement data element. In some embodiments, the mask includes a portion (e.g., edit) that covers the data element or data string. However, since no key is involved, the conversion, mapping, masking and randomization are not encryption.

In some embodiments, converting includes using different terminology for the data elements. In some embodiments, the transforming includes seeding a data element transformation model between the sensor type and the data element using the local sensor data and the external sensor data. For example, a fingerprint value of 1 equals an index data element value of 10. Here, the fingerprint has 26 points that can be used to identify the fingerprint. This fingerprint value may then map to an index data element value between 0 and 100.

In some embodiments, masking includes seeding a data element reference array and/or model for each type of data element to be masked using local sensor data and external sensor data. Then, for a particular data element; a number; a character; or a sequence of numbers, characters, or data elements. For example, the sensor data provides a seed value of 5 from a particular sensor (note: pPOS may know this rule). Masking is then done with a particular data element, for example, a name such as Jeffery. The mask will translate Jeffery to become "JeffXry", where the mask value is an entry in data element position 5. As another example of a mask, the sensor data provides a seed value 30 (in the range of 0-1000) from a particular sensor data element. Masking is then done by converting and replacing particular data elements. Beginning with account number 4111333333333333. The seed value 30 is an index value in the matrix that represents a particular data element type, size, and placement (e.g., index value 30 represents length 4 starting at data element 5). The masked account number then becomes 4111! @ # $ 33333333.

the merchant image verifier 340 may verify the merchant image transaction, where verification includes authenticating data elements in the merchant image transaction. In some embodiments, verifying the image means that the system 300 that created the image can return the image to the original state of the transaction. In some embodiments, system 300 may be a pPOS device. Thus, in some embodiments, the pPOS device that created the image may return the image to the original state of the transaction. In some embodiments, the merchant image transaction is verified by performing one or more of the following: a checksum check is performed, a CRC (cyclic redundancy check) check is performed, and a MAC (message authentication code) check is performed. For example, a MAC (message authentication code) is a cryptographic checksum on data that uses a session key to detect accidental and intentional modifications of data.

it is important to note that system 300 (which in some embodiments is a pPOS device) holds "rules" for creating mirrored data rather than the mirrored data itself. Additionally, in some embodiments, the "rules" (for creating mirrored data) are driven by local sensor switches (i.e., typically customer-related data) and external data sensor switches (i.e., typically merchant-related data).

As also shown in fig. 3, the system 300 additionally includes data encryption 370, merchant acquirer message formatting 380, and a transmitting merchant image 360. The data encryption 370 is configured to encrypt transaction data transmitted from the data filter 303 to the data encryption 370 through the interface 304. Data encryption 370 further transmits the encrypted transaction data to merchant acquirer message formatting 380 through interface 375. Merchant acquirer message formatting 380 is configured to format encrypted transaction data for transmission to a merchant acquirer through interface 385. In other words, the system 300 is configured to format and transmit encrypted transaction data to the merchant acquirer through the interface 385, where encryption is performed by data encryption 370 and formatting is performed by merchant acquirer message formatting 380. Additionally, the transferring merchant image 360 is configured to receive merchant image transactions from the merchant image creator 340 via the interface 345. The transmitting merchant image 360 is additionally configured to transmit the merchant image transaction to the merchant through the interface 365.

FIG. 3 additionally shows that the system 300 additionally includes a synchronized merchant image 390 that implements a merchant transaction image synchronization process. To implement the synchronization process, synchronized merchant image 390 is configured to receive the original transaction from merchant image validator 340 via interface 346. Additionally, synchronized merchant image 390 is additionally configured to communicate with merchants through interface 395 and, if desired, transmit the original transaction to the merchant through interface 395.

Fig. 4 illustrates a first personal point-of-sale (pPOS) device 400, according to some example embodiments, the first pPOS device 400 configured to provide a merchant transaction image and merchant transaction image synchronization (where the merchant transaction image is created in a secure MCF (microcontroller function)) for "card-in-card" e-commerce transactions and/or merchant payments in a vehicle. Fig. 4 shows that pPOS device 400 includes a secure microcontroller function (MCF)406, a secure element 437, a second MCF 441, a reader 402, and a local sensor switch 405. Fig. 4 also shows that pPOS device 400 includes these interfaces: interface to transaction data 401, interface 411 from secure MCF to reader, interface 412 from secure element to secure MCF, interface 431 from local sensor switch to secure element, interface 445 from second MCF 441 to secure MCF, interface 465 to merchant, interface 495 to merchant mirror sync, and interface 485 to merchant acquirer.

In fig. 4, secure MCF 406 may be configured to create a merchant image transaction from payment and/or customer identification data elements, verify the merchant image transaction, and encrypt transaction data to a merchant acquirer. Secure MCF 406 may be additionally configured to provide application and data level encryption and hardware/software tamper detection. Secure MCF 406 may also include a payment kernel (not shown in fig. 4), and the payment kernel may be configured to process payments.

In fig. 4, reader 402 may be configured to read payment and/or identity instruments. The reader 402 may be additionally configured to filter transaction data, where filtering includes identifying payment and/or customer identification data elements in a transaction. In some embodiments, reader 402 may be an authenticated EMV level 1 contact and/or contactless reader, where EMV stands for Europay, MasterCard, and Visa.

in fig. 4, the secure element 437 may be configured to store and process payment and identification applications. In some embodiments, the secure element 437 may be configured to execute secure element applications for payment and authentication. In some embodiments, the secure element application may perform authentication using a multi-factor authentication method. In some embodiments, the secure element application may perform authentication using multi-factor authentication through PKI (public key infrastructure) and FIDO (Fast IDentity Online). In some embodiments, the secure element 437 may additionally be configured to execute a second secure element application for customer biometric data storage and verification.

Fig. 4 also shows a local sensor switch 405. The local sensor switch 405 may be configured to initiate and/or terminate a transaction. The local sensor switch 405 may also transmit local sensor data 430 to the secure element 437. In some embodiments, the local sensor switch 405 may be additionally configured to collect user authentication data. In some embodiments, the local sensor switch 405 may be additionally configured to collect user authentication data and notify the user of the device status.

In some embodiments, the local sensor switch 405 includes a biometric sensor. In some embodiments, the biometric sensor is used to collect user biometric data to enroll and authenticate a user of the device and/or a transaction from the device to the merchant and/or merchant acquirer. In some embodiments, the biometric data is managed by a user of the device. In some embodiments, the biometric data may be one or more of the following: a user's face, a user's finger, a user's fingerprint, a user's iris, a user's voice, a user's heart rhythm, a user's physical quality, and any other biometric identification of a user.

In some embodiments, the local sensor switch 405 includes a touch sensor. In some embodiments, the touch sensor is used to gather user-created data to register and authenticate a user of the device and/or a transaction from the device to a merchant and/or merchant acquirer. In some embodiments, the touch pattern and sequence data can be managed by a user of the device using a touch sensor.

in fig. 4, pPOS device 400 further includes a second MCF 441. The second MCF 441 is configured to format and transmit the encrypted transaction data to the merchant acquirer. In some embodiments, the secure MCF 406 and/or the second MCF 441 are configured to format and transmit the encrypted transaction data to the merchant acquirer. The second MCF 441 is additionally configured to transmit the merchant image transaction to the merchant. In some embodiments, the secure MCF 406 and/or the second MCF 441 are additionally configured to transmit the merchant image transaction to the merchant.

In some embodiments, the secure MCF 406 and/or the second MCF 441 may be configured to perform I/O (input/output) functions. In some embodiments, secure MCF 406 and/or second MCF 441 may be configured to perform I/O (input/output) functions with certified EMV level 3 (L3) payment applications, where EMV stands for Europay, MasterCard, and Visa.

Fig. 5 illustrates a second personal point of sale (pPOS) device 500, according to some example embodiments, said second pPOS device 500 configured to provide a merchant transaction image and merchant transaction image synchronization of a "card present" e-commerce transaction and/or a merchant payment in a vehicle (where the merchant transaction image is created in a secure MCF (microcontroller function) and the external sensor data is provided by an external data sensor switch). pPOS device 500 of FIG. 5 is similar to pPOS device 400 of FIG. 4, except that pPOS device 500 also has external data sensor switch 550 that provides external sensor data 520.

Specifically, FIG. 5 shows that pPOS device 500 includes a secure microcontroller function (MCF)506, a secure element 537, a second MCF 541, a reader 502, a local sensor switch 505, and an external data sensor switch 550. Fig. 5 also shows that pPOS device 500 includes these interfaces: interface 501 to transaction data, interface 511 from secure MCF to reader, interface 512 from secure element to secure MCF, interface 531 from local sensor switch to secure element, interface 552 from external data sensor to external sensor data, interface 521 from external data sensor switch to secure element, interface 545 from second MCF 541 to secure MCF 506, interface 565 to merchant, interface 595 to merchant mirror synchronization, and interface 585 to merchant acquirer.

The functional components of fig. 5, such as the safety microcontroller function (MCF)506, the safety element 537, the second MCF 541, the reader 502 and the local sensor switch 505, all behave and are configured in a similar manner to their corresponding functional components in fig. 4.

In addition, FIG. 5 also shows an external data sensor switch 550. The external data sensor switch 550 may transmit the external sensor data 520 to the secure element 537.

In some embodiments, the external data sensor switch is configured to process external data of the device. In some embodiments, the external data sensor switch is configured to verify, manage, and/or create a transaction. In some embodiments, the external data sensor switch allows external data access to the configuration and processing of the payment kernel by the merchant, merchant acquirer, payment issuer, and/or identification issuer. In some embodiments, the external data sensor switch allows external data access to the configuration and processing of the payment kernel by the merchant, merchant acquirer, payment issuer, and/or identification issuer, where the external data is processed by the external data sensor switch. In some embodiments, the external data sensor switch provides one or more of the following functions: (1) a sensor data validation and filter; (2) data identification by type and/or sensor and/or interface and/or communication protocol; (3) data association between data type and sensor; (4) data fusion between data, communication protocols, and data types.

In some embodiments, pPOS device 500 may authenticate the merchant to pPOS device 500 in the customer's vehicle using external data elements and sources. The external data includes the physical address of the merchant, geolocation data, cell tower phone data, local merchant bluetooth and Wi-Fi data from beacons or hotspots.

In some embodiments, the external data may include sensor data, such as cellular signals, WiFi (wireless local area network) signals, UHF (ultra high frequency) signals, beacon signals, V2X (vehicle-to-infrastructure and/or vehicle-to-vehicle) radar signals, image data. In some embodiments, the external data may include sensor data consisting of one of: geographic location data, bluetooth or bluetooth low energy orientation and signal power, WiFi (wireless local area network) signals, GSM (global system for mobile communications) signals, NFMI (near field magnetic induction) signals, image data, radar data, V2X (vehicle-to-infrastructure and/or vehicle-to-vehicle) radar signals.

In some embodiments, the external data type is an RF (radio frequency) signal comprising one or more of the following: WiFi (wireless local area network) signals, bluetooth or bluetooth low energy signals, GSM (global system for mobile communications) signals, NFMI (near field magnetic induction) signals, V2X (vehicle-to-infrastructure and/or vehicle-to-vehicle) radar signals, UHF (ultra high frequency) signals, HF (high frequency) signals, LF (low frequency) signals. In some embodiments, the external data type is image data comprising one or more of: images and/or video from a side-looking camera, a front-facing camera, or a rear-facing camera on a vehicle; images and/or video from a side-looking camera, a front-facing camera, or a rear-facing camera of the second vehicle.

With respect to sensor data validation and filters, in some embodiments, a sensor data filter is a process or capability that removes data errors, such as measurement errors, inconsistent data, and/or duplicate data, from a sensor. One example would be to obtain WiFi data from a merchant, and some of the data lacks data elements. The filter will remove/delete the data.

With respect to data associations between data types and sensors, in some embodiments, sensor data associations are the ability to understand collected data as it applies to other data in appropriate scenarios. Data association is the ability to extract data from a variety of sources and obtain the benefit of determining a more informed way to proceed from understanding the relationships between the data. One example would be to combine WiFi merchant data with geo-location user cellular data as a way of determining that the user is at a merchant location.

With respect to data fusion between data, communication protocols, and data types, in some embodiments, sensor data fusion is a process that integrates multiple data sources to produce more consistent, accurate, and useful information than any individual data source provides. An example of this would be the creation of a new event/transaction from WiFi merchant data with a pos device that makes a payment with the geographic location user cellular data and the user.

in some embodiments, data association and fusion includes one or more of the following functions: sensor data collection and data event verification; correlation of sensor data events with image processing data and/or geo-location data and/or transaction history; fusion of sensor data events with image processing data and/or geo-location data and/or transaction history.

Fig. 6 illustrates a third personal point of sale (pPOS) device 600, according to some example embodiments, the third pPOS device 600 configured to provide a merchant transaction image and merchant transaction image synchronization (where the merchant transaction image is created in a reader) for "card-in-card" e-commerce transactions and/or merchant payments in a vehicle. pPOS device 600 of FIG. 6 is similar to pPOS device 400 of FIG. 4, except that the merchant image creator 610 and data encryption 670 functions (or components) have been "moved" from the secure MCF to the reader.

Specifically, fig. 6 shows that pPOS device 600 includes a secure microcontroller function (MCF)606, a secure element 637, a second MCF 641, a reader 602, and a local sensor switch 605. Fig. 6 also shows that pPOS device 600 includes these interfaces: interface to transaction data 601, interface from secure MCF to reader 611, interface from secure element to secure MCF 612, interface from local sensor switch to secure element 631, interface from secure element to reader 635, interface from second MCF 641 to secure MCF 606, interface to merchant 665, interface to merchant mirror sync 695, and interface to merchant acquirer 685.

The functional components of fig. 6, such as the safety microcontroller function (MCF)606, the safety element 637, the second MCF 641, the reader 602, and the local sensor switch 605, all function in a similar manner and are configured in a similar manner to their corresponding functional components in fig. 4, except for the safety microcontroller function (MCF)606 and the reader 602.

In FIG. 6, the functionality of merchant image creation 610 and data encryption 670 has been added to reader 602. Accordingly, the reader 602 may be configured to create a merchant image transaction from the payment and/or customer identification data elements, verify the merchant image transaction, and read the payment and/or identity instrument. The reader 602 may also be configured to filter transaction data, where filtering includes identifying payment and/or customer identification data elements in a transaction. In some embodiments, the reader 602 may be an authenticated EMV level 1 contact and/or contactless reader, where EMV stands for Europay, MasterCard, and Visa.

In fig. 6, the functions of merchant image creation 610 and data encryption 670 have been removed from the secure MCF 606. Accordingly, the secure MCF 606 is configured to validate merchant image transactions. However, secure MCF 406 may still be otherwise configured to provide application and data level encryption and hardware/software tamper detection. The secure MCF 606 may also include a payment kernel (not shown in fig. 6), and the payment kernel may be configured to process payments.

Fig. 7 illustrates a fourth personal point of sale (pPOS) device 700, according to some example embodiments, the fourth pPOS device 700 configured to provide merchant transaction mirroring and merchant transaction mirroring synchronization for "on-card" e-commerce transactions and/or merchant payments in a vehicle (where the merchant transaction mirroring is created in the reader and the external sensor data is provided by the external data sensor switch). pPOS device 700 of FIG. 7 is similar to pPOS device 600 of FIG. 6, except that pPOS device 700 also has external data sensor switch 750 that provides external sensor data 720.

Specifically, FIG. 7 shows pPOS device 700 includes a secure microcontroller function (MCF)706, a secure element 737, a second MCF 741, a reader 702, a local sensor switch 705, and an external data sensor switch 750. Fig. 7 also shows that pPOS device 700 includes these interfaces: interface to transaction data 701, interface from secure MCF to reader 711, interface from secure element to secure MCF 712, interface from local sensor switch to secure element 731, interface from external data sensor to external sensor data 752, interface from external data sensor switch to secure element 721, interface from second MCF 741 to secure MCF 706 745, interface to merchant 765, interface to merchant mirror synchronization 795, and interface to merchant acquirer 785.

The functional components of fig. 7, such as the safety microcontroller function (MCF)706, the safety element 737, the second MCF 741, the reader 702, and the local sensor switch 705, all operate and are configured in a similar manner to their corresponding functional components in fig. 6.

in addition, FIG. 7 also shows an external data sensor switch 750. The external data sensor switch 750 may transmit the external sensor data 720 to the secure element 737.

Fig. 8 illustrates a process flow 800 for a "card present" transaction performed with a personal point of sale (pPOS) device in conjunction with a merchant transaction image, according to some example embodiments.

In the process flow 800 of FIG. 8, flow begins by checking whether there is data in the buffer waiting to be processed. If the answer is yes (i.e., there is data in the buffer pending processing), the process flow 800 checks if customer data or payment data is found. If not, process flow returns to checking whether there is data in the buffer waiting to be processed. If so, process flow continues to create customer mirror data elements with local sensor switch data, wherein the local sensor switch inputs the data elements. Next, process flow continues to create device mirrored data elements with external data sensor switch data, wherein the external data sensor switch inputs the data elements. The process flow 800 also encrypts the data with the merchant, merchant acquirer, or user (i.e., customer) key in parallel. After creating the mirrored data and encrypting the customer/payment data, process flow 800 returns to the beginning through point a and then again checks whether there is data in the buffer waiting to be processed. Now, if the answer is yes and there is still data in the buffer waiting to be processed, process flow 800 continues with the steps described above. However, if the answer is no and there is no more data in the buffer waiting to be processed, process flow 800 continues to the step on the left side of FIG. 8. Here, there are two parallel series of processing steps. In a first series of processing steps, the encrypted merchant acquirer data is formatted into merchant acquirer messages. The process flow 800 then sends the formatted message to the merchant acquirer. In a second series of processing steps, the process flow 800 validates the merchant image data. Next, process flow 800 creates a merchant transaction image and then sends the merchant transaction image to the merchant.

FIG. 9 illustrates a detailed view of a "merchant transaction image" creation process (which is part of the process flow of FIG. 8) in accordance with some example embodiments. Specifically, FIG. 9 is a detailed view of the right side of the process flow of FIG. 8 (i.e., creating mirrored data with local sensor switch data and external data sensor switch data). Fig. 9 shows a process flow 900, which process flow 900 begins with the step "yes, there is data waiting to be processed in the buffer" of fig. 8.

In FIG. 9, process flow 900 begins after checking and finding that there is data pending in a buffer (steps from FIG. 8, not shown in FIG. 9), a customer data buffer is acquired process flow 900 assumes that payment or identification data has been found, process flow 900 shows that there are two types of data, (1) customer payment data associated with the payment, (2) customer identification data associated with the identification, then customer and device data mirroring is created, where creating a data mirroring from payment and/or customer identification data elements includes using one or more of the following four data encoding functions data conversion, data mapping, data masking, and data masking process flow 900 shows that the data encoding functions additionally include using local sensor data and external sensor data to seed data elements initialization arrays and/or modeling functions for each type of data element to be converted, mapped, masked, and randomized (e.g., data element indexing, user preference filter and merchant preference filter), where local sensor switch transmits local sensor data and external data sensor switch transmits external sensor data, process flow switch data 900, process flow data further data is shown as if there is a local sensor data element to be processed, then a local sensor data buffer, a local sensor data is not more than a local sensor data processing, a local sensor data processing process flow 900, and a process flow sensor data is not displayed, and if the local sensor data is not more data is not included as a local sensor data processing data element, a wireless sensor data processing data buffer, a wireless sensor processing data element, a wireless sensor processing data buffer, a wireless sensor processing data element, then a wireless sensor processing data buffer, a wireless sensor processing data buffer, a wireless sensor processing process flow 900, a wireless sensor processing data processing.

FIG. 10 illustrates a flow chart of method steps for providing a transaction image of a merchant transaction using a personal point of sale (pPOS), according to some example embodiments. As shown in fig. 10, the method 1000 begins at step 1010 where the method filters transaction data, where the filtering includes identifying payment and/or customer identification data elements in the transaction. The method then continues to step 1020. In step 1020, the method creates a merchant mirrored transaction from the payment and/or customer identification data elements, wherein creating includes using a data encoding function. Next, at step 1030, the method validates the merchant image transaction, wherein validating includes authenticating data elements in the merchant image transaction.

in this specification, example embodiments have been presented with a selected set of details. However, those of ordinary skill in the art will understand that many other example embodiments may be practiced that include a different selected set of these details. The following claims are intended to cover all possible example embodiments.

The various aspects, embodiments, implementations or features of the described embodiments may be used alone or in any combination. Various aspects of the described embodiments may be implemented in software, hardware, or a combination of software and hardware.

The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the described embodiments. However, it will be apparent to one skilled in the art that the specific details are not required in order to practice the described embodiments. Thus, the foregoing descriptions of specific embodiments are presented for purposes of illustration and description. The description is not intended to be exhaustive or to limit the described embodiments to the precise form disclosed. It will be apparent to those skilled in the art that many modifications and variations are possible in light of the above teaching.