Systems, methods, and computer program products for providing a contactless protocol.

(54) Title: SYSTEMS, METHODS AND PRODUCTS OF COMPUTER PROGRAMS TO PROVIDE A PROTOCOL WITHOUT CONTACT.

(54) Title: SYSTEMS, METHODS, AND COMPUTER PROGRAM PRODUCTS FOR PROVIDING A CONTACTLESS PROTOCOL.

(57) Summary

Software systems, methods, and products are provided to manage contactless transactions. A first touch is made when a system is located in a predetermined proximity with respect to a payment terminal. A first selection command is received from the payment terminal that includes an AID corresponding to a first application. A first response based on the first selected command is transmitted to the payment terminal. The payment terminal receives a data request that includes information indicating compatible data types. A second response based on the data request and including transaction data is transmitted to the payment terminal. The transaction data includes at least a portion of the business data stored in the at least one memory.

(57) Abstract

Systems, methods and Computer program products are provided for managing contactless transactions. A first tap is performed when a system is placed within a predetermined proximity to a payment terminal. A first select command including an AID corresponding to a first application is received from the payment terminal. A first response based on the first select command is transmitted to the payment terminal. A data request including Information indicating supported data types is received from the payment terminal. A second response based on the data request and including transaction data is transmitted to the payment terminal. The transaction data ineludes at least a portion of commerce data stored in the at least one memory.

COMPUTER PROGRAMS SYSTEMS, METHODS AND PRODUCTS FOR

PROVIDE A PROTOCOL WITHOUT CONTACT

FIELD OF THE INVENTION

The examples of aspects described herein refer in general terms to contactless protocols and, more particularly, to computer software systems, methods and products to provide a contactless protocol that enables interoperation between mobile devices, communication readers Near Field (NFC) and Point of Sale Systems (POS).

BACKGROUND OF THE INVENTION

NFC technology is a standards-based wireless communication technology that enables the exchange of data between devices located in a certain proximity, generally less than ten centimeters away. One use of NFC technology is in conducting contactless transactions, including payment, access, and ticketing. For example, an NFC-enabled mobile device may have a payment application and payment account information (i.e., credentials associated with a financial instrument such as a debit or credit card) issued by a consumer financial institution. Each payment application can store and manage multiple

Ref.:252197 business data sets associated with multiple merchants, manufacturers or brands in a security element. The application and payment account information are generally encrypted and stored in a secure area on the mobile device. In turn, the mobile device can use NFC technology to communicate with NFC-enabled point-of-sale (POS) systems in locations with attendants, such as businesses, and locations without attendants, such as vending machines. To pay, the consumer simply brings the mobile device up to approximately ten centimeters from a POS system that allows contactless payment and the transaction is made. The process is typically the same as that for contactless debit and credit cards.

Sometimes it is referred to placing the mobile device or contactless debit or credit card near a reader with NFC enabled so that these connect your communication as wave [shake] or tap [touch]. An app for a mobile device that allows consumers to tap to pay on an NFC-enabled POS system is generally called a wallet app or mobile wallet app for customers. A payment-related application is generally referred to as a payment application. Common contactless payment apps are made available using any of the following technologies: American Express® ExpressPay, Discover® ZIP, MasterCard® PayPass, or Visa® PayWave. .

You can also use NFC to read product information or receive special offers, loyalty information, or rewards, for example, NFC tags, smart posters, or smart billboards. An offer, loyalty and reward application is referred to herein as a commercial application.

A technical challenge associated with the use of commercial and payment technologies cooperatively involves the ability to allow the same touch event that sends payment information to include additional information associated with merchant loyalty cards, offers, rewards, and the like. To this end, messaging technologies in existing NFC readers or NFC enabled POS payment terminals could be improved to effectively support messaging technology that takes and / or receives both payment credentials (using payment protocols previously mentioned) as other commercial data (loyalty, offers, prizes, etc.) of mobile devices used to carry out transactions. Another technical difficulty involves publishing business items (eg, offers, loyalty card credentials, rewards, and the like) on a mobile device, so that those business items can, in turn, be presented as part of a POS transaction. typical (eg, a purchase).

BRIEF DESCRIPTION OF THE INVENTION

The exemplary embodiments included herein meet the needs mentioned above by providing computer software systems, methods and products to provide a contactless protocol.

In one embodiment, a system for managing contactless transactions includes at least one memory that functions to store business data and financial instrument data, and at least one processor coupled to the at least one memory. A first touch is made, where the first touch occurs when the system is located in a predetermined proximity with respect to a payment terminal. A first selection command is received from the payment terminal that includes an AID corresponding to a first application. A first response based on the first selected command is transmitted to the payment terminal. A data request is received from the payment terminal that includes information indicating compatible types of data. A second response based on the data request and including transaction data is transmitted to the payment terminal. The transaction data includes at least a portion of the business data stored in the at least one memory.

In another embodiment, a method of managing contactless transactions includes: performing a first touch, where the first touch occurs when the mobile device is placed within a predetermined proximity of a payment terminal; receiving from the payment terminal a first selection command that includes an AID corresponding to a first application; transmitting to the payment terminal a first response based on the first selection command; receive from the payment terminal a data request that includes information indicating the types of data supported; and transmitting to the payment terminal a second response based on the data request, wherein the second response includes transaction data. The transaction data includes at least a portion of the business data stored in at least one memory.

In another embodiment, a non-transient computing means has sequences of instructions stored therein to cause one or more processors to: perform a first touch, where the first touch occurs when the mobile device is placed within a predetermined proximity of a computer terminal. payment; receive from the payment terminal a first selection command that includes an AID corresponding to a first application; transmit to the payment terminal a first response based on the first selection command; receive from the payment terminal a data request that includes information indicating the types of data supported; and transmit to the payment terminal a second response based on the data request, wherein the second response includes transaction data. The transaction data includes at least a portion of the business data stored in at least one memory.

BRIEF DESCRIPTION OF THE FIGURES

The characteristics and advantages of the examples of embodiments of the invention included herein will be more evident from the detailed description indicated below, when taken in conjunction with the following figures.

FIG. 1 is a graphical representation of a platform architecture according to an embodiment example.

FIG. 2 illustrates a one-touch timing diagram according to an example mode.

FIG. 3 shows a timing diagram illustrating a business process flow that includes a double tap and post-transaction data transmission according to an example modality.

FIG. 4 shows a timing diagram illustrating a business process flow that includes a double tap and post-transaction data and payment transmissions according to an example modality.

FIG. 5 illustrates an example of multi-block data flow according to an example of embodiment.

FIG. 6 illustrates screen captures or windows generated by the graphical user interface for a wallet application in accordance with an embodiment example of the present invention.

FIG. 7 illustrates a flowchart illustrating an instant offer implementation example in accordance with an embodiment of the present invention.

FIG. 8 is a collaboration diagram of functional modules used in a computer system in accordance with an example embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

The exemplary modalities included herein are directed to computer program systems, methods, and products to provide a contactless protocol, which are described herein below in terms of a merchant transaction example. This description is not intended to limit the application of the modality examples included herein. In fact, after reading the following description, it will be obvious to the expert in the relevant technique (s) how to implement the following modality examples in alternative modalities (eg, involving mass transit transactions that require a wireless communications connection between a mass transit terminal and a mobile device).

The terms application, applet, applet, tool and / or the plural form of these terms are used interchangeably herein to refer to an application (that works independently or in conjunction with other applications) or set or subset of instructions or codes that, when executed by one or more processors (eg. , in a mobile device, card reader, terminal, point of sale (POS) system or server) make the processor or processors perform specific tasks. For example, a wallet application can be used to perform interface or transaction related functions such as storing, processing, accessing, or transmitting account, financial, loyalty, offer, or membership data. A wallet application can also incorporate or interact with one or more payment applications, such as the American Express® ExpressPay payment applets, NetWork Zip^YE from Discover®, PayPass ™ from MasterCard® and payWave ™ from

Visa.

In general terms, trade-related services are made available through a series of applications available on various different platforms.

The first application (or series of applications) exists on a server within a mobile business platform (MoCom). The MoCom platform is responsible for the management of consumer data, including offers and loyalty programs. Additionally, the MoCom platform serves as a campaign manager for deals, as it provides a remote data warehouse for deals that are made available to the consumer through available merchant portals within a wallet application.

There is a second app on a mobile device in the form of a wallet app. The wallet application provides the consumer's primary user interface (Ul) and additional business application services through which the wallet application can access additional resources in a security element (SE). its acronym in English) of a mobile device.

There is a third application in a security feature of a mobile device in the form of a JavaCard applet. This applet stores trade related data such as loyalty and offer data and provides an interface through which the data can be managed. The applet can be accessed using commands from an Application Protocol Data Unit (APDU) as defined in the

<td>International Organization</td><td>of</td><td>Standardization (ISO,</td><td>by</td><td>their</td>

<td>7816-4.</td><td></td><td></td><td></td><td></td>

<td>The fourth application</td><td colspan="2">exists in a reader</td><td>with</td><td>NFC</td>

<td>enabled (mentioned in</td><td>the</td><td>simply present</td><td>how</td><td>a</td>

reader). The reader may be a standalone device or attached to (and managed by) a point of sale (POS) terminal. This application facilitates or provides access to the interface with a security element on a mobile device, performing specific tasks that optimize the APDU's command / data exchange tasks. For example, this includes reading offers or loyalty information after placing a mobile device near a reader (that is, a touch).

There is a fifth application (or series of applications) in a merchant's POS system, including a POS terminal and any additional merchant-specific software / hardware. These applications manage the data related to payment / loyalty / offers / prizes received from the security element on a mobile device through a reader. In most cases, this data is then sent to one or more MoCom or merchant-specific platforms.

FIG. 1 is a graphical representation of a platform architecture according to an embodiment example. As shown in FIG. 1, system 100 includes a mobile device 110 with communication coupled with a contactless reader 120 (eg, proximity or NFC) and a mobile wallet platform 130. Reader 120 also couples its communication with a POS terminal 140 POS terminal 14 0 can be found inside the same protective cover as reader 120. Alternatively, the POS terminal 140 and reader 120 couple their communication with each other, but each of these components is placed separately.

Mobile device 110 may be, for example, a cell phone or the like, and include an Illa processor, a memory 111b, a lile contactless front end (CLF), a llld baseband modem, and a user interface as a screen (not shown). The llld baseband modem is a digital modem used for mobile network communications. The CLF lile is a set of circuits that deals with the analog aspect of NFC or contactless communications and the communication protocol layers of a contactless transmission link. The

CLF lile is also used to exchange data between the reader 120 and a security element (or SE) 112 included in the mobile device 110, for example, to carry out contactless transactions.

Security element 112 can be implemented as a Universal Integrated Circuit Card (UICC), integrated SE card, secure micro-card (microSD) and the like. Security element 112 is generally considered secure because it is a standalone system that includes specialized memory and is protected by proven hardware and software hardening techniques through independent analysis.

Security element 112 includes (eg, stores therein) one or more business applets 113. Each business applet 113 is associated with a business service and an account issued by a business service provider (SP). A service provider is a company, organization, entity, or the like that provides services to customers or consumers. Examples of service providers include entities that issue accounts such as banks, merchants, card associations, marketing companies, and transit authorities. A service can be an activity, capacity, functionality, work or use allowed or provided by a service provider, such as a payment service, credit, debit, checks, gifts, offers or loyalty program, transport pass service and the like .

A commercial service provider may provide (or have provided) a security element 112 with one or more individual commercial subprograms 113. In addition, other independent service providers may provide (or have provided) Security Element 112 with their own commercial subprogram / s 113. Generally, a commercial applet 113 stores both offer-related and loyalty-related data, which provides an APDU interface through which this data can be managed. Business applet 113 functions as a generic storage container allowing multiple loyalty / offer services to share mechanisms (eg, security feature, mobile device) for loyalty / offer data management. If memory constraints and performance requirements limit the amount of loyalty / offer data that can be stored in security element 112, additional data can be stored in the memory of mobile device 111b and can be managed by the consumer via of commercial tool 115. For example, any offer-related graphic image can be stored in memory 111b to optimize memory allocation of the security element. The corresponding offer platform 131, loyalty platform 132 or prize platform 133 may be responsible for managing loyalty / offer data.

The commercial applet 113 includes a table of merchant data stored in the cache memory that allows to store / manage all the data related to a given merchant. This allows the commercial data of a given merchant to be pre-loaded into security element 112 or mobile device 110 by a wallet application. The following defines examples of business elements (and their corresponding label values ​​during Label Length Value (TLV) encoding that are included in the cached merchant data table.

This data is stored in a register-oriented buffer memory. In an example modality, a merchant identifier (Merchant Identifier) ​​is used as the key field for search / retrieval tasks. Optionally, an index (or table with check codes) can be created to improve performance.

One or more business applets 113 may be loaded into security element 112, for example, during the manufacture and / or configuration of security element 112 and can be customized to allow its use in conducting business transactions. A commercial applet 113 interfaces with a reader 120 through a commercial application programming interface (API) 123. In an example modality, a commercial applet 113 is in the form of a JavaCard applet and can be accessed using APDU commands, as defined in ISO 7816-4. In particular, commercial applet 113 communicates commercial elements to reader 120 through security element 112, using ISO 7816 commands through the ISO protocol.

14443 from NFC.

Security element 112 may also include one or more payment applets 117, wherein each payment applet 117 is associated with a payment service and an account issued by a payment service provider. One or more payment applets 117 can be loaded into security element 112, for example, during the manufacture and / or configuration of security element 112 and can be customized to allow its use in conducting payment transactions. A payment applet 117 interfaces with reader 120 through API 124. In one embodiment example, a payment applet 117 is in the form of a JavaCard applet and can be accessed using APDU commands, such as defined in ISO

7816-4. Payment applet 113 also communicates payment items to reader 12 0 through security item 112, using ISO 7816 commands through NFC's ISO 14443 protocol.

It should be understood that other communications between the aforementioned devices may include communications with or through other hardware, software, and / or intermediate systems, and that communications may include receiving, transferring and / or managing data.

A wallet application 114 stored on a mobile device 110 includes instructions that, when executed by the processor of the mobile device 110, cause the mobile device 110 to act as an instrument, for example, to process transactions, such as business transactions and / or contactless payment. The wallet application 114 communicates using APDU commands as defined in ISO 7816-4 with the commercial applet 113 through the commercial API 116 and with the paid applet 117 through the paid API 118.

Business tool 115 is a component of Wallet application 114 that provides an interface for consumers to manage business items (eg, loyalty card credentials, offers, and rewards), for example, through screen interactions or the user interface of a mobile device. Business tool 115 maintains, for example, a master list of business items on the computer in a memory of the mobile device (eg. eg 111b). In turn, a subset of offers identified as ready for use is moved to security element 112 for communication to contactless reader 120 and POS terminal 140. Confidential information, such as loyalty account identifiers, can be stored in security element 112.

Payment tool 119 is a component of wallet application 114 that provides an interface for consumers to manage payment items (eg, credit or debit card credentials), for example through screen interactions or the user interface of a mobile device.

Reader 120 includes a commercial reader application 121 (referred to herein simply as a reader application) and a POS interface 122. Reader 120 manages two interfaces: an interface with security element 112 on mobile device 110 and the other interface with the POS terminal 140 which includes a reader interface 141 and a commercial application data manager 142. The functionality of the reader 120 is the same regardless of whether the reader 120 is autonomous and connects to, or integrates with, the merchant's payment terminal or POS. The contactless payment functionality is also found in reader 120, but is not shown.

Mobile device 110 also couples its communication to a mobile wallet platform 130, which in turn couples its communication to a bidding platform 131, loyalty platform 132 and prize platform 133. The Bidding Platform 131, Loyalty Platform 132, and Rewarding Platform 133 may be referred to collectively as a Mobile Business Platform (MoCom) 134 and these are implemented on one or more servers, individually and collectively referred to in the present as a MoCom server (not shown).

In one embodiment, a customer can use mobile device 110 to perform a contactless transaction at a POS equipped with a reader 120. The customer places mobile device 110 within a required predetermined proximity of contactless reader 120 (ie, touches it ), which causes the mobile CLF of mobile device 110 to communicate with reader 120 using, for example, NFC ISO 14443 protocols. Reader 120 also communicates with wallet application 114, business applet 113 and / or payment applications on mobile device 110 to perform contactless transactions.

A security element uses a Payment System Proximity Environment (PPSE) that serves as a directory of available credentials currently stored in security element 112. Each credential is assigned a corresponding application identifier (AID) associated with a payment application and stored in the PPSE. When a NFC-enabled mobile device containing security element 112 is placed near an NFC-enabled contactless reader, the contactless reader reads the credential and completes the transaction. However, before doing so, the reader is initialized.

On mobile device 110, PPSE is an application that is used to maintain a list of payment applications stored in security element 112 and provides accessibility to each payment application stored on mobile device 112 by making them visible or invisible (i.e. accessible) for systems or devices.

Reader initialization

The initialization of reader 120 will now be described in more detail. In one embodiment, reader 120 implements a function indicated as an Entry Point Manager (EPM) to control which application is selected on a mobile device. In this mode, the EPM controls whether the reader 120 sends a command to the mobile device 110 to select an application to carry out a commercial transaction or a command to carry out a payment transaction. A command to select a business application is referred to herein as Select Business Type. A command to select a paid application is referred to herein as Select PPSE.

The EPM also controls the start mode of the reader 120 and the subsequent change of the application during a finalization process. Therefore, the EPM facilitates the switch (in reader 120) between the Select trade type command for a commercial transaction and the Select the command.

PPSE for payment transactions.

Start a business transaction on a reader

A reader can be configured to initiate a business transaction on a reader in various ways, which are described in more detail below. In one mode, referred to herein as automatic startup, reader application 121 is the default application of reader 120. Being the default application allows the reader application 121 to be available to the consumer as the first touch option (ie after initial communication coupling between the mobile device 110 and the contactless reader 120).

Another mode, called manual start, allows manual intervention to start the reader 121 business application. Manual intervention can be presented in the form of a POS 13 0 terminal command (eg initiated using a user interface). POS terminal) or a consumer who selects a commercial application on a mobile device using the commercial tool 115.

Another way, called payment with post-transaction data, involves controlling how many payments are managed in a chain of activities. If a merchant supports post-transaction data provisioning, for example, then payment and receipt of merchant data can be accomplished in the same touch event, such as after the final transaction total has been calculated.

Another way is called payment first. The payment option first works in conjunction with automatic start mode and / or manual start mode to initiate a Select PPSE command for payment and then a Select merchant type command to obtain business data (eg. ., loyalty data, offer data, prize data and the like). Business data is referred to interchangeably herein as business elements.

Auto start mode

With reference to FIG. 1, Automatic startup mode provides commercial functionality to reader 120 at the beginning of the POS completion process. When the mobile device 110 touches the reader 120, the reader application 121 causes the reader 120 to send a Select type of business message to the mobile device 110, including the AID corresponding to the commercial application used to carry out a transaction without Contact. If the mobile device 110 accepts the message, it responds by sending a positive response message. The reader 120 then sends the Get Data command to the mobile device 110

Commercial. The Get Business Data command contains merchant-specific data that security element 112 uses to conduct a business transaction. Also, after successfully completing the Get Business Data transaction, control passes to mobile device 110. If reader 120 receives a negative response to the Select Business Type message, it returns control to EPM.

Manual start mode

Still referring to FIG. 1, in manual start mode, reader 120 starts reader application 121 in response to a request from the consumer or POS terminal 140. In this manual start mode, when starting a completion process reader 120 is in a PPSE selection state. For a consumer-initiated business transaction, the consumer selects the business application on the consumer-facing device (eg. , the commercial tool 115). Then the consumer-facing device sends a command to the reader

120 to start the reader application 121 through the EPM. For a business transaction initiated by terminating POS, POS terminal 140 sends the command to reader 120 to initialize reader application 121. In one mode, this is initiated by a cashier through an interface on the terminal from POS 140.

After the reader 121 business application has been started on the reader 120, the business application works as described above in automatic startup mode.

Payment with post-transaction data

In the post transaction data payment mode, a payment transaction can be performed so that the post transaction data is communicated between the POS terminal 140, the reader 120 and the security element 112. This option allows initiation of the commercial protocol at the beginning of consumer completion, but reader 120 does not request payment until the final transaction total has been calculated.

POS terminal 140 sends a Post Transaction command to reader 120, for example, with a transaction identifier (ID) and redeemed coupon IDs. The reader 120 then transmits a touch request to make the payment. The touch allows reader 120 to first request payment credentials from security element 112 and then have reader application 121 send business data (eg, coupon data) to security element 112. Both functions are performed in a single touch of mobile device 110 on reader 120.

Pay first

In payment mode first, payment can be made first, before a business transaction. This option is adapted to a situation where the payment / PPSE process must precede any commercial processing. The payment mode first works in conjunction with the automatic and manual startup modes referred to above. Commercial and payment processing is accomplished in one touch.

EXAMPLE OF COMMERCIAL PROCESS FLOWS

Normal business process flow (one touch)

FIG. 2 illustrates a one-touch timing diagram 200 according to an example embodiment. The next flow of the process can begin as items you want to buy at a POS are scanned. For convenience, reader 120 (Figure 1) and POS terminal 140 (Figure 1) are illustrated as a single component and are collectively referred to as payment terminal 201. When applicable, each component (i.e., reader 120 or POS terminal 140) is referenced individually.

A merchant's POS 2 02 system may be a merchant's server used by a merchant to control the operation of payment terminal 201. In one example embodiment, merchant's POS 202 system sends a command to payment terminal 201 to activate the reader (Activate Reader) before scanning articles, as articles are scanned or after articles have been scanned. In each case, reader 120 prompts a user (or consumer) to place a mobile device 110 near reader 120, as shown in step 250 (Request 'touch'). In response to a request for the user to place a mobile device 110 near the reader 120 (step 250), a consumer touches the mobile device 110 with the reader 120 as shown in step 251.

Once the NFC connection is established between mobile device 110 and reader 120, the following command exchanges are initiated to initialize the service and process both a paid transaction and a business transaction. The processing and initialization exchanges of the payment transaction between the security element 112 and the reader 120 include steps 260 and the processing and initialization exchanges of the commercial transaction between the security element 112 and the reader 120 include the steps 262 Steps 260 may be performed before steps 262, after them, or at substantially the same time.

<td>With reference in</td><td>first place at</td><td>stages 262</td><td>, then</td>

<td colspan="2">having touched a mobile device with</td><td>the reader</td><td>120 the</td>

<td>reader 120 sends you</td><td colspan="3">a Select type command</td>

<td>trade to the item</td><td>security 112</td><td>With</td><td>an AID</td>

<td>private commercial</td><td>(Select AID</td><td>Commercial</td><td>) than</td>

indicate which business applet in security element 112 you are trying to cooperate with (e.g. business applet

113). In response to this, security element 112 sends a positive or negative response. A negative response (not shown) causes reader 120 to interrupt reader application 121 (Figure 1) and pass control to EPM (not shown). If the response is positive (Positive response), then reader 120 sends a (Obtain Business Data) command to security element 112 that specifies identification information, such as a merchant / business identifier and any additional

<td>fidelity,</td><td>offers</td><td>or</td><td>awards</td><td>they admit</td><td>that</td><td>information of</td>

<td>Location,</td><td>date</td><td>and</td><td>hour,</td><td>the version</td><td>of</td><td>the application</td>

<td>commercial</td><td colspan="2">reader</td><td colspan="2">121 admitted by</td><td>the</td><td>reader 120 and</td>

any merchant capacity data.

Security element 112 returns corresponding commercial elements (eg loyalty data, offer data, prize data) to reader 12 0 (Loyalty Data and Offers) according to the fields received in the Get Commercial Data command of reader 120. In one embodiment, business applet 113 incorporates a package containing business data (eg. , a buffer or set of buffers including loyalty data, bid data or prize data). In another embodiment, the buffer is pre-built using memory space on security element 112.

With reference to steps 260, in one embodiment, reader 120 begins payment processing by sending a request for PPSE (Select PPSE) to security element 112.

If the AID Select requests are successful

Commercial and Select the PPSE, as shown in step 264 (Read Success Indication), the payment terminal 201 sends the commercial application data and payment credentials received to the merchant's POS system 202 for processing (Commercial Data and Payment). In turn, merchant 202's POS system records the loyalty identifier and offers (not shown) and applies any applicable discounts as product scanning continues, as shown in step 266. This concludes the process. commercial application and leads to payment processing.

After completing the scan and having approved a transaction amount for payment, a payment authorization request is made to a payment platform 203 (Payment Authorization Request). For its part, the payment platform 203 returns an authorization result (Authorization Result) that indicates whether or not the payment was authorized.

Referring again to steps 260, in one embodiment, a request to Select PPSE by reader 120 to security element 112 causes security element 112 to return a payment AID from the PPSE indicating which payment subprogram (and , therefore, which corresponding payment network) should be used to carry out the payment transaction (PPSE payment AID). In response to this, reader 120 sends Select AID indicating that it supports the particular applet (Select AID). Security element 112 sends file control information (FCI) associated with the payment applet (eg, FIG. 1, 117) to reader 120. Similarly, the security element Security 112 sends other card information and payment to reader 12 0 (Card / Payment Details).

FIG. 3 shows a timing diagram 300 illustrating a business process flow that includes a double tap and post-transaction data transmission according to an example embodiment. This modality can be used when a merchant has data to communicate in turn to a mobile device. For convenience, reader 120 (Figure 1) and POS terminal 140 (Figure 1) are illustrated as a single component and are collectively referred to as payment terminal 301. When applicable, each component (i.e., reader 120 or POS terminal 140) is referenced individually. Generally, the POS 140 terminal (Figure 1) initiates a second touch request by sending a Post-Transaction Command command to the reader.

120. For its part, reader 120 requests a second touch from the consumer.

A merchant POS 3 02 system may be a merchant server used by a merchant to control the operation of the payment terminal 301. In one example embodiment, the merchant's POS system 302 sends a command to the payment terminal 301 to activate reader 120 (Activate Reader) before scanning articles, as articles are scanned or after articles have been scanned. In each case, reader 120 prompts a user to place a mobile device 110 near reader 120, as shown in step 350 (Request 'touch'). In response to a request for the user to place a mobile device 110 near the reader 120 (step 350), a consumer touches the mobile device 110 with the reader 120 as shown in step 351.

Once the NFC connection is established between mobile device 110 and reader 120, the following command exchanges are initiated to initialize the service and process both a paid transaction and a business transaction. The processing and initialization exchanges of the payment transaction between security element 112 and reader 120 include steps 360 and the processing and initialization exchanges of the commercial transaction between security element 112 and reader 120 include steps 362 Steps 360 can be performed before steps 362, after them, or at substantially the same time.

Referring first to steps 362, after having touched a mobile device 110 against reader 120, reader 120 sends a Select business type command to security element 112 along with a particular business AID (Select Business AID ) indicating which business subprogram in security element 112 you intend to cooperate with (eg business subprogram 113). In response to this, security element 112 sends a positive or negative response. A negative response (not shown) causes reader 120 to interrupt reader application 121 (Figure 1) and pass control to EPM (not shown). If the response is positive (Positive Response), then reader 120 sends a command to security element 112 that specifies identification information, such as a merchant / merchant identifier and any additional loyalty and offer programs that support that location information. , date and time, the version of the commercial application of reader 121 supported by the reader 120 and any merchant capacity data (Obtain Commercial Data). Security element 112 returns corresponding business elements (eg, loyalty data and offers) to reader 120 (Loyalty Data and Offers) based on the fields received in the Get Business Data command from reader 120. In a mode This is done by commercial applet 113 that incorporates a data packet (essentially a buffer or set of buffers including loyalty data and offers). In another embodiment, the buffer may be pre-built using memory space on security element 112.

Referring next to steps 360, in one embodiment, a request to Select PPSE by reader 120 to security element 112 causes security element 112 to return a payment AID from the PPSE indicating which payment applet ( and, therefore, which payment network) should be used to carry out the payment transaction (PPSE payment AID). In response to this, reader 12 0 sends Select AID indicating that it supports the particular applet (Select AID). Security element 112 sends FCI associated with the payment applet (eg, 117) to reader 120. Similarly, security element 112 sends other card information and payment to reader 120 (Data Card / Payment). If the requests to Select Business AID and Select PPSE are successful, as shown in step 364, payment terminal 301 sends you business application data and payment credentials received from merchant POS system 302 for processing (Commercial and Payment Data). In turn, merchant 302's POS system records the loyalty identifier and offers (not shown) and applies any applicable discounts as product scanning continues, as shown in step

366 .

After completing the scan and having approved a transaction amount for payment, a payment authorization request is made to a payment platform 303 (Payment Authorization Request). For its part, the payment platform 303 returns an authorization result (Authorization Result) that indicates whether or not the payment was made.

If there is data to return to payment terminal 301, the merchant's POS system creates a properly formatted Post Transaction Data with TLV command and sends the data to reader 120. After receiving a post transaction command, payment terminal 301 requests the consumer a second tap, as shown in step 368 (Request for 2nd 'tap').

With reference to step 369 and steps 370, when the mobile device 110 is placed near the reader 120 a second time as shown in step 369, the reader 120 sends a Select Trade Type command to security element 112 together with a particular business AID (Select Business AID) indicating which business subprogram in security element 112 you intend to cooperate with (eg business subprogram 113).

If a negative response is received, reader 120 interrupts the commercial application of reader 121. If a positive response is received, then reader 120 sends security element 112 the data received in the Post-Transaction Data command from the POS 140 (Post-transaction data). This concludes the commercial processing for this transaction.

FIG. 4 shows a timing diagram 400 illustrating a business process flow that includes a double tap and post-transaction data and payment transmissions according to an example modality. In this scenario, payment and post-transaction data are processed after the basket total has been calculated and all discounts applied. The use of this flow is controlled by a data element with reader start mode with a particular bit (p. eg, Payment with Post-Transaction Transaction) activated.

For convenience, the reader 120 (Figure 1) and the POS terminal 140 (Figure 1) are illustrated as a single component and are collectively referred to as a payment terminal 401. Where applicable, each component is referred to (is i.e. reader 120 or POS terminal 140) individually. Generally, a merchant POS system

402 initiates a second touch request by sending a post-transaction data command to reader 120. For its part, reader 120 requests a second touch from the consumer.

A merchant POS 402 system may be a merchant server used by a merchant to control the operation of payment terminal 401. In one example embodiment, merchant POS 402 sends a command to payment terminal 401 to activate the reader (Activate the Reader) before scanning articles, as articles are scanned or after articles have been scanned. In each case, reader 120 prompts a user to place a mobile device 110 near reader 120, as shown in step 450 (Request 'touch'). In response to a request for the user to place a mobile device 110 near the reader 120 (step 450), a consumer touches the mobile device 110 with the reader 120 as shown in step 451.

After an NFC connection has been established between mobile device 110 and reader 120, the following command exchanges start. Command exchanges are done to initialize the service and process both a payment transaction and a business transaction. The processing and initialization exchanges of the payment transaction between security element 112 and reader 120 include steps 472 and the processing and initialization exchanges of commercial transaction between security element 112 and reader 12 0 include stages 462 and 474.

Referring first to steps 462, after having touched a mobile device against reader 120, reader 120 sends a Select business type command to security element 112 along with a particular business AID (Select Business AID) indicating which business applet in security element 112 to cooperate with (eg, business applet 113). In response to this, security element 112 sends a positive or negative response. A negative response (not shown) causes reader 120 to interrupt reader application 121 (Figure 1) and pass control to EPM (not shown). If the response is positive (Positive Response), then reader 120 sends a command to security element 112 that specifies identification information, such as a merchant / merchant identifier and any additional loyalty and offer programs that support that location information. , date and time, the version of the commercial application of reader 121 supported by reader 120 and any merchant capacity data (Get Commercial Data). Security element 112 returns corresponding business elements (eg loyalty data and offers) to reader 120 (Loyalty Data and Offers) according to the fields received in the Get command

Business data from reader 120. In one embodiment, this is done by business applet 113 that incorporates a data package (eg, a buffer or set of buffers that include loyalty and offer data). In another embodiment, the buffer may be pre-built using memory space on security element 112.

At step 464, reader 120 signals to the consumer that the transaction has been completed and that equipment can be removed from payment terminal 401, causing reader 120 to send data from the commercial application to POS terminal 140 and , in turn, to the merchant's POS system for processing (Loyalty Data and Offers). A seller can continue processing the shopping basket.

Merchant POS system 402 registers loyalty identifier and offers (not shown) and applies any applicable discounts as product scanning continues, as shown in step 466. After having calculated the basket total, merchant POS system 402 sends a payment request to payment terminal 401 and sends post-transaction data to payment terminal 401 (if data is available for shipment ) (Send Post-transaction Data and Payment Request).

In step 468, the payment terminal 140 requests a touch to make the payment. For its part, reader 120 activates the reader field. When the mobile device 110 is detected in the field of the reader 120, the payment processing is performed, as shown in steps 472. In particular, the reader 120 makes a request to Select the PPSE to the security element 112 to make the security element 112 return a payment AID of the PPSE indicating which payment subprogram (and, therefore, what network Payment) should be used to complete the payment transaction (PPSE Payment AID). In response to this, reader 12 0 sends a Select AID command indicating that it supports the particular applet (Select AID). Security element 112 sends FCI associated with the payment applet (eg, FIG. 1, 117) to reader 120. Similarly, security element 112 sends other card information and payment to the reader 120 (Card / Payment Details).

With reference to steps 474, if the payment terminal 401 received post-transaction data from merchant's POS system 402, reader 120 starts business application 121 (Figure 1) and sends security element 112 the command Select type of business along with a particular business AID (Select Business AID) after touching a 12 0 mobile device a second time. The Select Merchant AID command identifies which business applet in security element 112 should be used to cooperate with reader 120. In response to this, security element 112 sends a positive or negative response. A negative response (not shown) causes reader 120 to interrupt reader application 121 (Figure 1) and pass control to EPM (not shown). If the response is positive (Positive Response), then reader 120 sends post-transaction data to security element 112 (Post-transaction Data), with TLVs correctly formatted.

This concludes the commercial processing for this transaction.

If the AID Select requests are successful

Commercial and Select the PPSE, the payment terminal 401 sends the payment application data and payment credentials received to the merchant's POS system 402 for processing (Card / Payment Data). For its part, the merchant's POS system sends platform 403 a payment authorization request (Payment Authorization Request). In turn, the payment platform 403 returns an authorization result (Authorization Result) that indicates whether or not the payment was authorized.

If the commercial information and payment credentials are successfully read, the reader 120 can provide a notification, either through an interface in the payment terminal 140, the commercial tool 115 (figure 1) or the payment tool 119 (figure 1), as shown in step 478 (Reading Success Indication).

Commercial message specifications

Data encryption

In one modality, all command / response data is encoded using the BER-TLV format (ISO 7816-4 Attachment D). In some cases, TLVs (Label, Length, Value) can be nested (embedded TLV). Due to the flexible nature of the TLV encoding format, tagged data can be placed in any order. This applies when both incoming and outgoing payload data is formatted. Furthermore, this data is stored in registry-oriented tables. The order of the TLV encoded data elements stored there is not critical. However, some data may be placed at the beginning of the registry to improve search / index performance. Therefore, the tables with log data included in this document are provided as samples for reference purposes.

A tag is encoded using a private tag class and a tag type that represents a primitive data object encoded in one or more subsequent bytes. Therefore, the first byte (tag class) is set to OxDR. In all cases, the label of the data element is defined in a single byte. Thus, the second byte of the label has the most significant bit (b8) set to 0. This allows valid label values ​​of up to 128 (0x00 - 0x7F).

Length encoding supports both short and long shapes. When the length is less than (&lt;) 128 bytes, the most significant bit (b8) is set to 0 and the actual length is specified in the remaining bits (b7-bl). When the length is greater than (&gt;) 128 bytes, the most significant bit (b8) is set to 1 (length mask = 0x80) and the remaining bits (b7-bl) define the number of subsequent bytes in the length field . Subsequent bytes encode an integer equal to the number of bytes in the value field.

BER-TLV example

Assuming that the incoming data uses a label value of 0x21 (consumer ID) with a length of 8 bytes and a value of (0x1122334455667788), the data is encoded as shown in Table 1:

TABLE 1

<td>Label</td><td>Length</td><td>Value</td>

<td>DF 21</td><td> 08</td><td> 11 22 33 44 55 66 77 88</td>

<td>DF 21</td><td> 81 08</td><td> 11 22 33 44 55 66 77 88</td>

<td>DF 21</td><td> 82 00 08</td><td> 11 22 33 44 55 66 77 88</td>

TLV encoding allows the length indicator to be expressed in multiple bytes. Preferably, a multi-byte length is supported. In its bounded form, the length field consists of a single byte where bit 8 is set to 0 and bits 7 to 1 encode the number of bytes in the value field. Therefore, a byte can encode any amount from zero to 127. Any amount from one to 127 is coded the same way in the BER-TLV length field as it is in the Le and Le fields. Coding differs for zero, 128, and more. See, for example, the encoding of data objects in the Get Business Data command described below.

In the extended form, the length field consists of two or more bytes. Bit 8 of the first byte is set to 1 and bits 7 to 1 are not all the same and therefore encode the number of subsequent bytes in the length field. Those subsequent bytes encode the number of bytes in the value field. ISO / IEC 7816 does not use the indefinite length specified by ASNI ISO / IEC 7816 basic encoding standards, which support length fields of one, two, ... up to five bytes (Table 2). In ISO / IEC 7816, the values ​​'80' and '85' through 'FF' are invalid for the first byte of the length fields.

TABLE 2 - BER-TLV length fields in ISO / IEC 7816

<td></td><td>1st byte</td><td>2 'byte | 3 · byte | 4 · byte | 8byte</td><td>N</td>

<td>1 byte</td><td>W to 7P</td><td></td><td>Θ to 127</td>

<td>2 bytes</td><td> *81'</td><td>Wa'FP l</td><td> 0 9</td>

<td>3 bytes</td><td> '8?</td><td>OOOCT to FFFF * |</td><td>0 to 65 535</td>

<td>4 bytes</td><td> %3·</td><td>• 000000- aTFFFFF *]</td><td>0 to 16 777 215</td>

<td>8 bytes</td><td> *84*</td><td>to TfFFFFFP</td><td>0a 4284 8672 »</td>

Select the commercial applet

In one embodiment, processing begins when reader 120 detects a mobile device 110 in field of reader 120 and NFC communications have started. At that time, reader 120 sends a command to security element 112 to select a business applet, particularly a Select business type command.

The Select trade type command (also referred to as Select the Commercial Subprogram) is standardized as defined in the ISO 780163 description. Table 3 shows an example of the structure of the Select trade type command:

TABLE 3 - Select the Commercial Subprogram

<td>CLA</td><td>INS</td><td>P1</td><td>P2</td><td>You</td><td>Data</td><td>You</td>

<td> 00</td><td>A4</td><td> 04</td><td> 00</td><td> 09</td><td>A00000048510010101</td><td> 00</td>

Security element 112 on mobile device 110 20 validates the Select merchant type command and returns an appropriate response. Table 4 shows examples of responses (also referred to as

State):

TABLE 4 - Status Codes

<td>SW1</td><td>SW2</td><td>Description</td>

<td> 90</td><td> 00</td><td>Successful command execution</td>

<td> 67</td><td> 00</td><td>Incorrect data length</td>

<td> 69</td><td> 01</td><td>ID of unsupported application</td>

<td> 69</td><td> 99</td><td>Application not available</td>

<td>6A</td><td> 82</td><td>Application not installed</td>

All the responses without being '90 00' (Successful command execution) cause the commercial application 121 (figure 1) to interrupt in the reader 120 and pass the control to the

EPM.

Obtain business data

After starting reader application 121 and initiating communications between reader 120 and security element 112, reader 120 sends a command to mobile device 110 to obtain business data,

Obtain Business Data. Next, in Tables 5 and 6, an example of the Get Business Data command is defined. In this example, specific loyalty data and offers are requested. Reader 120 uses the field of

Merchant's ability to determine which fields should be present in the request and response data.

Date and time stamp information is optional. In one mode, the date and time are synchronized with the POS. In the event that the POS does not have this information, the date / time of the POS terminal 14 0 can be used. If the date and time are not available, the reader 120 does not send the date stamp data element and hour.

In an example modality, the data elements included in the Get Business Data request are preconfigured in the reader 120 or the POS terminal 14 0 at the time of implementation. The data can be modified after the reader 120 has been installed and configured.

TABLE 5 - Obtain commercial data

<td>CLA</td><td>INS</td><td>P1</td><td>P2</td><td>You</td><td colspan="2">Data</td><td>You</td>

<td> 90</td><td> 50</td><td> 00</td><td> 00</td><td>XX</td><td>Merchant ID / ID</td><td>of the</td><td> 00</td>

<td></td><td></td><td></td><td></td><td></td><td colspan="2">merchant [+ loyalty ID +</td><td></td>

<td></td><td></td><td></td><td></td><td></td><td>coupon types + brand</td><td>of</td><td></td>

<td></td><td></td><td></td><td></td><td></td><td>date / time + version of</td><td>the</td><td></td>

<td></td><td></td><td></td><td></td><td></td><td>application + capacity</td><td>of the</td><td></td>

<td></td><td></td><td></td><td></td><td></td><td>merchant]</td><td></td><td></td>

TABLE 6 - Command Data

<td>Data element</td><td>Size in bytes</td><td>Value</td><td>Request</td>

<td>Identifier tag from the merchant</td><td> 2</td><td>OxDF 31</td><td>S</td>

<td>Length of identifier</td><td> 1</td><td>XX</td><td></td>

<td>Identifier of merchant</td><td>XX</td><td>[ID of the merchant]</td><td></td>

<td>MerchantStore_ID tag [Business ID of merchant]</td><td> 2</td><td>OxDF 32</td><td>S</td>

<td>Lenght of Merchant_Store_ID</td><td> 1</td><td>XX</td><td></td>

<td>Merchant Store ID</td><td>XX</td><td>(Location / ID of the store)</td><td></td>

<td>Loyalty_ID tag [ID of fidelity] # 1 for secondary fidelity</td><td> 2</td><td>OxDF 41</td><td>Opt.</td>

<td>Identifier length η. ° 1</td><td> 1</td><td>XX</td><td></td>

<td>Loyalty ID # 1</td><td>XX</td><td>[ID of fidelity] (Hex)</td><td></td>

<td colspan="3"> .......</td><td></td>

<td>Loyalty_ID η tag. ° X for secondary fidelity</td><td> 2</td><td>OxDF 41</td><td>Opt.</td>

<td>Identifier length fidelity η. ° X</td><td> 1</td><td>XX</td><td></td>

<td>Loyalty ID η. ° X</td><td>XX</td><td>Loyalty ID (Hex)</td><td></td>

<td></td><td></td><td></td><td></td>

<td>Date_Time_Stamp tag [Date and time stamp]</td><td> 2</td><td>OxDF 11</td><td>Opt.</td>

<td>Date_Time_Stamp length</td><td> 1</td><td>0x07</td><td></td>

<td>Date_Time_Stamp</td><td> 7</td><td>B CD (mmddhhmms s)</td><td></td>

<td>Commerce_App_Version tag [Application version commercial]</td><td> 2</td><td>OxDF 12</td><td>S</td>

<td>Lenght of Commerce App_Version</td><td> 1</td><td>0x02</td><td></td>

<td>Commerce_App_Version data</td><td> 2</td><td>[older + minor] Hex</td><td></td>

<td></td><td></td><td></td><td></td>

<td>Merchant Capability Label [Merchant capacity]</td><td> 2</td><td>OxDF 33</td><td>S</td>

<td>Lenght of Merchant_Capability</td><td> 1</td><td>0x02</td><td></td>

<td>Merchant Capability Facts</td><td> 2</td><td>Hex 2 bytes</td><td></td>

<td></td><td></td><td></td><td></td>

<td>Label Startup_Mode Terminal [Mode terminal start]</td><td> 2</td><td>OxDF 34</td><td>Opt.</td>

<td>Lenght of Startup_Mode Terminal</td><td> 1</td><td>0x02</td><td></td>

<td>Data of Startup_Mode Terminal</td><td> 1</td><td>Hex of 1 bytes</td><td></td>

<td>Total:</td><td>&lt;var&gt;</td><td></td><td></td>

Table 7 defines the possible Status Word values ​​that the Get Business Data command can return.

TABLE 7 - Status Codes

<td>SW1</td><td>SW2</td><td>Description</td>

<td> 90</td><td> 00</td><td>Successful command execution</td>

<td> 61</td><td>XX</td><td>More data follow</td>

<td> 67</td><td> 00</td><td>Incorrect data length</td>

<td> 69</td><td> 09</td><td>Internal error</td>

Any response other than '61 xx 'or '90 00' results in reader 120 interrupting business application 121 and passing control to EPM, after recording the error and storing the data to send to business tool 115.

If the Get Business Data request is formatted correctly, business applet 113 in security element 112 filters the data based on the merchant identifier (Merchant_ID), loyalty identifier (Loyalty_ID), and offer type code (Offer_Type_Code) for format response data for reader 120 based on the version number on the request. Business applet 113 can return more than one loyalty ID and multiple offer messages, depending on the wallet configuration. Table 8 presents examples of response data:

TABLE 8 - Sample response data

<td>Data element</td><td>Size in bytes</td><td>Value</td>

<td>Label Consumer_ID [ID of the consumer]</td><td> 2</td><td>0XDF21</td>

<td>Consumer_ID Length</td><td> 1</td><td>0x10</td>

<td>Consumer_ID data</td><td> 16</td><td>[ID of the consumer]</td>

<td></td><td></td><td></td>

<td>Loyalty ID Label # 1</td><td> 2</td><td>0XDF41</td>

<td>Loyalty_ID # 1 Length</td><td> 1</td><td>XX</td>

<td>Loyalty Identifier # 1</td><td>XX</td><td>[ID of fidelity]</td>

<td>Loyalty_Account_Code tag [Loyalty account code] η. ⁰ 1</td><td> 2</td><td>0xDF43</td>

<td>Loyalty_Account_Code length η. ° 1</td><td> 1</td><td>XX</td>

<td>Loyalty Account Code η. ° 1</td><td>XX</td><td>[Code of bill]</td>

<td></td><td></td><td></td>

<td>Loyalty_ID tag [ID of fidelity] # 2</td><td> 2</td><td>OxDF 41</td>

<td>Loyalty_ID # 2 Length</td><td> 1</td><td>XX</td>

<td>Loyalty_ID Data # 2</td><td>XX</td><td>[ID of fidelity]</td>

<td>Loyalty_Account_Code Label # 2</td><td> 2</td><td>0xDF43</td>

<td>Loyalty Account Code Length n. ° 2</td><td> 1</td><td>XX</td>

<td>Loyalty_Account_Code Code No. 2</td><td>XX</td><td>[Code of bill]</td>

<td colspan="3"> .......</td>

<td>Offer_ID [Offer ID] tag η. ° 1</td><td> 2</td><td>0xDF51</td>

<td>ID Offer ID length η. ° 1</td><td> 2</td><td>X'81 xx '</td>

<td>ID Offer ID value η. ° 1</td><td>XX</td><td>[Coupon ID]</td>

<td>Offer Code tag [Offer Code] # 1</td><td> 2</td><td>0xDF53</td>

<td>Offer Code Length # one</td><td> 2</td><td>0x'81xx '</td>

<td>Offer_Code # 1 code value</td><td>XX</td><td>[Code of coupon]</td>

<td></td><td></td><td></td>

<td>Offer_ID tag n.⁰ 2</td><td> 2</td><td>0xDF51</td>

<td>ID Length Offer_ID # 2</td><td> 2</td><td>0x'81xx '</td>

<td>ID Value Offer_ID # 2</td><td>XX</td><td>[Coupon ID]</td>

<td>Offer_Code # 2 code tag</td><td> 2</td><td>0xDF53</td>

<td>Offer Code Length # 2</td><td> 2</td><td>0x'81xx '</td>

<td>Offer_Code # 2 code value</td><td>XX</td><td>[Code of coupon]</td>

<td colspan="3"> .......</td>

<td>Total:</td><td>&lt;var&gt;</td><td></td>

The following is a sample parsing of an example response data. The NFC reader (or POS terminal) manages this business data to a POS system in a data chain that can contain consumer data, loyalty and / or offers. The merchant's POS system can then parse the data to obtain loyalty and bid data and process the data to the merchant's specifications.

DF 21 10 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF

<td> 5</td><td>DF</td><td> 41</td><td> 06</td><td> 18</td><td>DB</td><td>6E</td><td> 23</td><td>F4</td><td>0B</td><td>DF</td><td> 43</td><td>0D</td><td> 02</td><td> 31</td><td> 38</td><td> 44</td><td> 42</td><td> 36</td><td> 45</td><td> 32</td>

<td></td><td> 33</td><td> 46</td><td> 34</td><td> 30</td><td> 42</td><td>DF</td><td> 51</td><td> 08</td><td> 88</td><td> 77</td><td> 66</td><td> 55</td><td> 44</td><td> 33</td><td> 22</td><td> 05</td><td>DF</td><td> 53</td><td> 09</td><td> 02</td>

<td></td><td> 42</td><td> 41</td><td> 31</td><td> 38</td><td> 37</td><td> 36</td><td> 35</td><td> 34</td><td>DF</td><td> 51</td><td> 08</td><td> 88</td><td> 77</td><td> 66</td><td> 55</td><td> 44</td><td> 33</td><td> 22</td><td> 06</td><td>DF</td>

<td></td><td> 53</td><td>OC</td><td> 02</td><td> 41</td><td> 39</td><td> 39</td><td> 39</td><td> 39</td><td> 31</td><td> 33</td><td> 33</td><td> 35</td><td> 37</td><td> 38</td><td>DF</td><td> 51</td><td> 08</td><td> 88</td><td> 77</td><td> 66</td>

<td></td><td> 55</td><td> 44</td><td> 33</td><td> 22</td><td> 07</td><td>DF</td><td> 53</td><td> 10</td><td> 02</td><td>5A</td><td> 58</td><td> 31</td><td> 37</td><td> 39</td><td> 35</td><td> 36</td><td> 37</td><td> 35</td><td> 34</td><td> 38</td>

<td> 10</td><td> 33</td><td> 31</td><td> 43</td><td> 46</td><td>DF</td><td> 51</td><td> 08</td><td> 88</td><td> 77</td><td> 66</td><td> 55</td><td> 44</td><td> 33</td><td> 22</td><td> 08</td><td>DF</td><td> 53</td><td>OC</td><td> 02</td><td> 31</td>

<td></td><td> 38</td><td> 30</td><td> 30</td><td> 38</td><td> 37</td><td> 32</td><td> 30</td><td> 30</td><td> 30</td><td> 31</td><td>DF</td><td> 51</td><td> 08</td><td> 88</td><td> 77</td><td> 66</td><td> 55</td><td> 44</td><td> 33</td><td> 22</td>

<td></td><td> 09</td><td>DF</td><td> 53</td><td> 33</td><td> 02</td><td> 57</td><td>4B</td><td> 52</td><td> 50</td><td> 31</td><td> 32</td><td> 33</td><td> 34</td><td> 35</td><td> 36</td><td> 37</td><td> 38</td><td> 39</td><td> 41</td><td> 42</td>

<td></td><td> 43</td><td> 44</td><td> 45</td><td> 46</td><td> 47</td><td> 48</td><td> 49</td><td>4A</td><td>4B</td><td>4C</td><td>4D</td><td>4E</td><td>4F</td><td> 50</td><td> 50</td><td> 57</td><td> 50</td><td> 57</td><td> 50</td><td> 57</td>

<td></td><td> 50</td><td> 57</td><td> 50</td><td> 57</td><td> 50</td><td> 57</td><td> 50</td><td> 57</td><td> 50 !</td><td> 57 5</td><td> &gt;0 5</td><td> 7 5</td><td> 0 5</td><td colspan="2">7 50 4C</td><td>i al</td><td></td><td></td><td></td><td></td>

Example of parsing of data

DF 21 10 00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF (consumer ID)

DF 41 06 18 DB 6E 23 F4 OB (MoCom Loyalty ID)

<td>DF</td><td> 43</td><td>0D 02 31 38 44 42 36</td><td> 45</td><td> 32 33</td><td> 46</td><td> 34</td><td> 30</td><td> 42</td>

<td>(Code</td><td>of</td><td>consumer loyalty)</td><td></td><td></td><td></td><td></td><td></td><td></td>

<td>DF</td><td> 51</td><td> 08 88 77 66 55 44 33 22</td><td> 05</td><td>(ID of</td><td>the</td><td colspan="2">offer</td><td>of</td>

<td>MoCom)</td><td>you</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td>

<td>DF</td><td> 53</td><td> 09 02 42 41 31 38 37 36 35</td><td> 34</td><td>(Code</td><td>of</td><td>the</td><td colspan="2">offer</td>

from the merchant) # 1

DF 51 08 88 77 66 55 44 33 22

Post-transaction data

As noted above, a Post-Transaction Data command provides a mechanism for receiving data from a merchant's POS system (MPOS). Merchant POS terminal 140 initiates this command and preferably supports it in the merchant capability field. In an example modality, this command consists of a single data frame with a maximum data size of 255 bytes. The data content uses the standard TLV format, but can also be variable. This command enables dynamic reconciliation or consolidation of post-transaction data. Additional data labels can be defined for the transmission of additional data from the POS / MPOS terminal to security element 112 on mobile device 110. An example of a post-transaction data command is illustrated in Tables 9 and 10 (Data Post-transaction):

TABLE 9 - Post-Transaction Data Command

<td>CLA</td><td>INS</td><td>Pl</td><td>P2</td><td>You</td><td colspan="2">Data</td><td>You</td>

<td> 90</td><td> 52</td><td> 00</td><td> 00</td><td>XX</td><td>&lt;Data</td><td>post-transaction</td><td> 00</td>

<td></td><td></td><td></td><td></td><td></td><td>coded</td><td>with TLV&gt;</td><td></td>

TABLE 10 - Command Data

<td>Data element</td><td>Size in bytes</td><td>Value</td><td>Request</td>

<td>Transaction ID</td><td> 2</td><td>Ox DF 61</td><td>Opt.</td>

<td>ID length of the transaction</td><td> 1</td><td>XX</td><td></td>

<td>ID data of the transaction</td><td>XX</td><td>ID of the transaction generated by the merchant</td><td></td>

<td>Offer ID # 1 code</td><td> 2</td><td>OXDF 51</td><td>Opt.</td>

<td>Offer ID # 1 Length</td><td> 1</td><td>XX</td><td></td>

<td>Offer_ID η. ° 1 data</td><td>XX</td><td>ID of the coupon</td><td></td>

<td> .......</td><td></td><td></td><td></td>

<td>Offer ID # X code</td><td> 2</td><td>OxDF 51</td><td>Opt.</td>

<td>Offer ID length η. ° X</td><td> 1</td><td>XX</td><td></td>

<td>Offer ID # X Data</td><td>XX</td><td>ID of the coupon</td><td></td>

<td>Total:</td><td>&lt;var&gt;</td><td></td><td></td>

Multiple block data management

FIG. 5 illustrates an example of multi-block data flow according to an example of embodiment. When security element 112 has more than 255 bytes of data to send, a Get Response (CO) command is used to retrieve the remaining response data. In particular, this command is used to retrieve the remaining data when business applet 113 must send more than, for example, 255 bytes of response data.

With reference to FIG. 5, after a user touches a mobile device with commerce enabled 110 against reader 120, reader 120 sends a Select type of commerce command to security element 112 of mobile device 110. A positive response ('90 00 ') causes reader 120 to send a Get Business Data command. In response to this, security element 112 returns loyalty and offer data. As shown in FIG. 5, the SW1 response status flag of Get Business Data is set to '61' and the SW2 flag is set to '00'.

A Get Response command is triggered when the SW1 flag is set on the Get Business Data response to '61'. In this example, the SW2 flag is set to '00' because the business applet 113 on mobile device 110 may not know how much data needs to be sent. The response after the Get Answer command also contains a SW1 flag set to '61', causing reader 120 to send a second Get Answer command to mobile device 110.

This sequence is interrupted when the SW1 flag of the Get Business Data response is set to any value without being '61'. For example, a SW1 value of '90' in response to a Get Response command, as shown in FIG. 5, will indicate a normal completion. Any other SW1 value can be logged as an error.

Table 11 defines configuration examples for the Get Response Data APDU command:

TABLE 11 - Obtain response data

<td>CLA</td><td>INS</td><td>P1</td><td>P2</td><td>You</td><td>Data</td><td>You</td>

<td> 90</td><td>CO</td><td> 00</td><td> 00</td><td> 00</td><td>&lt;none&gt;</td><td> 00</td>

The actual length of the remaining data is variable. Therefore, the data length of Le can be 0x00, allowing business applet 113 to handle a variable length response.

Table 12 defines the possible status word values ​​(status codes) that the APDU command can return

Obtain Response Data.

TABLE 12 - Status Codes

<td>SW1</td><td>SW2</td><td>Description</td>

<td> 90</td><td> 00</td><td>Successful command execution</td>

<td> 61</td><td>XX</td><td>More data follow</td>

<td> 67</td><td> 00</td><td>Incorrect data length</td>

<td> 69</td><td> 09</td><td>Internal error</td>

Reader configuration data

In one embodiment, during the installation and configuration of the reader 120, certain merchant and specific business data is loaded and saved in the reader 120. The reader 120 uses this data to complete the Get Business Data command from the reader 120. These items of Data can be updated as new features and functions become available.

Commercial AID

As explained above, a business AID is sent in the Select business type command. If mobile device 110 accepts the command, business applet 113 starts and APDU / response command flows start between reader 120 and security element 112. In one example mode, the business AID value is A00000048510010101. This value can be included in the code in reader 120. In one embodiment, the reader 120 need not support a partial selection.

Merchant_ID

A merchant identifier (Merchant_ID (DF31)) can be loaded into reader 12 0. The merchant ID is a value assigned by a service provider. In a modality, this value is assigned by the operator of the MoCom platform. This is necessary to allow business applet 113 to filter loyalty and coupon data and send the appropriate items to reader 120.

Merchant_Store_ID

A merchant merchant identifier value (Merchant_store_ID (DF32)) is loaded into reader 120 and this is a value assigned by a service provider. This value can be used, for example, for informational purposes.

Loyalty_ID

A fidelity identifier value (Loyalty_ID (DF41)) is used when requesting multiple fidelity IDs during a touch. This is accomplished by configuring secondary fidelity in the merchant's capabilities (DF33). This allows business applet 113 to return additional loyalty numbers in response to a Get Business Data command. Multiple additional Loyalty_IDs (eg 5) can be encoded in the request for

Obtain Business Data.

Or ffe r_Type_Code s

The offer type codes (Offer Type Codes (DF54)) are loaded into reader 120. The values ​​assigned to the offer type codes are assigned by a service provider. Business applet 113 uses this value to filter offers and send only the appropriate items to reader 120. Multiple Offer_Type_Codes can be identified and sent to security element 112 in the Get Business Data command.

Commerce_Application_Version

A commercial application version number (Commerce_Application__Version) can be loaded into reader 120 to represent the version of the commercial reader description that the application encodes in reader 120 and for which it certifies.

I rchant_Capab i1i ties

Merchant Capability Values ​​represent business characteristics supported by a particular merchant. Reader 120 can also use this data element to format the Get Data command

Commercial.

Terminal_Startup_Mode

A terminal start mode command (Terminal Start Mode (DF34)) instructs reader 120 to provide the mechanism used to start commercial application 121. This data element is not sent to security element 112. This data element is also used to define the processing flows between reader 120 and security element 112 in the equipment.

Fields of obtaining commercial data

Table 13 provides an example of defining data requested by reader 120 to format the Select Business Type and Get Services commands.

Commercial:

TABLE 13

<td>Data element</td><td>Label</td><td>Size</td><td>Format of the</td>

<td></td><td></td><td>maximum</td><td>data</td>

<td></td><td></td><td>Bytes</td><td></td>

<td>Commercial AID</td><td></td><td> 09</td><td>Hex</td>

<td>Merchant ID</td><td>DF 31</td><td> 8</td><td>Hex</td>

<td>Store ID of</td><td>DF 32</td><td> 32</td><td>ASCCI</td>

<td>merchant</td><td></td><td></td><td></td>

<td>Identifier</td><td>DF 41</td><td> 8</td><td>B C D</td>

<td>fidelity # 1 to X</td><td></td><td></td><td></td>

<td>Date and time stamp</td><td>DF 11</td><td> 7</td><td>B C D</td>

<td>Version of the</td><td>DF 12</td><td> 2</td><td>Hex</td>

<td>specification</td><td></td><td></td><td></td>

<td>(major / minor)</td><td></td><td></td><td></td>

<td>Capacities of</td><td>DF 33</td><td> 2</td><td>Binary</td>

<td>merchant</td><td></td><td></td><td></td>

<td>Start mode</td><td>DF 34</td><td> 2</td><td>Binary</td>

<td>commercial</td><td></td><td></td><td></td>

Format of the commercial applet version

A version value of the business applet is a two-byte hex field, where the first byte contains the major version (xx) and the second byte contains the minor version (xx). These fields are updated according to the specific version of the technical description of the commercial reader implemented in the reader 120. In an example of modality, the first official version of the commercial application 121 is 0x0100.

Merchant Capabilities

A merchant capabilities field (Merchant Capabilities 10 Field (DF 33)) determines which business functions the merchant implements. Reader 120 can pass this field to mobile device 110, and mobile device 110 uses the information to integrate a response framework, called a Data Response framework.

Commercial. Table 14 illustrates examples of merchant capabilities:

TABLE 14 - Business format of the merchant's capacity data start mode

<td>Byte</td><td>Bit</td><td>Value</td><td>NFC reader function</td>

<td> 1</td><td> 8</td><td>1 = merchant</td><td>If bit 8 is found</td>

<td></td><td>MSB</td><td>admits</td><td>activated, the reader sends the ID</td>

<td></td><td></td><td>fidelity</td><td>of the requested merchant and</td>

<td></td><td></td><td>0 = no</td><td>optionally a loyalty ID</td>

<td></td><td></td><td></td><td>for the merchant</td>

<td> 1</td><td> 7</td><td>1 = fidelity</td><td>Bit 8 must be set Se</td>

<td></td><td></td><td>high school</td><td>includes loyalty ID</td>

<td></td><td></td><td>0 = no</td><td>additional in request</td>

<td></td><td></td><td></td><td>Obtain Business Data</td>

<td> 1</td><td> 6</td><td>1 = supports</td><td>Type fields are included</td>

<td></td><td></td><td>offers</td><td>Offer on request</td>

<td></td><td></td><td>0 = no</td><td>Obtain Business Data</td>

<td> 1</td><td> 5</td><td>1 = supports</td><td>The merchant can request</td>

<td></td><td></td><td>offers</td><td>additional offers in the</td>

<td></td><td></td><td>additional</td><td>Request to Get Trade</td>

<td></td><td></td><td>0 = no</td><td></td>

<td> 1</td><td> 4</td><td>1 = supports</td><td>Some merchants may</td>

<td></td><td></td><td>pay without</td><td>choose to accept only</td>

<td></td><td></td><td>Contact</td><td>commercial payments but not without</td>

<td></td><td></td><td>0 = no</td><td>Contact. This configuration</td>

<td></td><td></td><td></td><td>bit is only</td>

<td></td><td></td><td></td><td>informative. It doesn't stop the</td>

<td></td><td></td><td></td><td>PPSE process.</td>

<td> 1</td><td> 3</td><td>1 = ID of the</td><td></td>

<td></td><td></td><td>merchant</td><td></td>

<td></td><td></td><td>entrepreneur</td><td></td>

<td></td><td></td><td>0 = no</td><td></td>

<td> 1</td><td> 2</td><td>1 = offer</td><td>Indicates that the merchant</td>

<td></td><td></td><td>based on the</td><td>can support based offers</td>

<td></td><td></td><td>cloud</td><td>in the cloud (future)</td>

<td></td><td></td><td>0 = no</td><td></td>

<td> 1</td><td> 2</td><td> 0</td><td>Reserved for future use</td>

<td></td><td></td><td></td><td></td>

<td> 1</td><td> 1</td><td>1 = supports</td><td>The reader receives data from</td>

<td></td><td></td><td>post data</td><td>redeem the POS and send them to you</td>

<td></td><td></td><td>transaction</td><td>to the team</td>

<td></td><td></td><td>0 = no</td><td></td>

<td> 2</td><td> 8-1</td><td> 0</td><td>Reserved for future use</td>

Business Home Mode Format

A commercial start mode format value (Commercial Start Mode (DF34)) tells reader 120 what mechanism to use to start commercial application 121 on reader 120. In one mode, this data item is not sent to the device mobile 110 at the command Get Business Data. In another embodiment, this data element is optional. Table 15 illustrates examples of startup modes that can be used to launch the business application

121. In an example mode, bits 7 and 8 are unique and only one bit is taken at a time:

TABLE 15 - Commercial start mode

<td> 15</td><td>Byte</td><td>Bit</td><td colspan="2">Value</td><td colspan="2">Reader function</td>

<td></td><td> 1</td><td> 8</td><td> 1</td><td>start</td><td>When starting the check</td><td>the</td>

<td></td><td></td><td>MSB</td><td colspan="2">automatic</td><td>reader requests commercial AID</td><td>in</td>

<td></td><td></td><td></td><td>0 = no</td><td></td><td>the first TOUCH</td><td></td>

<td></td><td> 1</td><td> 7</td><td> 1</td><td>start</td><td colspan="2">The reader only selects</td>

<td> 20</td><td></td><td></td><td>Handbook</td><td></td><td colspan="2">Commercial AID after certain</td>

<td></td><td></td><td></td><td>0 = no</td><td></td><td>user intervention.</td><td></td>

<td rowspan="2"> 1</td><td rowspan="2"> 6</td><td rowspan="2">1 = Payment with post data transaction 0 = no</td><td colspan="2">Payment and post data</td>

<td>transaction will take place TOUCH 2</td><td>in</td>

<td> 1</td><td> 5</td><td>Pay first</td><td>Payment PPSE</td><td>is</td>

<td></td><td></td><td></td><td>precedent in modes</td><td>of</td>

<td></td><td></td><td></td><td>automatic and manual start</td><td></td>

<td> 1</td><td> 4-1</td><td> 0</td><td colspan="2">Reserved for future use</td>

<td> 2</td><td> 8-1</td><td> 0</td><td colspan="2">Reserved for future use</td>

Sending messages to the reader

By reading data from the commercial application of the mobile device 110, the reader 120 sends the data to a

POS of merchant or resident of POS application in POS terminal 140. Reader 120 removes headers from

APDU and unlock the data from the mobile device 110. The tagged TLV frames are then assigned to the appropriate protocol and sent to the merchant's POS system or POS application running at the POS terminal for processing.

Business Response Data Description

During a successful interaction with a reader 120, the data is returned to the merchant's POS system (or POS terminal). This information is typically made up of a consumer loyalty number and / or a certain number of offers defined by the merchant and loaded into the consumer's wallet.

Consumer ID

A consumer identifier (consumer ID) is a unique identifier that is assigned to a consumer during the wallet activation process. Typically, the consumer ID is maintained even if the consumer moves their wallet to a new mobile device or different mobile network. In a preferred embodiment, the consumer ID is sent from the mobile device to the reader in every trade-related interaction, even if the team has no offer or loyalty data to send. The merchant's POS system can use consumer ID presentation to trigger specific actions related to a single touch of payment.

Loyalty ID

A loyalty identifier (loyalty ID) is sent along with each requested consumer loyalty number during a touch event. The Loyalty ID is a unique value assigned by the MoCom platform to each merchant's loyalty program. In most cases, the loyalty ID received by the reader corresponds to the ID of the merchant who configured the Get Business Data command. The use of this information by a merchant system is optional.

Consumer loyalty code

A consumer loyalty code (Consumer Loyalty Code) corresponds to the loyalty number assigned to the consumer for a merchant specific loyalty program. The wallet app 114 allows multiple numbers to be presented from}

fidelity in touch. If the system is configured for multiple consumer loyalty codes, each consumer loyalty code will be preceded by its unique loyalty ID.

Offer ID

A mobile commercial offer identifier (Offer ID) is sent along with each consumer offer number sent during a business session. The offer ID is a unique value assigned to each offer sent to a consumer's wallet. In one modality, there are not two Offer IDs generated by the MoCom platform that have the same value.

Merchant Offer Code

The merchant generates a merchant offer code (Merchant Offer Code or Offer Number) and this is loaded into the consumer wallet application in various ways. This number corresponds to the same offer defined in the merchant's POS system for processing. Multiple merchant offers (eg 10) can be submitted during a single business transaction. The merchant's system parses the data to extract the individual merchant's offers.

Business response data fields

Table 16 defines examples of data elements that can be returned to the merchant's POS system after a successful business transaction.

TABLE 16

<td>Data element</td><td>Label</td><td>Size</td><td>Format</td><td>of</td>

<td></td><td></td><td>maximum</td><td>the data</td><td></td>

<td></td><td></td><td>Bytes</td><td></td><td></td>

<td>Consumer ID</td><td>DF 21</td><td> 16</td><td colspan="2">B C D</td>

<td>Loyalty ID</td><td>DF 41</td><td> 8</td><td colspan="2">Hex</td>

<td>Loyalty code</td><td>DF 43</td><td> 32</td><td>ASCII,</td><td>Hex,</td>

<td>consumer</td><td></td><td></td><td>B C D</td><td></td>

<td>Offer ID</td><td>DF 51</td><td> 8</td><td colspan="2">B C D</td>

<td>Offer code of</td><td>DF 53</td><td> 48</td><td>ASCII,</td><td>Hex,</td>

<td>merchant</td><td></td><td></td><td>B C D</td><td></td>

In one mode, a Terminal Start Mode data item is passed to reader 120, but it is not passed to security item 112. Reader 120 uses this information to control when send commands are sent to it.

Select type of business and Select the PPSE to security element 112.

Functionality of the commercial application of the reader

The following section provides a list of functions performed by the business application on Reader 120. Some of these functions are automatic, while others are triggered by an API call from the POS terminal or the

Merchant's POS.

Select the commercial AID command

After starting the commercial application on reader 120 and having detected a device in the reader 120 field, the first command sent is Select the Commercial AID. The command contains the RID value assigned by

ISO and a PIX value generated by a commercial service provider. The commercial AID value is A00000048510010101.

This value must be included in the code in reader 120.

Command to obtain commercial data

The Get Business Services Data command is a general request for data for security element 112. Get Business Data has a number of optional and mandatory fields that communicate information to business applet 113. Business applet 113 uses this information to include the data items that need to be sent to reader 120. Reader 120 uses the fields in the Merchant Capability records to determine which optional fields should be included in the request to the team.

Post-transaction data

The Post-Transaction Data command was created to provide a mechanism for receiving data from the MPOS. This command consists of a single data frame with a maximum data size of 255 bytes. The data content uses the standard TLV format, but the content may be variable. Additional data labels can be defined for the transmission of additional data from the POS / MPOS terminal to security element 112 on the mobile device

110 .

NFC error recovery

In a preferred embodiment, reader 120 can recover from a read error generated by prematurely removing the apparatus from the NFC field. Reader 120 sends read error signals to the consumer through a fault interface, such as a speaker that beeps, or a display that provides an optical indication, such as by lights. The consumer is asked to perform the touch again and the transaction that was in process during the error is restarted. In the event that multiple transactions are being processed, such as a business transaction and a PPSE transaction, reader 120 will attempt to retrieve the last process performed.

Large blocks of data supported

In one embodiment example, reader 120 reads and writes multiple 255-byte blocks of data to and from mobile device 112 in a single touch process.

Date and time stamp supported

When reader 120 has connectivity to the merchant's POS system, the date and time can be taken from the POS terminal at the start of the transaction.

TLV Master Tag List

Table 17 defines the data elements and corresponding label values, as well as the desired byte sizes / max that are used by commerce-based applications. Additional values ​​were provided for items with a limited / fixed value range.

TABLE 17 - APDU Commands

<td colspan="4">Commercial services</td>

<td colspan="4">Shared data items</td>

<td>Data element</td><td>Label</td><td>Max Size</td><td>Description</td>

<td>DATE_TIME_STAMP</td><td>OxDFll</td><td> 7</td><td>Brand of date hour (yyyymmddhhmms s)</td>

<td>COMMERCE_APP_VERSIΟΝ</td><td>0xDF12</td><td> 2</td><td>Version number of application commercial admitted</td>

<td colspan="4">Customer data elements</td>

<td>Data element</td><td>Label</td><td>Size maximum</td><td>Description</td>

<td>CONSUMER_ID</td><td>0XDF21</td><td> 16</td><td>Identifier of consumer specific to the MoCom platform</td>

<td>CONSUMER_KEY [Key consumer]</td><td>0xDF22</td><td> 16</td><td>3DES key specific to customer generated by the platform MoCom</td>

<td>CONSUMER_CERT [Certificate of consumer]</td><td>0xDF23</td><td> 8</td><td>Signature / certificate consumer generated by the MoCom platform</td>

<td colspan="4">Merchant data elements</td>

<td>Data element</td><td>Label</td><td>Size maximum</td><td>Description</td>

<td>MERCHANT_ID [ID of the merchant]</td><td>0xDF31</td><td> 8</td><td>Identifier of merchant specific to the MoCom platform</td>

<td>MERCHANT_STORE_ID</td><td>0xDF32</td><td> 32</td><td>Character data ASCII of identifier of the store of merchant specific to the MoCom platform</td>

<td>MERCHANT_CAPABILITY</td><td>0xDF33</td><td> 2</td><td>Services of the commercial application admitted</td>

<td>NFC READER_START_MODE [Start mode of the NFC reader]</td><td>0XDF34</td><td> 2</td><td>Start mode of payment terminal with NFC enabled (provided by the POS system merchant during initialization)</td>

<td colspan="4">Merchant Capabilities</td>

<td>Data element</td><td>Value</td><td>Size maximum</td><td>Description</td>

<td></td><td></td><td></td><td>The application of</td>

<td></td><td></td><td></td><td>Get information</td>

<td></td><td></td><td></td><td>Commercial includes a</td>

<td>MERCAP_MERCHANT_</td><td></td><td></td><td>valid identifier</td>

<td>LOYALTY [Loyalty</td><td>0x80</td><td> 1</td><td>from the merchant</td>

<td>from the merchant of</td><td></td><td></td><td>used for</td>

<td>MERCAP]</td><td></td><td></td><td>determine the data</td>

<td></td><td></td><td></td><td>of fidelity that</td>

<td></td><td></td><td></td><td>you receive the applet.</td>

<td></td><td></td><td></td><td>The application of</td>

<td></td><td></td><td></td><td>Get information</td>

<td></td><td></td><td></td><td>Commercial includes</td>

<td></td><td></td><td></td><td>Identifiers</td>

<td>MERCAP_ADDITIONAL_</td><td></td><td></td><td>Additional fidelity.</td>

<td>LOYALTY [Loyalty</td><td>0x4 0</td><td> 1</td><td>Loyalty data</td>

<td>additional MERCAP]</td><td></td><td></td><td>additional ones</td>

<td></td><td></td><td></td><td>determined by</td>

<td></td><td></td><td></td><td>Loyalty ID</td>

<td></td><td></td><td></td><td>specified.</td>

<td rowspan="2">MERCAP_MERCHANT_ OFFERS [Offers</td><td rowspan="2">of the</td><td rowspan="2">0x2 0</td><td rowspan="2"> 1</td><td colspan="2">Are included type fields</td>

<td>offer in</td><td>the</td>

<td>merchant</td><td>of</td><td></td><td></td><td>request</td><td>of</td>

<td>MERCAP]</td><td></td><td></td><td></td><td colspan="2">Get information</td>

<td></td><td></td><td></td><td></td><td>Commercial</td><td></td>

<td></td><td></td><td></td><td></td><td>Application</td><td>of</td>

<td></td><td></td><td></td><td></td><td colspan="2">Get information</td>

<td></td><td></td><td></td><td></td><td>Commercial</td><td></td>

<td></td><td></td><td></td><td></td><td>It includes</td><td>a</td>

<td colspan="2">MERCAP_ADDITIONAL_</td><td></td><td></td><td>identifier</td><td></td>

<td colspan="2">OFFERS [Offers</td><td></td><td></td><td>valid</td><td>of the</td>

<td></td><td></td><td>0x10</td><td> 1</td><td></td><td></td>

<td>additional</td><td>of</td><td></td><td></td><td>merchant</td><td></td>

<td>MERCAP]</td><td></td><td></td><td></td><td>used</td><td>for</td>

<td></td><td></td><td></td><td></td><td>decide</td><td>the</td>

<td></td><td></td><td></td><td></td><td colspan="2">offers data</td>

<td></td><td></td><td></td><td></td><td>receiving</td><td>the</td>

<td></td><td></td><td></td><td></td><td>applet.</td><td></td>

<td></td><td></td><td></td><td></td><td>Indicates that</td><td>the</td>

<td>MERCAP_PAYMENT</td><td></td><td>0x08</td><td> 1</td><td>merchant</td><td></td>

<td>[MERCAP payment]</td><td></td><td></td><td></td><td>supports the</td><td>payment</td>

<td></td><td></td><td></td><td></td><td>no contact.</td><td></td>

<td>MERCAP_ENTERPRISE [MERCAP company]</td><td colspan="2">0x04</td><td colspan="2"> 1</td><td>Indicates that the Merchant ID entrepreneur</td>

<td>MERCAP_CLOUD [Cloud MERCAP]</td><td colspan="2">0x02</td><td colspan="2"> 1</td><td>Indicates that they are supported loyalty and offers cloud based</td>

<td>MERCAP_REDEMPTION [MERCAP exchange]</td><td colspan="2">0x01</td><td colspan="2"> 1</td><td>NFC reader supports data transmission offer exchange (from the POS) to the applet using the command Exchange of Offers.</td>

<td colspan="6">Data elements of the service provider platform</td>

<td>PLATFORM_SIGNATURE [Signature of the platform]</td><td>0x71</td><td colspan="2"> 8</td><td colspan="2">MAC generated in the MoCom platform / signature attached to the / data command that originate from the platform for the purpose of remote verification (integrity / authenticity of data).</td>

<td>PLATFORM_KEY [Key of the platform]</td><td>0x72</td><td> 16</td><td>Key platform</td><td>of MoCom</td><td>the</td>

<td>PLATFORM_CERT</td><td></td><td></td><td colspan="2">Certificate of</td><td>the</td>

<td>[Certificate of the</td><td>0x73</td><td> 8</td><td>urine platform</td><td>MoCom</td><td></td>

<td>platform]</td><td></td><td></td><td></td><td></td><td></td>

<td colspan="4">Fidelity</td>

<td colspan="4">Loyalty data elements</td>

<td>Data element</td><td>Label</td><td>Size maximum</td><td>Description</td>

<td>EMBEDDED_TLV_ LOYALTY_DATA [Data TLV loyalty Incorporated]</td><td>0xDF40</td><td>XX</td><td>Label of Data of TLV fidelity incorporated</td>

<td>LOYALTY_ID [ID of fidelity]</td><td>0XDF41</td><td> 8</td><td>Identifier fidelity specific to the MoCom platform</td>

<td>LOYALTY_STATUS [Loyalty status]</td><td>0xDF42</td><td> 1</td><td>State of account / card loyalty (see continuation)</td>

<td>LOYALTY_ACCOUNT_ CODE [Code of loyalty account]</td><td>0xDF43</td><td> 32</td><td>Count of fidelity (data of the code bars)</td>

<td rowspan="2"></td><td rowspan="2">0xDF44</td><td rowspan="2"> 8</td><td colspan="2">MAC specific to the</td>

<td>platform MoCom / Firm</td><td>for</td>

<td>LOYALTY_MAC_</td><td></td><td></td><td>integrity/</td><td></td>

<td>SIGNATURE [Signature of</td><td></td><td></td><td>check</td><td>of</td>

<td>Loyalty MAC]</td><td></td><td></td><td>authenticity</td><td></td>

<td colspan="6">Transaction log</td>

<td colspan="6">Transaction data elements</td>

<td colspan="2">Data element</td><td>Label</td><td>Size maximum</td><td colspan="2">Description</td>

<td>EMBEDDED_TLV_</td><td></td><td>0xDF60</td><td></td><td>Label of</td><td>data</td>

<td>TRANSACTION_LOG</td><td></td><td></td><td></td><td>register</td><td>of the</td>

<td>[Registry</td><td>of</td><td></td><td>XX</td><td>transaction</td><td></td>

<td>transaction of</td><td>TLV</td><td></td><td></td><td></td><td></td>

<td>Incorporated]</td><td></td><td></td><td></td><td></td><td></td>

<td></td><td></td><td></td><td></td><td>ID of</td><td>the</td>

<td>TRANSACTION_ID [ID</td><td>of</td><td>0xDF61</td><td> 16</td><td colspan="2">transaction (assigned by the</td>

<td>the transaction]</td><td></td><td></td><td></td><td>POS)</td><td></td>

<td>TRANSACTION_STATUS</td><td></td><td>0xDF62</td><td></td><td>Label of</td><td>data</td>

<td>[State</td><td>the</td><td></td><td> 3</td><td>register</td><td>of the</td>

<td>transaction]</td><td></td><td></td><td></td><td>transaction</td><td></td>

<td colspan="4">Offers</td>

<td>Data elements of</td><td>the offer</td><td></td><td></td>

<td>Data element</td><td>Label</td><td>Size</td><td>Description</td>

<td></td><td></td><td>maximum</td><td></td>

<td>EMBEDDED_TLV_</td><td></td><td></td><td>Data label</td>

<td>OFFER DATA</td><td></td><td></td><td>of TLV offers</td>

<td></td><td>0xDF50</td><td>XX</td><td></td>

<td>the TLV offer</td><td></td><td></td><td>incorporated</td>

<td>incorporated]</td><td></td><td></td><td></td>

<td></td><td></td><td></td><td>Identifier</td>

<td></td><td></td><td></td><td>specific offers</td>

<td></td><td>0xDF51</td><td> 8</td><td></td>

<td></td><td></td><td></td><td>of the platform</td>

<td>OFFER_ID</td><td></td><td></td><td>MoCom</td>

<td></td><td></td><td></td><td>Offer status</td>

<td>OFFER_STATUS [Status</td><td>0xDF52</td><td> 1</td><td>(see</td>

<td>of the offer]</td><td></td><td></td><td>continuation)</td>

<td></td><td></td><td></td><td>Code data</td>

<td></td><td></td><td></td><td>supply bars</td>

<td></td><td>0xDF53</td><td> 130</td><td></td>

<td>OFFER_CODE [Code</td><td></td><td></td><td>(data bar</td>

<td>of the offer]</td><td></td><td></td><td>UPC / EPC / GS1)</td>

<td>OFFER_TYPE_CODE</td><td></td><td></td><td>Offer type (see</td>

<td>[Type code</td><td>0xDF54</td><td> 9</td><td>then)</td>

<td>offer]</td><td></td><td></td><td></td>

<td rowspan="2"></td><td colspan="2">OFFER_MAC_</td><td rowspan="2">0xDF55</td><td rowspan="2"> 8</td><td rowspan="2">Security firm of specific data of the platform</td>

<td>SIGNATURE [Signature</td><td>of</td>

<td> 5</td><td>Offer mac]</td><td></td><td></td><td></td><td>MoCom</td>

<td></td><td>OFFER_UPDATE_FLAG</td><td></td><td></td><td></td><td>Brand of</td>

<td></td><td>[Brand</td><td>of</td><td>0xDF56</td><td> 1</td><td>update (status</td>

<td></td><td>upgrade</td><td>of</td><td></td><td></td><td>sync)</td>

<td></td><td>offer]</td><td></td><td></td><td></td><td></td>

ίο

Table 18 provides a master list of APDU command examples supported by Business Applet 113.

TABLE 18

<td>Command</td><td>CLA</td><td>INS</td><td>P1</td><td>P2</td><td>You</td><td colspan="3">Data</td><td>You</td>

<td>Obtain</td><td> 90</td><td> 50</td><td> 00</td><td> 00</td><td>XX</td><td colspan="2">Date / time stamp</td><td> +</td><td> 00</td>

<td>data</td><td></td><td></td><td></td><td></td><td></td><td>ID of the</td><td>merchant</td><td> +</td><td></td>

<td>commercial</td><td></td><td></td><td></td><td></td><td></td><td>ID of the</td><td>Commerce</td><td> [+</td><td></td>

<td></td><td></td><td></td><td></td><td></td><td></td><td>version</td><td colspan="2">of application</td><td></td>

<td></td><td></td><td></td><td></td><td></td><td></td><td colspan="3">commercial + capacity</td><td></td>

<td></td><td></td><td></td><td></td><td></td><td></td><td colspan="2">from the merchant +</td><td>ID</td><td></td>

<td></td><td></td><td></td><td></td><td></td><td></td><td>of the</td><td>transaction</td><td> +</td><td></td>

<td></td><td></td><td></td><td></td><td></td><td></td><td>ID of</td><td>fidelity</td><td> +</td><td></td>

<td></td><td></td><td></td><td></td><td></td><td></td><td>codes</td><td>offer]</td><td></td><td></td>

<td>Post data</td><td> 90</td><td> 52</td><td> 00</td><td> 00</td><td>XX</td><td>&lt;Data</td><td>of</td><td>the</td><td> 00</td>

<td>transaction</td><td></td><td></td><td></td><td></td><td></td><td>transaction</td><td></td><td></td><td></td>

<td></td><td></td><td></td><td></td><td></td><td></td><td>coded</td><td>by</td><td>TLV&gt;</td><td></td>

<td>Obtain</td><td> 90</td><td>CO</td><td> 00</td><td> 00</td><td>XX</td><td>None</td><td></td><td></td><td></td>

<td>data</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td>

<td>remaining</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td>

Specially formatted data elements

The data elements included in the business data payload can include a format byte that identifies the data encoding used for the element. The merchant specifies the data encryption to ensure compatibility at the point of sale. The trading platform provides the value of formatted data to the wallet application 114. Therefore, no further interpretation / formatting is required between platform 130, wallet 114, security element 112, and reader 120 / POS terminal 140 (collectively referred to as payment terminal). The payment terminal (or the merchant's POS system) has the function of properly interpreting the data and providing it to the merchant's system for processing.

In an example modality, the following data elements include the following format values:

• Loyalty account code (DF 43) • Offer code (DF 53)

Table 19 defines the possible byte values ​​of the format and their corresponding encoding rule:

TABLE 19

<td>Format byte</td><td>Coding rule</td><td>Description</td>

<td>0x00</td><td>Hexadecimal</td><td>Each byte of data is encoded in hexadecimal format (in stupid).</td>

<td>0x01</td><td>Decimal coded binary (BCD)</td><td>Each quartet represents a single digit. Therefore, only the decimal values ​​are specified. A data stream containing an odd number (length) of digits includes the hex value F in the first quartet of the data stream.</td>

<td>0x02</td><td>ASCII</td><td>Each byte represents an ACII value that is interpreted that way and is executed as its corresponding CHAR value. In most cases, these data streams are converted to a string before they are passed to the merchant's POS system for processing.</td>

A BCD encoded data value that includes the hexadecimal value F in the first quartet will identify a data stream that contains an odd number of digits. Therefore, the BCD 12345 data stream is encoded in a 3-byte buffer, as follows: 0xF12345.

Examples of implementations

FIG. 6 illustrates screen captures or windows generated by the graphical user interface for a wallet application in accordance with an embodiment example of the present invention. For the purposes of this implementation example, mobile device 110 has some loyalty cards and redeemable offers stored in memory 111b.

The wallet 601 home screen features a set of merchant 604 tiles. There is one tile for each merchant that has a redeemable item (eg, a loyalty card or redeemable offer) in the mobile wallet. For example, the user can scroll through the tiles, left and right, to find a particular merchant. Once the particular merchant is found, the tile is selected to open a 602 merchant offer view. This can be done prior to making a transaction or immediately before making the transaction, for example, while waiting in line, or before (eg, while searching for a store).

Merchant Offer View 602 presents a list of redeemable offers 603 available in the wallet. Non-exchangeable promotions can also be presented. If present, a 605 loyalty card is also presented and made available in Merchant Offer View 602.

If the selected merchant is not a merchant-enabled merchant, there is no option to upload offers for a commercial transaction. If the merchant is a merchant-enabled merchant, however, one or more buttons or icons 606a, 606b are presented, allowing offers to be loaded for a business transaction.

The user can select an offer (eg 606a) and then select the Accept button at the bottom of the screen.

In an example embodiment, security element 112 can guarantee a limit on the number of offers (eg, 10 offers), and the user interface of business tool 115 guarantees this limit while the user is activating offers. The Accept button activates the loading of selected offers in security element 112. If there are offers from another merchant in security element 112, they can be withdrawn at the same time as new offers are loaded, this ensures that there are only offers from one merchant in 112 at a given time.

When the loading of the security element is completed, the user touches the mobile device 110 with the reader 120. What happens next depends on some factors. If the touched reader cannot process the commercial elements, the selected payment card is sent, but no commercial elements are sent (eg offers or loyalty credentials). A message is presented after the touch through the reader interface, indicating that the payment credentials have been sent, without additional information.

If the touched reader can process the commercial items, but the merchant ID does not match the selected merchant, no offers will be sent. Business applet 113 in security element 112 can search for a loyalty card for this merchant ID and transmit loyalty credentials, if present. A message is presented after the touch through an interface, indicating that an event occurred and identifies the merchant and records that loyalty credentials (if available) were sent, as well as payment credentials.

If the reader being tapped is a merchant-enabled reader and the merchant ID matches the selected merchant, selected offers and (if present) loyalty card credentials are sent to the merchant. The mobile device 110 can present a message after the touch through the user interface of the commercial tool 115 confirming that the offers and loyalty (if present) were sent, along with the payments.

After the touch, the offers that were uploaded to security element 112 are kept in security element 112 until the user withdraws them or selects offers from another merchant. Alternatively, if the offers expire, they are removed from security element 112 when wallet maintenance is performed. In an example modality, the selected merchant will continue to be the active merchant on the wallet home page until the user selects a different merchant.

Implementation of instant offers

Fig. 7 illustrates a flowchart illustrating an instant offer implementation example in accordance with an embodiment of the present invention. In this modality, a mobile trading platform (MoCom) can be integrated with the merchant's POS system to implement a mechanism for users to select offers through the use of a wallet application and / or instant offers that merchants make available to the clients.

A wallet application running on a mobile device can be used to allow consumers to pay for purchases and present loyalty and offers through a payment terminal. One way that the consumer can redeem an offer is through the selection of the offer through the wallet application that will be presented at the point of payment.

Offers can also be provided to consumers that can be instantly redeemed through the wallet app. Offers are referred to herein as instant offers. This feature allows merchants to reward consumers who use a mobile device that runs the wallet application to make purchases. Consumers benefit from the instant offer since, among other reasons, they do not need to specifically select an offer using the wallet application. Depending on the implementation, an instant offer can be used in conjunction with an offer explicitly selected by the consumer from the wallet application. If the consumer selects an offer or is provided instantly, a consumer identification value (consumer ID) retrieved from the mobile device (eg, security element 112) is used as the key to retrieving and redeeming an instant offer .

Referring to Fig. 7, in one embodiment, a consumer selects offers from the wallet application to be presented at the point of payment. At block 702, a payment is requested at the POS. If, at block 704, the payment is determined not to be a contactless payment, at block 706 the payment process is completed by alternative means (eg, using cash) and the completion process is completed. If, at block 704, the payment is determined to be a contactless payment, the mobile device user is asked to touch his mobile device with the reader (eg, reader 120 described above).

In response, the mobile device is touched by the reader. During the touch event, a number of data items can be passed between the reader and a security item on the mobile device, as described above. In one embodiment, payment card, consumer ID, loyalty number, and offer code data is passed to the reader during the reader's touch. In this mode, the consumer ID is sent to the reader, even if the touch is for a payment-only transaction with no offers selected.

If, at block 708, it is determined that there is no MoCom consumer ID, at block 706, the payment process is completed and the completion process is completed by processing the payment.

If, at block 708, it is determined that there is an ID of the

<td>consumer</td><td>MoCom,</td><td>in</td><td>block 710 is determined</td><td>yes</td><td>there is</td><td>a</td>

<td>offer of</td><td>MoCom</td><td>tea-</td><td colspan="2">ex. , a selected offer</td><td>by</td><td>the</td>

<td colspan="2">user by</td><td>a</td><td>wallet app).</td><td>Yes,</td><td>in</td><td>the</td>

In block 710, it is determined that there is a MoCom offer, it is determined in block 712 whether a MoCom instant offer has also been defined. If, at block 712, it is determined that a MoCom instant offer has been defined, both the MoCom offer (i.e., an offer selected by a user via a wallet application interface) and an MoCom instant offer are processed. , as shown in block 714. Once the MoCom offer and / or MoCom instant offer is processed, the payment associated with the offers is processed, as shown in step 706.

If, in block 710, it is determined that there is no MoCom offer, it is determined in block 716 whether a MoCom instant offer has been defined. If not, the payment is completed, as shown in step 706. If a determination is made in block 716 that there is a MoCom instant offer, the MoCom instant offer is processed, as shown in block 718, and the payment associated with the MoCom instant offer is processed, as shown in block 706.

If a determination is made in block 712 that a MoCom instant offer has not been defined, a standard MoCom instant offer is processed, as shown in block 720, and the processed payment is completed in block 706.

The merchant's POS system can use the presence of the consumer ID to trigger the use of an instant offer. For example, the offer could be a cent reduction or percentage reduction offer that is defined by the merchant through the MoCom system. For example, this can be applied to the purchase of a specific item 5. In an implementation example, the merchant is provided with an option to disable instant offer functionality or when a wallet offer is presented during touch.

The merchant can define the instant offer and then distribute it to their retail sites. The offer may also have a specific associated start and end date. The ability to distribute instant offers to different geographic areas can also be considered.

Business applet / applet / instance management package

The following section defines AID values ​​and application-specific parameters used during download / installation of Business applet 113

Table 20 defines the AIDs.

(Fig. 1).

Table 20 - AID

<td>Description</td><td>AID</td>

<td>AID of</td><td>A0 00 00 04 85 10 01 01</td>

<td>package</td><td></td>

<td>AID of</td><td>A0 00 00 04 85 10 01 01 00</td>

<td>applet</td><td></td>

<td>AID of the</td><td>A0 00 00 04 85 10 01 01 01</td>

<td>instance</td><td></td>

I

Applet Specific Installation Parameters You can provide the initial business services data characteristics of Business Applet 15 using the applet specific installation parameters. This data complies with the JavaCard AID standard and the installation parameters.

These parameters must be coded as shown in

Table 21:

TABLE 21 - Subprogram installation parameters

<td>Data provision</td><td>Size in bytes</td><td>Value default</td><td>by</td>

<td>Maximum number of records</td><td> 2</td><td> 20</td><td></td>

<td>fidelity</td><td></td><td></td><td></td>

<td>Maximum number of records in the</td><td> 2</td><td> 1</td><td></td>

<td>merchant before loading</td><td></td><td></td><td></td>

<td>Maximum number of records</td><td> 2</td><td> 3</td><td></td>

<td>transaction</td><td></td><td></td><td></td>

<td>Total:</td><td> 6</td><td colspan="2"></td>

Memory requirements

Examples of memory specifications are listed in Table 22 below. The first memory description, Package Download, indicates the approximate amount of non-volatile memory space (EEPROM) required to download the package from the commercial applet. The second memory description, Instance Creation, indicates the amount of memory required to create an instance of the Business applet. The last memory requirement, Transient Data Space, indicates the amount of volatile memory (RAM) that each instance of the business applet uses.

TABLE 22 - Subprogram Memory Requirements

<td>Memory</td><td>Size</td>

<td></td><td>in bytes</td>

<td>Package Download</td><td> 9396</td>

<td>Instance creation</td><td> 6260</td>

<td>Data space</td><td> 518</td>

<td>transient</td><td></td>

Data management

Available business data (eg loyalty, offers, rewards, etc.) is stored within business applet 113 in security element 112. All relevant business data is stored in three individual data tables. These data tables are managed by business applet 113. Additional business data can be stored / managed within a corresponding business tool 115 on the equipment.

In one embodiment, the data elements defined herein have a variable length. Therefore, a maximum length will be assigned to all elements (including those with a fixed length). As a result, all references to lengths and size in bytes should be interpreted as maximum values.

Commercial data

Business applet 113 manages a few data fields shared by all business service applications. These data fields are stored in persistent data variables. Table 23 defines an example of a data item, the consumer ID. Additional items such as consumer / platform keys and certificates can also be stored.

TABLE 23

<td colspan="2">Variable</td><td>Kind</td><td colspan="3">Description</td>

<td></td><td></td><td></td><td colspan="2">Consumer ID</td><td>exclusive</td>

<td>ID</td><td>of the</td><td>byte []</td><td>assigned to</td><td>a</td><td>consumer</td>

<td>consumer</td><td></td><td></td><td>/user</td><td>of</td><td>MoCom</td>

<td></td><td></td><td></td><td>specific.</td><td></td><td></td>

Loyalty data table

Business applet 113 also includes loyalty data tables that allow the storage / management of all consumer loyalty data.

Table 24 defines the data elements (and their corresponding tag values ​​used during TLV encoding) that are included in the fidelity data table.

TABLE 24 - Loyalty data

<td>Data element</td><td>Value of the label</td><td>Size in bytes</td><td>Overload of coding of the TLV</td>

<td>LOYALTY_PROGRAM_ID [ID of the program fidelity]</td><td>0xDF41</td><td> 8</td><td> 3</td>

<td>LOYALTY_ACCOUNT_CODE [Account code of fidelity]</td><td>0xDF43</td><td> 32</td><td> 3</td>

<td colspan="2">Total:</td><td> 40</td><td> 6</td>

<td colspan="2">Minimum record size TLV encoded:</td><td colspan="2"> 46</td>

The data is stored in a registry-oriented data buffer, where the fidelity identifier (fidelity ID) is used as the key field for search / retrieval tasks.

In one example modality, the TLV data overhead includes a maximum of five bytes per element data overhead (2-byte tag and 3-byte length), as required by the BER-TLV encoding format.

In an alternative mode, an index (or table with check codes) can be created internally to increase the speed of the fidelity ID search task.

Cached merchant data table

The commercial applet 113 also includes a table of merchant data stored in the cache memory that allows to store / manage all the data related to a given merchant. This feature allows the commercial data of a given merchant to be preloaded by the wallet application 114 to improve performance.

Table 25 defines the data elements (and their corresponding tag values ​​used during TLV encoding) that are included in the cached merchant data table.

TABLE 25 - Merchant Data Cached

<td>Data element</td><td colspan="2">Value of the label</td><td>Size in bytes</td><td>Overload of TLV coding</td>

<td>MERCHANT ID</td><td colspan="2">0XDF31</td><td> 8</td><td> 3</td>

<td>LOYALTY_PROGRAM_ID [Loyalty Program ID]</td><td colspan="2">0xDF41</td><td> 8</td><td> 3</td>

<td>LOYALTY ACCOUNT CODE</td><td colspan="2">0xDF43</td><td> 32</td><td> 3</td>

<td>OFFER ID</td><td colspan="2">0xDF51</td><td> 8</td><td> 3</td>

<td>OFFER CODE</td><td colspan="2">0xDF53</td><td> 130</td><td> 3</td>

<td colspan="5"></td>

<td colspan="2">Maximum</td><td colspan="2"> 104</td><td> 6</td>

<td>Minimum size of TLV encoded:</td><td>registry</td><td colspan="3"> 110</td>

The data is stored in a registry-oriented data buffer, where the merchant identifier (merchant ID) is used as the key field for search / retrieval tasks. An index (or table with check codes) can be created internally to increase the speed of the merchant ID search task.

In one example modality, the TLV data overhead includes a maximum of five bytes per element data overhead (2-byte tag and 3-byte length), as required by the BER-TLV encoding format.

Transaction log

Business applet 113 includes a transaction log that is used to record usage within the MoCom platform at the MoCom point of sale. During synchronization tasks of Commercial Tool 115 and Security Element 112, this transaction log is transmitted to Commercial Tool 115 for subsequent Over-the-Air Synchronization (OTA) with the MoCom platform .

The actual content of the transaction log depends on the data / parameters of the Get Business Data command provided by reader 120 during the transaction process at the merchant's point of sale. An exact copy of the payload of the data sent to business applet 113 by reader 120 is stored using the Get Business Data APDU command within the business transaction log.

The status of the transaction is determined based on the logical result of the commercial data processing. If a data / processing error is detected within business applet 113, the corresponding internal error code can be attached to the transaction log.

The following table defines the data elements (and their corresponding tag values ​​used during TLV encoding) that are included in the transaction log.

TABLE 26 - Transaction registration data

<td>Data element</td><td>Value of the label</td><td>Size in bytes</td><td>Overload of TLV encoding</td>

<td>Data / parameter (s) of the Get Business Data command</td><td>XX</td><td> 255</td><td> 4</td>

<td>TRANSACTION STATUS</td><td>0xDF62</td><td> 3</td><td> 3</td>

<td colspan="2">Total:</td><td> 266</td><td> 7</td>

<td colspan="2">Maximum encoded record size of</td><td> 273</td><td></td>

<td>TLV:</td><td></td><td></td><td></td>

The data is stored in a register-oriented buffer memory. A variable data size of the Get Business Data command is enabled.

The TLV data overhead includes a maximum of five bytes per element data overhead (2-byte tag and 3-byte length), as required by the BER-TLV encoding format.

Error handling

In an example modality, error detection and management runs on two levels. First, the APDU command response includes a two-byte Status Word result value. These responses are standardized and determined by ISO 7816-4. However, the Business Services applet internally manages a second level of error execution. The second level of management includes issuing a standard status word 0x6909 in response to the APDU command. Following this response, the client can issue a second command (Get Internal Error Code) to obtain a two-byte internal error code. This code may be a cross reference to Table 27. Table 27 provides details about the site and the reason the error occurred within the applet.

In particular, Table 27 provides a master list of all possible internal error codes obtained by the APDU command Get Internal Error Code Supported by the Business applet.

<td></td><td>TABLE 27 - Internal error codes</td>

<td>Code</td><td></td>

<td>of</td><td>Error Description</td>

<td>error</td><td></td>

<td>0x0101</td><td>SSE_INTERNAL_ERROR_APPLET_NOT_PROVISION [SSE ERROR INTERNAL NO SUBPROGRAM PROVIDED]</td>

<td>0x0102</td><td>SSE_INTERNAL_ERROR_COMMAND_NOT_ALLOWED_VIA_ CONTACTLESS_INTERFACE [SSE INTERNAL ERROR COMMAND NO PERMITTED THROUGH NO CONTACT INTERFACE]</td>

<td>0x0103</td><td>SSE_INTERNAL_ERROR_COMMAND_NOT_ALLOWED_INVALID_CONTEXT [SSE INTERNAL ERROR COMMAND NOT PERMITTED CONTEXT INVALID]</td>

<td>0x0201</td><td>SSE_INSTALL_INVALID_INSTALLATION_PARAMETER_LENGTH [SSE INSTALL INSTALLATION PARAMETER LENGTH INVALID]</td>

<td>0x0301</td><td>SSE_PARSE_COMMAND_DATA_INVALID_COMMERCE_TAG [SSE SYNTATIC ANALYSIS OF LABEL COMMAND DATA INVALID COMMERCIAL]</td>

<td>0x0302</td><td>SSE_PARSE_COMMAND_DATA_INVALID_CONSUMER_ID_LENGTH [SSE SYNTATIC ANALYSIS OF COMMAND DATA LENGTH OF INVALID CONSUMER ID]</td>

100

<td>0x0302</td><td>SSE_PARSE_COMMAND_DATA_INVALID_MERCHANT_ID_LENGTH [SSE SYNTATIC ANALYSIS OF COMMAND DATA INVALID MERCHANT ID LENGTH]</td>

<td>0x0302</td><td>SSE_PARSE_COMMAND_DATA_INVALID_MERCHANT_LOCATION_ LENGTH [SSE SYNTATIC ANALYSIS OF COMMAND DATA INVALID CONSUMER LOCATION LENGTH]</td>

<td>0x0303</td><td>SSE_PARSE_COMMAND_DATA_INVALID_DATE_TIME_STAMP_ LENGTH [SSE SYNTATIC ANALYSIS OF COMMAND DATA INVALID DATE AND TIME MARK]</td>

<td>0x0304</td><td>SSE_PARSE_COMMAND_DATA_INVALID_MERCHANT_COMMERCE_ APP_VERSION_LENGTH [SSE SYNTATIC DATA ANALYSIS COMMAND APPLICATION VERSION LENGTH INVALID MERCHANT COMMERCIAL]</td>

<td>0x0305</td><td>SSE_PARSE_COMMAND_DATA_INVALID_MERCHANT_ CAPABILITIESJLENGTH [SSE SYNACTICAL ANALYSIS OF COMMAND DATA CAPACITY LENGTH OF INVALID TRADER]</td>

<td>0x0306</td><td>SSE_PARSE_COMMAND_DATA_INVALID_LOYALTY_ID_LENGTH [SSE SYNTATIC ANALYSIS OF COMMAND DATA INVALID LOYALTY ID LENGTH]</td>

<td>0x0307</td><td>SSE_PARSE_COMMAND_DATA_INVALID_LOYALTY_ACCOUNT_CODE_ LENGTH [SSE SYNTATIC ANALYSIS OF COMMAND DATA INVALID LOYALTY ACCOUNT CODE LENGTH]</td>

<td>0x0308</td><td>SSE_PARSE_COMMAND_DATA_INVALID_OFFER_ID_LENGTH [SSE SYNTATIC ANALYSIS OF ID LENGTH COMMAND DATA OF THE INVALID OFFER]</td>

<td>0x0309</td><td>SSE_PARSE_COMMAND_DATA_INVALID_OFFER_TYPE_CODE_ LENGTH [SSE SYNTATIC ANALYSIS OF COMMAND DATA CODE LENGTH OF INVALID OFFER TYPE]</td>

<td>0x030Α</td><td>SS E_PARS E_COMMAND_DATA_INVALID_TRANSACTION_ID_LENGTH [SSE SYNTATIC ANALYSIS OF COMMAND DATA ID LENGTH OF INVALID TRANSACTION]</td>

101

<td>0χ030Β</td><td>S SE_PARS E_COMMAND_DATA_INVALID_CACHED_MERCHANT_DATA_ OFFER_COUNT_LENGTH [SSE SYNTATIC ANALYSIS OF DATA FROM COMMAND LENGTH OF COUNT OF DATA OFFER OF MERCHANT STORED IN INVALID CACHE MEMORY]</td>

<td>0x030C</td><td>SSE_PARSE_COMMAND_DATA_INVALID_CACHED_MERCHANT_DATA_ LENGTH [SSE SYNTATIC ANALYSIS OF COMMAND DATA LENGTH OF MERCHANT DATA STORED IN MEMORY INVALID CACHE]</td>

<td>0X030D</td><td>SSE_PARSE_COMMAND_DATA_INVALID_COMMERCE_TAG [SSE SYNTATIC ANALYSIS OF COMMERCIAL LABEL COMMAND DATA INVALID]</td>

<td>OxOAOl</td><td>SSE_GET_RESPONSE_REMAINING_DATA_INVALID_RESUME_STATE [SSE GET ANSWER REMAINING DATA INVALID RESUME STATE]</td>

<td></td><td></td>

<td>OxOBOl</td><td>SS E_VERIFY_REQUIRED_PARAMETERS_INVALID_PARAMETER_TAG [SSE VERIFY REQUIRED PARAMETERS PARAMETER LABEL INVALID]</td>

<td>0x0B02</td><td>SSE_VERIFY_REQUIRED_PARAMETERS_DATE_TIME_STAMP_NOT_ PRESENT [SSE VERIFY REQUIRED PARAMETERS BRAND OF DATE AND TIME NOT PRESENT]</td>

<td>0x0B03</td><td>SSE_VERIFY_REQUIRED_PARAMETERS_MERCHANT_ID_NOT_PRESENT [SSE VERIFY REQUIRED PARAMETERS MERCHANT ID NOT PRESENT]</td>

<td>0x0B04</td><td>SS E_VERIFY_REQUIRED_PARAMETERS_MERCHANT_STORE_ID_NOT_ PRESENT [SSE VERIFY REQUIRED PARAMETERS ID OF MERCHANT'S TRADE NOT PRESENT]</td>

<td>0x0B05</td><td>SSE_VERIFY_REQUIRED_PARAMETERS_MERCHANT_COMMERCE_APP_ VERSION_NOT_PRESENT [SSE VERIFY REQUIRED PARAMETERS MERCHANT'S TRADE REQUEST VERSION NO PRESENT]</td>

102

<td>ΟχΟΒΟδ</td><td>SSE_VERIFY_REQUIRED_PARAMETERS_MERCHANT_ CAPABILITIES_NOT_PRESENT [SSE VERIFY PARAMETERS REQUIRED CAPACITY OF MERCHANT NOT PRESENT]</td>

<td>ΟχΟΒ07</td><td>SSE_VERIFY_REQUIRED_PARAMETERS_LOYALTY_ID_NOT PRESENT [SSE VERIFY REQUIRED PARAMETERS ID OF FAITHFULNESS PRESENT]</td>

<td>ΟχΟΒΟΘ</td><td>SSE ^ ERIFYJkE (2UIRED_PARAMErERS_L0YALTY_ACQC) UNT_C0DE_NOT_ PRESENT [SSE VERIFY REQUIRED PARAMETERS CODE OF LOYALTY ACCOUNT NOT PRESENT]</td>

<td>ΟχΟΒΟΑ</td><td>SSE_VERIFY_REQUIRED_PARAMETERS_OONSUMER_ID_NOT_PRESENT [SSE VERIFY REQUIRED PARAMETERS CONSUMER ID NO PRESENT]</td>

<td>ΟχΟΒΟΒ</td><td>SSE3 / ERIFY_REQUIRED_PAR7 \ MEIERS_CACHEDJ ^ ERCHANT_DATA_0FFER_ COUNT_NOT_PRESENT [SSE VERIFY REQUIRED PARAMETERS COUNT OF SUPPLY OF DATA OF THE OFFEROR STORED IN THE CACHE MEMORY NOT PRESENT]</td>

<td>OxOBOC</td><td>SSE_VERIFY_REQUIRED_PARAMETERS_EMBEDDED_TLV_CACHED_ MERCHANT_DATA_NOT_PRESENT [SSE VERIFY PARAMETERS REQUIRED MERCHANT DATA STORED IN THE INCORPORATED TLV CACHE MEMORY NOT PRESENT]</td>

<td>OxOCOl</td><td>SS E_GET_COMMERCE_DATA_INVALID_WALLET_STATE [SSE GET BUSINESS DATA STATEMENT OF WALLET INVALID]</td>

<td>OxOEOl</td><td>SS E_UPDATE_CACHED_MERCHANT_DATA_FAILED_CMD_BUFFER_ LENGTH_EXCEEDED [SSE DATA UPDATE FAILED OF THE MERCHANT STORED IN THE CACHE MEMORY CMD INTERMEDIATE MEMORY LENGTH EXCEEDED]</td>

<td>0x1101</td><td>LME_INVALID_LOYALTY_TAG [LME LOYALTY LABEL INVALID]</td>

103

<td>0x1102</td><td>LME_INVALID_LOYALTY_ID_LENGTH [LME ID LENGTH OF INVALID LOYALTY]</td>

<td>0x1103</td><td>LME_INVALID_LOYALTY_ACCOUNT_CODE_LENGTH [LME LOYALTY ACCOUNT CODE LENGTH INVALID]</td>

<td></td><td></td>

<td>0x1201</td><td>LME_GET_LOYALTY_DATA_RECORD_NOT_FOUND [LME GET FIDELITY DATA RECORD NOT FOUND]</td>

<td>0x1202</td><td>LME_GET_LOYALTY_DATA_INSUFFICIENT_BUFFER_LENGTH [LME OBTAIN FIDELITY DATA MEMORY LENGTH INSUFFICIENT INTERMEDIATE]</td>

<td>0x1301</td><td>LME_UPDATE_LOYALTY_ID_NOT_SPECIFIED [LME UPDATE FIDELITY ID NOT SPECIFIED]</td>

<td></td><td></td>

<td>0x1401</td><td>LME_DELETE_LOYALTY_ID_NOT_SPECIFIED [LME DELETE FIDELITY ID NOT SPECIFIED]</td>

<td>0x1402</td><td>LME_DELETE_LOYALTY_DATA_RECORD_NOT_FOUND [LME DELETE FIDELITY DATA RECORD NO FOUND]</td>

<td></td><td></td>

<td>0x1501</td><td>LME_GET_LOYALTY_RECORD_INSUFFICIENT_BUFFER_LENGTH [LME GET FIDELITY LOG LENGTH OF INSUFFICIENT INTERMEDIATE MEMORY]</td>

<td></td><td></td>

<td>0x3101</td><td>TLVME_MAX_DATA_LENGTH_EXCEEDED [TLVME LENGTH DATA EXCEEDED MAXIMUM]</td>

<td></td><td></td>

<td>0x3201</td><td>TLVME APPEND FAILED INVALID LENGTH [TLVME FAILED ATTACH INVALID LENGTH]</td>

<td></td><td></td>

104

<td>0x3301</td><td>TLVME_GET_NEXT_TAG_FAILED_INVALID_CONTEXT_NO_CURRENT_TAG [TLVME GET NEXT LABEL FAILED CONTEXT INVALID NO CURRENT LABEL]</td>

<td></td><td></td>

<td>0x3401</td><td>TLVME_GET_TLV_OBJECT_FAILED_INVALID_TAG_CLAS S [TLVME GET TLV OBJECT FAILED INVALID LABEL CLASS]</td>

<td>0x3402</td><td>TLVME_GET_TLV_OBJECT_FAILED_INVALID_LENGTH [TLVME GET TLV OBJECT FAILED INVALID LENGTH]</td>

<td>0x3403</td><td>TLVME_GET_TLV_OBJECT_FAILED_TLV_LENGTH_NOT_SUPPORTED [TLVME GET TLV OBJECT FAILED TLV LENGTH NO ADMITTED]</td>

<td></td><td></td>

<td>0x3501</td><td>TLVME_GET_NEXT_ELEMENT_FAILED_INVALID_TAG_CLASS [TLVME GET NEXT ITEM FAILED LABEL CLASS INVALID]</td>

<td>0x3502</td><td>TLVME_GET_NEXT_ELEMENT_FAILED_TLV_LENGTH_NOT_SUPPORTED [TLVME GET NEXT ITEM FAILED TLV LENGTH NOT ADMITTED]</td>

<td>0x3503</td><td>TLVME_GET_NEXT_ELEMENT_FAILED_INVALID_LENGTH [TLVME GET NEXT ITEM FAILED INVALID LENGTH]</td>

<td>0x3504</td><td>TLVME_GET_NEXT_ELEMENT_FAILED_BUFFER_LENGTH_EXCEEDED [TLVME GET NEXT ITEM FAILED LENGTH OF EXCESSED INTERMEDIATE MEMORY]</td>

<td></td><td></td>

<td>0x4101</td><td>DME_DATAMANAGER_INVALID_RECORD_NUMBER [DME MANAGER OF DATA INVALID REGISTRATION NUMBER]</td>

<td>0x4102</td><td>DME_DATAMANAGER_INVALID_RECORD_LENGTH [DME MANAGER OF INVALID REGISTRATION LENGTH DATA]</td>

105

<td>0x4103</td><td>DME_DATAMANAGER_RECORD_NOT_INITIALIZED [DME GESTOR REGISTRATION DATA NOT INITIALIZED]</td>

<td>0x4104</td><td>DME_DATAMANAGER_RECORD_STORE_FULL [DME MANAGER OF DATA REGISTRATION WAREHOUSE FULL]</td>

<td>0x4105</td><td>DME_DATAMANAGER_INVALID_DATA_LENGTH [DME MANAGER OF DATA INVALID DATA LENGTH]</td>

<td>0x4106</td><td>DME_DATAMANAGER_INSUFFICIENT_BUFFER_SIZE [DME DATA MANAGER INTERMEDIATE MEMORY SIZE INSUFFICIENT]</td>

<td></td><td></td>

<td>0x4201</td><td>DME_DATAMANAGER_PRIMARY_INDEX_NOT_ACTIVE [DME DATA MANAGER PRIMARY INDEX NOT ACTIVE]</td>

<td>0x4202</td><td>DME_DATAMANAGER_PRIMARY_INDEX_KEY_NOT_SPECIFIED [DME KEY DATA MANAGER PRIMARY INDEX NO SPECIFIED]</td>

<td>0X4203</td><td>DME_DATAMANAGER_INVALID_PRIMARY_INDEX_KEY_LENGTH [DME DATA MANAGER INDEX KEY LENGTH PRIMARY INVALID]</td>

<td></td><td></td>

<td>0xA201</td><td>SUE_NO_INSTALL_PARAMETERS_FOUND [SUE NOT KNOWN FOUND INSTALLATION PARAMETERS FOUND]</td>

106

<td>0xA202</td><td>SUE_INSUFFICIENT_APPLICATION_PARAMETER_BUFFER_ LENGTH [SUE INTERMEDIATE MEMORY LENGTH OF INSUFFICIENT APPLICATION PARAMETER]</td>

<td>0xA203</td><td>SUE_NO_APPLICATION_SPECIFIC_INSTALL_PARAMETERS_ FOUND [SUE NO PARAMETERS FOUND APPLICATION-SPECIFIC INSTALLATION]</td>

<td>OxDIOl</td><td>SSE_SECURITY_AUTHENTICATION_FAILED [SSE SECURITY AUTHENTICATION FAILURE]</td>

<td>0xD102</td><td>SSE_SECURITY_INVALID_CIPHER_DATA_LENGTH [SSE SECURITY LENGTH OF INVALID DATA]</td>

<td>0xD103</td><td>SSE_SECURITY_INVALID_KEY_DATA_LENGTH [SSE SECURITY INVALID KEY DATA LENGTH]</td>

<td>0XD104</td><td>SSE_SECURITY_INVALID_DIVERSIFICATION_DATA_LENGTH [SSE SECURITY DATA LENGTH OF INVALID DIVERSIFICATION]</td>

<td>OxDCOO</td><td>SSE_SECURITY_CRYPTO_EXCEPTION_UNDEFINED_REASON [SSE SECURITY EXCEPTION CRYPTO INDEFINITE REASON]</td>

<td>OxDCOl</td><td>SSE_SECURITY_CRYPTO_EXCEPTION_ILLEGAL_VALUE [SSE SECURITY EXCEPTION CRYPTO ILLEGAL VALUE]</td>

107

<td rowspan="2">0xDC02</td><td colspan="3">SSE_SECURITY_CRYPTO_EXCEPTION_UNINITIALIZED_</td>

<td>KEY [SSE SECURITY EXCEPTION INITIALIZED]</td><td>KEY CRYPTO</td><td>NOT</td>

<td>0xDC03</td><td>SSE SECURITY CRYPTO EXCEPTION</td><td>NO SUCH</td><td></td>

<td></td><td></td><td></td><td></td>

<td></td><td colspan="2">ALGORITHM [SSE SECURITY EXCEPTION CRYPTO</td><td>NOT</td>

<td></td><td>THERE IS SUCH ALGORITHM]</td><td></td><td></td>

<td>0xDC04</td><td>SS E_S ECURITY_CRYPTO_EXCE PTION_</td><td>INVALID_INIT</td><td></td>

<td></td><td colspan="3">[SSE SECURITY EXCEPTION CRYPTO INITIALIZATION</td>

<td></td><td>INVALID]</td><td></td><td></td>

<td>0XDC05</td><td>SS E_S E CURITY_CRYPTO_EXCEPTION_</td><td colspan="2">ILLEGAL_USE [SSE</td>

<td></td><td>SECURITY EXCEPTION CRYPTO USE</td><td>ILLEGAL]</td><td></td>

Commercial services

The following section provides a detailed description of the APDU commands available through commercial applet 113.

APDU Commands

All communications / data exchanges with commercial applet 113 will be performed using APDU commands, as defined in ISO 7816 standards. Additional restrictions and data execution are described below.

Command Usage Restrictions

For security reasons, a subset of the available commercial services commands may be restricted

108 to specific connection modes. In a mode, called a contact mode (wallet), all the commands for

APDUs defined in Table 18 above are available. However, in contactless mode, the following commands are allowed:

• Get version • Get internal error code • Get answer (remaining data) • Get business data

If any other APDU command is sent in contactless mode, you get an exception and set the value of the corresponding invalid command mode (0x0102) as Internal Error Code.

In one mode, the Get Business Data command can only be successfully executed when Wallet Application 114 is open. When the consumer starts or ends the wallet application 114, it is the responsibility of the wallet application 114 to notify a wallet company applet (WCAp) so that it can perform monitoring, management and / or security. In turn, the WCAp applet reports the status of the wallet application to the business applet through a shared interface. The

109 WCAp applets are described in US Patent Application No. 13 / 857,400 entitled Systems, Methods, and Computer Program Products For Securing And Managing Applications On Secure Elements. security] which is incorporated herein in its entirety by this reference.

Data payload management

Business applet 113 validates that all required parameters have been included in the data payload. However, in most cases, all irrelevant data elements can be ignored and a command will be processed normally. In one embodiment, business applet 113 checks the expected length value (Le). It can be assumed to be zero, allowing business applet 113 to send all available data through the response.

Get version

The Get Version command is used to get the version information of the currently loaded Business applet 113. The version will be stored in three bytes (xx.yy.zz), where xx = release version number, yy - major version number (Wave) and zz - minor version number. This information is assigned, for example, through a MoCom platform system, specified during the

110 applet development or packaging, or stored as a static value within code, and cannot be changed.

Table 28 defines the settings for the Get Version APDU command:

TABLE 28 - Obtain internal version

<td>CLA</td><td>INS</td><td>P1</td><td>P2</td><td>You</td><td>Data</td><td>You</td>

<td> 90</td><td> 10</td><td> 00</td><td> 00</td><td> 00</td><td>&lt;none&gt;</td><td> 3</td>

In one mode, no data is sent to the business applet. The length of the data Le is 0x00.

Version information is contained in a three-byte response. The length of the data Le is 0x03. A length of 0x00 is also allowed. The examples of response data elements are defined in Table 29:

TABLE 29 - Response Data

<td>Data element</td><td>Size in bytes</td><td>Value</td>

<td>Commercial version specification label</td><td> 1</td><td>0xDF12</td>

<td>Commercial version specification length</td><td> 1</td><td> 3</td>

<td>Commercial version specification value</td><td> 3</td><td>[Version (xx.yy.zz)]</td>

<td>Total:</td><td> 5</td><td></td>

Table 30 defines the possible Status Word values ​​that this command can return.

111

TABLE 30 - Status Codes

<td>SW1</td><td>SW2</td><td>Description</td>

<td> 90</td><td> 00</td><td>Successful command execution</td>

<td> 67</td><td> 00</td><td>Incorrect data length</td>

<td> 69</td><td> 09</td><td>Internal error</td>

Subprogram supply

A provision applet provisioning command enables you to supply (or update) consumer-related data, including customer ID and optionally related security data (certificates and key value). New / updated data values ​​are specified using the command data. In an example mode, the Supply Applet command can only be used to update the consumer ID.

Tables 31 and 32 define the settings for the Supply applet APDU command:

TABLE 31 - Supply applet

<td>CLA</td><td>INS</td><td>Pl</td><td>P2</td><td>You</td><td>Data</td><td>You</td>

<td> 90</td><td> 12</td><td> 00</td><td> 00</td><td>XX</td><td>Coded supply data by TLV</td><td> 00</td>

The incoming data, illustrated in Table 31,

112 they consist of the supply data encoded by TLV. Therefore, the length of the data Le is variable.

In one mode, business applet 113 does not return any data. The length of the data Le is 0x00.

TABLE 32 - Command Data

<td>Data element</td><td>Size</td><td>Value</td>

<td></td><td>in</td><td></td>

<td></td><td>bytes *</td><td></td>

<td>Supply element tag</td><td> 1</td><td>[Label of</td>

<td>of data</td><td></td><td>element]</td>

<td>Element data length</td><td> 1</td><td>XX</td>

<td>Element data value</td><td>XX</td><td>[Data]</td>

<td colspan="3"> .......</td>

<td>Total:</td><td>&lt;var&gt;</td><td></td>

Table 33 defines the possible Status Word values ​​that the Supply Applet command can return

TABLE 33 - Status Codes

<td>SW1</td><td>SW2</td><td>Description</td>

<td> 90</td><td> 00</td><td>Successful command execution</td>

<td> 67</td><td> 00</td><td>Incorrect data length</td>

<td> 69</td><td> 09</td><td>Internal error</td>

113

Get consumer information

The Get Consumer Information command is used to get a subset of static data related to the card owner (i.e. consumer). This data includes the following:

Consumer identifier

Table 34 defines the settings for the Get Consumer Information APDU command:

TABLE 34 - Obtain Consumer Information

<td>CLA</td><td>INS</td><td>P1</td><td>P2</td><td>You</td><td>Data</td><td>You</td>

<td> 90</td><td> 14</td><td> 00</td><td> 00</td><td> 00</td><td>&lt;none&gt;</td><td> 00</td>

No data is sent to business applet 113. The length of the data Le is, for example, 0x00. The actual length of the requested consumer information returned by the applet is variable, specific to the available consumer data. Therefore, the data length of Le is 0x00, which allows the applet to handle a variable length response.

The response data is returned as a stream of data formatted with TLV. The consumer ID can also be returned.

114

TABLE 35 - Response Data

<td>Data element</td><td>Size in bytes</td><td>Value</td>

<td>Consumer ID tag</td><td> 1</td><td>0XDF21</td>

<td>Consumer ID length</td><td> 1</td><td> 16</td>

<td>Consumer ID</td><td> 16</td><td>[ID of the consumer]</td>

<td>Total:</td><td>&lt;var&gt;</td><td></td>

Table 36 defines the possible Status Word values ​​that this command can return.

TABLE 36 - Status Codes

<td>SW1</td><td>SW2</td><td>Description</td>

<td> 90</td><td> 00</td><td>Successful command execution</td>

<td> 67</td><td> 00</td><td>Incorrect data length</td>

<td> 69</td><td> 09</td><td>Internal error</td>

Obtain business data

The Get Business Data command provides business information (eg loyalty, offers, and rewards) for a specified merchant (or set of merchants), based on the specified merchant / fidelity identifiers and offer types

115 admitted. This command provides a single point of contact to reader 120 attached to the merchant's POS system (eg, POS terminal).

A date / time stamp, merchant ID, merchant ID, business protocol version, and merchant capacity can be sent as part of the incoming data. Additional fidelity identifiers can also be sent to specify (filter) the requested fidelity information. The applet will search for a loyalty data table (Table 5), for the specified loyalty program / merchant ID and retrieve the corresponding loyalty data. Additional offer type codes can also be sent as part of the incoming data to specify the type of offer information requested. Business applet 113 searches the cached merchant data table (Table 25) for the specified merchant identifier / offer code / s and retrieves the corresponding offer data.

The required parameters include:

• Date / time stamp • Merchant ID • Merchant ID • Application version

116

Once the transmission has been successfully completed, the applet will create an entry in your transaction log that records the request for business data.

Tables 37 and 38 define the settings for the Get Business Data APDU command:

TABLE 37 - Obtain commercial data

<td>CLA</td><td>INS</td><td>Pl</td><td>P2</td><td>You</td><td>Data</td><td>You</td>

<td> 90</td><td> 50</td><td> 00</td><td> 00</td><td>XX</td><td></td><td> 00</td>

Incoming data consists of a date / time stamp (used for the transaction log), merchant identifier, merchant identifier, merchant capacity byte, and an optional set of additional data elements, including one or more additional loyalty identifiers (indicating loyalty programs supported by the merchant's site) and additional offer codes (indicating the type of offers supported by the merchant's site). In one embodiment, if a merchant does not specify a Merchant Capability parameter, a default mode is used that supports only loyalty and merchant-based offers.

The actual length of the requested business data returned by the applet is variable and specific to the

117 data related to the offers / loyalty available. Therefore, the data length of Le is 0x00, which allows the applet to handle a variable length response.

TABLE 38 - Command Data

<td>Data element</td><td>Size in bytes</td><td>Value</td>

<td>Date / time stamp label</td><td> 1</td><td>OxDFll</td>

<td>Date / time stamp length</td><td> 1</td><td> 7</td>

<td>Date / time stamp</td><td> 7</td><td>[Brand of date hour]</td>

<td>Merchant ID tag</td><td> 1</td><td>0xDF31</td>

<td>Merchant ID Length</td><td> 1</td><td> 8</td>

<td>Merchant ID</td><td> 8</td><td>[ID of the merchant]</td>

<td>Merchant ID tag</td><td> 1</td><td>0x32</td>

<td>Merchant ID Length</td><td> 1</td><td> 32</td>

<td>Merchant ID</td><td> 32</td><td>[Business ID]</td>

<td>Commercial version label</td><td> 1</td><td>0xDF12</td>

<td>Commercial version length</td><td> 1</td><td> 3</td>

118

<td>Commercial version data</td><td></td><td> 2</td><td>[Version application commercial]</td><td>of</td>

<td>Capacity label merchant</td><td>of the</td><td> 1</td><td>0xDF33</td><td></td>

<td>Capacity length merchant</td><td>of the</td><td> 1</td><td> 2</td><td></td>

<td>Capacity data merchant</td><td>of the</td><td> 1</td><td>[Code capacity merchant]</td><td>of of the</td>

<td>ID tag transaction</td><td>the</td><td> 1</td><td>0xDF61</td><td></td>

<td>ID length transaction</td><td>the</td><td> 1</td><td> 16</td><td></td>

<td>Transaction ID</td><td></td><td> 16</td><td>[ID of transaction]</td><td>the</td>

<td colspan="2">Loyalty ID tag additional</td><td> 1</td><td>0xDF41</td><td></td>

<td colspan="2">Loyalty ID Length additional</td><td> 1</td><td> 8</td><td></td>

<td>Additional loyalty ID</td><td></td><td> 8</td><td>[ID fidelity]</td><td>of</td>

119

<td colspan="3"> .......</td>

<td>Offer Type Label</td><td> 1</td><td>0xDF54</td>

<td>additional</td><td></td><td></td>

<td>Offer type length</td><td> 1</td><td> 9</td>

<td>additional</td><td></td><td></td>

<td>Offer type code</td><td> 9</td><td>[Type code</td>

<td>additional</td><td></td><td>offer]</td>

<td colspan="3"> .......</td>

<td>Total:</td><td>&lt;var&gt;</td><td></td>

The response data is returned as a stream of data formatted with TLV. The MoCom platform specific consumer identifier and all relevant offer / loyalty data are returned in a single data payload.

Consumer ID

The consumer ID is sent in TLV format, where the data is sent using the label CONSUMER_ID [CONSUMER ID] (0XDF21). In one mode, unless an error is detected, the client ID will always be returned.

Fidelity

In one embodiment, each loyalty data instance will consist of the following data elements encoded by TLV:

120 • Loyalty identifier • Loyalty account code

Within this data stream, the first tag will contain the byte of the fidelity identifier tag (T) (0xDF41). The length byte (L) will specify the length of the fidelity identifier. The value (V) will contain the actual fidelity identifier of length L for the corresponding fidelity data to be established immediately below.

The second label should contain the byte of the Loyalty Account Code (T) label (0xDF43).

The length byte (L) will specify the total length of the account code data related to the

Previous fidelity identifier. The value (V) will contain the actual fidelity data of length L.

Any additional fidelity identifiers found in the fidelity data table are attached to the payload of the data encoded by TLV using this same format.

Offers

Each offer data instance will consist of the following data elements encoded by TLV:

• Offer ID • Offer Code

121

Within this data stream, the first tag contains the byte of the bid ID tag (T) (0xDF51). The length byte (L) specifies the length of the

Offer ID. The value (V) contains the offer ID for the corresponding offer data below.

The second label preferably contains the byte value of the Offer Code (T) label (0xDF53). The length byte (L) specifies the length of the Offer Type Code. The value (V) contains the data of the Offer Code for the corresponding offer ID.

Any additional offer identifiers found in the offer data table are attached to the payload of the data encoded by TLV using this same format. The examples of response data are defined in

Table 39.

122

TABLE 39 - Response Data

<td>Data element</td><td>Size in bytes</td><td>Value</td>

<td>Identifier label of consumer</td><td> 1</td><td>0XDF21</td>

<td>Identifier length of consumer</td><td> 1</td><td> 16</td>

<td>Consumer identifier</td><td> 16</td><td>[ID of the consumer]</td>

<td>Identifier tag fidelity</td><td> 1</td><td>0xDF41</td>

<td>Identifier length</td><td> 1</td><td> 8</td>

<td>Loyalty identifier</td><td> 8</td><td>[ID of fidelity]</td>

<td>Account Code Label loyalty</td><td> 1</td><td>0xDF43</td>

123

<td>Account Code Length</td><td> 1</td><td> 32</td>

<td>Loyalty account code</td><td> 32</td><td>[Code of</td>

<td></td><td></td><td>bill]</td>

<td colspan="3"> .......</td>

<td>Offer ID tag</td><td> 1</td><td>0xDF51</td>

<td>Offer ID Length</td><td> 1</td><td> 8</td>

<td>Offer ID value</td><td> 8</td><td>[ID of the</td>

<td></td><td></td><td>offer]</td>

<td>Offer Code Label</td><td> 1</td><td>0xDF53</td>

<td>Offer Code Length</td><td> 1</td><td> 130</td>

<td>Offer Code Value</td><td> 130</td><td>[Code of the</td>

<td></td><td></td><td>offer]</td>

<td colspan="3"> .......</td>

<td>Total:</td><td>&lt;var&gt;</td><td></td>

Business applet 113 handles the transmission of multiple response packets (using the Get Response command) when the total data length exceeds 256 bytes. Table 40 defines the possible Status Word values ​​that the Get Response command can return.

124

TABLE 40 - Status Codes

<td>SW1</td><td>SW2</td><td>Description</td>

<td> 90</td><td> 00</td><td>Successful command execution</td>

<td> 61</td><td> 00</td><td>Successful command execution with data</td>

<td></td><td></td><td>Additional available through Get</td>

<td></td><td></td><td>answer</td>

<td> 67</td><td> 00</td><td>Incorrect data length</td>

<td> 69</td><td> 09</td><td>Internal error</td>

Post-transaction data

The Post-Transaction Data command provides a method through which the merchant's PoS system or payment terminal can return post-transaction data, including the 15 redeemed coupons, new offers, electronic receipts, or other improved business data.

Tables 41 and 42 define the settings for the Post-Transaction Data APDU command:

TABLE 41 - Post-transaction data

<td>CLA</td><td>INS</td><td>P1</td><td>P2</td><td>You</td><td colspan="4">Data</td><td>You</td>

<td> 90</td><td> 52</td><td> 00</td><td> 00</td><td>XX</td><td>&lt;Data</td><td>of</td><td>the</td><td>transaction</td><td> 00</td>

<td></td><td></td><td></td><td></td><td></td><td colspan="2">encoded by</td><td>TLV&gt;</td><td></td><td></td>

Incoming data consists of supply data

125 encrypted by TLV and a platform signature for authentication purposes. Therefore, the length of the data Le is variable.

Business applet 113 does not necessarily have to return 5 data. The length of the data Le is 0x00.

TABLE 42 - Command Data

<td>Data element</td><td>Size in bytes</td><td>Value</td>

<td>Post-transaction data element tag</td><td> 1</td><td>[Label of element]</td>

<td>Element data length</td><td> 1</td><td>XX</td>

<td>Element data value</td><td>XX</td><td>[Data]</td>

<td colspan="3"> .......</td>

<td>Total:</td><td>&lt;var&gt;</td><td></td>

Table 43 defines the possible Status Word values ​​that the Post-Transaction Data command can return.

TABLE 43 - Status Codes

<td>SW1</td><td>SW2</td><td>Description</td>

<td> 90</td><td> 00</td><td>Successful command execution</td>

<td> 67</td><td> 00</td><td>Incorrect data length</td>

<td> 69</td><td> 09</td><td>Internal error</td>

Get transaction log

The Get Transaction Log command is used to get all the data stored in the transaction log. Typically, this command is used by the business tool for the purposes of security element data synchronization tasks and the tool.

126

Table 44 defines the settings for the Get Transaction Log APDU command:

TABLE 44 - Obtain transaction record

<td>CLA</td><td>INS</td><td>P1</td><td>P2</td><td>You</td><td>Data</td><td>You</td>

<td> 90</td><td> 54</td><td> 00</td><td>Ox</td><td> 00</td><td>&lt;none</td><td></td>

<td>P2 value</td><td>Subprogram behavior</td>

<td>0x00</td><td>Normal processing</td>

<td>0x01</td><td>Delete record from transaction. They were not transmitted data.</td>

<td>0x02</td><td>Get registration status of the transaction</td>

In one mode, no data is sent to the business applet. The length of the data Le is 0x00. The actual length of the transaction data returned by the applet is variable, depending on the number of transaction records and the variable length of the corresponding transaction record data. Therefore, the data length of Le can be 0x00, allowing business applet 113 to handle a variable length response.

Preferably, the response data is returned as a data stream formatted with TLV.

127

Transaction log response data

Each transaction record will consist of a built-in TLV transaction record tag, followed by all related data elements. The data elements included in the transaction log are a mirror of those provided during the corresponding Get Business Data command requested by the merchant-enabled payment terminal (NFC reader) at the merchant's point of sale. Additional transaction records are attached to the data using the same format.

Table 45 illustrates examples of response data.

TABLE 45 - Response Data

<td>Data element</td><td>Size in bytes</td><td>Value</td>

<td>Record label embedded TLV transaction</td><td> 1</td><td>0xDF60</td>

<td>Record length embedded TLV transaction</td><td> 3</td><td>XX</td>

<td>Transaction details encoded by TLV</td><td>XX</td><td>XX</td>

<td colspan="3"> .......</td>

<td>Total:</td><td>&lt;var&gt;</td><td></td>

In one embodiment, commercial applet 113 manages the transmission of multiple response packets, using the Get Response command, when the total data length exceeds 256 bytes.

Registration status response data from the

128 transaction

When the transaction registration status is requested, the business applet responds with status information within the embedded TLV data payload. This data includes the number of available transaction records, loyalty and offer records sent during the last transaction. This is the same data payload that is provided to WCAp through the shared interface. Table 46 illustrates examples of response data.

TABLE 46 - Response Data

<td>Element of</td><td colspan="2">data</td><td>Size in</td><td>Value</td>

<td></td><td></td><td></td><td>bytes</td><td></td>

<td>Label</td><td>of</td><td>state</td><td> 1</td><td>0xE4</td>

<td>transaction</td><td>from TLV</td><td>Incorporated</td><td></td><td></td>

<td>Length</td><td>of</td><td>register of</td><td> 1</td><td>OxOC</td>

<td>transaction</td><td>from TLV</td><td>Incorporated</td><td></td><td></td>

129

<td>Record count tag of the transaction</td><td> 1</td><td>OxDB</td>

<td>Record count length of the transaction</td><td> 1</td><td>0x02</td>

<td>Record count value of the transaction</td><td> 2</td><td>xx</td>

<td>Loyalty count tag of the last transaction</td><td> 1</td><td>OxDC</td>

<td>Loyalty count length of the last transaction</td><td> 1</td><td>0x02</td>

<td>Loyalty count value of the last transaction</td><td> 2</td><td>XX</td>

<td>Offer count tag the last transaction</td><td> 1</td><td>OxDD</td>

<td>Offer Count Length the last transaction</td><td> 1</td><td>0x02</td>

<td>Offer count value of the last transaction</td><td> 2</td><td>XX</td>

<td>Total:</td><td> 14</td><td></td>

130

Table 47 defines the possible Status Word values ​​that the Get Transaction Log command can return.

TABLE 47 - Status Codes

<td>SW1</td><td>SW2</td><td>Description</td>

<td> 90</td><td> 00</td><td>Successful command execution</td>

<td> 61</td><td> 00</td><td>Successful command execution with data Additional available through Get answer</td>

<td> 67</td><td> 00</td><td>Incorrect data length</td>

<td>6B</td><td> 00</td><td>Wrong P1 / P2 parameter</td>

<td> 69</td><td> 09</td><td>Internal error</td>

Get internal error code

The Get Internal Error Code command is used to retrieve the last internal error code generated by the Business Services applet. This code provides a value that can cross reference the Internal Error Codes table (Table 26), which provides a more specific description of the error. This command is used for more detailed diagnosis and error resolution.

Table 48 defines the settings for the command

131 APDU Get internal error code:

TABLE 48 - Get internal error code

<td>CLA</td><td>INS</td><td>Pl</td><td>P2</td><td>You</td><td>Data</td><td>You</td>

<td> 90</td><td> 70</td><td> 00</td><td> 00</td><td> 00</td><td>&lt;none&gt;</td><td> 02</td>

In one mode, no data is sent to the applet. Le's data length is 0x00. The error code is contained within a two-byte response. Therefore, the length of the data Le is 0x02.

The following Table defines the possible Status Word values ​​that this command can return.

TABLE 49 - Status Codes

<td>SW1</td><td>SW2</td><td>Description</td>

<td> 90</td><td> 00</td><td>Successful command execution</td>

<td> 67</td><td> 00</td><td>Incorrect data length</td>

<td> 69</td><td> 09</td><td>Internal error</td>

Loyalty services

Obtain loyalty data

The Get Loyalty Data command defined in the

Tables 50 and 51 are used to obtain the stored fidelity information based on a specified fidelity identifier. The fidelity identifier of two

132 Bytes can be sent as part of the incoming data to specify the requested fidelity information. The business applet scans a loyalty data table for the specified loyalty / merchant ID and retrieves all corresponding loyalty data.

TABLE 50 - Obtain loyalty data

<td>CLA</td><td>INS</td><td>Pl</td><td>P2</td><td>You</td><td>Data</td><td>You</td>

<td> 90</td><td> 30</td><td> 00</td><td> 00</td><td>XX</td><td>[Loyalty ID encoded by TLV]</td><td> 00</td>

The incoming (optional) data will consist of a TLV-encoded fidelity identifier indicating the requested fidelity information. If Le is set to 0x00 (no incoming data is specified), all available fidelity identifiers are returned.

The actual length of the requested fidelity data returned by the applet is variable, specific to the available / requested fidelity data. Therefore, the data length of Le is 0x00, allowing the applet to handle a variable length response.

133

TABLE 51 - Command Data

<td>Data element</td><td>Size in bytes</td><td>Value</td>

<td>Identifier tag</td><td> 1</td><td>0xDF41</td>

<td>fidelity</td><td></td><td></td>

<td>Identifier length</td><td> 1</td><td> 8</td>

<td>fidelity</td><td></td><td></td>

<td>Loyalty identifier</td><td> 8</td><td>[ID of</td>

<td></td><td></td><td>fidelity]</td>

<td>Total:</td><td>&lt;var&gt;</td><td></td>

The response data (Table 51) is returned as a data stream formatted with TLV. All relevant loyalty data is returned in a single data payload.

In one mode, if fidelity data dump is requested (Le = 0x00), a list of all fidelity identifiers is returned in LV format (no label). Therefore, only the Loyalty Identifier is included for each entry in the data payload.

Each loyalty data instance includes the following data elements:

Loyalty identifier

134

Loyalty account code

TABLE 52 - Response Data

<td>Data element</td><td>Size in bytes</td><td>Value</td>

<td>Identifier tag fidelity</td><td> 1</td><td>0xDF41</td>

<td>Identifier length</td><td> 1</td><td> 8</td>

<td>Loyalty identifier</td><td> 8</td><td>[ID of fidelity]</td>

<td>Loyalty Account Code Label</td><td> 1</td><td>0xDF43</td>

<td>Account Code Length</td><td> 1</td><td>XX</td>

<td>Loyalty account code</td><td>XX</td><td>[Code of bill]</td>

<td>Total (Max):</td><td>&lt;var&gt;</td><td></td>

Table 53 defines the possible Status Word values ​​that this command can return.

TABLE 53 - Status Codes

<td>SWl</td><td>SW2</td><td>Description</td>

<td> 90</td><td> 00</td><td>Successful command execution</td>

<td> 61</td><td> 00</td><td>Successful command execution with additional data available through Get Response</td>

<td> 67</td><td> 00</td><td>Incorrect data length</td>

<td> 69</td><td> 09</td><td>Internal error</td>

Update loyalty data

The Update Loyalty Data command is used to add or update the loyalty data of the specified merchant. The data is sent as a stream of data formatted with TLV. If there is a fidelity identifier specified, the fidelity data is updated

135 corresponding. If there is no fidelity identifier, a new data record is created in the fidelity data table. Tables 54 and 55 define the settings for the Update Loyalty Data APDU command:

TABLE 54 - Updating loyalty data

<td>CLA</td><td>INS</td><td>Pl</td><td>P2</td><td>You</td><td>Data</td><td>You</td>

<td> 90</td><td> 32</td><td> 00</td><td> 00</td><td>XX</td><td>Loyalty data encoded by TLV</td><td> 00</td>

Incoming data will consist of fidelity data encoded by TLV. Therefore, the length of the data Le is variable. In one mode, the applet does not return data. The length of the data Le is 0x00.

TABLE 55 - Command Data

<td>Data element</td><td>Size in bytes</td><td>Value</td>

<td>Identifier tag fidelity</td><td> 1</td><td>0xDF41</td>

<td>Identifier length</td><td> 1</td><td> 8</td>

<td>Loyalty identifier</td><td> 8</td><td>[ID of fidelity]</td>

<td>Loyalty Account Code Label</td><td> 1</td><td>0xDF43</td>

<td>Account Code Length</td><td> 1</td><td>XX</td>

<td>Loyalty account code</td><td>XX</td><td>[Code of bill]</td>

<td>Total:</td><td>&lt;var&gt;</td><td></td>

Table 56 defines the possible Status Word values ​​that this command can return.

136

TABLE 56 - Status Codes

<td>SW1</td><td>SW2</td><td>Description</td>

<td> 90</td><td> 00</td><td>Successful command execution</td>

<td> 67</td><td> 00</td><td>Incorrect data length</td>

<td> 69</td><td> 09</td><td>Internal error</td>

Delete loyalty data

The Delete Loyalty Data command is used to delete the loyalty data of the specified merchant. The data command specifies the byte code of the merchant. Alternatively, the P2 byte can be used to debug existing offerings. If P2 is set to

OxFF, all offer data repository is removed.

Tables 57 and 58 define the settings for the Delete Loyalty Data APDU command:

TABLE 57 - Delete loyalty data

<td>CLA</td><td>INS</td><td>P1</td><td>P2</td><td>You</td><td>Data</td><td>You</td>

<td> 90</td><td> 34</td><td> 00</td><td>XX</td><td>XX</td><td>TLV-encoded fidelity ID</td><td> 00</td>

The incoming data consists of a fidelity identifier encoded by TLV. Therefore, the length of the data Le is variable.

In one modality, commercial applet 113 does not

137 returns no data. The length of the data Le is 0x00.

TABLE 58 - Command Data

<td>Data element</td><td>Size in bytes</td><td>Value</td>

<td>Identifier tag fidelity</td><td> 1</td><td>0xDF41</td>

<td>Identifier length fidelity</td><td> 1</td><td>XX</td>

<td>Loyalty identifier</td><td>XX</td><td>[ID of fidelity]</td>

<td>Total:</td><td>&lt;var&gt;</td><td></td>

<td>P2 value</td><td>Subprogram behavior</td>

<td>0x00</td><td>Normal processing</td>

<td>OxFF</td><td>Debug loyalty table (delete all records)</td>

Table 59 defines the possible Status Word values ​​that the Delete Loyalty Data command can return.

TABLE 59 - Status Codes

<td>SW1</td><td>SW2</td><td>Description</td>

<td> 90</td><td> 00</td><td>Successful command execution</td>

<td> 67</td><td> 00</td><td>Incorrect data length</td>

<td> 69</td><td> 09</td><td>Internal error</td>

Cached merchant data services

Get cached merchant data

138

The Get Cached Merchant Data command is used to get all previously loaded data that belongs to a specific merchant. The merchant identifier can be sent as part of the incoming data to specify the previously loaded data requested. If provided, business applet 113 scans a cached merchant data table for the specified merchant ID and retrieves all corresponding data.

This command can also be used to obtain information about merchants stored in the cache stored in the Business Services applet.

Table 60 defines the settings for the Get Cached Merchant Data APDU command:

TABLE 60 - Get Cached Merchant Data

<td>CLA</td><td>INS</td><td>P1</td><td>P2</td><td>You</td><td>Data</td><td>You</td>

<td> 90</td><td> 56</td><td> 00</td><td> 00</td><td>XX</td><td>&lt;none&gt;</td><td> 00</td>

In one mode, no data is sent to the applet. Le's data length is 0x00. The actual length of the requested cached merchant data returned by the applet is variable,

139 specific to available / requested cached merchant data. Therefore, the data length of Le is 0x00, allowing the applet to handle a variable length response.

Response data (Table 61) can be returned as a data stream formatted with TLV. All cached data is returned in a single data payload. Each instance of the cached merchant data includes the following corresponding cached merchant data elements (if available):

• Merchant Identifier • Loyalty Identifier • Loyalty Account Code • Offer Identifier (s) • Offer Code (s)

140

TABLE 61 - Response Data

<td>Data element</td><td>Size in bytes</td><td>Value</td>

<td>Merchant ID tag</td><td> 1</td><td>0xDF31</td>

<td>Merchant ID Length</td><td> 1</td><td> 8</td>

<td>Merchant ID</td><td> 8</td><td>[ID of the merchant]</td>

<td>Loyalty ID tag</td><td> 1</td><td>0xDF41</td>

<td>Loyalty ID Length</td><td> 1</td><td> 8</td>

<td>Loyalty ID value</td><td> 8</td><td>[Loyalty ID]</td>

<td>Loyalty Account Code Label</td><td> 1</td><td>0xDF43</td>

<td>Loyalty Account Code Length</td><td> 1</td><td> 32</td>

<td>Value of the Loyalty Account Code</td><td> 32</td><td>[Loyalty account code]</td>

<td colspan="3"> .......</td>

<td>Offer ID tag</td><td> 1</td><td>0xDF51</td>

<td>Offer ID Length</td><td> 1</td><td>XX</td>

<td>Offer ID value</td><td>XX</td><td>[Offer ID]</td>

<td>Offer Code Label</td><td> 1</td><td>0xDF53</td>

<td>Offer Code Length</td><td> 1</td><td>XX</td>

<td>Offer Code Value</td><td>XX</td><td>[Code of the offer]</td>

<td colspan="3"> .......</td>

<td colspan="3">Total: | &lt;var&gt; |</td>

In an example modality, the cached merchant data will be loaded / managed by the wallet application and may include multiple bid codes / LDs belonging to the specific merchant. However, the applet will generate a prefix of the customer identifier to the response data and will attach any additional offer / loyalty data requested by the Get Business Data command.

141

Table 62 defines the possible Status Word values ​​that this command can return.

TABLE 62 - Status Codes

<td>SWl</td><td>SW2</td><td>Description</td>

<td> 90</td><td> 00</td><td>Successful command execution</td>

<td> 67</td><td> 00</td><td>Incorrect data length</td>

<td> 69</td><td> 09</td><td>Internal error</td>

Update cached merchant data

The Refresh Cached Merchant Data command is used to update cached data (quick response) for a specified merchant. The data is sent as a TLV-formatted data stream, similar to the response data returned by the Get Business Data command. This command is used to preload a response from

Obtain business details of the given merchant.

Tables 63 and 64 define the settings for the Refresh Cache Merchant Data APDU command:

142

TABLE 63 - Update Cached Merchant Data

<td>CLA</td><td>INS</td><td>P1</td><td>P2</td><td>You</td><td colspan="4">Data</td><td>You</td>

<td> 90</td><td> 58</td><td> 00</td><td>Ox</td><td>XX</td><td>Data</td><td>of the</td><td colspan="2">merchant</td><td> 02</td>

<td></td><td></td><td></td><td></td><td></td><td colspan="2">stored in</td><td>the</td><td>memory</td><td></td>

<td></td><td></td><td></td><td></td><td></td><td>cache</td><td>coded</td><td>by</td><td>TLV</td><td></td>

P2 value

0x00

0x01

OXff

Applet behavior Normal processing APDU string (data will be attached to the buffer

Delete cached merchant data [Le = 0]

Incoming data consists of merchant data stored in cache memory encoded by TLV. Therefore, the length of the data Le is variable.

The business applet returns a two-byte response that contains the number of available bytes remaining in the cache of merchant data stored in the cache. Therefore, the length of the data Le is 0x02 (or 0x00).

143

TABLE 64 - Command Data

<td>Data element</td><td>Size in bytes</td><td>Value</td>

<td>Merchant ID tag</td><td> 1</td><td>0xDF31</td>

<td>Merchant ID Length</td><td> 1</td><td> 8</td>

<td>Merchant ID value</td><td> 8</td><td>[ID of the merchant]</td>

<td>Offer count tag merchant details cached</td><td> 1</td><td>0x57</td>

<td>Offer Count Length merchant details cached</td><td> 1</td><td> 1</td>

<td>Offer count value of merchant details cached</td><td> 1</td><td>[Count of CMD offer]</td>

<td>Data label of merchant stored in the TLV cache Incorporated</td><td> 1</td><td>0x58</td>

144

<td>Length</td><td>of</td><td>data</td><td>of the</td><td>XX</td><td>XX</td>

<td>merchant</td><td colspan="2">stored in</td><td>the</td><td></td><td></td>

<td>memory</td><td>cache</td><td>of the</td><td>TLV</td><td></td><td></td>

<td>Incorporated</td><td></td><td></td><td></td><td></td><td></td>

<td>Label of</td><td>ID of</td><td>the offer</td><td></td><td> 1</td><td>0xDF51</td>

<td>Lenght of</td><td>ID of</td><td>the offer</td><td></td><td> 1</td><td>XX</td>

<td>ID value</td><td>of the</td><td>offer</td><td></td><td>XX</td><td>[ID of the</td>

<td></td><td></td><td></td><td></td><td></td><td>offer]</td>

<td>Label of</td><td>Code</td><td colspan="2">of the offer</td><td> 1</td><td>0xDF53</td>

<td>Lenght of</td><td>Code</td><td colspan="2">of the offer</td><td> 1</td><td>XX</td>

<td colspan="2">Code Value</td><td>the offer</td><td></td><td>XX</td><td>[Code of the</td>

<td></td><td></td><td></td><td></td><td></td><td>offer]</td>

<td colspan="6"> .......</td>

<td colspan="4">Total:</td><td>&lt;var&gt;</td><td></td>

The response data (Table 65) returned by the command consists of a 2-byte (short) value that represents the number of remaining bytes available in the cache of merchant data stored in the cache. This allows wallet application 114 to manage how many cached offerings can fit in the Business Services applet.

145

TABLE 65 - Response Data

<td>Element of</td><td>data</td><td>Size in bytes</td><td>Value</td>

<td>Size of</td><td>the buffer</td><td> 2</td><td>XX</td>

<td>(bytes) of</td><td>merchant details</td><td></td><td></td>

<td>stored</td><td>in the cache</td><td></td><td></td>

<td>available</td><td></td><td></td><td></td>

<td colspan="2">Total:</td><td> 2</td><td></td>

Table 66 defines the possible Status Word values ​​that this command can return.

TABLE 66 - Status Codes

<td>SW1</td><td>SW2</td><td>Description</td>

<td> 90</td><td> 00</td><td>Successful command execution</td>

<td> 67</td><td> 00</td><td>Incorrect data length</td>

<td> 69</td><td> 09</td><td>Internal error</td>

Table 67 defines the data elements and corresponding values ​​and target / max byte sizes used by business applications in accordance with the examples of aspects described herein. Additional values ​​were provided for items with a limited / fixed value range.

146

TABLE 67

<td colspan="4">Commercial services</td>

<td colspan="4">Shared data items</td>

<td>Data element</td><td>Label ta</td><td>Max Size</td><td>Description</td>

<td>DATE_TIME_STAMP</td><td>0x11</td><td> 7</td><td>Brand of date hour</td>

<td>COMMERCE_APP_VERSION</td><td>0x12</td><td> 3</td><td>Number of version of application commercial admitted</td>

<td colspan="4">Consumer data elements</td>

<td>Data element</td><td>Label ta</td><td>Size maximum</td><td>Description</td>

147

<td>CONSUMER_ID</td><td>0x21</td><td> 16</td><td>Identifier of specific consumer the MoCom platform</td>

<td>CONSUMER_KEY</td><td>0x22</td><td> 16</td><td>Specific 3DES key consumer generated by the MoCom platform</td>

<td>CONSUMER_CERT</td><td>0x23</td><td> 8</td><td>Signature / certificate of consumer generated by the MoCom platform</td>

<td colspan="4">Merchant data elements</td>

<td>Data element</td><td>Label ueta</td><td>Tama not maxi mo</td><td>Description</td>

<td>MERCHANT_ID</td><td>0x31</td><td> 8</td><td>Identifier of specific merchant the MoCom platform</td>

<td>MERCHANT_STORE_ID</td><td>0x32</td><td> 32</td><td>Identifier of the trade of specific merchant the MoCom platform</td>

148

<td>MERCHANT_CAPABILI TY</td><td>0x33</td><td> 2</td><td>Services of the commercial application admitted</td>

<td>READER_START_MODE</td><td>0x34</td><td> 2</td><td>Start mode of payment terminal with NFC enabled (provided by the POS system merchant during the initialization)</td>

<td colspan="4">Merchant Capabilities</td>

<td>Data element</td><td>Value</td><td>Size maximum</td><td>Description</td>

<td>MERCAP_MERCHANT_ LOYALTY</td><td>0x80</td><td> 1</td><td>The Get command Commercial data includes a valid identifier of the merchant who used to determine the loyalty data received by the applet.</td>

149

<td>MERCAP_ADDITIONAL LOYALTY</td><td>0x4 0</td><td> 1</td><td>Request to Obtain Commercial data includes identifiers loyalty additional. The data additional loyalty are determined by the loyalty ID specified.</td>

<td></td><td></td><td></td><td>Fields of</td>

<td>MERCAP_MERCHANT_</td><td>0x2 0</td><td> 1</td><td>type of offer in the</td>

<td>OFFERS</td><td></td><td></td><td>Get request</td>

<td></td><td></td><td></td><td>Commercial data</td>

<td></td><td></td><td></td><td>The Get Data command</td>

<td></td><td></td><td></td><td>commercial includes a</td>

<td></td><td></td><td></td><td>valid identifier of</td>

<td>MERCAP_ADDITIONAL</td><td>0x10</td><td> 1</td><td>merchant being used</td>

<td></td><td></td><td></td><td>to determine the</td>

<td>OFFERS</td><td></td><td></td><td>offers data</td>

<td></td><td></td><td></td><td>received by the</td>

<td></td><td></td><td></td><td>applet.</td>

150

<td>MERCAP_PAYMENT</td><td>0x08</td><td> 1</td><td>The merchant admits contactless payment.</td><td>the</td>

<td></td><td></td><td></td><td>The merchant admits</td><td>the</td>

<td></td><td></td><td></td><td>cloud swap.</td><td>The</td>

<td></td><td></td><td></td><td colspan="2">applet only</td>

<td>MERCAP CLOUD</td><td>0x02</td><td> 1</td><td></td><td></td>

<td></td><td></td><td></td><td>will return the ID</td><td>of the</td>

<td></td><td></td><td></td><td>consumer for</td><td>the</td>

<td></td><td></td><td></td><td>resolution in the cloud.</td><td></td>

<td></td><td></td><td></td><td>The payment terminal</td><td>and</td>

<td></td><td></td><td></td><td>merchant supports</td><td>the</td>

<td></td><td></td><td></td><td>data transmission</td><td>of</td>

<td>MERCAP REDEMPTI</td><td></td><td></td><td>exchange of offer</td><td>(to</td>

<td></td><td>0x01</td><td> 1</td><td></td><td></td>

<td>ON</td><td></td><td></td><td>from the ECR)</td><td>to the</td>

<td></td><td></td><td></td><td>applet using</td><td>the</td>

<td></td><td></td><td></td><td colspan="2">post command</td>

<td></td><td></td><td></td><td>transaction.</td><td></td>

<td colspan="5">MoCom platform data elements</td>

151

<td>PLATFORM_SIGNATURE [Signature of the platform]</td><td>0x71</td><td> 8</td><td>MAC generated in the MoCom platform / signature attached to command / data to be originate from the platform with verification purposes from distance (integrity / authenticity data).</td>

<td>PLATFORM_KEY [Key of the platform]</td><td>0x72</td><td> 16</td><td>Platform key from MoCom</td>

<td>PLATFORM_CERT [Certificate of the platform]</td><td>0x73</td><td> 8</td><td>Certificate of the MoCom platform</td>

152

<td colspan="6">Fidelity</td>

<td colspan="6">Loyalty data elements</td>

<td colspan="2">Data element</td><td>Label</td><td>Size maximum</td><td colspan="2">Description</td>

<td>EMBEDDED_TLV_</td><td></td><td></td><td>XX</td><td>Data label</td><td>of</td>

<td colspan="2">LOYALTY_DATA [Data</td><td></td><td></td><td>fidelity of</td><td>TLV</td>

<td></td><td></td><td>0x40</td><td></td><td></td><td></td>

<td>fidelity</td><td>TLV</td><td></td><td></td><td>Incorporated</td><td></td>

<td>Incorporated]</td><td></td><td></td><td></td><td></td><td></td>

<td></td><td></td><td></td><td> 8</td><td>Identifier</td><td>of</td>

<td>LOYALTY_ID [ID</td><td>of</td><td>0x41</td><td></td><td colspan="2">specific fidelity</td>

<td>fidelity]</td><td></td><td></td><td></td><td colspan="2">the MoCom platform</td>

<td></td><td></td><td></td><td> 1</td><td>State</td><td>the</td>

<td>LOYALTY_STATUS</td><td></td><td>0x42</td><td></td><td>account / card</td><td>of</td>

<td>[State</td><td>of</td><td></td><td></td><td>fidelity (see</td><td>to</td>

<td>fidelity]</td><td></td><td></td><td></td><td>continuation)</td><td></td>

<td>LOYALTY_ACCOUNT_</td><td></td><td></td><td> 32</td><td colspan="2">Loyalty account</td>

<td>CODE [Code of</td><td>the</td><td>0x43</td><td></td><td>(code data</td><td>of</td>

<td>bill</td><td>of</td><td></td><td></td><td>bars)</td><td></td>

<td>fidelity]</td><td></td><td></td><td></td><td></td><td></td>

<td></td><td></td><td></td><td> 8</td><td>Specific MAC</td><td>the</td>

<td></td><td></td><td></td><td></td><td colspan="2">MoCom / Signature platform</td>

<td>LOYALTY_MAC_</td><td></td><td>0x44</td><td></td><td>for integrity /</td><td></td>

<td>SIGNATURE [Signature</td><td>of</td><td></td><td></td><td>check</td><td>of</td>

<td>Loyalty Mac]</td><td></td><td></td><td></td><td>authenticity</td><td></td>

153

<td colspan="7">Loyalty status</td>

<td>Data element</td><td colspan="2">Value</td><td colspan="2">Size maximum</td><td colspan="2">Description</td>

<td>LOYALTY_STATUS_ DEACTIVATED [State loyalty disabled]</td><td colspan="2">0x00</td><td colspan="2"> 1</td><td colspan="2">Loyalty account inactive. No available.</td>

<td>LOYALTY_STATUS_</td><td></td><td></td><td></td><td></td><td colspan="2">Loyalty account</td>

<td>ACTIVE [State of</td><td colspan="2">0x01</td><td> 1</td><td></td><td colspan="2">active. Available</td>

<td>active fidelity]</td><td></td><td></td><td></td><td></td><td colspan="2">for your use.</td>

<td colspan="7">Transaction log</td>

<td>Data elements of</td><td>the</td><td colspan="3">transaction</td><td></td><td></td>

<td colspan="2">Data element</td><td colspan="2">Label</td><td colspan="2">Size maximum</td><td>Description</td>

<td>EMBEDDED_TLV_</td><td></td><td>0x60</td><td></td><td></td><td></td><td>Data label</td>

<td>TRANSACTION_LOG</td><td></td><td></td><td></td><td></td><td></td><td>record of the</td>

<td>[Register of</td><td>the</td><td></td><td></td><td>XX</td><td></td><td>transaction</td>

<td colspan="2">TLV transaction</td><td></td><td></td><td></td><td></td><td></td>

<td>Incorporated]</td><td></td><td></td><td></td><td></td><td></td><td></td>

<td>TRANSACTION_ID [ID the transaction]</td><td>of</td><td colspan="2">0x61</td><td colspan="2"> 16</td><td>Transaction ID (assigned by ECR)</td>

154

<td>TRANSACTION_STATUS [State of transaction]</td><td>0x62</td><td> 11</td><td>State of transaction including status byte (see then word 2-byte status, Error code 2-byte internal, 2-byte number of records of transaction available, count ultimate fidelity transaction 2 bytes, count last offer 2-byte transaction</td>

<td colspan="4">Transaction status</td>

<td>Data element</td><td>Value</td><td>Size maximum</td><td>Description</td>

<td>TRANSACTION_STATUS_ SUCCESSFUL [Status of the transaction satisfactory]</td><td>0x00</td><td> 1</td><td>Commercial data received. Outcome pending.</td>

<td>TRANSACTION_STATUS_ FAILED [State of the transaction failure]</td><td>0x01</td><td> 1</td><td>Error detected. Error code attached intern.</td>

155

<td colspan="4">Offers</td>

<td colspan="4">Data elements of the offer</td>

<td>Data element</td><td>Label</td><td>Size maximum</td><td>Description</td>

<td>EMBEDDED_TLV_ OFFER_DATA</td><td>0x50</td><td>XX</td><td>Data label TLV offers incorporated</td>

<td>OFFER_ID</td><td>0x51</td><td> 8</td><td>Identifier specific offers from the platform MoCom</td>

<td>OFFERjSTATUS</td><td>0x52</td><td> 1</td><td>Offer status (see below)</td>

156

<td colspan="2">OFFER_CODE</td><td>0x53</td><td> 48</td><td>Code data Offe bars (bar of UPC / EPC / GS1)</td><td>of : rta LtOS</td>

<td></td><td></td><td></td><td></td><td colspan="2">Type of offer (see</td>

<td></td><td></td><td>0x54</td><td> 9</td><td></td><td></td>

<td>OFFER_TYPE_CODE</td><td></td><td></td><td></td><td>continuation)</td><td></td>

<td></td><td></td><td></td><td></td><td>Security firm</td><td>of</td>

<td></td><td></td><td></td><td></td><td colspan="2">specific data</td>

<td></td><td></td><td>0x55</td><td> 8</td><td></td><td></td>

<td>OFFER_MAC_</td><td></td><td></td><td></td><td>of the platform</td><td>of</td>

<td>SIGNATURE</td><td></td><td></td><td></td><td>MoCom</td><td></td>

<td></td><td></td><td></td><td></td><td colspan="2">Update mark</td>

<td></td><td></td><td>0x56</td><td> 1</td><td>(state</td><td>of</td>

<td colspan="2">OFFER_UPDATE_FLAG</td><td></td><td></td><td>synchronization)</td><td></td>

<td>CACHED_MERCHANT_</td><td></td><td></td><td></td><td colspan="2">Offer count within</td>

<td>DATA OFFER COUNT</td><td></td><td></td><td></td><td></td><td></td>

<td></td><td></td><td></td><td></td><td>of the data</td><td>of the</td>

<td colspan="2">[Offer count</td><td></td><td></td><td></td><td></td>

<td>of data</td><td>of the</td><td>0x57</td><td> 1</td><td colspan="2">merchant stored</td>

<td>merchant</td><td></td><td></td><td></td><td>in the cache</td><td></td>

<td>stored</td><td>in</td><td></td><td></td><td></td><td></td>

<td>cache]</td><td></td><td></td><td></td><td></td><td></td>

<td>EMBEDDED_TLV_</td><td></td><td></td><td></td><td colspan="2">Merchant details</td>

<td>CACHED MERCHANT</td><td></td><td></td><td></td><td></td><td></td>

<td></td><td></td><td></td><td></td><td>(offer) stored</td><td>in</td>

<td>DATA</td><td>of the</td><td></td><td></td><td></td><td></td>

<td>merchant</td><td></td><td>0x58</td><td>XX</td><td>cache memory</td><td>of the</td>

<td>stored</td><td>in</td><td></td><td></td><td>Built-in TLV</td><td></td>

<td>cache</td><td>of</td><td></td><td></td><td></td><td></td>

<td colspan="2">TLV built-in]</td><td></td><td></td><td></td><td></td>

157

<td colspan="4">Offer status</td>

<td>Data element</td><td>Value</td><td>Size maximum</td><td>Description</td>

<td>OFFER_STATUS_</td><td></td><td></td><td>Offer present in</td>

<td>DEACTIVATED [State</td><td>0x00</td><td> 1</td><td>data repository but</td>

<td>of the offer</td><td></td><td></td><td>not available for</td>

<td>disabled]</td><td></td><td></td><td>exchange.</td>

<td>OFFER_STATUS_</td><td></td><td></td><td>Offer present in</td>

<td>ACTIVE [State of</td><td>0x01</td><td> 1</td><td>data repository.</td>

<td>the active offer]</td><td></td><td></td><td>Available for exchange.</td>

<td>OFFER_STATUS_</td><td></td><td></td><td>Expired offer</td>

<td>EXPIRED [State of</td><td>0x10</td><td> 1</td><td></td>

<td>the expired offer]</td><td></td><td></td><td></td>

<td>OFFER_STATUS_</td><td></td><td></td><td>The</td>

<td>SUBMITTED [Status of</td><td>0x20</td><td> 1</td><td>offer for exchange.</td>

<td>the offer</td><td></td><td></td><td>Outstanding result.</td>

<td>filed]</td><td></td><td></td><td></td>

<td></td><td></td><td></td><td>The</td>

<td>OFFER STATUS</td><td></td><td></td><td>offer.</td>

<td></td><td>0x40</td><td> 1</td><td></td>

<td>REDEEMED [State of</td><td></td><td></td><td></td>

<td>redeemed offer]</td><td></td><td></td><td></td>

158

<td colspan="4">Offer type</td>

<td>Data element</td><td rowspan="2">Value</td><td rowspan="2">Size maximum</td><td rowspan="2">Description</td>

<td></td>

<td>OFFER_TYPE_CLASS_01 [Kind of kind of offer 01]</td><td>0x01</td><td> 1</td><td>Offer class: Specific to merchant (ID of the adjunct merchant)</td>

<td>OFFER_TYPE_CLASS_02 [Kind of kind of offer 02]</td><td>0x02</td><td> 1</td><td>Offer class: CPG</td>

<td>OFFER_TYPE_CLASS_03 [Kind of kind of offer 03]</td><td>0x03</td><td> 1</td><td>Offer class: Various</td>

Specially formatted data elements

A few data elements included in the business data payload include a format byte that identifies the data encoding used for the element. The merchant specifies the data encryption to ensure compatibility at the point of sale. The MoCom platform provides the value of formatted data to the wallet application. Therefore, no additional interpretation / formatting is required between the platform, wallet, security element and payment terminal. The

159 The payment terminal (or the merchant's POS system) has the function of properly interpreting the data and providing it to the merchant's system for processing.

The following data elements will include the byte of the format:

• Loyalty account code • Offer code

Table 68 defines the possible byte values ​​of the format and their corresponding encoding rule:

TABLE 68

<td>Byte Format</td><td>Rule coding</td><td>of</td><td>Description</td>

<td>0x00</td><td>Hexadecimal</td><td></td><td>Each byte of data is encoded in hexadecimal format (in stupid).</td>

<td>0x01</td><td colspan="2">Decimal coded binary (BCD)</td><td>Each quartet represents a single digit. Thus, only the decimal values. A data stream containing an odd quantity (length) digit includes hex value F in the first quartet of the data stream.</td>

160

<td>0x02</td><td>ASCII</td><td>Each byte represents a</td><td>value</td>

<td></td><td></td><td colspan="2">ACII which is interpreted from that</td>

<td></td><td></td><td>mode and it runs like its</td><td>value</td>

<td></td><td></td><td colspan="2">Corresponding CHAR. In the</td>

<td></td><td></td><td>most cases</td><td>these</td>

<td></td><td></td><td>data streams</td><td>I know</td>

<td></td><td></td><td>turn into a string</td><td>before</td>

<td></td><td></td><td colspan="2">that they go to the POS system</td>

<td></td><td></td><td>from the merchant to processing.</td><td>the</td>

A BCD encoded data value that includes the hexadecimal value F in the first quartet will identify a data stream that contains an odd number of digits. Therefore, the BCD 12345 data stream is encoded into a 3-byte buffer, as follows: 0xF12345.

Implementation of the computer readable medium

The examples of modalities described above, such as, for example, the systems and procedures described in relation to Figs. 1-7, or any part or function thereof, can be implemented through the use of hardware, software, or a combination of the two. Implementation can be done on one or more computers or other processing systems. Although the management performed according to these examples of modalities may have been mentioned in the terms commonly associated with the mental operations carried out by a human operator, a

161 human operator to perform any of the operations described herein. In other words, operations can be fully implemented with machine operations. Useful machines for operating the exemplary embodiments presented herein include general-purpose digital computers or similar devices.

Fig. 8 is a block diagram of a general purpose and / or private computer 800, in accordance with some of the embodiment examples of the invention. Computer 800, for example, can be a user device, a user computer, a client computer, and / or a server, among other things.

Computer 800 may include, but is not limited to, a processor device 810, main memory 825, and interconnect bus 805. Processor device 810 may include, but is not limited to, a single microprocessor, or may include a variety of microprocessors. to configure the 800 computer as a multiprocessor system. Main memory 825 stores, among other things, instructions and / or data for execution by processor device 810. The main memory 625 can include dynamic random access memory (DRAM) banks, as well as a cache.

Computer 800 may additionally include a

162 mass storage device 830, peripheral device (s) 840, portable storage medium device (s) 850, input control device (s) 880, a graphics subsystem 860 and / or output display 870. With For illustrative purposes, all components of the 800 computer are shown in Fig. 8 coupled by the 805 bus. However, the 800 computer is not limited to these. Devices of computer 800 can be coupled by one or more data transport means. For example, processor device 810 and / or main memory 825 can be coupled via a local microprocessor bus. The mass storage device 830, peripheral device (s) 840, portable storage medium device (s) 850 and / or graphics subsystem 860 may be coupled by one or more input / output buses (1 / 0). Mass storage device 830 may be a non-volatile storage device for storing data and / or instructions for use by processor device 810. Mass storage device 830 can be implemented, for example, with a magnetic disk drive or an optical disc drive. In a software mode, the mass storage device 830 is configured to load the contents of the mass storage device 830 into main memory 825.

The 850 Portable Storage Media Device

163 works in conjunction with a non-volatile portable storage medium, such as compact disc read-only memory (CD-ROM), to enter and retrieve data and encode to and from the 800 computer. In some In modalities, the software for storing an internal identifier in metadata can be stored on portable storage medium, and can be entered into computer 800 by means of portable storage medium device 850. The 840 peripheral device (s) can include any type of computing media device, such as an input / output interface (I / O) configured to add additional functionality to the 800 computer. For example, the peripheral device (s) 840 may / may include a network interface card to connect the 800 computer to a network 820.

The input control device (s) 880 provides a portion of the user interface for a user of the computer 800. The input control device (s) 880 may / include a keyboard control device and / or cursor. . The keyboard can be configured to enter alphanumeric characters and / or other key information. The cursor control device may include, for example, a mouse, a trackball, a pointer and / or cursor movement keys. For the purpose of displaying information

164 graphic and text, computer 800 may include graphical subsystem 860 and output display 870. Output display 870 may include a cathode ray tube (CRT) display and / or glass display Liquid (LCD). The graphic subsystem 860 receives graphic and text information, and processes the information to display data on the 870 output screen.

Each component of the computer 800 may represent a broad category of a computer component of a computer for general and / or private use. The components of the 800 computer are not limited to the specific implementations provided herein.

Parts of the embodiment examples of the invention can be conveniently implemented by using a conventional general-purpose computer, a specialized digital computer and / or a microprocessor programmed according to the indications of the present description, as is evident to the experts in computer technology. The appropriate software encoding can be easily prepared by expert programmers based on the indications of the present description.

Some modalities can also be implemented by preparing integrated circuits

165 application specific, field programmable gate matrices or by interconnecting an appropriate network of conventional component circuits.

Some modalities include a computer program product. The computer program product may be a storage medium or media with instructions stored there that can be used to control, or arrange for, a computer to perform any of the procedures of the embodiment examples of the invention. The storage medium may include, but is not limited to, a floppy disk, a Blu-Ray disk, a DVD, a CD-ROM, a micro-drive, a magnetic optical disk, a ROM, RAM, EPROM, EEPROM, DRAM, VRAM, flash memory, flash memory card, magnetic card, an optical card, nanosystems, a molecular memory integrated circuit, a RAID, remote data storage and / or any other type of device suitable for storing instructions and / or data.

Stored on any computer-readable medium, some implementations include software to control both general and / or special purpose computer or microprocessor hardware, and to allow the computer or microprocessor to interact with a human user or other mechanism that uses the results. of the examples of embodiments of the invention. The software may include, of

166 non-exhaustive mode, devices, operating systems and user applications. Finally, the computer readable medium further includes software that performs examples of aspects of the invention, as described above.

The software modules to implement the procedures described above that are included in the programming and / or software of the computer or microprocessor for general and / or special use.

While various examples of embodiments of the invention have been described above, it should be understood that they have been presented by way of illustration and not of limitation. It is apparent to those skilled in the relevant art that various changes in form and detail can be made. Therefore, the invention should not be limited to any of the embodiment examples described above, but should be defined only in accordance with the following claims and their equivalents.

In addition, it should be noted that the figures are presented by way of example only. The structure of the embodiment examples presented herein is flexible and configurable enough that they can be used and carried out in ways other than those shown in the attached figures.

Additionally, the purpose of the Summary is to enable the United States Patent and Trademark Office and the public

167 in general, and particularly scientists, engineers, and practitioners in the art who are unfamiliar with patent or legal terms or phraseology, to quickly determine the nature and substance of the technical description of the application from a brief inspection. The Summary is not intended to limit the scope of the modality examples presented herein in any way. It should also be noted that the procedures mentioned in the claims should not necessarily be carried out in the order presented.

It is noted that in relation to this date, the best method known by the applicant to put the aforementioned invention into practice, is the one that is clear from the present description of the invention.

168