TRANSMISSION-PULSE SEQUENCE INCLUDING PROXY FOR SECONDARY MAGNETIC STRIPE

Abstract

A contactless payment device and method streams a sequence of magnetic-field pulses directly to two magnetic-stripe read heads of a point-of-sale terminal. The stream of pulses includes essential information needed to approve a transaction. The essential information is structured for a primary channel associated with one of the read heads. A series of proxy bits are included in the stream in order to satisfy the data collection requirements for a secondary channel associated with the other read head. The proxy bits are included in a custom bit stream that may be used to improve acceptance of payment transmission data at a POS terminal.

Claims

1. A contactless magnetic stripe transmission method, comprising: generating a first bit sequence based on Track 1 data of a magnetic stripe card, the first bit sequence omitting data corresponding to at least one non-discretionary field of Track 1; generating a second bit sequence based on Track 2 data of the magnetic stripe card, the second bit sequence including data for all of the fields of Track 2; transmitting the first bit sequence from a contactless payment device as a first series of magnetic-field pulses in forward or reverse bit-order; and transmitting the second bit sequence from the contactless payment device as a second series of magnetic-field pulses in forward or reverse bit-order, following or preceding the transmitting the first bit sequence, the first and second bit sequences being transmitted as part of a same transaction.

2. The contactless magnetic stripe transmission method of claim 1, wherein generating the first bit sequence includes replacing the primary account number from Track 1 with one-or-more zero characters or space characters.

3. The contactless magnetic stripe transmission method of claim 2, wherein generating the first bit sequence includes substituting zero or space characters for all fields other than the cardholder name field from Track 1.

4. The contactless magnetic stripe transmission method of claim 3, wherein transmitting the first and second bit sequences transmits the first bit sequence is in forward bit-order, followed by the second bit sequence in forward bit-order or reverse bit-order.

5. The contactless magnetic stripe transmission method of claim 1, wherein generating the first bit sequence includes the primary account number from Track 1 in the first bit sequence.

6. The contactless magnetic stripe transmission method of claim 5, wherein generating the first bit sequence includes substituting one-or-more alphanumeric characters for a cardholder name of Track 1 in the first bit sequence.

7. The contactless magnetic stripe transmission method of claim 7, wherein generating the first bit sequence includes substituting zero or space characters for expiration date, service code, and discretionary data fields of Track 1.

8. The contactless magnetic stripe transmission method of claim 7, wherein transmitting the first and second bit sequences transmits the first bit sequence is in forward bit-order, followed by the second bit sequence in reverse bit-order, or wherein transmitting the first and second bit sequences transmits the second bit sequence is in forward bit-order, followed by the first bit sequence in reverse bit-order.

9. The contactless magnetic stripe transmission method of claim 1, wherein: generating the second bit sequence comprises including five start bits corresponding to a semicolon as a start character indicating a start of Track 2 content, and generating the first bit sequence comprises changing one or more bits within the first bit sequence to eliminate occurrence of the five start bits in forward or reverse bit-order.

10. The contactless magnetic stripe transmission method of claim 1, wherein: generating the second bit sequence comprises including five end bits corresponding to a question mark as an end character indicating an end of Track 2 content, and generating the first bit sequence comprises changing one or more bits within the first bit sequence to eliminate occurrence of the five end bits in forward or reverse bit-order.

11. A contactless magnetic stripe transmission device comprising: a processor that generates bit sequences; a driver that generates a time-variable electric signal; an inductor that emits magnetic flux in response to the time-variable electric signal, a memory including instructions to be executed by the processor to: generate a first bit sequence based on Track 1 data of a magnetic stripe card, the first bit sequence omitting data corresponding to at least one non-discretionary field of Track 1; generate a second bit sequence based on Track 2 data of the magnetic stripe card, the second bit sequence including data for all of the fields of Track 2; transmit the first bit sequence via the driver and the inductor as a first series of magnetic-field pulses in forward or reverse bit-order; and transmit the second bit sequence via the driver and the inductor as a second series of magnetic-field pulses in forward or reverse bit-order, following or preceding transmission of the first bit sequence as part of a same transaction.

12. The contactless magnetic stripe transmission device of claim 11, wherein the instructions to generate the first bit sequence comprise instructions to: replace the primary account number from Track 1 with one-or-more zero characters or space characters.

13. The contactless magnetic stripe transmission device of claim 12, wherein the instructions to generate the first bit sequence comprise instructions to: substitute zero or space characters for all fields other than the cardholder name field from Track 1.

14. The contactless magnetic stripe transmission device of claim 13, wherein the instructions to transmit the first bit sequence and to transmit the second bit sequence comprise instructions to transmit the first bit sequence in forward bit-order, followed by the second bit sequence in forward bit-order or reverse bit-order.

15. The contactless magnetic stripe transmission device of claim 11, wherein the instructions to generate the first bit sequence comprise instructions to: include the primary account number from Track 1 in the first bit sequence.

16. The contactless magnetic stripe transmission device of claim 15, wherein the instructions to generate the first bit sequence comprise instructions to: substitute one-or-more alphanumeric characters for a cardholder name of Track 1 in the first bit sequence.

17. The contactless magnetic stripe transmission device of claim 16, wherein the instructions to generate the first bit sequence comprise instructions to: substitute zero or space characters for expiration date, service code, and discretionary data fields of Track 1.

18. The contactless magnetic stripe transmission device of claim 17, wherein the instructions to generate the first bit sequence comprise instructions to transmit the first bit sequence in forward bit-order, followed by the second bit sequence in reverse bit-order, or transmits the second bit sequence is in forward bit-order, followed by the first bit sequence in reverse bit-order

19. The contactless magnetic stripe transmission device of claim 11, wherein the instructions to generate the second bit sequence comprise instructions to include five start bits corresponding to a semicolon as a start character indicating a start of Track 2 content, and wherein the instructions to generate the first bit sequence comprise instructions to change one or more bits within the first bit sequence to eliminate occurrence of the five start bits in forward or reverse bit-order.

20. The contactless magnetic stripe transmission device of claim 11, wherein the instructions to generate the second bit sequence comprise instructions to include five end bits corresponding to a question mark as an end character indicating an end of Track 2 content, and wherein the instructions to generate the first bit sequence comprise instructions to change one or more bits within the first bit sequence to eliminate occurrence of the five end bits in forward or reverse bit-order.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0047] FIG. 1 illustrates a typical magnetic stripe and its tracks in accordance with existing industry standards.

[0048] FIG. 2 illustrates a structure of the data encoded on the first track of the magnetic stripe of FIG. 1 in accordance with existing industry standards.

[0049] FIG. 3 illustrates a structure of the data encoded on the second track of the magnetic stripe of FIG. 1 in accordance with existing industry standards.

[0050] FIG. 4 illustrates a structure of the data encoded on the third track of the magnetic stripe of FIG. 1 in accordance with existing industry standards.

[0051] FIG. 5 illustrates a structural arrangement of a magnetic stripe reader (MSR) including two read heads, as is commonly used with or included in point-of-sale (POS) terminals.

[0052] FIGS. 6A to 6D illustrate frameworks used to create improved pulse sequence transmissions that include both the data for a primary channel and proxy bits for a secondary channel.

[0053] FIGS. 7A and 7B illustrate examples of the proxy bit streams in FIGS. 6A and 6B.

[0054] FIG. 8 illustrates a process for constructing the proxy bit streams.

[0055] FIGS. 9A and 9B illustrate examples of the frameworks from FIG. 6A and 6B in which the primary channel corresponds to magnetic-stripe Track 2 channel and the secondary channel corresponds to the Track 1 channel.

[0056] FIGS. 10A and 10B illustrate examples of bit sequences used for the proxy bit stream.

[0057] FIGS. 11A and 11B illustrate examples of the frameworks from FIG. 6A and 6B in which the primary channel corresponds to magnetic-stripe Track 3 data and the secondary channel corresponds to Track 1.

[0058] FIGS. 12A to 12H illustrate embodiments of the improved pulse sequence transmissions based on the frameworks in FIGS. 6A and 6B in which the primary channel corresponds to Track 2 and the secondary channel corresponds to Track 1.

[0059] FIGS. 13A to 13D illustrate embodiments of the improved pulse sequence transmissions based on the frameworks in FIGS. 6C and 6D in which the primary channel corresponds to Track 2 and the secondary channel corresponds to Track 1.

[0060] FIGS. 14A and 14B illustrate embodiments of the improved pulse sequence transmissions based on the frameworks in FIGS. 6C and 6D in which the primary channel corresponds to Track 2 and the secondary channel data is omitted.

[0061] FIG. 15 illustrates a process used by a device to determine which of the improved pulse sequences to use.

[0062] FIG. 16 is a block diagram conceptually illustrating example components in a system including the device that generates the improved pulse sequence transmission.

DETAILED DESCRIPTION

[0063] Track data for different channels can be arranged serially within a magnetic pulse stream. Each character of track data is represented by a plurality of binary bits in accordance with the character configuration 114. Prior to transmission, the binary bits are encoded as F2F data. Each binary 1 bit is encoded to generate magnetic flux transitions at the edges of the bit, and another transition at the center of the bit. Each binary 0 bit is encoded to generate magnetic flux transitions at the edges of the bit, with no transition at the center of the bit.

[0064] The success or failure of a stream format may vary from POS-terminal to POS-terminal. A magnetic-stripe-simulating device can be configured according to the disclosure to try a different stream format (also referred to as frameworks) if an initial attempt fails, such as when a device user presses the pay button more than once within a threshold amount of time (indicating a likelihood that the prior stream transmission was rejected by the POS terminal). The magnetic-stipe-simulating device may select frameworks based on, among other things, a hierarchical table of frameworks and the geographic/regional location in which the transaction is being performed.

[0065] The successful reception of a multi-channel serial stream transmission depends in part on each decoder in the MSR correctly detecting bits in the stream for that decoder's channel, while ignoring or discarding the bits corresponding to other channels. Since all of the read heads 500 will receive all of the magnetic pulses emitted for all of the channels, the deluge of pulses can easily exceed a decoder's ability to handle cross-channel leakage, which will cause a transaction to fail.

[0066] Ordinarily, the data from a secondary channel, e.g. Track 1 data, might be collected by a POS terminal, but is not necessarily verified as part of the transaction approval process. The financial services companies that process card payments typically rely on the data from a single, primary track, e.g. Track 2 data, to validate a transaction. However, merchants sometimes wish to collect extra data from another track, such as collecting the data from the Name field 218 of Track 1 101, even if the transaction can be approved by the transaction processor with only data from Track 2 102 or Track 3 103. Merchants may collect such information for their own purposes, such as marketing or customer tracking.

[0067] There are several ways the merchant's system might collect the extra data. One approach is for the merchant's own payment processing software to collect the secondary data as a requirement before the primary track data (e.g., Track 2 sequence 311 or Track 3 sequence 411) is relayed by the POS terminal to the financial services network for transaction approval. For example, if the Name field 218 data from Track 1 101 is not received by the MSR, the merchant's payment processing system may forgo sending the primary track data for approval, or otherwise cancel the transaction. Another approach is to forward all of the data collected to the financial services network, and then receive the Name field 218 data (unverified) bundled with the reply that authorizes the transaction. In any case, if this secondary channel data is not received, the merchant's system may cancel the transaction even though the primary channel data ordinarily needed for transaction approval was collected in its entirety.

[0068] Field experiments with POS terminals from a wide variety of vendors indicate that the software used by the POS terminals is tolerant of the data for one track not being received at the exact same time as the data of another track, so long as the sequence of pulses corresponding to each track are received in close proximity. For example, if a POS system will rely on the data from Track 2 102 for card verification and transaction approval, but the data from the Track 1 Name field 218 is also collected for other purposes, the software will tolerate receiving the data interpreted as the Name field 218 before or after receiving the Track 2 data.

[0069] Since the secondary channel data may not be verified/validated, substitute data (proxy data) can be used in its place without compromising transaction approval. Depending upon whether the quantity of proxy data is within the tolerance of the primary channel decoder's noise tolerance limits, the primary channel decoder might ignore the proxy data as noise. To better handle issues like cross-track leakage, most POS terminals will reject extraneous signals as noise if the signals do not conform to the format expected for a specific read channel. Most POS terminal decoders will simply filter out bits deemed to be noise, rejecting the noise bits as not being meaningful.

[0070] How much noise a decoder will tolerate before rejecting a bit sequence depends in part on where in the sequence the noise occurs, and varies between POS terminal models and vendors. As a result, a quantity of proxy data can be inserted into the beginning or end of the primary channel pulse sequence that is received by the primary channel read head, without the sequence being rejected (or, according to the present disclosure, in order to improve the likelihood that the sequence will not be rejected). The pulses of the proxy data preceding or following the expected primary sequence are simply discarded by the primary channel's decoder as noise, while the data from the pulse sequence in the expected format used by the primary channel is retained. Similarly, the primary channel pulse sequence will be discarded by the secondary channel's decoder.

[0071] The bit rate (baud) produced by the tracks of a magnetic stripe 11 when a card is swiped through an MSR depends both on the recording density 113 of the respective track and the speed with which the card is swiped. To accommodate this variation in swipe speed, the decoders of the MSR that receive the pulse sequences from the read heads 501 and 502 are tolerant of a wide range of bit rates. Based on field experiments, the pulse demodulation performed by each channel decoder is independent of the other. In other words, each channel decoder independently determines a bit rate for the track data it is configured to receive, without regard to the bit rates detected on any other channel. So, for example, if the Track 1 and the Track 2 pulses are received at a same rate, and that rate is within the tolerances of each of the corresponding channel decoders, then both decoders should recover their respective channel data, even though the Track 1 data should theoretically be received at a higher bit rate than the Track 2 data (based on a ratio of the recording densities 113a and 113b).

[0072] The MSRs of modern POS terminals are able to recover the encoded bit sequence in a track without regard to whether a magnetic stripe 11 is swiped forward or backward. To accommodate this, the MSRs are able to recover bit sequences in accordance with the track standards 112 in either the regular or reverse order. A POS terminal may look for the Start Sentinel (210/310/410) at either end of the bit sequence to determine how to process received data.

[0073] Experiments were performed on a variety of POS terminals to determine whether it was possible to provide proxy pulses prior to the pulses conveying stripe data in order to improve the chances that the channel data would be properly received and decoded by the MSR's decoders (i.e. no error received). In view of the ability of POS terminals to read stripe data forward and backward, experiments were performed using two groups of pulses: forward-forward, backward-backward, backward-forward, and forward-backward combinations.

[0074] If the first group of pulses is properly received and decoded, the transaction should be successful without regard to the second group. If the first group of pulses is rejected but the second group of pulses was received (i.e. in a second swipe) and decodes correctly, the transaction should go through. If both swipes produce noise/errors (i.e. are not decoded correctly), the transaction will fail.

[0075] As noted above, the design and operation of POS terminals is not standardized so there was no certainty that providing extra/proxy pulses or a duplicate copy of the primary channel data would improve results. However, it has been determined that the success rate for transaction approval increases when the contactless payment device provides the extra/proxy pulses and/or a duplicate copy of the primary channel data. Thus, according to the disclosure, as discussed hereinafter, custom bit streams may be added to the Track 1 and/or Track 2 data to improve acceptance of data at POS terminals when the contactless payment device transmits magnetic stripe data.

[0076] FIGS. 6A to 6D illustrate frameworks used to create improved pulse transmission sequences 600-603 to convey the data for a primary channel and proxy bits in a forward (632) and/or reverse (634) bit order for a secondary channel. The proxy bit stream is concatenated onto the beginning (632a/634a) and/or the end (632b/634b) of a primary channel bit sequence TA 641, or the primary channel bit sequence in reverse-bit order TAR 642. Each pulse sequence 600-603 may be transmitted directly to the read heads (e.g., 501, 502) of an MSR using an inductive loop.

[0077] When a bit sequence for a channel is to be transmitted in reverse-bit-order, it is denoted by the R. For example, a T2-T1R stream includes Track 2 102 data in forward bit-order, followed by Track 1 101 data in reverse bit-order. As another example, a T2-T1R-T2R stream includes Track 2 102 data in forward bit-order, followed by Track 1 101 data in reverse bit-order, followed by a second copy of Track 2 102 data in reverse bit-order. The second copy of T2 in T2-T1R-T2R is redundant, and is included in the stream in case the Track 2 decoder in the MSR fails to capture the first copy.

[0078] Referring to FIGS. 6A and 6B, the pulse transmission sequences 600 and 601 each comprise (in order) a series of leading clocking bits 630, the proxy bit stream 632a/634a, the primary channel bit sequence in either forward (TA 641 in FIG. 6A) or reverse order (TAR 642 in FIG. 6B), a second proxy bit stream 632b/634b, and a series of trailing clocking bits 636. An example of each of the leading clocking bits 630 and the trailing clocking bits 636 would be thirty binary zeros (encoded in the transmitted magnetic pulses). The leading clocking bits 630 and the trailing clocking bits 636 have the same number of bits-per-character 651 as the primary channel bit sequence 641/642, whereas the proxy bit streams 632/634 may have a different number of bits-per-character 652.

[0079] The proxy bits streams 632/634 may include customized bit streams or sequences configured to minimize read errors for a particular POS terminal. That is, based on empirical analysis and testing, the bits-per-character and/or number of proxy bits and/or state of proxy bits (1 or 0) may be selected to improve reading of the pulse transmission sequence by a given POS terminal since POS terminals from different manufacturers, and different POS terminal models from the same manufacturer have different MSR and read head sensitivities. Accordingly, the customized bit stream of proxy bits can be tuned, i.e. used in a selected configuration to minimize read errors of the pulse transmission sequence.

[0080] The leading clocking bits 630 are transmitted at a same bit rate (Baud A 661 in FIG. 6A; Baud C 663 in FIG. 6B) as the primary channel bit sequence 641/642. The leading clocking bits 630 help the MSR and the primary channel decoder synchronize for the bit rate of the primary channel bit sequence 641/642. The bit rate (Baud B 662) of the proxy bit stream is independent of the bit rate 661/663 of the primary channel bit sequence 641/642, and may be the same or different. For example, the bit rate 662 of the proxy bit stream 632/634 may be increased relative to the bit rate 661/663 of the primary channel bit sequence 641/642 to shorten the length of time needed to transmit the proxy bit stream 632/634, as this may increase the likelihood that the primary channel decoder will treat the proxy bit stream 632/634 as noise by shortening the time window used to transmit the proxy bits.

[0081] FIG. 6A includes a structural format of the primary channel bit sequence TA 641. The format includes a start sentinel 610, the primary track character sequence 611, an end sentinel 626, and a longitudinal redundancy check (LRC) 628. The bit sequence TA 641 may, for example, correspond to the structure of the bit sequence for Track 2 102 or Track 3 103. Configured for Track 2, the start sentinel 610 corresponds to start sentinel 310, the characters 611 correspond to numeric and control characters 311, the end sentinel 626 corresponds to the end sentinel 326, and the LRC 628 corresponds to the LRC 328. Configured for Track 3, the start sentinel 610 corresponds to start sentinel 410, the characters 611 correspond to numeric and control characters 411, the end sentinel 626 corresponds to the end sentinel 426, and the LRC 628 corresponds to the LRC 428.

[0082] In an alternative configuration, referring to FIGS. 6C and 6D, the pulse sequences 602 and 603 (in order) each comprise a series of leading clocking bits 630, the primary channel bit sequence in either forward (TA 641 in FIG. 6C) or reverse (TAR 642 in FIG. 6D), a proxy bit stream 632/634, the primary channel bit sequence in the opposite order, and a series of trailing clocking bits 636. The forward primary-channel bit sequence TA 641 may have a bit rate (Baud A 661) that is different than the bit rate (Baud C 663) of the reverse primary channel bit sequence TAR 642, although the same bit rate may also be used. Each of the bit rates 661 to 663 is independent of the others.

[0083] As illustrated in FIGS. 6A to 6D, if the trailing clocking bits 636 are included in the sequence 600-603, the bit rate may be set to match that of the closest preceding primary channel bit sequence 641/642. The addition of the trailing clocking bits 636 can help the MSR to correctly read the preceding sequence. Additional segments may be included in the sequences 600-603, such as including additional clocking bits between the primary channel bit sequence(s) 641/642 and the proxy bit stream 632/634, with the additional clocking bits having the same character configuration (bit per character 651) and the same bit rate (Baud A 661; Baud C 663) as the primary bit sequence.

[0084] FIG. 7A illustrates an example of a proxy bit stream 632. The proxy bit stream 632 may be configured to include a custom bit sequence 733. The information content of the custom bit sequence 733 may be arbitrary since it is not subject to verification by the transaction processor, but is designed to satisfy the data requirements of the POS terminal. For example, the custom bit sequence 733 may consist of a couple of alphanumeric characters, each having a number of bits-per-character 652 corresponding to the character configuration 114 of the secondary channel. In the alternative, the custom bit sequence 733 may be based on information found in a field in a secondary track of a magnetic stripe 11, such as a characters based on the Name field 218.

[0085] To be recognized by the secondary channel decoder of the MSR, the proxy bit stream 632 comprises a bit sequence U 743 that includes (in order) a start sentinel character 710, the custom bit sequence 733, an end sentinel character 726, and longitudinal redundancy check (LRC) data bits 728. Lead clocking bits 709 may be included prior to the start sentinel 710. The start sentinel character 710 and the end sentinel character 726 are those of the secondary channel.

[0086] The bit sequence U 743 may also include offset bit(s) 750 prior to the start sentinel character 710. The offset bit(s) 750 include at least one non-zero bit and has fewer bits than the bits-per-character 651 associated with the primary channel bit sequence 641/642, and fewer bits than the bits-per-character 652 associated with the proxy bit stream 632/634. So, for example, if the sequences include 5-bits per character and 7-bits per character, then there may be one-to-four offset bits 750. The offset bits 750 may either be included in or excluded from the computation of the LRC data bits 728, and do not correspond to a character. The inclusion of the offset bits 750 improves the likelihood that the primary channel decoder will regard the proxy stream as noise.

[0087] As illustrated in FIG. 7B, the bit sequence U 743 may be reversed to provide bit sequence UR 744 that serves as a proxy bit stream 634. When reversed, a set of trailing clocking bits 730 may be included prior to the reversed LRC at the beginning of the sequence UR 744. Proxy bit streams 632 and 634 are interchangeable, although some POS terminals may be more responsive to one than the other (i.e. one may produce fewer read errors than the other).

[0088] The length of proxy bit stream 632/634 depends in part on the noise tolerance of the MSR's primary channel, and the length of the proxy stream in terms of both the number of bits included and the time needed to transmit. The maximum number of bits that can be transmitted in the proxy bit stream 632/634 varies from POS terminal to POS terminal. Further, the custom bit sequence 733 may include fewer bits than the primary track data characters 611 to improve pulse reading accuracy (i.e. lead to fewer read errors), and it may omit at least some of the field information that would ordinarily be required if a track of a magnetic stripe 11 corresponding to the secondary channel were used for transaction approval. In other words, while proxy bit stream 632/634 may mimic some features of a track data structure, data ordinarily required by the corresponding secondary channel standard 112 may be omitted.

[0089] A nomenclature can be used to identify the structure of the custom bit sequence 733 (within the forward-bit-order proxy sequences 632 and reverse bit-order proxy bit sequences 634). The structure of the secondary data in the custom bit sequence is described by indicating the track identifier, followed by a postfix of one-or-more letter codes, as follows: [0090] a means the real Primary Account Number (PAN) from the secondary channel track; [0091] s means one-or-more space characters; [0092] e means the real four character expiration date from the secondary channel track; [0093] v means the real four character expiration data and a three character service code 101; [0094] n means null data composed of one-or-more zero characters replacing one-or-more non-discretionary data fields; [0095] c means a custom name field, composed of upper case letters, numbers, and/or spaces that is different from the actual Name data of the secondary channel track; and [0096] d means data, and is composed of the real four character expiration data, a three character service code 101, and real discretionary data.

[0097] Variant details of forward-bit-order proxy sequences 632 using these postfixes where Track 1 101 is the secondary track are demonstrated in the following examples for T1n, T1ne, T1nv, T1nd, T1an, T1ae, T1av, T1ad, T1ncn, T1nce, T1ncv, T1ncd, T1acn, T1ace, T1acv, T1acd, and T1s. All of these examples are equally applicable to reverse-bit-order proxy sequences 634. An example of a Format Code 212 that may be used with these variants is the letter B, which is used in the standard Track 1 data format in accordance with the IATA standard 112a.

[0098] As T1n, the custom bit sequence 733 is composed of a Format Code 212, a series of one-or-more nulls (zero characters) instead of the PAN field data 214, a field separator 216a, the Name field data 218, a field separator 216b, and one-or-more nulls instead of the Additional Data 222. PAN field data 214, Additional Data 222, and Discretionary Data 224 are omitted. For example, a T1n sequence may be structured as a bit stream consisting of a Start Sentinel 210, a Format Code 212 (e.g., the letter B), a single zero character replacing the PAN field data 214, a Field Separator 216a, a single zero character replacing the Name field data 218, a Field Separator 216b, a single zero character replacing the Additional Data field data 222, and an End Sentinel 226. A Longitudinal Redundancy Check character 228 is calculated and appended on in the conventional manner.

[0099] As T1ne, the custom bit sequence 733 is composed of a Format Code 212, a series of one-or-more nulls (zero characters) instead of the PAN field data 214, a field separator 216a, one-or-more nulls instead of the Name field data 218, a field separator 216b, and the four character expiration date. There is no additional data after the expiration data, with the end sentinel 226 and the LRC 228 calculated based on the previous data (i.e., the T1ne payload) following the expiration date. PAN field data 214, Name field data 218, the three-character Service Code, and the Discretionary Data 224 are omitted. For example, a T1ne sequence may be structured as a bit stream consisting of a Start Sentinel 210, a Format Code 212 (e.g., the letter B), a single zero character replacing the PAN field data 214, a Field Separator 216a, a single zero character replacing the Name field data 218, a Field Separator 216b, a four-digit expiration date (e.g., 4912 indicating an expiration of December 2049), an End Sentinel 226, and the LRC 228 calculated and appended on in the conventional manner.

[0100] As T1nv, the custom bit sequence 733 is composed of a Format Code 212, a series of one-or-more nulls (zero characters) instead of the PAN field data 214, a field separator 216a, one-or-more nulls instead of the Name field data 218, a field separator 216b, the real four character expiration data and a three character service code 101 (as Additional Data 222). There is no additional data after the service code, with the service code being followed by the end sentinel 226 and an LRC 228. PAN field data 214, Name field data 218, and the Discretionary Data 224 are omitted. For example, a T1nv sequence may be structured as a bit stream consisting of a Start Sentinel 210, a Format Code 212 (e.g., the letter B), a single zero character replacing the PAN field data 214, a Field Separator 216a, a single zero character replacing the Name field data 218, a Field Separator 216b, a four-digit expiration date (e.g., 4912 indicating an expiration of December 2049) and the 101 service code, an End Sentinel 226, and the LRC 228 calculated and appended on in the conventional manner.

[0101] As T1nd, the custom bit sequence 733 is composed of a Format Code 212, a series of one-or-more nulls (zero characters) instead of the PAN field data 214, a field separator 216a, one-or-more nulls instead of the Name field data 218, a field separator 216b, the real four character expiration data and a three character service code 101 (as Additional Data 222), and real Discretionary Data 224. PAN field data 214 and Name field data 218 are omitted. For example, a T1nd sequence may be structured as a bit stream consisting of a Start Sentinel 210, a Format Code 212 (e.g., the letter B), a single zero character replacing the PAN field data 214, a Field Separator 216a, a single zero character replacing the Name field data 218, a Field Separator 216b, a four-digit expiration date (e.g., 4912 indicating an expiration of December 2049) and the 101 service code, real Discretionary Data 224 (e.g., 987654321), an End Sentinel 226, and the LRC 228 calculated and appended on in the conventional manner.

[0102] As T1an, the custom bit sequence 733 is composed of a Format Code 212, the real PAN data 214, a field separator 216a, one-or-more nulls instead of the Name field data 218, a field separator 216b, and one-or-more nulls instead of the Additional Data 222. The Name field data 218, Additional Data 222, and Discretionary Data 224 are omitted. For example, a T1an sequence may be structured as a bit stream consisting of a Start Sentinel 210, a Format Code 212 (e.g., the letter B), real PAN field data 214 (e.g., primary account number 4444555566667777), a Field Separator 216a, a single zero character replacing the Name field data 218, a Field Separator 216b, a single zero character replacing the Additional Data field data 222, an End Sentinel 226, and an LRC 228.

[0103] As T1ae, the custom bit sequence 733 is composed of a Format Code 212, the real PAN data 214, a field separator 216a, one-or-more nulls instead of the Name field data 218, a field separator 216b, and the real four digit expiration date. Name field data 218, three character Service Code, and Discretionary Data 224 are omitted. For example, a T1ae sequence may be structured as a bit stream consisting of a Start Sentinel 210, a Format Code 212 (e.g., the letter B), real PAN field data 214 (e.g., primary account number 4444555566667777), a Field Separator 216a, a single zero character replacing the Name field data 218, a Field Separator 216b, a four-digit expiration date (e.g., 4912 indicating an expiration of December 2049), an End Sentinel 226, and an LRC 228.

[0104] As T1av, the custom bit sequence 733 is composed of a Format Code 212, the real PAN data 214, a field separator 216a, one-or-more nulls instead of the Name field data 218, a field separator 216b, the real four digit expiration date and a 101 service code (as Additional Data 222). Name field data 218 and Discretionary Data 224 are omitted. For example, a T1av sequence may be structured as a bit stream consisting of a Start Sentinel 210, a Format Code 212 (e.g., the letter B), real PAN field data 214 (e.g., primary account number 4444555566667777), a Field Separator 216a, a single zero character replacing the Name field data 218, a Field Separator 216b, a four-digit expiration date (e.g., 4912 indicating an expiration of December 2049) and the 101 service code, an End Sentinel 226, and an LRC 228.

[0105] As T1ad, the custom bit sequence 733 is composed of a Format Code 212, the real PAN field data 214, a field separator 216, the real four character expiration data and a three character service code 101 (as Additional Data 222), and real Discretionary Data 224. Name field data 218 is omitted. For example, a T1ad sequence may be structured as a bit stream consisting of a Start Sentinel 210, a Format Code 212 (e.g., the letter B), real PAN field data 214 (e.g., primary account number 4444555566667777), a Field Separator 216a, a single zero character replacing the Name field data 218, a Field Separator 216b, a four-digit expiration date (e.g., 4912 indicating an expiration of December 2049) and the 101 service code, real Discretionary Data 224 (e.g., 987654321), an End Sentinel 226, and an LRC 228.

[0106] As T1ncn, the custom bit sequence 733 is composed of a Format Code 212, one-or-more nulls instead of the PAN field data 214, a field separator 216a, custom name field data (such as one-or-more alphanumeric characters substituted for the Name field data 218), a field separator 216b, and one-or-more nulls. PAN field data 214, Additional Data 222 and Discretionary Data 224 are omitted.

[0107] As T1nce, the custom bit sequence 733 is composed of a Format Code 212, one-or-more nulls instead of the PAN field data 214, a field separator 216a, custom name field data (such as one-or-more alphanumeric characters substituted for the Name field data 218), a field separator 216b, and the real four character expiration date. PAN field data 214, the three-character Service Code, and the Discretionary Data 224 are omitted.

[0108] As T1ncv, the custom bit sequence 733 is composed of a Format Code 212, one-or-more nulls instead of the PAN field data 214, a field separator 216a, custom name field data (such as one-or-more alphanumeric characters substituted for the Name field data 218), a field separator 216b, the real four character expiration data and a three character service code 101 (as Additional Data 222). PAN field data 214 and the Discretionary Data 224 are omitted.

[0109] As T1ncd, the custom bit sequence 733 is composed of a Format Code 212, one-or-more nulls instead of the PAN field data 214, a field separator 216a, custom name field data (such as one-or-more alphanumeric characters substituted for the Name field data 218), a field separator 216b, the real four character expiration data and a three character service code 101 (as Additional Data 222), and the real Discretionary Data 224. PAN field data 214 is omitted.

[0110] As T1acn, the custom bit sequence 733 is composed of a Format Code 212, the real PAN data 214, a field separator 216a, custom name field data (such as one-or-more alphanumeric characters substituted for the Name field data 218), a field separator 216b, and one-or-more nulls. Additional Data 222 and Discretionary Data 224 are omitted. For example, a T1acn sequence may be structured as a bit stream consisting of a Start Sentinel 210, a Format Code 212 (e.g., the letter B), real PAN field data 214, a Field Separator 216a, a single uppercase letter character replacing the Name field data 218, a Field Separator 216b, a single zero character replacing the Additional Data field data 222, an End Sentinel 226, and an LRC 228.

[0111] As T1ace, the custom bit sequence 733 is composed of a Format Code 212, the real PAN field data 214, a field separator 216a, custom name field data (such as one-or-more alphanumeric characters substituted for the Name field data 218), a field separator 216b, and the real four-character expiration date. The three-character Service Code and the Discretionary Data 224 are omitted.

[0112] As T1acv, the custom bit sequence 733 is composed of a Format Code 212, the real PAN field data 214, a field separator 216a, custom name field data (such as one-or-more alphanumeric characters substituted for the Name field data 218), a field separator 216b, the real four character expiration data and a three character service code 101 (as Additional Data 222). Discretionary Data 224 is omitted.

[0113] As T1acd, the custom bit sequence 733 is composed of a Format Code 212, the real PAN field data 214, a field separator 216a, custom name field data (such as one-or-more alphanumeric characters substituted for the Name field data 218), a field separator 216b, the real four character expiration data and a three character service code 101 (as Additional Data 222), and the real Discretionary Data 224.

[0114] As T1s, the custom bit sequence 733 is composed of a Format Code 212, one-or-more space characters substituted for the PAN field data 214, a field separator 216a, the Name field data 218, a field separator 216b, and one-or-more space characters substituted for the Additional Data 222. PAN field data 214, Additional Data 222, and Discretionary Data 224 are omitted.

[0115] The 101 code as the three character service code signals to a POS terminal that the simulated card is magstripe only, to avoid issues related to chip cards. For example, if the code 201 is used, the POS terminal may display a message that this is a chip card, please insert your card. Codes other than 101 may be used, so long as the code indicates that the card data is for a magnetic stripe card that does not include an otherwise POS-terminal-compatible chip. As such, the 101 code may be substituted for the code that appeared on a user's actual credit card, but is a valid code in accordance with the IATA standard 112a.

[0116] The number of zero characters used with as null data with the n code and spaces used with the s code may correspond to the number of field characters ordinarily associated with the replaced field in accordance with the track standard 112, although fewer may be used. For example, as demonstrated in the above examples, a single zero character or a single space character may be used in place of each non-discretionary field.

[0117] In these variants, those that include null, space, or substitute data are particularly useful when communicating with POS terminals that require secondary track data in order to process a transaction, but that may not actually verify the contents of the omitted or substituted portions of the secondary track data. An example of this is when a merchant's system requires the inclusion of secondary track data for data mining and marketing purposes, but might not actually verify the omitted secondary data (or cancel a transaction even if the replacement data is not what the system was expecting).

[0118] The primary channel decoder may recognize the start sentinel 610 and/or the end sentinel 626 based in part on the sentinels each being adjacent to a series of binary zeros (e.g., the leading clocking bits 630 and the trailing clocking bits 636). The proxy bit stream 632 should not include the specific bit sequence corresponding to the start sentinel 610 of the primary bit sequence 641/642 in either the forward or reverse directions. So, for example, if the start sentinel 610 corresponds to a five-bit sequence equal to the character ; as used with Track 2 102 and Track 3 103, then the proxy bit streams 632 and 634 should not include that five-bit sequence adjacent to binary zeros in either the forward or reverse directions. Similarly, the proxy bit stream 632 also does not include the specific bit sequence corresponding to the end sentinel 626 of the primary bit sequence 641/642 adjacent to binary zeros in either the forward or reverse directions.

[0119] FIG. 8 illustrates an example of a process for assembling a pulse transmission sequence according to the disclosure, including constructing the proxy bit streams 632/634. The process begins by generating (810) a custom bit sequence 733. This may range from generating a random string of bits, to selecting a couple of characters in the information content format 115 of the secondary channel, to selecting information corresponding to a field used with the secondary channel, along with one-or-more control characters (e.g., Field Separators), format-centric code characters (e.g. Format Code 212), and/or placeholder characters that substitute for omitted secondary-channel field information. As described, customized bit sequences may be configured to minimize read errors for a particular POS terminal. The bits-per-character and/or number of proxy bits and/or state of proxy bits (1 or 0) may be selected to improve reading of the pulse transmission sequence by a given POS terminal since POS terminals from different manufacturers, and different POS terminal models from the same manufacturer, have different MSR and read head sensitivities. Accordingly, the customized bit sequence of the proxy bits can be generated/selected to tune the pulse transmission sequence to minimize read errors for a given POS terminal.

[0120] The custom bit sequence 733 is searched (814) for the forward and backward bit patterns of the primary channel start sentinel (SS) 610 adjacent to zeros (e.g., zeros equaling or exceeding a number of bits of one character). If the forward or backward SS bit pattern is found (816 Yes), then at least one bit of the custom bit sequence 733 is modified (822) to eliminate the primary channel SS bit pattern.

[0121] After modifying (822) the custom bit sequence 733, or if the bit sequence 733 is searched and the primary channel SS bit pattern is not found (816 No), then the process may be configured to create (834) the bit sequence U 743. Creating the bit sequence U 743 may include, for example, concatenating the secondary channel start sentinel 710, the custom bit sequence 733, and the secondary channel end sentinel 726, and calculating and appending on the LRC 728. Leading clocking zeros 709, the offset bit(s) 750, and/or the trailing clocking zeros 730 may also be appended. The offset bit(s) 750 may either be included in or excluded from the computation of the LRC 728. An aggregated bit pattern of the pulse transmission sequence 600-603 is created (836) to include the bit sequence U 743 and/or the reverse bit sequence UR 744.

[0122] Prior to assembling (834) the bit sequence U 734, the custom bit sequence 733 may also be checked for the primary channel end sentinel (ES) 626 bit pattern adjacent to zeros. If checking for the primary channel ES bit pattern, the custom bit sequence 733 is searched (824) for the forward and backward bit patterns of the primary channel end sentinel (ES) 626 adjacent to zeros (e.g., zeros equaling or exceeding a number of bits of one character). If the forward or backward ES bit pattern is found (826 Yes), then at least one bit of the custom bit sequence 733 is modified (834) to eliminate the primary channel ES bit pattern.

[0123] FIGS. 9A and 9B illustrate examples of the frameworks from FIGS. 6A and 6B in which the primary channel corresponds to the Track 2 102 channel and the secondary channel corresponds to the Track 1 101 channel. In these example, the Track 2 T2 character sequence 311 is the primary channel data 611, with the bit sequence T2 941 corresponding to the Track 2 data structure 102. The proxy bit streams 932 and 934 include some features of the Track 1 data structure 101, but omit data ordinarily required by the IATA standard 112a. Examples of the Track 1 custom bit sequences that may be used in the proxy bit streams 932 and 934 include the T1n, T1ne, T1nv, T1nd, T1an, T1ae, T1av, T1ad, T1ncn, T1nce, T1ncv, T1ncd, T1acn, T1ace, T1acv, T1acd, and T1s examples discussed above in connection with custom bit sequences 733.

[0124] Referring to FIGS. 9A and 9B, alternative pulse transmission sequences 900 and 901 each comprise (in order) a series of leading clocking bits 930, the proxy bit stream 932a/934a, the primary channel bit sequence in either forward (T2 941 in FIG. 9A) or reverse (T2R 942 in FIG. 9B) order, the proxy bit stream 932b/934b, and a series of trailing clocking bits 936. As discussed with the clocking bits 630 and 636, an example of each of the leading clocking bits 930 and the trailing clocking bits 936 would be thirty binary zeros (encoded in the transmitted magnetic pulses). The leading clocking bits 930 and the trailing clocking bits 936 have the same number of bits-per-character 951 as the primary channel bit sequence 941/942 (five bits-per-character), whereas the proxy bit stream 932/934 have a different number of bits-per-character 952 (seven bits-per-character).

[0125] As discussed in connection with FIGS. 6A to 6D, the leading clocking bits 930 are transmitted at a same bit rate (Baud A 661 in FIG. 9A; Baud C 663 in FIG. 9B) as the primary channel T2 bit sequence 941/942. The bit rate (Baud B 662) of the proxy bit stream is independent of the bit rate 661/663 of the primary channel bit sequence 941/942, and may be the same or different. Again, the proxy bit stream(s) may include customized bit streams or sequences configured to minimize read errors for a particular POS terminal based on empirical analysis and testing. The bits-per-character and/or number of proxy bits and/or state of proxy bits (1 or 0) may be selected to improve reading of the pulse transmission sequence by a given POS terminal to tune the pulse transmission sequence to minimize read errors for the given POS terminal.

[0126] The structural format of the Track 2 bit sequence T2 941 includes the start sentinel 310, the primary track character sequence 311, the end sentinel 326, and a longitudinal redundancy check (LRC) 328.

[0127] FIGS. 10A and 10B illustrate the proxy bit stream 932/934. The proxy bit stream 932/934 may be configured to include a custom bit sequence 1033, which is an embodiment of the custom bit sequence 733 configured for the Track 1 channel. As discussed in connection with proxy bit streams 632 and 634, the information content of the custom bit sequence 1033 may be arbitrary, since it is not subject to verification by the transaction processor, but is designed to satisfy the data requirements of the POS terminal and minimize read errors of the pulse transmission. For example, the custom bit sequence 1033 may consist of a couple of alphanumeric characters, each having a number of bits-per-character 952 corresponding to the character configuration 114a used with the Track 1 channel. As an alternative, as illustrated in FIG. 10A, the custom bit sequence 1033 may include information based on the Track 1 Name field 218, subject to any bit alterations made to the information contained within the Name field 218 in accordance with the process discussed in connection with FIG. 8.

[0128] The proxy bit stream 932 comprises a bit sequence U 1043 that includes (in order) a Track 1 start sentinel character 210, the custom bit sequence 1033, a Track 1 end sentinel character 226, and longitudinal redundancy check (LRC) data bits 228. A series of leading clocking bits 1009 (e.g., ten zeros) may be included prior to the start sentinel 210. The custom bit sequence 1033 may comprise (in order) a Format Code character 212, one-or-more arbitrary numeric characters and/or space characters 1017 (e.g. one or two zero characters), a first Field Separator 219a, information based on a Track 1 Name Field 218, a second Field Separator 219b, and a custom discretionary data 1024 consisting of one or more numeric characters and/or space characters (e.g., four zero characters or a four character expiration date). As an alternative to the field 1017 containing arbitrary numeric characters, the field 1017 may contain the last four digits of the PAN data, or one-or-more spaces and zeros followed by the last four digits of the PAN data.

[0129] In terms of the nomenclature presented above, if the character fields 1017 and 1024 each consist of one-or-more zeros, the custom bit sequence 1033 can be expressed as T1n. If the character fields 1017 and 1024 each consist of one-or-more spaces, the custom bit sequence 1033 can be expressed as T1s. If the character field 1017 consists of one-or-more zeros, and the character field 1024 consists of one-or-more spaces, the custom bit sequence 1033 can be expressed as T1ns. If the character field 1017 consists of one-or-more spaces, and the character field 1024 consists of one-or-more zeros, the custom bit sequence 1033 can be expressed as T1sn.

[0130] Of these variants, the T1nT2 variant resolves recognition problems with many POS terminals significantly improving the first tap success rate in testing. A variant that demonstrates similar behaviors and benefits is T1nT2R. Counterpart sequences are T1n-T2 and T1n-T2R, where the hyphen between the sequences represents an inserted time gap where the emitted magnetic flux falls to zero between emission of the T1n and T2 bit sequences. Clocking bits may also be inserted between the T1n and T2 bit sequences, with the T1nT2 and T1n-T2 bit sequences. Another variant that resolves recognition problems with many POS terminals is T2T1acnR, where the T1acn proxy sequence is transmitted in reverse bit-order. A variant that demonstrates similar behaviors and benefits is T1acnT2R. As noted with T1n-T2, a zero-flux time gap and/or clocking bits can also be inserted between these two sequence as T2-T1acnR and T1acn-T2R.

[0131] Referring back to the process in FIG. 8, even if the characters included in the custom bit sequences 733 and 744, such as the Format Code 212, Name field 218, last four PAN digits, custom name field, and/or the expiration date, are initially set to actual values associated with a customer's account, the information may be altered to eliminate occurrence of the forward and backward bit patterns corresponding to the Track 2 Start Sentinel 310 and End Sentinel 326. Although the Name field 218 may include the entirety of the Name field information associated with a customer's account, as discussed above in connection with the custom name field (the c postfix), the Name field information may be shortened or abbreviated, or substitute information may be used, so as to reduce the length of the custom bit sequence 1033. The offset bit(s) 750 may be included between the leading clocking bits 1009 the start sentinel 210. The offset bits 750 may either be included in or excluded from the computation of the LRC data bits 228, and do not correspond to a character.

[0132] The included information based on the Format Code 212, Name field 218, custom name field, last four PAN digits and/or expiration date might not be used to validate the transaction, but instead are used to satisfy requirements of software used by the merchant's payment processing system (e.g., software within the POS terminal), which may check for the presence of the information and/or make record of the information. Transaction approval by the transaction processor (e.g., 1680 in FIG. 16) remains dependent upon the portion of the pulse sequence corresponding to the Track 2 sequence. Satisfying the data field requirements of the merchant's payment processing software improves the likelihood that the POS terminal will accept and validate the transaction based on the Track 2 data.

[0133] As illustrated in FIG. 10B, the bit sequence U 1043 may be reversed to provide bit sequence UR 1044 that serves as a proxy bit stream 934. When reversed, a set of trailing clocking bits 730 may be included prior to the reversed LRC at the beginning of the sequence UR 1044. Proxy bit streams 932 and 934 are interchangeable, although some POS terminals may be more responsive to one than the other.

[0134] FIGS. 11A and 11B illustrate examples of the frameworks from FIGS. 6A and 6B in which the primary channel corresponds to the Track 3 103 channel and the secondary channel corresponds to the Track 1 101 channel. In these example, the Track 3 T3 character sequence 411 is the primary channel data 611, with the bit sequence T3 1141 corresponding to the Track 3 data structure 103. The proxy bit streams 932 and 934 include some features of the Track 1 data structure 101, but omit data ordinarily required by the IATA standard 112a.

[0135] Referring to FIGS. 11A and 11B, the pulse transmission sequences 1100 and 1101 each comprise (in order) a series of leading clocking bits 1130, the proxy bit stream 932a/934a, the primary channel bit sequence in either forward (T3 1141 in FIG. 11A) or reverse (T3R 1142 in FIG. 11B) order, the proxy bit stream 932b/934b, and a series of trailing clocking bits 1136. As discussed with the clocking bits 630 and 636, an example of each of the leading clocking bits 1130 and the trailing clocking bits 1136 would be thirty binary zeros (encoded in the transmitted magnetic pulses). The leading clocking bits 1130 and the trailing clocking bits 1136 have the same number of bits-per-character 951 as the primary channel bit sequence 1141/1142 (five bits-per-character), whereas the proxy bit stream 932/934 may have a different number of bits-per-character 952 (e.g., seven bits-per-character).

[0136] As discussed in connection with FIGS. 6A to 6D, the leading clocking bits 1130 are transmitted at a same bit rate (Baud A 661 in FIG. 11A; Baud C 663 in FIG. 11B) as the primary channel T3 bit sequence 1141/1142. The bit rate (Baud B 662) of the proxy bit stream is independent of the bit rate 661/663 of the primary channel bit sequence 1141/1142, and may be the same or different. The structural format of the Track 3 bit sequence T3 1141 includes the start sentinel 410, the primary track character sequence 411, the end sentinel 426, and a longitudinal redundancy check (LRC) 428.

[0137] FIGS. 12A to 12H illustrate embodiments of the improved pulse sequence transmissions based on the frameworks in FIGS. 9A and 9B in which the primary channel corresponds to Track 2 and the secondary channel corresponds to Track 1. Although not illustrated, Track 3 may be substituted for Track 2 in the pulse sequences in FIGS. 12A to 12H (in accordance with the frameworks in FIGS. 11A and 11B).

[0138] FIG. 12A illustrates a pulse sequence T2U 1200, comprising leading clocking bits 930, the T2 bit sequence 941, the bit sequence U 1043, and the trailing clocking bits 936. FIG. 12B illustrates a pulse sequence T2RU 1201, which is the same as sequence 1200 but uses the T2R bit sequence 942 as the primary channel sequence.

[0139] FIG. 12C illustrates a pulse sequence T2UR 1202, comprising leading clocking bits 930, the T2 bit sequence 941, the bit sequence UR 1044, and the trailing clocking bits 936. FIG. 12D illustrates a pulse sequence T2RUR 1203, which is the same as sequence 1202 but uses the T2R bit sequence 942 as the primary channel sequence.

[0140] FIG. 12E illustrates a pulse sequence UT2 1204, comprising leading clocking bits 930, the bit sequence U 1043, the T2 bit sequence 941, and the trailing clocking bits 936. FIG. 12F illustrates a pulse sequence UT2R 1205, which is the same as sequence 1204 but uses the T2R bit sequence 942 as the primary channel sequence.

[0141] FIG. 12G illustrates a pulse sequence URT2 1206, comprising leading clocking bits 930, the bit sequence UR 1044, the T2 bit sequence 941, and the trailing clocking bits 936. FIG. 12H illustrates a pulse sequence URT2R 1207, which is the same as sequence 1206 but uses the T2R bit sequence 942 as the primary channel sequence.

[0142] FIGS. 13A to 13D illustrate embodiments of the improved pulse sequence transmissions based on the frameworks in FIGS. 6C and 6D in which the primary channel corresponds to Track 2 and the secondary channel corresponds to Track 1. Although not illustrated, Track 3 may be substituted for Track 2 in the pulse sequences in FIGS. 13A to 13D.

[0143] FIG. 13A illustrates a pulse sequence T2UT2R 1300, comprising leading clocking bits 930, the T2 bit sequence 941, the bit sequence U 1043, the T2R bit sequence 942, and the trailing clocking bits 936. FIG. 13B illustrates a pulse sequence T2URT2R 1301, which is the same as sequence 1300 but uses the UR bit sequence 1044 as the as the secondary channel proxy bit stream.

[0144] FIG. 13C illustrates a pulse sequence T2RUT2 1302, comprising leading clocking bits 930, the T2R bit sequence 942, the bit sequence U 1043, the T2 bit sequence 941, and the trailing clocking bits 936. FIG. 13D illustrates a pulse sequence T2RURT2 1303, which is the same as sequence 1302 but uses the UR bit sequence 1044 as the as the secondary channel proxy bit stream.

[0145] As noted above, Baud A 661, Baud B 662, and Baud C 663 are each independent. Preferably, each of Baud A 661, Baud B 662, and Baud C 663 have a bit rate between eighty (80) and eight hundred (800) bits-per-second. As an example, referring to the pulse sequence T2U 1200 in FIG. 12A, Baud A 661 might be one hundred (100) bits-per-second, whereas Baud B 662 might be two hundred (200) bits-per-second. As another example, referring to the pulse sequence T2UT2R 1300 in FIG. 13A, Baud A 661 might be eighty (80) bits-per-second, whereas Baud B 662 might be one hundred (100) bits-per-second, and Baud C 663 might be two-hundred (200) bits-per-second. The transitions between baud rates may be smooth and gradual, or may be abrupt. When a smooth transition is provided between baud rates, additional zeroes may be included within the sequences to facilitate a smooth transition between rates (e.g., between the proxy bit stream and the primary channel sequence).

[0146] FIGS. 14A and 14B illustrate embodiments of a framework for improved pulse sequence transmissions based on the frameworks in FIGS. 6C and 6D in which the primary channel corresponds to Track 2 and the secondary channel data is omitted. FIG. 14A illustrates a pulse sequence T2T2R 1400, comprising leading clocking bits 930, the T2 bit sequence 941, the T2R bit sequence 942, and the trailing clocking bits 936. FIG. 14B illustrates a pulse sequence T2RT2 1401, comprising leading clocking bits 930, the T2R bit sequence 942, the T2 bit sequence 941, and the trailing clocking bits 936. Tested examples of Baud A 661 and Baud C 663 with the embodiments in FIGS. 14A and 14B include T2 at 100 bits-per-second and T2R at 300 bits-per-second, and T2 at 300 bits-per-second and T2R at 200 bits-per-second. As discussed above, counterpart sequences are T2R-T2 and T2-T2R, where the hyphen between the sequences represents an inserted time gap where the emitted magnetic flux falls to zero between emission of the T2 and T2R bit sequences. The baud rates used to transmit the T2 and T2R portions may be the same, or may be different.

[0147] FIG. 15 illustrates a process used by a device to selectively determine which of the improved pulse sequences to use. The process begins with software on a contactless payment device receiving (1540) an indication to output a card payment pulse sequence. An example of receiving the indication is detecting a touch of a region of a graphical user interface (GUI) on touch-sensitive display that corresponds to a pay button.

[0148] The contactless payment device determines (1542) its geographic location. Any technique may be used to acquire location information, such as using information from satellite geographic positioning system receiver such as a Global Positioning System (GPS) receiver and/or a Global Navigation Satellite System (GLONASS) receiver. Other examples of how location information may be acquired include using other radio sources (e.g., via at least one antenna), such as mapping services that triangulate off of known WiFi service set identifiers (SSIDs) or cellular towers within range of the device.

[0149] The device may contain a default list of pulse transmission sequences. Using information stored on the device and/or by accessing a database over a wireless network, the device identifies (1544) which of the pulse transmission sequences have been determined to work and which have been determined not to work with POS terminals at the location, and/or within a geographic region (e.g., a country), as certain manufacturers and types of POS terminals are known to predominate in certain geographic regions/countries. Each sequence and bit-rate combination may be associated with a weighted score corresponding to a confidence level that the sequence will or will not work at a specific location and/or within a specific region.

[0150] Either in combination with geographic-location based sequence identification (1542/1544), or as another approach to identifying sequences, image processing may be used to identify physically distinctive types of POS terminals. For example, the Square mag-reader dongle made by Square, Incorporated, has a distinctive shape that is identifiable using conventional image pattern recognition. In addition, some POS terminals have distinctively shaped features such as the shape of the pin/keypad.

[0151] The device processes (1541) an image captured by a camera of the device to identify patterns in the captured image (or images). The device then identifies (1543) whether any of the identified patterns corresponds to that of a specific type of POS terminal. Using information stored on the device and/or by accessing a database over a wireless network, the device identifies (1545) which of the pulse transmission sequences have been determined to work for the identified POS terminal (if the device is able to identified a specific terminal). Each sequence and bit-rate combination may be associated with a weighted score corresponding to a confidence level that the sequence will or will not work with the specific terminal.

[0152] The device sorts (1546) the default list using rules. The sort may give sequences that are indicated as working at the specific geographic location and/or with a specific identified terminal the highest priority. Sequences indicated as working within the region (e.g., a country), but untested at the specific location and/or with the specific identified terminal, may be given next-highest priority. Sequences known not to work at the specific geographic location and in the regions and/or with the specific identified terminal may be given lowest priority. Among sequences given the lowest priority, if the associated confidence score exceeds a stored threshold value indicating that it is highly improbably that the sequence would work, the sequence may be culled from the sorted list. Sequences indicated as working within the geographic region, but not at the specific geographic location and/or with the specific identified terminal, may be given next-to-last priority.

[0153] Other sequences may retain their default ordering in the list if they have not been tested. The default ordering may be based on, among other things, each sequence's success rate in other geographic regions or overall. The list of candidate pulse transmission sequences and bit-rate combinations, their default ordering, and the individual or combined weighted scores indicating which sequences do and do not work at the location and within the region and/or with a specific device may be reconciled between the contactless payment device and a database on a remote server, either as part of the transaction process or as part of occasional updates.

[0154] The sequences in the list may vary in structure (as discussed in connection with FIGS. 6A to 7B, and 9A to 14B). The same sequence framework may be identified more than once, such as including occurrences of a same sequence at different bit-rate combinations, and/or using a same framework but with different structures of the custom bit sequences 733/1033 for the proxy bit streams.

[0155] Based on the ordered priority, the contactless payment device selects (1548) a sequence, and outputs (1550) the sequence as a series of magnetic pulses. Ideally, the POS terminal properly receives the sequence and the transaction is approved. However, if the device receives (1556 Yes) another indication to output a sequence within a specified duration (e.g., thirty seconds), the assumption is made that the transaction was not approved and the device user wishes to try again. The contactless payment device stores (1558) that the selected sequence did not work at the location and/or POS terminal type (updating the sequence's weighted score(s)), and if another sequence remains in the sorted list (1560 Yes), selects (1564) and outputs (1550) a next sequence in the list to try again. If a sequence in the list has a weighted score above a threshold value, so as to indicate that it is highly probably that the sequence should work at the location, the contactless payment device may try outputting that sequence more than once before selecting another.

[0156] If the contactless payment device runs out of sequences to try (1560 No), there are several options available, depending upon how the device is configured. For example, contactless payment device may retry a sequence at the top of the sorted list, but using a different bit-rate combination, such as repeating the top scoring sequence at a slower bit-rate. As another example, the device may loop back to the top of stored list and reuse the framework of the top scoring sequence with a different proxy bit stream, such as trying a shorter custom bit sequence 733/1033 (e.g., by subtracting characters from the name field 218, rerunning the process in FIG. 8 and/or changing the number of offset bit(s) 750, and trying again). As another example, the contactless payment device may request (1562) additional sequence frameworks from a remote server. As a last resort, the contactless payment device may output an error indication for the benefit device's user.

[0157] If the device does not receive (1556 No) another indication to output a sequence within a specified duration (e.g., thirty seconds), the assumption is made that the transaction was approved. The contactless payment device stores (1572) that the selected sequence did work at the location and/or with the identified POS terminal type (updating the sequence's weighted score(s)). The time and date of the transaction may also be logged by the device, so as to allow a later comparison of the transaction with transactions approved by a transaction processor, so as to validate the improved confidence value (i.e., the weighted score) associated with the sequence and bit-rate combination.

[0158] FIG. 16 is a block diagram illustrating example components in a system 1600 including an improved contactless payment device 1610 according to the disclosure. A processor 1602 on the device 1610 executes instructions to perform the processes and output the improved pulse sequence transmissions discussed in connection with FIGS. 6A to 15.

[0159] The device 1610 includes one or more processors 1602, that each include a central processing unit (CPU) for processing data and executing instructions, and a memory 1604 for storing the data and the instructions. The memory 1604 may include volatile random access memory (RAM) and/or other types of memory. The device 1610 also includes a data storage component 1608, for storing the data and the processor-executable instructions. The data storage component 1608 may include one or more non-volatile storage types such as read only memory (ROM), flash memory, phase-change memory, Ferroelectric RAM, etc. The device 1610 may also be connected to removable or external non-volatile memory and/or storage, such as a removable memory card, a USB thumb drive, networked cloud storage, etc., through input/output (I/O) interfaces 1606.

[0160] The processor-executable instructions that configure the device 1610 and its various components are executed by the processor(s) 1602, using the memory 1604 as temporary working storage at runtime. The processor-executable instructions may be stored in the non-volatile memory 1604, the storage component 1608, and/or an external device. Some of the instructions may be embedded in hardware or firmware in addition to or instead of software.

[0161] The I/O interfaces 1606 may include interfaces for an external peripheral device connection such as universal serial bus (USB), as well as interfaces for wireless local area network (such as WiFi), Bluetooth, and/or cellular network (such as Long Term Evolution (LTE)) connectivity via the antenna(s) 1620. The I/O interfaces 1606 may also provide interfaces to a display 1622 including touch sensors 1624, and to one or more cameras 1680.

[0162] The antenna(s) may also be used by a location detector 1618, which may include one or more specialized radio receivers, such as a GPS receiver or GLONASS receiver. Instructions executed by the processor(s) 1602 may determine (1542) the device's geographic location based on location information determined by the location detector 1618.

[0163] The device 1610 may also include an image processor 1682, either as a component (e.g., a digital signal processor), or as instructions stored in storage 1608 that configure the processor 1602 to perform image processing. The image processor 1682 processes (1541) images captured by the one or more cameras 1680 to perform the pattern recognition used to identify (1543) POS terminals that are recognizable based on distinctive physical features/shape.

[0164] In addition, the image processor 1682 may be used to identify the location of the POS terminal's MSR 1630 based on pattern recognition. Instructions stored in storage 1608 may be used to configure the processor 1602 to cause the display of information on the display 1622 instructing a user how to position the device 1610 relative to the MSR 1630 to improve the likelihood that the POS terminal 1640 will correctly receive the magnetic pulse sequence when magnetic flux 1629 is emitted via the inductive loop 1628. The instructions may be in the form, for example, of an augmented reality interface that displays the live image of the MSR 1630 as captured by the camera 1680 on the display 1622, together with an overlay indicating whether the user should move the device up, down, closer, further, etc. from the MSR 1630.

[0165] The device 1610 may include an address/data bus 1614 for conveying data among components of the device 1610. Each component within the device 1610 may also be directly connected to other components in addition to (or instead of) being connected to other components across the bus 1614.

[0166] The list of pulse transmission sequences described hereinbefore may be stored in memory 1604 and/or storage component 1608, and updated/reconciled against data stored on a database server 1690, reached via a connection over one-or-more networks 1699. To output (1550) a pulse transmission sequence, a driver 1627 receives a bit sequence from the processor 1602, and converts the bit sequence into a time-modulated alternating current which is applied to an inductive loop 1628. The application of the alternating current to the loop 1628 generates the pulse transmission sequence as a series of magnetic field pulses.

[0167] An illustrative POS terminal 1640, such as may work in conjunction with the contactless payment device 1610, includes an MSR 1630. The MSR includes the read heads 501 and 502 that receive the magnetic field pulses. The first channel read head 501 outputs a signal to a first channel decoder 1633. The second channel read head 502 outputs a signal to a primary channel decoder 1634. It should be appreciated that other components may be implemented in various configurations in different models by different manufacturers of POS terminals. The MSR 1630 may be integrated with the POS terminal 1640, or may be separate. The MSR 1630 may communicate with components of the POS terminal 1640 via input/output (I/O) interfaces 1646.

[0168] The POS terminal 1640 includes one or more processors 1642, that each include a central processing unit (CPU) for processing data and executing instructions, and a memory 1644 for storing the data and the instructions. The memory 1644 may include volatile random access memory (RAM) and/or other types of memory. The POS terminal 1640 also includes a data storage component 1648, for storing the data and the processor-executable instructions. The data storage component 1648 may include one or more non-volatile storage types such as read only memory (ROM), flash memory, a hard disk drive (HDD), etc. The POS terminal 1640 may also be connected to removable or external non-volatile memory and/or storage, such as a USB thumb drive, an optical disc drive, networked cloud storage, etc., through the I/O interfaces 1646.

[0169] The processor-executable instructions that configure the POS terminal 1640 and its various components are executed by the processor(s) 1642, using the memory 1644 as temporary working storage at runtime. The processor-executable instructions may be stored in the non-volatile memory 1644, the storage component 1648, and/or an external device. Some of the instructions may be embedded in hardware or firmware in addition to or instead of software. Some or all of the functionality of the channel decoders 1633 and 1634 may be performed by the processor(s) 1642 instead of or in conjunction with dedicated decoder circuitry within the MSR 1630.

[0170] The POS terminal 1640 may include an address/data bus 1638 for conveying data among components of the terminal 1640. Each component within the POS terminal 1640 may also be directly connected to other components in addition to (or instead of) being connected to other components across the bus 1638.

[0171] The POS terminal 1640 may use an input/output (I/O) interface 1646 to communicate with a transaction processor 1680 via network(s) 1699. Instructions executed by the processor(s) 1642 receive the decoded pulse information from the MSR 1630, extract the information needed for transaction approval, and forward at least a portion of the extracted information to the transaction processor 1680. The transaction processor 1680 sends back information indicating whether the transaction is approved or denied. The POS terminal 1640 may output an indication of whether the transaction approved or denied, such as outputting a message via a display (not illustrated), by activating an indicator, by outputting a sound, etc.

[0172] Although mentioned in the Background, but not discussed in detail in connection with the improved pulse transmission sequences, a portion of the content of the primary channel sequence may be dynamic. So, for example, referring to FIG. 15, each time a selected sequence is output (1550) by the device 1610, a portion of the primary channel bit sequence (e.g., 641, 642, 941, 942, 1141, 1142) may be altered for security purposes.

[0173] Also, in addition to working with contactless systems, the improved pulse sequences may also be used with any of the cards that can be swiped through an MSR. For example, the improved sequences may be used with electronics cards that use a series of MEMS coil arrays embedded in the card to mimic the domains of a magnetic stripe. The improved sequences could also be encoded into a magnetic stripe that contains a single wide track (e.g., a single track spanning the width of Track 1 101 and Track 2 102, spanning the width of Track 1 101 through Track 3 103, or spanning the width of Tracks 2 102 and Track 3 103), so that a single track is configured to convey information to multiple MSR read heads.

[0174] As discussed in connection with FIGS. 8, 15, and 16, processes performed by the contactless payment device 1610 may be implemented by one-or-more processors 1602 contained within devices, and/or by other devices across a distributed environment (e.g., database server 1690). Processor-executable instructions that configure the processors to assemble (FIG. 8) and output (FIG. 15) the improved pulse transmission sequences may be implemented as an article of manufacture such as a memory device or a non-transitory computer readable storage medium. The computer readable storage medium may be, for example, a non-volatile computer memory, a hard drive, a solid-state drive (SSD), a flash memory drive, removable disk and/or other media.

[0175] The example frameworks and detailed embodiments of contactless payment system disclosed herein are intended to teach the principles of how to create the improved pulse transmission sequences to one of ordinary skill, rather than to be exhaustive. Many modifications and variations may be apparent to those of skill in the art, such as changing the order of process steps, while still achieving the benefits and advantages of the improved system. Moreover, aspects of the system may be practiced without some or all of the specific details and steps disclosed herein.

[0176] As used in this disclosure, the term a may include one or more items unless specifically stated otherwise. Further, the phrase based on is intended to mean based at least in part on unless specifically stated otherwise.