US20130054462A1 - Ecommerce system with payment data division - Google Patents
Ecommerce system with payment data division Download PDFInfo
- Publication number
- US20130054462A1 US20130054462A1 US13/558,198 US201213558198A US2013054462A1 US 20130054462 A1 US20130054462 A1 US 20130054462A1 US 201213558198 A US201213558198 A US 201213558198A US 2013054462 A1 US2013054462 A1 US 2013054462A1
- Authority
- US
- United States
- Prior art keywords
- data
- payment
- payment data
- subsets
- data processing
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000012545 processing Methods 0.000 claims abstract description 144
- 238000013475 authorization Methods 0.000 claims abstract description 81
- 238000000034 method Methods 0.000 claims description 29
- 230000004931 aggregating effect Effects 0.000 claims 1
- TVZRAEYQIKYCPH-UHFFFAOYSA-N 3-(trimethylsilyl)propane-1-sulfonic acid Chemical compound C[Si](C)(C)CCCS(O)(=O)=O TVZRAEYQIKYCPH-UHFFFAOYSA-N 0.000 description 21
- 230000008569 process Effects 0.000 description 17
- 230000015654 memory Effects 0.000 description 16
- 230000004044 response Effects 0.000 description 10
- 230000002776 aggregation Effects 0.000 description 8
- 238000004220 aggregation Methods 0.000 description 8
- 238000013461 design Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 4
- 238000004590 computer program Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000001413 cellular effect Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 241000962514 Alosa chrysochloris Species 0.000 description 1
- RWSOTUBLDIXVET-UHFFFAOYSA-N Dihydrogen sulfide Chemical compound S RWSOTUBLDIXVET-UHFFFAOYSA-N 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000006378 damage Effects 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
Definitions
- the present disclosure relates in general to the field of data processing, and more specifically to a method and system for dividing payment data.
- on-line transactions involve some form of payment and often involve payment via a payment mechanism, such as a credit card or electronic checking, that involves payment data electronically sent by the customer and stored by the merchant or a third party.
- a payment mechanism such as a credit card or electronic checking
- Payment data represents data that can be used to pay for a commercial transaction.
- Exemplary payment data for a credit card holder includes a cardholder name, a cardholder billing address, a credit card number, credit card security code, credit card expiration month, and credit card expiration year.
- Other payment data can includes a credit card issue month and a card issue year. Misappropriation of payment data can result in credit card fraud, substantial financial loss, credit rating injuries, and other undesirable consequences to both the customer and the merchant.
- PCI SSC Payment Card Industry Security Standards Council
- PCI DSS payment card industry data security standard
- ATM automated teller machine
- POS point of sale
- the PCI DSS standard is intended to increase controls around cardholder data to enhance payment card data security and, thus, for example, reduce credit card fraud and provide consumer confidence in engaging in credit card transactions, particularly on-line credit card transactions.
- FIG. 1 depicts an exemplary ecommerce system 100 having a PCI DSS compliant merchant server system 106 .
- the ecommerce system 100 includes a customer client system 102 that engages in ecommerce activity with the merchant server system 106 .
- the client computer system 102 is a computer system that includes a web browser software application 104 to allow a user of the client computer system 102 to receive and transmit data via the Internet. Examples of web browser 104 are Internet Explorer available from Microsoft Corporation of Washington, US and Firefox available from Mozilla of California, US.
- the client computer system 102 via web browser 104 allows a user of the client computer system 102 to browse web pages 108 provided by and interact with the merchant server system 106 via a network, such as the Internet or a private network.
- the web browser 104 To capture payment data from the user, the web browser 104 presents a payment form to the user, and the user enters payment data into the form. The web browser 104 captures the payment data in the form and provides the payment data 110 to the merchant server system 106 .
- the payment data 110 is encrypted and provide via a secure connection, such via a secure sockets layer.
- Providing the payment data 110 can be in response to a request to purchase one or more products and/or services offered by the merchant server system 106 or can be in anticipation of a future purchase.
- the merchant server system 106 stores the payment data 110 along with a user identification code to associate the user with the user's payment data 110 .
- the merchant server system 106 sends the payment data, merchant data, and a payment authorization request 112 to a payment authorization system 114 .
- the payment authorization system 114 then provides payment authorization data 118 to the merchant server system 106 .
- the payment response 116 can indicate approval or denial of payment.
- the payment authorization system 116 can be any system that provides payment authorization services and, in at least one embodiment, includes a payment gateway and a card association. Companies such as Authorize.Net with offices in Mountain View, Calif., Skipjack Financial Services in Cincinnati, Ohio, Sage Pay, London, England offer payment gateway services. Companies such as Visa, MasterCard, American Express, and Discover Card offer card association services.
- the merchant server system 106 complies with the PCI DSS.
- Compliance with PCI DSS can be relatively expensive in terms of, for example, an investment in secure facilities, secure hardware and software, encryption technology, and compliance verification.
- merchant compliance with PCI DSS has been considered as a reasonable way to protect payment data from misappropriation and provide consumer confidence in providing payment data via a public network, such as the Internet.
- FIG. 1 depicts an ecommerce system having a PCI DSS compliant merchant server system.
- FIG. 2 depicts an ecommerce system having for dividing payment data.
- FIG. 3 depicts an ecommerce system, which represents one embodiment of the ecommerce system of FIG. 2 .
- FIG. 4 depicts a payment data division and separation process.
- FIG. 5 depicts an ecommerce system, which represents one embodiment of the ecommerce system of FIG. 3 .
- FIG. 6 depicts an ecommerce system, which represents one embodiment of the ecommerce system of FIG. 5 .
- FIG. 7 depicts an ecommerce system, which represents one embodiment of the ecommerce system of FIG. 3 .
- FIG. 8 depicts an ecommerce system, which represents one embodiment of the ecommerce system of FIG. 3 .
- FIG. 9 depicts an ecommerce system, which represents one embodiment of the ecommerce system of FIG. 3 .
- FIG. 10 depicts an exemplary computer system.
- payment data is divided into proper subsets and distributed among multiple data processing systems, and each of the data processing systems stores less than all of the subsets of the payment data after the subsets of payment data are distributed and until at least sending the payment data to a payment authorization system for processing.
- distributing proper subsets of the payment data among multiple data processing systems enhances security of the payment data by limiting an amount of time and the locations in which a complete set of payment data is persisted.
- dividing the payment data into proper subsets and distributing the subsets among multiple data processing systems facilitates a number of ecommerce system configurations that can, in at least one embodiment, not only enhance payment data security, but can also allow merchants to accept electronic payment without the merchant server system coming within the scope of information security standards such as the payment card industry data security standard (PCI DSS). If a data processing system does not fall within the scope of the information security standard, the data processing system does not need to incur the expense of complying with the standard.
- PCI DSS payment card industry data security standard
- Ecommerce system 200 includes a client computer system 202 that engages in an ecommerce transaction with a merchant data processing system 204 via the network 206 .
- the ecommerce system 200 divides payment data into proper payment data subsets to, for example, enhance security and minimize the number of data processing systems that fall within the scope of PCI DSS requirements.
- the ecommerce system 200 can be configured in any of a number of ways to divide and combine the payment data.
- the network 206 can be any type of network, such as the Internet.
- the client computer system 202 is a computer system that includes a web browser software application (not shown) such as the web browser application 104 ( FIG. 1 ) to allow a user of the client computer system 202 to receive and transmit data with a merchant data processing system via the network 206 .
- the merchant data processing system is, in at least one embodiment, one of the data processing systems 204 . 0 - 204 .N or can be another data processing system such data processing system 208 .
- the network 206 can be any type of network such as, for example, the Internet.
- the data processing systems 204 . 0 - 204 .N are each part of a separate network in that, for example, each data processing system 204 . 0 - 204 .N has independent and distinct access requirements.
- Firewalls 214 . 0 - 214 .N permit or deny network transmissions to data processing systems 204 . 0 - 204 .N based upon a set of rules to, for example, protect the data processing systems 204 . 0 - 204 .N from unauthorized access while permitting legitimate data to pass.
- the payment data 203 is encrypted and transmitted via a secure connection, such via a secure sockets layer. Providing the payment data 203 can be in response to a request to purchase one or more products and/or services offered by one of the data processing systems 204 .X or data processing system 208 .
- the ecommerce system 200 can be configured in any number of ways to divide payment data into proper subsets of data.
- the client computer system 202 sends payment data 203 through the network 206 , and N+1 data processing systems 204 . 0 - 204 .N each store respective proper payment data subsets S 0 -SN of the payment data.
- a “proper subset” is a subset that contains less than all elements of a set. In mathematical terms, if A is a subset of S and A ⁇ S, then A is called a proper subset of S. “N” is an integer that is greater than or equal to 1. (Although four (4) data processing systems 204 .X are actually depicted in FIG.
- the number of data processing systems can range from 2 to N.
- “X” represents the ith data processing system, and i is an element of the set ⁇ 0, . . . , N ⁇ ).
- the client computer system 202 divides the payment data 208 into the proper payment data subsets S 0 -SN, and the payment data 203 represents the proper payment data subsets S 0 -SN.
- the payment data 203 is a complete set, and one of the data processing systems 204 .X, such as data processing system 204 . 0 , divides the aggregate payment data 203 into the proper payment data subsets S 0 -SN.
- Data processing systems 204 . 0 - 204 .N store the respective proper payment data subsets S 0 -SN in respective memories 212 . 0 - 212 .N.
- the ecommerce system 200 can also be configured in multiple ways to combine the payment data and obtain a payment authorization response.
- the data processing system 204 .X or 208 functioning as a merchant data processing system requests at least one of the other data processing systems 204 . 0 - 204 .N to proceed with payment authorization.
- the data processing system 204 .X receives all of the payment data subsets S 0 -SN, combines the payment data subsets S 0 -SN into a single, complete payment data set, and sends the complete payment data set to the payment authorization system 216 for payment authorization processing.
- payment authorization system 216 is identical to payment authorization system 116 ( FIG. 1 ).
- the data processing system 204 .X or 208 functioning as a merchant data processing system requests the other data processing systems 204 . 0 - 204 .N to send the payment data subsets S 0 -SN to the payment authorization system 216 .
- the payment authorization system 216 then combines the payment data subsets S 0 -SN into a single, complete payment data set and proceeds with the payment authorization processing.
- the payment data 203 can be divided into proper subsets of payment data subsets S 0 -SN in any number of ways.
- the payment data 203 includes a set of elements that represent values in a payment form presented to a user of the client computer system 202 .
- Exemplary payment data for a credit card holder (also referred to as a “cardholder”) includes a cardholder name, a cardholder billing address, a credit card number, credit card security code, credit card expiration month, and credit card expiration year.
- Other payment data can includes a credit card issue month and a card issue year. Assuming that N equals 1, the payment data 203 is bifurcated into two proper payment data subsets S 0 and S 1 as depicted in Table 1.
- the payment data subsets S 0 -S N are proper data subsets since neither of the payment data subsets S 0 -S N contain all of the payment data 203 . Additionally, the payment data subsets S 0 -S N can be disjoint or non-disjoint.
- E 1 ⁇ e 0 , e 1 , . . . , e T ⁇
- S y is selected from the set E i for all i and T.
- E i is an element representing an i th element of the payment data.
- e x is the X th sub-element of an element E i .
- S y is the y th subset of one or more elements and/or portions of elements of the payment data 203 .
- the PCI DSS applies to a data processing system when the data processing system has access to a complete set of payment data 203 . However, since less than all of the data processing systems 204 . 0 - 204 .N have access to the combined payment data, the number of data processing systems 204 . 0 - 204 .N within the compliance scope of PCI DSS is reduced. In at least one embodiment, only one data processing system 204 .X has access to the complete set of payment data, only one data processing system 204 .X maintains PCI DSS compliance.
- the data processing system 204 .X that maintains PCI DSS compliance can respond to payment requests, combine payment data subsets S 0 -S N , and send the combined payment data to the payment authorization system 216 .
- data processing system 204 .X momentarily combines the payment data subsets S 0 -S N , thereby minimizing security risks associated with payment data misappropriation.
- the data processing system 204 .X that maintains PCI DSS compliance can offer PCI DSS compliance as a service to other data processing systems while minimizing exposure of the payment data to misappropriation.
- FIG. 3 depicts an ecommerce system 300 , which represents one embodiment of the ecommerce system 200 .
- FIG. 4 depicts a payment data division, aggregation, and payment authorization process 400 .
- the ecommerce system 300 operates in accordance with the payment data division, aggregation, and payment authorization process 400 .
- the ecommerce system 300 includes a client computer system 302 that represents one embodiment of the client computer system 202 .
- the ecommerce system 300 also includes N data processing systems DPS 0 — 3 -DPS N — 3 , which represent respective embodiments of data processing systems 204 . 0 - 204 .N. N is an integer greater than or equal to 1.
- the client computer system 302 and data processing systems DPS 0 — 3 -DPS N — 3 are interconnected via a network such as the network 206 ( FIG. 2 ).
- Each of the data processing systems DPS 0 — 3 -DPS N — 3 includes a firewall (depicted as the outer perimeter) so that each of the data processing systems DPS 0 — 3 -DPS N — 3 is a separate system.
- client computer system 302 includes a payment data divider 304 to read payment data and divide payment data into proper subsets of payment data S 0 -S N .
- the particular implementation of the payment data divider 304 is a matter of design choice.
- the payment data divider 304 can be implemented using, for example, hardware and/or software that can perform hypertext transport protocol (HTTP) functions.
- HTTP hypertext transport protocol
- the payment data divider 304 is implemented as JavaScript, Visual Basic script, and/or Flash.
- one of the data processing systems, data processing system DPS X provides payment data divider 304 to the client computer system 302 for installation in the client computer system 302 .
- the entity and manner of providing the payment data divider 304 to the client computer system 302 is a matter of design choice.
- the data processing system DPS X is a third party data processing system that facilitates obtaining payment authorization for a merchant.
- Operation 446 is depicted in dotted lines because, in at least one embodiment, the payment data divider 304 is installed in the client computer system 302 as part of the web browser 306 or is included by a manufacturer of the client computer system 302 .
- the data processing system DPS N — 3 represents a merchant server system (indicated by the “(MERCHANT)”) that provides one or more web pages 303 to the client computer system 302 .
- the merchant data processing system DPS N — 3 provides one or more web pages 303 to the client computer system 302 .
- the web browser application 306 of the client computer system 302 renders the web page(s) 303 for display to and review by a user of the client computer system 302 .
- the web page(s) include data to display products, such as goods or services, offered by the merchant data processing system DPS N — 3 .
- the user of the client computer system 302 may then decide to enter into a commercial transaction with the merchant for one or more products offered in one or more of the web pages 303 and, in operation 403 , initiate a checkout process.
- Operation 403 is depicted using dotted lines because, as subsequently explained in more detail, in some embodiments, the payment data 305 is divided and transmitted in anticipation of a future commercial transaction rather than in response to a present commercial transaction.
- the customer continues with the check out process in accordance with a checkout process established by the merchant data processing system DPS X .
- the user initiates a ‘buy’ request via the web browser 306 , and the web browser forwards the ‘buy’ request to the merchant data processing system DPS X .
- at least one of the web pages 303 includes a payment form, such as a data entry form or shopping cart, which, in operation 405 , allows the client computer system 302 to obtain payment data 305 from the user or from previously stored data for the purchase of one or more products.
- the merchant data processing system DPS N — 3 also sends merchant transaction data 301 to associate the merchant with the payment data 305 .
- the particular content of the merchant transaction data 301 is a matter of design choice.
- the merchant transaction data 301 includes a merchant identifier, transaction identifier, and a token to associate the payment data 305 with the particular transaction for which the payment data 305 applies.
- the token allows the client computer system 302 to encrypt the payment data 305 .
- the payment data divider 304 has no ability to store and/or distribute all or part of the payment data subsets S 0 -S N without authorization by the user.
- the client computer system 302 divides the subsets of payment data S 0 -S N in anticipation of a future commercial transaction with a merchant server system, such as data processing system DPS N — 3 . In at least one embodiment, in operation 403 , the client computer system 302 divides the subsets of payment data S 0 -S N for completion of a financial component of the present commercial transaction with the data processing system DPS X .
- the payment data divider 304 divides the payment data 305 into the N+1 payment data subsets S 0 -S N prior to distributing the payment data subsets S 0 -S N .
- An embodiment of operation 407 can be implemented using the following pseudocode:
- the payment data divider 304 includes parsing and division rules that determine how the payment data 305 will be allocated to payment data subsets S 0 -S N .
- the particular rules are a matter of design choice.
- the payment data divider 304 specifies how to divide and allocate the payment data 305 into the payment data subsets S 0 -S N .
- the value of N is 1, and the payment data divider 304 bifurcates the payment data 305 into two payment data subsets S 0 and S 1 as, for example, presented in Table 1.
- each payment data subset S 0 -S N includes transaction identification data.
- the transaction identification data associates each of the payment data subsets S 0 -S N with a particular transaction.
- the transaction identification data includes data to identify the particular transaction and an identifier of the merchant from which the products are being obtained.
- each data processing systems DPS 0 — 3 -DPS N — 3 receives only part of the payment data subsets S 0 -S N .
- the payment data divider 304 utilizes asynchronous JavaScript and XML (AJAX) technology to distribute the payment data subsets S 0 -S N to the data processing systems DPS 0 — 3 -DPS N — 3 .
- the payment divider 304 also includes the merchant transaction data 301 , or at least a merchant identifier, as part of each of the payment data subsets S 0 -S N .
- each of the data processing systems DPS 0 — 3 -DPS N — 3 receives a payment data subset.
- data processing system DPS X receives payment data subset S X .
- each of data processing systems DPS 0 — 3 -DPS N — 3 encrypts and stores one of the respective payment data subsets S 0 -S N including the merchant transaction data 301 and a user identifier.
- the data processing systems DPS 0 — 3 -DPS N — 3 do not have the ability to return any or all of the payment data subsets S 0 -S N to the client computer system 302 .
- the number of times the payment data subsets S 0 -S N are transmitted is minimized.
- the merchant credentials include an identifier that identifies the merchant to at least a payment gateway of the payment authorization system 308 .
- a payment gateway is typically a system that interacts with a payment processor of a bank used by the merchant.
- the merchant credentials may also include information, such as a password, used to access the payment authorization system 308 .
- the payment authorization system 308 can be any payment authorization system that, for examples, electronically authorizes payment.
- the payment authorization system 308 is identical to the payment authorization system 116 ( FIG. 1 ).
- Operation 460 aggregates the payment data subsets S 0 -S N into an aggregated payment data set 310 .
- the particular system that aggregates the payment data subsets S 0 -S N into the payment data set 310 is a matter of design choice.
- one of the data processing systems DPS 0 — 3 -DPS N — 3 aggregates the payment data subsets S 0 .
- the payment authorization system 308 aggregates the payment data subsets S 0 -S N into the payment data set 310 .
- the system that aggregates the payment data subsets S 0 -S N into the payment data set 310 comes within the scope of the PCI DSS.
- the other data processing systems that do not have access to the complete payment data 310 are not within the scope of the PCI DSS and, thus, do not incur the costs associates with PCI DSS compliance.
- one of the data processing systems DPS 0 — 3 -DPS N — 3 sends a payment authorization request to the payment authorization system 308 .
- the payment authorization request includes the complete payment data subsets S 0 -S 1 , either combined, if aggregated by one of the data processing systems DPS 0 — 3 -DPS N — 3 , or separate, if aggregated by the payment authorization system 308 .
- the payment authorization request also includes the merchant credentials, a transaction amount and currency, and a reference identifier for the merchant, if desired.
- the payment authorization request is sent using a secure transmission, such as using the HTTPS protocol.
- the payment authorization system 308 and at least one of the data processing systems DPS 0 — 3 -DPS N — 3 receives the payment authorization response 312 .
- the data processing system upon successful authorization, for security if one of the data processing systems DPS 0 — 3 -DPS N — 3 has the complete payment data 310 , the data processing system destroys at least part of the payment data 310 , such as the payment data subset. 1 in Table 1.
- a request by one of the data processing systems DPS 0 — 3 -DPS N — 3 is made to the payment authorization system 308 to capture the authorized funds to complete the financial component of the commercial transaction.
- Embodiments of the payment data division, aggregation, and payment authorization process 400 can also be implemented by a variety of ecommerce system embodiments.
- the following description includes several exemplary ecommerce system embodiments. It will be understood that other ecommerce systems can also implement the payment data division, aggregation, and payment authorization process 400 and variations thereof.
- FIG. 5 depicts ecommerce system 500 , which represents one embodiment of ecommerce system 300 .
- the data processing system DPS N — 5 represents a merchant data processing system, and the client computer system 302 and the merchant data processing system DPS N — 5 conduct a commercial transaction as, for example, described in conjunction with ecommerce system 300 .
- the payment divider 304 divides the payment data 305 into the payment data subsets S 0 -S 1 , encrypts the payment data subsets S 0 -S 1 , and distributes the data payment subsets S 0 -S 1 among the data processing systems DPS 0 — 5 -DPS N — 5 .
- ecommerce system 500 performs operations 401 - 409 and 446 - 454 as previously described.
- Data processing system DPS 0 — 5 includes a data aggregator 502 that aggregates all of the payment data subsets S 0 -S 1 .
- merchant data processing system DPS N — 5 authenticates with data processing system DPS 0 — 5 and sends payment data subset S N including merchant transaction data to data processing system DPS 0 — 5 with a request to obtain payment authorization from payment authorization system 504 for the transaction identified by the merchant transaction data.
- the merchant data processing system DPS N — 5 also sends a request to all other data processing system DPS 1 — 5 -DPS N-1 — 5 to send payment data subsets S 1 -S N-1 and merchant transaction data to data processing system DPS 0 — 5 .
- data processing systems DPS 1 — 5 -DPS N — 5 Since the data processing systems DPS 1 — 5 -DPS N — 5 only receive respective proper payment data subsets S 0 -S N , none of the data processing systems DPS 1 — 5 -DPS N — 5 have access to all of the payment data 305 . Accordingly, in at least one embodiment, data processing systems DPS 1 — 5 -DPS N — 5 are outside the scope of PCI DSS, do not need to comply with PCI DSS standards, and, therefore, save costs associated with PCI DSS implementation and compliance.
- the data aggregator 502 decrypts and aggregates (i.e. combines) the payment data subsets S 0 -S N into a complete set of payment data.
- the particular aggregation process of data aggregator 502 is a matter of design choice.
- the data aggregator 502 performs a reverse process of payment data divider 304 to reassemble the payment data subsets into payment data 305 .
- the data aggregator 502 aggregates the payment data into a format specified by the payment authorization system 504 .
- the data processing system DPS 0 — 5 processes the merchant transaction data to determine payment gateway account information for the merchant. The data processing system DPS 0 — 5 then sends the combined payment data, merchant data, and an authorization request 506 to the payment authorization system 504 in accordance with the payment gateway account information for the merchant.
- the merchant data identifies the merchant with a merchant identifier, identifies the transaction with a transaction identifier, and provides merchant account credentials to access the payment authorization system 504 .
- the data 506 also includes a token to be used by the payment authorization system 504 to decrypt the data 506 .
- payment authorization system 506 processes the data 506 and generates the payment authorization response 312 as previously described.
- FIG. 6 depicts ecommerce system 600 , which represents one embodiment of ecommerce system 500 .
- Ecommerce system 500 bifurcates the payment data 305 into proper payment data subsets S 0 and S 1 and distributes the bifurcated payment data subsets to respective data processing system DPS 0 — 6 and merchant data processing system DPS 1 — 6 .
- the payment data 305 is bifurcated as depicted in Table 1.
- FIG. 7 depicts ecommerce system 700 , which represents one embodiment of ecommerce system 300 .
- ecommerce system 700 performs operations 401 - 409 and 446 - 454 of payment data division, aggregation, and payment authorization process 400 as previously described.
- the data processing system DPS N — 7 After the data processing system DPS 0 — 7 -DPS N — 7 receive respective payment data subsets S 0 -S 1 , the data processing system DPS N — 7 sends a payment authorization request 702 to the payment authorization system 704 and sends a request to the data processing systems data processing system DPS 0 — 7 -DPS N — 7 directly data processing system DPS 0 — 7 -DPS N — 7 to send respective payment data subsets S 0 -S N-1 to payment authorization system 704 .
- Payment authorization system 704 includes data aggregator 706 , which combines the payment data subsets S 0 -S 1 to complete payment authorization.
- the data aggregator 704 combines the payment data subsets S 0 -S N as described in conjunction with the data aggregator 502 . Once the payment authorization system 704 aggregates the payment data subsets S 0 -S N , payment authorization system 506 processes the aggregated data and generates the payment authorization response 312 as previously described.
- FIG. 8 depicts ecommerce system 800 , which represents one embodiment of ecommerce system 300 .
- ecommerce system 800 functions identically to ecommerce system 700 except that the data aggregator 802 is part of a computer system separate from the payment authorization system 504 .
- the data aggregator 802 combines the payment data subsets S 0 -S N as described in conjunction with the data aggregator 502 .
- FIG. 9 depicts ecommerce system 900 , which represents one embodiment of ecommerce system 300 .
- the payment data division, aggregation, and payment authorization process 400 operations 401 - 405 and 446 - 449 function as previously described.
- the client computer system 902 provides the complete payment data 305 to data processing system DPS 0 —9 .
- the data processing system DPS 0 — 9 system includes a data divider 906 .
- Data divider 906 divides the payment data 305 into proper payment data subsets S 0 -S N as, for example, described with respect to payment data divider 304 .
- Data processing system DPS 0 then distributes the proper data subsets S 1 -S N , along with data to identify at least the transaction associated with the payment data subsets S 1 -S N , to data processing systems S 1 -S N .
- the payment data 305 can be sent to the payment authorization system 908 in any number of ways.
- data processing system DPS 0 — 9 recombines the payment data subsets S 0 -S 1 and sends the complete data set to payment authorization system 908 for processing, as described in conjunction with ecommerce system 500 .
- each of the data processing systems DPS 0 — 9 -DPS N — 9 sends the payment data subsets S 0 -S N to either a separate payment aggregator or to the payment authorization system 908 as respectively described in conjunction with ecommerce systems 800 and 700 .
- the payment authorization system 908 then generates the payment authorization response 312 as previously described.
- payment data from a client computer system is divided into proper subsets and distributed among multiple data processing systems, and each of the data processing systems stores less than all of the subsets of the payment data after the subsets of payment data are distributed and until at least sending the payment data to a payment authorization system for processing.
- the client computer systems and data processing systems described herein can be completely hardware implemented using, for example, an application specific integrated circuit(s) implemented using, for example, field programmable gate arrays or other logic circuits.
- the client computer system and data processing systems can also be implemented using a combination of software and hardware.
- the client computer system and data processing system can also be implemented as a specifically configured computer system that can perform the processes discussed herein, such as payment data division, aggregation, and payment authorization process 400 .
- FIG. 10 depicts an exemplary computer system 1000 , which can represent data processing systems and the client computer systems described herein.
- the processes discussed herein can also be implemented as code stored in a non-transitory, tangible computer programmable medium and executable by a general purpose or application specific computing system. Examples of a non-transitory, tangible computer programmable medium include hard-drive memories, solid state memories, such as flash memories, compact disks, and digital versatile disks.
- input user device(s) 1010 such as a keyboard and/or mouse, are coupled to a bi-directional system bus 1018 .
- the input user device(s) 1010 are for introducing user input to the computer system 1000 and communicating that user input to processor 1013 .
- the computer system of FIG. 10 generally also includes a video memory 1014 , main memory 1015 and mass storage 1009 , all coupled to bi-directional system bus 1018 along with input user device(s) 1010 and processor 1013 .
- the mass storage 1009 may include both fixed and removable media, such as other available mass storage technology.
- Bus 1018 may contain, for example, 32 or 64 address lines for addressing video memory 1014 or main memory 1015 .
- the system bus 1018 also includes, for example, an n-bit data bus for transferring DATA between and among the components, such as CPU 1009 , main memory 1015 , video memory 1014 and mass storage 1009 , where “n” is, for example, 32 or 64.
- n is, for example, 32 or 64.
- multiplex data/address lines may be used instead of separate data and address lines.
- I/O device(s) 1019 may provide connections to peripheral devices, such as a printer, and may also provide a direct connection to a remote computer system via a telephone link or to the Internet via an ISP.
- I/O device(s) 1019 may also include a network interface device to provide a direct connection to remote server computer systems via a direct network link to the Internet via a POP (point of presence).
- POP point of presence
- Such connection may be made using, for example, wireless techniques, including digital cellular telephone connection, Cellular Digital Packet Data (CDPD) connection, digital satellite data connection or the like.
- Examples of I/O devices include modems, sound and video devices, and specialized communication devices such as the aforementioned network interface.
- Computer programs and data are generally stored as instructions and data in mass storage 1009 until loaded into main memory 1015 for execution. Computer programs may also be in the form of electronic signals modulated in accordance with the computer program and data communication technology when transferred via a network.
- Mass storage 1009 and main memory 1015 both are forms of non-transitory storage devices on which executable code can be stored that, when executed by the processor 1013 , causes the processor to perform one or more or all of the functions described herein.
- the processor 1013 in one embodiment, is a microprocessor manufactured by Motorola Inc. of Illinois, Intel Corporation of California, or Advanced Micro Devices of California. However, any other suitable single or multiple microprocessors or microcomputers may be utilized.
- Main memory 1015 is comprised of dynamic random access memory (DRAM).
- Video memory 1014 is a dual-ported video random access memory. One port of the video memory 1014 is coupled to video amplifier 1016 .
- the video amplifier 1016 is used to drive the display 1017 .
- Video amplifier 1016 is well known in the art and may be implemented by any suitable means. This circuitry converts pixel DATA stored in video memory 1014 to a raster signal suitable for use by display 1017 .
- Display 1017 is a type of monitor suitable for displaying graphic images.
- the computer system 1000 described above is for purposes of example only.
Abstract
Description
- The present application claims priority to U.S. Provisional Pat. App. No. 61/526,971 filed on Aug. 24, 2011, which is incorporated herein by reference.
- The present disclosure relates in general to the field of data processing, and more specifically to a method and system for dividing payment data.
- Many customers and merchants transact business via an electronic network, such as the Internet. Most transactions involving the Internet (“on-line transactions”) involve some form of payment and often involve payment via a payment mechanism, such as a credit card or electronic checking, that involves payment data electronically sent by the customer and stored by the merchant or a third party.
- Payment data represents data that can be used to pay for a commercial transaction. Exemplary payment data for a credit card holder (also referred to as a “cardholder”) includes a cardholder name, a cardholder billing address, a credit card number, credit card security code, credit card expiration month, and credit card expiration year. Other payment data can includes a credit card issue month and a card issue year. Misappropriation of payment data can result in credit card fraud, substantial financial loss, credit rating injuries, and other undesirable consequences to both the customer and the merchant.
- Organizations have established standards to provide security in the exchange of sensitive information such as payment data. For example, for credit card transactions, the Payment Card Industry Security Standards Council (PCI SSC) established a payment card industry data security standard (PCI DSS) to provide an information security standard for organizations that handle credit card holder information for many debit, credit, prepaid, e-purse, automated teller machine (ATM), and point of sale (POS) cards. The PCI DSS standard is intended to increase controls around cardholder data to enhance payment card data security and, thus, for example, reduce credit card fraud and provide consumer confidence in engaging in credit card transactions, particularly on-line credit card transactions.
-
FIG. 1 depicts anexemplary ecommerce system 100 having a PCI DSS compliantmerchant server system 106. Theecommerce system 100 includes acustomer client system 102 that engages in ecommerce activity with themerchant server system 106. In at least one embodiment, theclient computer system 102 is a computer system that includes a webbrowser software application 104 to allow a user of theclient computer system 102 to receive and transmit data via the Internet. Examples ofweb browser 104 are Internet Explorer available from Microsoft Corporation of Washington, US and Firefox available from Mozilla of California, US. Theclient computer system 102 viaweb browser 104 allows a user of theclient computer system 102 to browseweb pages 108 provided by and interact with themerchant server system 106 via a network, such as the Internet or a private network. - To capture payment data from the user, the
web browser 104 presents a payment form to the user, and the user enters payment data into the form. Theweb browser 104 captures the payment data in the form and provides the payment data 110 to themerchant server system 106. Generally the payment data 110 is encrypted and provide via a secure connection, such via a secure sockets layer. Providing the payment data 110 can be in response to a request to purchase one or more products and/or services offered by themerchant server system 106 or can be in anticipation of a future purchase. Themerchant server system 106 stores the payment data 110 along with a user identification code to associate the user with the user's payment data 110. - To authorize payment from the user to the merchant, the
merchant server system 106 sends the payment data, merchant data, and apayment authorization request 112 to a payment authorization system 114. The payment authorization system 114 then providespayment authorization data 118 to themerchant server system 106. Thepayment response 116 can indicate approval or denial of payment. Thepayment authorization system 116 can be any system that provides payment authorization services and, in at least one embodiment, includes a payment gateway and a card association. Companies such as Authorize.Net with offices in Mountain View, Calif., Skipjack Financial Services in Cincinnati, Ohio, Sage Pay, London, England offer payment gateway services. Companies such as Visa, MasterCard, American Express, and Discover Card offer card association services. - Typically, to be authorized to conduct credit card payment transactions, the
merchant server system 106 complies with the PCI DSS. Compliance with PCI DSS can be relatively expensive in terms of, for example, an investment in secure facilities, secure hardware and software, encryption technology, and compliance verification. However, merchant compliance with PCI DSS has been considered as a reasonable way to protect payment data from misappropriation and provide consumer confidence in providing payment data via a public network, such as the Internet. - The present invention may be better understood, and its numerous objects, features and advantages made apparent to those skilled in the art by referencing the accompanying drawings. The use of the same reference number throughout the several figures designates a like or similar element.
-
FIG. 1 depicts an ecommerce system having a PCI DSS compliant merchant server system. -
FIG. 2 depicts an ecommerce system having for dividing payment data. -
FIG. 3 depicts an ecommerce system, which represents one embodiment of the ecommerce system ofFIG. 2 . -
FIG. 4 depicts a payment data division and separation process. -
FIG. 5 depicts an ecommerce system, which represents one embodiment of the ecommerce system ofFIG. 3 . -
FIG. 6 depicts an ecommerce system, which represents one embodiment of the ecommerce system ofFIG. 5 . -
FIG. 7 depicts an ecommerce system, which represents one embodiment of the ecommerce system ofFIG. 3 . -
FIG. 8 depicts an ecommerce system, which represents one embodiment of the ecommerce system ofFIG. 3 . -
FIG. 9 depicts an ecommerce system, which represents one embodiment of the ecommerce system ofFIG. 3 . -
FIG. 10 depicts an exemplary computer system. - Certain terms are used throughout the following description and claims to refer to particular system components. As one skilled in the art will appreciate, companies may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . ” Also, the term “couple” or “couples” is intended to mean either an indirect or direct electrical connection. Thus, if a first device couples to a second device, that connection may be through a direct electrical connection, or through an indirect electrical connection via other devices and connections.
- The following discussion is directed to various embodiments of the invention. Although one or more of these embodiments may be preferred, the embodiments disclosed should not be interpreted, or otherwise used, as limiting the scope of the disclosure, including the claims. In addition, one skilled in the art will understand that the following description has broad application, and the discussion of any embodiment is meant only to be exemplary of that embodiment, and not intended to intimate that the scope of the disclosure, including the claims, is limited to that embodiment.
- In at least one embodiment of an ecommerce system, payment data is divided into proper subsets and distributed among multiple data processing systems, and each of the data processing systems stores less than all of the subsets of the payment data after the subsets of payment data are distributed and until at least sending the payment data to a payment authorization system for processing. In at least one embodiment, distributing proper subsets of the payment data among multiple data processing systems enhances security of the payment data by limiting an amount of time and the locations in which a complete set of payment data is persisted.
- Furthermore, in at least one embodiment, dividing the payment data into proper subsets and distributing the subsets among multiple data processing systems facilitates a number of ecommerce system configurations that can, in at least one embodiment, not only enhance payment data security, but can also allow merchants to accept electronic payment without the merchant server system coming within the scope of information security standards such as the payment card industry data security standard (PCI DSS). If a data processing system does not fall within the scope of the information security standard, the data processing system does not need to incur the expense of complying with the standard.
- Ecommerce
system 200 includes aclient computer system 202 that engages in an ecommerce transaction with a merchant data processing system 204 via thenetwork 206. In at least one embodiment, theecommerce system 200 divides payment data into proper payment data subsets to, for example, enhance security and minimize the number of data processing systems that fall within the scope of PCI DSS requirements. Additionally, theecommerce system 200 can be configured in any of a number of ways to divide and combine the payment data. - The
network 206 can be any type of network, such as the Internet. In at least one embodiment, theclient computer system 202 is a computer system that includes a web browser software application (not shown) such as the web browser application 104 (FIG. 1 ) to allow a user of theclient computer system 202 to receive and transmit data with a merchant data processing system via thenetwork 206. The merchant data processing system is, in at least one embodiment, one of the data processing systems 204.0-204.N or can be another data processing system suchdata processing system 208. Thenetwork 206 can be any type of network such as, for example, the Internet. - The data processing systems 204.0-204.N are each part of a separate network in that, for example, each data processing system 204.0-204.N has independent and distinct access requirements. In at least one embodiment, firewalls 214.0-214.N. Firewalls 214.0-214.N permit or deny network transmissions to data processing systems 204.0-204.N based upon a set of rules to, for example, protect the data processing systems 204.0-204.N from unauthorized access while permitting legitimate data to pass. Generally the
payment data 203 is encrypted and transmitted via a secure connection, such via a secure sockets layer. Providing thepayment data 203 can be in response to a request to purchase one or more products and/or services offered by one of the data processing systems 204.X ordata processing system 208. - The
ecommerce system 200 can be configured in any number of ways to divide payment data into proper subsets of data. For example, in at least one embodiment, theclient computer system 202 sendspayment data 203 through thenetwork 206, and N+1 data processing systems 204.0-204.N each store respective proper payment data subsets S0-SN of the payment data. A “proper subset” is a subset that contains less than all elements of a set. In mathematical terms, if A is a subset of S and A≠S, then A is called a proper subset of S. “N” is an integer that is greater than or equal to 1. (Although four (4) data processing systems 204.X are actually depicted inFIG. 2 , the number of data processing systems can range from 2 to N. “X” represents the ith data processing system, and i is an element of the set {0, . . . , N}). In at least one embodiment, theclient computer system 202 divides thepayment data 208 into the proper payment data subsets S0-SN, and thepayment data 203 represents the proper payment data subsets S0-SN. In at least one embodiment, thepayment data 203 is a complete set, and one of the data processing systems 204.X, such as data processing system 204.0, divides theaggregate payment data 203 into the proper payment data subsets S0-SN. Data processing systems 204.0-204.N store the respective proper payment data subsets S0-SN in respective memories 212.0-212.N. - The
ecommerce system 200 can also be configured in multiple ways to combine the payment data and obtain a payment authorization response. In at least one embodiment, to request payment authorization, the data processing system 204.X or 208 functioning as a merchant data processing system requests at least one of the other data processing systems 204.0-204.N to proceed with payment authorization. In at least one embodiment, when a single data processing system 204.X receives the payment authorization request, the data processing system 204.X receives all of the payment data subsets S0-SN, combines the payment data subsets S0-SN into a single, complete payment data set, and sends the complete payment data set to thepayment authorization system 216 for payment authorization processing. In at least one embodiment,payment authorization system 216 is identical to payment authorization system 116 (FIG. 1 ). In another embodiment, the data processing system 204.X or 208 functioning as a merchant data processing system requests the other data processing systems 204.0-204.N to send the payment data subsets S0-SN to thepayment authorization system 216. Thepayment authorization system 216 then combines the payment data subsets S0-SN into a single, complete payment data set and proceeds with the payment authorization processing. - The
payment data 203 can be divided into proper subsets of payment data subsets S0-SN in any number of ways. For example, thepayment data 203 includes a set of elements that represent values in a payment form presented to a user of theclient computer system 202. Exemplary payment data for a credit card holder (also referred to as a “cardholder”) includes a cardholder name, a cardholder billing address, a credit card number, credit card security code, credit card expiration month, and credit card expiration year. Other payment data can includes a credit card issue month and a card issue year. Assuming that N equals 1, thepayment data 203 is bifurcated into two proper payment data subsets S0 and S1 as depicted in Table 1. -
TABLE 1 Payment Data Subset S0 Payment Data Subset S1 [Billing Address] [Expiration Month] [Cardholder Name] [Expiration Year] [Last 4 digits of card number] [All digits in card number except last 4] [Security Code] [Issue month] [Issue Year]
Brackets “[. . . ]” are used in Table 1 to indicate that the bracketed item is a value. Note also that the elements themselves can be subdivided. For example, the credit card number is an element and is subdivided into the last 4 digits in the proper payment data set 204.0 and the remaining digits in the proper data subset S1. - The payment data subsets S0-SN are proper data subsets since neither of the payment data subsets S0-SN contain all of the
payment data 203. Additionally, the payment data subsets S0-SN can be disjoint or non-disjoint. Regarding the division of data and subdivision of elements, in mathematical terms, Payment Data={E0, E1, . . . , EM}={S0, S1, . . . , SN}, and E1={e0, e1, . . . , eT}, Sy is selected from the set Ei for all i and T. Ei is an element representing an ith element of the payment data. ex is the Xth sub-element of an element Ei. Sy is the yth subset of one or more elements and/or portions of elements of thepayment data 203. - The PCI DSS applies to a data processing system when the data processing system has access to a complete set of
payment data 203. However, since less than all of the data processing systems 204.0-204.N have access to the combined payment data, the number of data processing systems 204.0-204.N within the compliance scope of PCI DSS is reduced. In at least one embodiment, only one data processing system 204.X has access to the complete set of payment data, only one data processing system 204.X maintains PCI DSS compliance. In at least one embodiment, the data processing system 204.X that maintains PCI DSS compliance can respond to payment requests, combine payment data subsets S0-SN, and send the combined payment data to thepayment authorization system 216. In at least one embodiment, data processing system 204.X momentarily combines the payment data subsets S0-SN, thereby minimizing security risks associated with payment data misappropriation. Thus, the data processing system 204.X that maintains PCI DSS compliance can offer PCI DSS compliance as a service to other data processing systems while minimizing exposure of the payment data to misappropriation. -
FIG. 3 depicts anecommerce system 300, which represents one embodiment of theecommerce system 200.FIG. 4 depicts a payment data division, aggregation, andpayment authorization process 400. In at least one embodiment, theecommerce system 300 operates in accordance with the payment data division, aggregation, andpayment authorization process 400. - The
ecommerce system 300 includes aclient computer system 302 that represents one embodiment of theclient computer system 202. Theecommerce system 300 also includes N data processing systems DPS0— 3-DPSN— 3, which represent respective embodiments of data processing systems 204.0-204.N. N is an integer greater than or equal to 1. In at least one embodiment, theclient computer system 302 and data processing systems DPS0— 3-DPSN— 3 are interconnected via a network such as the network 206 (FIG. 2 ). Each of the data processing systems DPS0— 3-DPSN— 3 includes a firewall (depicted as the outer perimeter) so that each of the data processing systems DPS0— 3-DPSN— 3 is a separate system. - Referring to
FIGS. 3 and 4 ,client computer system 302 includes apayment data divider 304 to read payment data and divide payment data into proper subsets of payment data S0-SN. The particular implementation of thepayment data divider 304 is a matter of design choice. Thepayment data divider 304 can be implemented using, for example, hardware and/or software that can perform hypertext transport protocol (HTTP) functions. In at least one embodiment, thepayment data divider 304 is implemented as JavaScript, Visual Basic script, and/or Flash. In at least one embodiment, inoperation 446, one of the data processing systems, data processing system DPSX, provides payment data divider 304 to theclient computer system 302 for installation in theclient computer system 302. The entity and manner of providing thepayment data divider 304 to theclient computer system 302 is a matter of design choice. In at least one embodiment, the data processing system DPSX is a third party data processing system that facilitates obtaining payment authorization for a merchant.Operation 446 is depicted in dotted lines because, in at least one embodiment, thepayment data divider 304 is installed in theclient computer system 302 as part of theweb browser 306 or is included by a manufacturer of theclient computer system 302. - In at least one embodiment, the data processing system DPSN
— 3 represents a merchant server system (indicated by the “(MERCHANT)”) that provides one ormore web pages 303 to theclient computer system 302. Inoperation 448, the merchant data processing system DPSN— 3 provides one ormore web pages 303 to theclient computer system 302. Inoperation 401, theweb browser application 306 of theclient computer system 302 renders the web page(s) 303 for display to and review by a user of theclient computer system 302. In at least one embodiment, the web page(s) include data to display products, such as goods or services, offered by the merchant data processing system DPSN— 3. The user of theclient computer system 302 may then decide to enter into a commercial transaction with the merchant for one or more products offered in one or more of theweb pages 303 and, inoperation 403, initiate a checkout process.Operation 403 is depicted using dotted lines because, as subsequently explained in more detail, in some embodiments, thepayment data 305 is divided and transmitted in anticipation of a future commercial transaction rather than in response to a present commercial transaction. - Assuming that the customer and merchant are engaged in a commercial transaction, the customer continues with the check out process in accordance with a checkout process established by the merchant data processing system DPSX. For example, in at least one embodiment, the user initiates a ‘buy’ request via the
web browser 306, and the web browser forwards the ‘buy’ request to the merchant data processing system DPSX. Inoperation 405, at least one of theweb pages 303 includes a payment form, such as a data entry form or shopping cart, which, inoperation 405, allows theclient computer system 302 to obtainpayment data 305 from the user or from previously stored data for the purchase of one or more products. In at least one embodiment, inoperation 450, the merchant data processing system DPSN— 3 also sendsmerchant transaction data 301 to associate the merchant with thepayment data 305. The particular content of themerchant transaction data 301 is a matter of design choice. In at least one embodiment, themerchant transaction data 301 includes a merchant identifier, transaction identifier, and a token to associate thepayment data 305 with the particular transaction for which thepayment data 305 applies. The token allows theclient computer system 302 to encrypt thepayment data 305. In at least one embodiment, thepayment data divider 304 has no ability to store and/or distribute all or part of the payment data subsets S0-SN without authorization by the user. - The particular event or events that prompt dividing the
payment data 305 into the proper subsets of payment data S0-SN is a matter of design choice. In at least one embodiment, inoperation 403, theclient computer system 302 divides the subsets of payment data S0-SN in anticipation of a future commercial transaction with a merchant server system, such as data processing system DPSN— 3. In at least one embodiment, inoperation 403, theclient computer system 302 divides the subsets of payment data S0-SN for completion of a financial component of the present commercial transaction with the data processing system DPSX. - In
operation 407, after obtaining the payment data and upon receipt of an authorization command, such as a ‘buy’ or ‘purchase’ command, thepayment data divider 304 divides thepayment data 305 into the N+1 payment data subsets S0-SN prior to distributing the payment data subsets S0-SN. An embodiment ofoperation 407 can be implemented using the following pseudocode: -
- read values from the payment form fields, such as credit card number, expiration month, expiration year, security code, billing address, cardholder name and issue month and year (if applicable); and
- parse the payment form fields and divide the
payment data 305 into the payment data subsets S0-SN.
- In at least one embodiment, the
payment data divider 304 includes parsing and division rules that determine how thepayment data 305 will be allocated to payment data subsets S0-SN. The particular rules are a matter of design choice. In at least one embodiment, thepayment data divider 304 specifies how to divide and allocate thepayment data 305 into the payment data subsets S0-SN. In at least one embodiment, the value of N is 1, and thepayment data divider 304 bifurcates thepayment data 305 into two payment data subsets S0 and S1 as, for example, presented in Table 1. - After dividing the
payment data 305 into the payment data subsets S0-SN, inoperation 409, thepayment data divider 304 distributes the payment data subsets S0-SN among the data processing systems DPS0— 3-DPSN— 3. In at least one embodiment, each payment data subset S0-SN includes transaction identification data. The transaction identification data associates each of the payment data subsets S0-SN with a particular transaction. In at least one embodiment, the transaction identification data includes data to identify the particular transaction and an identifier of the merchant from which the products are being obtained. When thepayment data divider 304 distributes the payment data subsets S0-SN “among” the data processing systems DPS0— 3-DPSN— 3, each data processing systems DPS0— 3-DPSN— 3 receives only part of the payment data subsets S0-SN. In at least one embodiment, thepayment data divider 304 utilizes asynchronous JavaScript and XML (AJAX) technology to distribute the payment data subsets S0-SN to the data processing systems DPS0— 3-DPSN— 3. Additionally, in at least one embodiment, thepayment divider 304 also includes themerchant transaction data 301, or at least a merchant identifier, as part of each of the payment data subsets S0-SN. - In
operation 454, each of the data processing systems DPS0— 3-DPSN— 3 receives a payment data subset. In at least one embodiment, data processing system DPSX receives payment data subset SX. In at least one embodiment, to protect the data payment subsets S0-SN from fraudulent use, each of data processing systems DPS0— 3-DPSN— 3 encrypts and stores one of the respective payment data subsets S0-SN including themerchant transaction data 301 and a user identifier. - In at least one embodiment, the data processing systems DPS0
— 3-DPSN— 3 do not have the ability to return any or all of the payment data subsets S0-SN to theclient computer system 302. Thus, in at least one embodiment the number of times the payment data subsets S0-SN are transmitted is minimized. - In operation 456, at least one, and preferably only one, of the data processing systems DPS0
— 3-DPSN— 3 sends merchant credentials to thepayment authorization system 308 in order to obtain apayment authorization response 312. In at least one embodiment, the merchant credentials include an identifier that identifies the merchant to at least a payment gateway of thepayment authorization system 308. A payment gateway is typically a system that interacts with a payment processor of a bank used by the merchant. The merchant credentials may also include information, such as a password, used to access thepayment authorization system 308. In at least one embodiment, thepayment authorization system 308 can be any payment authorization system that, for examples, electronically authorizes payment. In at least one embodiment, thepayment authorization system 308 is identical to the payment authorization system 116 (FIG. 1 ). -
Operation 460 aggregates the payment data subsets S0-SN into an aggregatedpayment data set 310. The particular system that aggregates the payment data subsets S0-SN into thepayment data set 310 is a matter of design choice. In at least one embodiment, one of the data processing systems DPS0— 3-DPSN— 3 aggregates the payment data subsets S0. In at least one embodiment, thepayment authorization system 308 aggregates the payment data subsets S0-SN into thepayment data set 310. In at least one embodiment, the system that aggregates the payment data subsets S0-SN into thepayment data set 310 comes within the scope of the PCI DSS. However, in at least one embodiment, the other data processing systems that do not have access to thecomplete payment data 310 are not within the scope of the PCI DSS and, thus, do not incur the costs associates with PCI DSS compliance. - In
operation 462, one of the data processing systems DPS0— 3-DPSN— 3 sends a payment authorization request to thepayment authorization system 308. The payment authorization request includes the complete payment data subsets S0-S1, either combined, if aggregated by one of the data processing systems DPS0— 3-DPSN— 3, or separate, if aggregated by thepayment authorization system 308. In at least one embodiment, the payment authorization request also includes the merchant credentials, a transaction amount and currency, and a reference identifier for the merchant, if desired. In at least one embodiment, the payment authorization request is sent using a secure transmission, such as using the HTTPS protocol. - In operation 464, the
payment authorization system 308 and at least one of the data processing systems DPS0— 3-DPSN— 3 receives thepayment authorization response 312. In at least one embodiment, upon successful authorization, for security if one of the data processing systems DPS0— 3-DPSN— 3 has thecomplete payment data 310, the data processing system destroys at least part of thepayment data 310, such as the payment data subset.1 in Table 1. - In operation 416, a request by one of the data processing systems DPS0
— 3-DPSN— 3 is made to thepayment authorization system 308 to capture the authorized funds to complete the financial component of the commercial transaction. - Embodiments of the payment data division, aggregation, and
payment authorization process 400 can also be implemented by a variety of ecommerce system embodiments. The following description includes several exemplary ecommerce system embodiments. It will be understood that other ecommerce systems can also implement the payment data division, aggregation, andpayment authorization process 400 and variations thereof. -
FIG. 5 depictsecommerce system 500, which represents one embodiment ofecommerce system 300. The data processing system DPSN— 5 represents a merchant data processing system, and theclient computer system 302 and the merchant data processing system DPSN— 5 conduct a commercial transaction as, for example, described in conjunction withecommerce system 300. Inecommerce system 500, thepayment divider 304 divides thepayment data 305 into the payment data subsets S0-S1, encrypts the payment data subsets S0-S1, and distributes the data payment subsets S0-S1 among the data processing systems DPS0— 5-DPSN— 5. - In at least one embodiment,
ecommerce system 500 performs operations 401-409 and 446-454 as previously described. Data processing system DPS0— 5 includes adata aggregator 502 that aggregates all of the payment data subsets S0-S1. When the merchant data processing system DPSN— 5 is ready to proceed with payment authorization, merchant data processing system DPSN— 5 authenticates with data processing system DPS0— 5 and sends payment data subset SN including merchant transaction data to data processing system DPS0— 5 with a request to obtain payment authorization frompayment authorization system 504 for the transaction identified by the merchant transaction data. The merchant data processing system DPSN— 5 also sends a request to all other data processing system DPS1— 5-DPSN-1— 5 to send payment data subsets S1-SN-1 and merchant transaction data to data processing system DPS0— 5. - Since the data processing systems DPS1
— 5-DPSN— 5 only receive respective proper payment data subsets S0-SN, none of the data processing systems DPS1— 5-DPSN— 5 have access to all of thepayment data 305. Accordingly, in at least one embodiment, data processing systems DPS1— 5-DPSN— 5 are outside the scope of PCI DSS, do not need to comply with PCI DSS standards, and, therefore, save costs associated with PCI DSS implementation and compliance. - The data aggregator 502 decrypts and aggregates (i.e. combines) the payment data subsets S0-SN into a complete set of payment data. The particular aggregation process of
data aggregator 502 is a matter of design choice. In at least one embodiment, thedata aggregator 502 performs a reverse process of payment data divider 304 to reassemble the payment data subsets intopayment data 305. In at least one embodiment, thedata aggregator 502 aggregates the payment data into a format specified by thepayment authorization system 504. - In at least one embodiment, the data processing system DPS0
— 5 processes the merchant transaction data to determine payment gateway account information for the merchant. The data processing system DPS0— 5 then sends the combined payment data, merchant data, and an authorization request 506 to thepayment authorization system 504 in accordance with the payment gateway account information for the merchant. In at least one embodiment, the merchant data identifies the merchant with a merchant identifier, identifies the transaction with a transaction identifier, and provides merchant account credentials to access thepayment authorization system 504. In at least one embodiment, the data 506 also includes a token to be used by thepayment authorization system 504 to decrypt the data 506. - Once the
payment authorization system 504 receives the data 506, payment authorization system 506 processes the data 506 and generates thepayment authorization response 312 as previously described. -
FIG. 6 depictsecommerce system 600, which represents one embodiment ofecommerce system 500.Ecommerce system 500 bifurcates thepayment data 305 into proper payment data subsets S0 and S1 and distributes the bifurcated payment data subsets to respective data processing system DPS0— 6 and merchant data processing system DPS1— 6. In at least one embodiment, thepayment data 305 is bifurcated as depicted in Table 1.Ecommerce system 600 functions identically toecommerce system 500 for N=1, except that, in the absence of other data processing systems, the merchant data processing system DPS1 does not request any other data processing systems to send payment data subsets to data processing system DPS0— 6. -
FIG. 7 depictsecommerce system 700, which represents one embodiment ofecommerce system 300. In at least one embodiment,ecommerce system 700 performs operations 401-409 and 446-454 of payment data division, aggregation, andpayment authorization process 400 as previously described. After the data processing system DPS0— 7-DPSN— 7 receive respective payment data subsets S0-S1, the data processing system DPSN— 7 sends apayment authorization request 702 to thepayment authorization system 704 and sends a request to the data processing systems data processing system DPS0— 7-DPSN— 7 directly data processing system DPS0— 7-DPSN— 7 to send respective payment data subsets S0-SN-1 topayment authorization system 704.Payment authorization system 704 includesdata aggregator 706, which combines the payment data subsets S0-S1 to complete payment authorization. In at least one embodiment, thedata aggregator 704 combines the payment data subsets S0-SN as described in conjunction with thedata aggregator 502. Once thepayment authorization system 704 aggregates the payment data subsets S0-SN, payment authorization system 506 processes the aggregated data and generates thepayment authorization response 312 as previously described. -
FIG. 8 depictsecommerce system 800, which represents one embodiment ofecommerce system 300. In at least one embodiment,ecommerce system 800 functions identically toecommerce system 700 except that thedata aggregator 802 is part of a computer system separate from thepayment authorization system 504. In at least one embodiment, thedata aggregator 802 combines the payment data subsets S0-SN as described in conjunction with thedata aggregator 502. -
FIG. 9 depicts ecommerce system 900, which represents one embodiment ofecommerce system 300. The payment data division, aggregation, andpayment authorization process 400 operations 401-405 and 446-449 function as previously described. In ecommerce system 900, theclient computer system 902 provides thecomplete payment data 305 to data processing system DPS0—9 . The data processing system DPS0— 9 system includes adata divider 906.Data divider 906 divides thepayment data 305 into proper payment data subsets S0-SN as, for example, described with respect topayment data divider 304. Data processing system DPS0 then distributes the proper data subsets S1-SN, along with data to identify at least the transaction associated with the payment data subsets S1-SN, to data processing systems S1-SN. - The
payment data 305 can be sent to thepayment authorization system 908 in any number of ways. For example, in at least one embodiment, data processing system DPS0— 9 recombines the payment data subsets S0-S1 and sends the complete data set topayment authorization system 908 for processing, as described in conjunction withecommerce system 500. In at least one embodiment, each of the data processing systems DPS0— 9-DPSN— 9 sends the payment data subsets S0-SN to either a separate payment aggregator or to thepayment authorization system 908 as respectively described in conjunction withecommerce systems payment authorization system 908 then generates thepayment authorization response 312 as previously described. - Thus, in at least one embodiment of an ecommerce system, payment data from a client computer system is divided into proper subsets and distributed among multiple data processing systems, and each of the data processing systems stores less than all of the subsets of the payment data after the subsets of payment data are distributed and until at least sending the payment data to a payment authorization system for processing.
- The client computer systems and data processing systems described herein can be completely hardware implemented using, for example, an application specific integrated circuit(s) implemented using, for example, field programmable gate arrays or other logic circuits. The client computer system and data processing systems can also be implemented using a combination of software and hardware. For example, the client computer system and data processing system can also be implemented as a specifically configured computer system that can perform the processes discussed herein, such as payment data division, aggregation, and
payment authorization process 400. -
FIG. 10 depicts anexemplary computer system 1000, which can represent data processing systems and the client computer systems described herein. The processes discussed herein can also be implemented as code stored in a non-transitory, tangible computer programmable medium and executable by a general purpose or application specific computing system. Examples of a non-transitory, tangible computer programmable medium include hard-drive memories, solid state memories, such as flash memories, compact disks, and digital versatile disks. - Referring to
computer system 1000, input user device(s) 1010, such as a keyboard and/or mouse, are coupled to abi-directional system bus 1018. The input user device(s) 1010 are for introducing user input to thecomputer system 1000 and communicating that user input toprocessor 1013. The computer system ofFIG. 10 generally also includes avideo memory 1014,main memory 1015 andmass storage 1009, all coupled tobi-directional system bus 1018 along with input user device(s) 1010 andprocessor 1013. Themass storage 1009 may include both fixed and removable media, such as other available mass storage technology.Bus 1018 may contain, for example, 32 or 64 address lines for addressingvideo memory 1014 ormain memory 1015. Thesystem bus 1018 also includes, for example, an n-bit data bus for transferring DATA between and among the components, such asCPU 1009,main memory 1015,video memory 1014 andmass storage 1009, where “n” is, for example, 32 or 64. Alternatively, multiplex data/address lines may be used instead of separate data and address lines. - I/O device(s) 1019 may provide connections to peripheral devices, such as a printer, and may also provide a direct connection to a remote computer system via a telephone link or to the Internet via an ISP. I/O device(s) 1019 may also include a network interface device to provide a direct connection to remote server computer systems via a direct network link to the Internet via a POP (point of presence). Such connection may be made using, for example, wireless techniques, including digital cellular telephone connection, Cellular Digital Packet Data (CDPD) connection, digital satellite data connection or the like. Examples of I/O devices include modems, sound and video devices, and specialized communication devices such as the aforementioned network interface.
- Computer programs and data are generally stored as instructions and data in
mass storage 1009 until loaded intomain memory 1015 for execution. Computer programs may also be in the form of electronic signals modulated in accordance with the computer program and data communication technology when transferred via a network.Mass storage 1009 andmain memory 1015 both are forms of non-transitory storage devices on which executable code can be stored that, when executed by theprocessor 1013, causes the processor to perform one or more or all of the functions described herein. - The
processor 1013, in one embodiment, is a microprocessor manufactured by Motorola Inc. of Illinois, Intel Corporation of California, or Advanced Micro Devices of California. However, any other suitable single or multiple microprocessors or microcomputers may be utilized.Main memory 1015 is comprised of dynamic random access memory (DRAM).Video memory 1014 is a dual-ported video random access memory. One port of thevideo memory 1014 is coupled tovideo amplifier 1016. Thevideo amplifier 1016 is used to drive thedisplay 1017.Video amplifier 1016 is well known in the art and may be implemented by any suitable means. This circuitry converts pixel DATA stored invideo memory 1014 to a raster signal suitable for use bydisplay 1017.Display 1017 is a type of monitor suitable for displaying graphic images. Thecomputer system 1000 described above is for purposes of example only. - The above discussion is meant to be illustrative of the principles and various embodiments of the present invention. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.
Claims (21)
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/558,198 US20130054462A1 (en) | 2011-08-24 | 2012-07-25 | Ecommerce system with payment data division |
US13/737,476 US8589307B2 (en) | 2011-08-24 | 2013-01-09 | Ecommerce system with payment data division |
US14/014,136 US20130346315A1 (en) | 2011-08-24 | 2013-08-29 | Ecommerce system with payment data division |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201161526971P | 2011-08-24 | 2011-08-24 | |
US13/558,198 US20130054462A1 (en) | 2011-08-24 | 2012-07-25 | Ecommerce system with payment data division |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/737,476 Continuation US8589307B2 (en) | 2011-08-24 | 2013-01-09 | Ecommerce system with payment data division |
Publications (1)
Publication Number | Publication Date |
---|---|
US20130054462A1 true US20130054462A1 (en) | 2013-02-28 |
Family
ID=47745044
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/558,198 Abandoned US20130054462A1 (en) | 2011-08-24 | 2012-07-25 | Ecommerce system with payment data division |
US13/737,476 Active US8589307B2 (en) | 2011-08-24 | 2013-01-09 | Ecommerce system with payment data division |
US14/014,136 Abandoned US20130346315A1 (en) | 2011-08-24 | 2013-08-29 | Ecommerce system with payment data division |
Family Applications After (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US13/737,476 Active US8589307B2 (en) | 2011-08-24 | 2013-01-09 | Ecommerce system with payment data division |
US14/014,136 Abandoned US20130346315A1 (en) | 2011-08-24 | 2013-08-29 | Ecommerce system with payment data division |
Country Status (1)
Country | Link |
---|---|
US (3) | US20130054462A1 (en) |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140149263A1 (en) * | 2012-11-27 | 2014-05-29 | Mashinery Pty Ltd. | Data Assembly, Transfer and Storage |
US20150206137A1 (en) * | 2014-01-22 | 2015-07-23 | PayWithMyBank, Inc. | Secure method to store sensitive data |
US20170076285A1 (en) * | 2014-05-07 | 2017-03-16 | Huawei Technologies Co., Ltd. | Payment Method and Apparatus and Payment Factor Processing Method and Apparatus |
US20190108520A1 (en) * | 2017-10-06 | 2019-04-11 | Mastercard International Incorporated | Distribution systems and related methods |
CN112507379A (en) * | 2020-12-17 | 2021-03-16 | 陈桂波 | High-security electronic commerce system based on block chain |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013185348A1 (en) * | 2012-06-15 | 2013-12-19 | 华为技术有限公司 | Method and device for processing charging data |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080010196A1 (en) * | 2006-07-06 | 2008-01-10 | Firethorn Holdings, Llc | Methods and Systems For Viewing Aggregated Payment Obligations in a Mobile Environment |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5878141A (en) * | 1995-08-25 | 1999-03-02 | Microsoft Corporation | Computerized purchasing system and method for mediating purchase transactions over an interactive network |
US6286098B1 (en) * | 1998-08-28 | 2001-09-04 | Sap Aktiengesellschaft | System and method for encrypting audit information in network applications |
US6938022B1 (en) * | 1999-06-12 | 2005-08-30 | Tara C. Singhal | Method and apparatus for facilitating an anonymous information system and anonymous service transactions |
-
2012
- 2012-07-25 US US13/558,198 patent/US20130054462A1/en not_active Abandoned
-
2013
- 2013-01-09 US US13/737,476 patent/US8589307B2/en active Active
- 2013-08-29 US US14/014,136 patent/US20130346315A1/en not_active Abandoned
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080010196A1 (en) * | 2006-07-06 | 2008-01-10 | Firethorn Holdings, Llc | Methods and Systems For Viewing Aggregated Payment Obligations in a Mobile Environment |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140149263A1 (en) * | 2012-11-27 | 2014-05-29 | Mashinery Pty Ltd. | Data Assembly, Transfer and Storage |
US20150206137A1 (en) * | 2014-01-22 | 2015-07-23 | PayWithMyBank, Inc. | Secure method to store sensitive data |
US20170076285A1 (en) * | 2014-05-07 | 2017-03-16 | Huawei Technologies Co., Ltd. | Payment Method and Apparatus and Payment Factor Processing Method and Apparatus |
EP3133544A4 (en) * | 2014-05-07 | 2017-04-19 | Huawei Technologies Co. Ltd. | Payment method and device and payment factor processing method and device |
US20190108520A1 (en) * | 2017-10-06 | 2019-04-11 | Mastercard International Incorporated | Distribution systems and related methods |
CN112507379A (en) * | 2020-12-17 | 2021-03-16 | 陈桂波 | High-security electronic commerce system based on block chain |
Also Published As
Publication number | Publication date |
---|---|
US8589307B2 (en) | 2013-11-19 |
US20130346315A1 (en) | 2013-12-26 |
US20130124418A1 (en) | 2013-05-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11373156B2 (en) | Method, system, and computer readable storage medium for alternative email-based website checkouts | |
AU2017200988B2 (en) | Payment device with integrated chip | |
AU2015259162B2 (en) | Master applet for secure remote payment processing | |
US8150767B2 (en) | System and method for conducting electronic commerce with a remote wallet server | |
US8589307B2 (en) | Ecommerce system with payment data division | |
US9349127B2 (en) | Serial number and payment data based payment card processing | |
US11843585B2 (en) | Systems and method for providing a data security service | |
US20140108172A1 (en) | Dynamic point of sale system integrated with reader device | |
US11694182B2 (en) | Systems and methods for displaying payment device specific functions | |
US20020042776A1 (en) | System and method for unifying electronic payment mechanisms | |
US11716200B2 (en) | Techniques for performing secure operations | |
US20220191013A1 (en) | Techniques For Secure Channel Communications | |
US20210390546A1 (en) | Systems and Methods for Secure Transaction Processing | |
TWI787666B (en) | System and method for converting financial transaction API specification | |
US20230308278A1 (en) | Tokenizing transactions using supplemental data | |
Arnab et al. | Using payment gateways to maintain privacy in secure electronic transactions | |
WO2022040762A1 (en) | Electronic payments systems, methods and apparatus |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: VOLUSION, INC., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SPROLES, KEVIN;WALLIS, JASON;WOOSLEY, JASON;REEL/FRAME:028740/0545 Effective date: 20120726 |
|
AS | Assignment |
Owner name: SILICON VALLEY BANK, CALIFORNIA Free format text: SECURITY AGREEMENT;ASSIGNOR:VOLUSION, INC.;REEL/FRAME:031891/0144 Effective date: 20131230 |
|
AS | Assignment |
Owner name: SILICON VALLEY BANK, TEXAS Free format text: SECURITY AGREEMENT;ASSIGNOR:VOLUSION, INC.;REEL/FRAME:031893/0001 Effective date: 20131230 |
|
AS | Assignment |
Owner name: MAIN STREET CAPITAL CORPORATION, TEXAS Free format text: AMENDED AND RESTATED INTELLECTUAL PROPERTY SECURITY AGREEMENT;ASSIGNOR:VOLUSION, LLC;REEL/FRAME:040680/0529 Effective date: 20161123 |
|
AS | Assignment |
Owner name: VOLUSION, LLC, TEXAS Free format text: CHANGE OF NAME;ASSIGNOR:VOLUSION, INC.;REEL/FRAME:045760/0397 Effective date: 20150126 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |