EP2852929A2 - Eco advantage mediation apparatuses, methods and systems - Google Patents

Abstract

The ECO ADVANTAGE MEDIATION APPARATUSES, METHODS AND SYSTEMS ("ECO ADVANTAGE") transforms user and account holder data inputs into eco and region analytics outputs. In some implementations, ECO ADVANTAGE receive a request for a user's eco balance and a account holder's current eco schedule from a account holder, receive an eco allocation confirmation indicating an allocation has been successfully processed and eco data, debit from a user's account an amount of ecos received from another account holder in a previous exchange for use in the allocation, credit to the user's account an amount of ecos based on the eco data, and store eco data in a eco record.

Description

1 ECO ADVANTAG E M EDIATION APPARATUSES, M ETHODS

2 AN D SYSTEMS

3 [ o o o l ] This application for letters patent disclosure document describes inventive

4 aspects that include various novel innovations (hereinafter "disclosure") and contains

5 material that is subject to copyright, mask work, and/or other intellectual property

6 protection. The respective owners of such intellectual property have no objection to the

7 facsimile reproduction of the disclosure by anyone as it appears in published Patent

8 Office file/records, but otherwise reserve all rights.

9 PRIORITY CLAI M

10 [0002] Applicant hereby claims priority to U.S. Patent Application Serial No.

11 13/842,593, filed March 15, 2013 and entitled "ECO ADVANTAGE MEDIATION

12 APPARATUSES, METHODS AND SYSTEMS," attorney docket no. MORE-

13 001/ooUS 1318827-2001, which in turn claims priority to Patent Cooperation Treaty

14 patent application serial no. PCT/BR2012/000148, filed May 21, 2012, entitled

15 "SISTEMA DE INTERMEDIACAO MUTUA DE VANTAGENS," attorney docket no.

16 P200015.

17 [0003] The entire contents of the aforementioned applications are herein is expressly incorporated by reference.

9 FI ELD

20 [0004] The present innovations generally address exchanging purchase benefits,

21 and more particularly, include ECO ADVANTAGE MEDIATION APPARATUSES,

22 METHODS AND SYSTEMS. [ 0005 ] However, in order to develop a reader's understanding of the innovations, disclosures have been compiled into a single description to illustrate and clarify how aspects of these innovations operate independently, interoperate as between individual innovations, and/or cooperate collectively. The application goes on to further describe the interrelations and synergies as between the various innovations; all of which is to further compliance with 35 U.S.C. §112.

BACKG ROU N D

[ 0006 ] Merchants can provide coupons or discounts to products in order to sell more stock. Coupons and discounts can be of a particular merchant-specified value.

BRI EF DESCRI PTION OF TH E DRAWI NGS [ 0007] The accompanying appendices and/or drawings illustrate various non- limiting, example, innovative aspects in accordance with the present descriptions: [ 0008 ] FIGURE la shows a block diagram illustrating example embodiments of the ECO ADVANTAGE; [ 0009 ] FIGURE lb shows a block diagram illustrating example embodiments of the ECO ADVANTAGE; [ 0010 ] FIGURE 2a shows a data flow diagram illustrating performing a transaction in example embodiments of the ECO ADVANTAGE; [ 0011] FIGURE 2b shows a logic flow diagram illustrating performing a transaction in example embodiments of the ECO ADVANTAGE; [ 0012 ] FIGURE 2c shows a data flow diagram illustrating performing an online transaction in example embodiments of the ECO ADVANTAGE; [ 0013 ] FIGURE 2d shows a logic flow diagram illustrating performing an online transaction in example embodiments of the ECO ADVANTAGE; [ 0014] FIGURE 3a shows a data flow diagram illustrating performing a transaction without an ECO ADVANTAGE account in example embodiments of the ECO ADVANTAGE;

[ 0015 ] FIGURE 3b shows a logic flow diagram illustrating performing a transaction without an ECO ADVANTAGE account in example embodiments of the ECO ADVANTAGE;

[ 0016 ] FIGURE 4a shows a data flow diagram illustrating enrolling a merchant in example embodiments of the ECO ADVANTAGE;

[ 0017] FIGURES 4b-c show logic flow diagrams illustrating enrolling a merchant in example embodiments of the ECO ADVANTAGE;

[ 0018 ] FIGURE 5a shows a data flow diagram illustrating creating and updating regions and categories in example embodiments of the ECO ADVANTAGE;

[ 0019 ] FIGURES 5b-d show logic flow diagrams illustrating creating and updating regions and categories in example embodiments of the ECO ADVANTAGE;

[ 0020 ] FIGURES 6a-b show data flow diagrams illustrating friend invitations and donations in example embodiments of the ECO ADVANTAGE;

[ 0021] FIGURES 6c-d show logic flow diagrams illustrating friend invitations and donations in example embodiments of the ECO ADVANTAGE;

[ 0022 ] FIGURE 7a shows a data flow diagram illustrating slow commit, credit- only transactions in example embodiments of the ECO ADVANTAGE;

[ 0023 ] FIGURE 7b shows a logic flow diagram illustrating slow commit, credit- only transactions in example embodiments of the ECO ADVANTAGE;

[ 0024] FIGURE 8a shows a data flow diagram illustrating fast commit, credit- only transactions in example embodiments of the ECO ADVANTAGE;

[ 0025 ] FIGURE 8b shows a logic flow diagram illustrating fast commit, credit- only transactions in example embodiments of the ECO ADVANTAGE;

[ 0026 ] FIGURE 9a shows a data flow diagram illustrating merchant reconciliation in example embodiments of the ECO ADVANTAGE; [0027] FIGURE 9b shows a logic flow diagram illustrating merchant reconciliation in example embodiments of the ECO ADVANTAGE;

[0028] FIGURE 10a shows a data flow diagram illustrating slow commit, cash and credit transactions in example embodiments of the ECO ADVANTAGE;

[0029] FIGURES lob-c show logic flow diagrams illustrating slow commit, cash and credit transactions in example embodiments of the ECO ADVANTAGE;

[0030] FIGURE 11a shows a data flow diagram illustrating fast commit, cash and credit transaction in example embodiments of the ECO ADVANTAGE;

[0031] FIGURES nb-c show logic flow diagrams illustrating fast commit, cash and credit transactions in example embodiments of the ECO ADVANTAGE;

[0032] FIGURE 12a shows a data flow diagram illustrating fast commit, cash only transactions in example embodiments of the ECO ADVANTAGE;

[0033] FIGURE 12b shows a logic flow diagram illustrating fast commit, cash only transactions in example embodiments of the ECO ADVANTAGE;

[0034] FIGURE 13a shows a data flow diagram illustrating slow commit, cash only transactions in example embodiments of the ECO ADVANTAGE;

[0035] FIGURE 13b shows a logic flow diagram illustrating slow commit, cash only transactions in example embodiments of the ECO ADVANTAGE;

[0036] FIGURE 14a shows a data flow diagram illustrating merchant and partner transactions in example embodiments of the ECO ADVANTAGE;

[0037] FIGURES I4b-c show logic flow diagrams illustrating merchant and partner transactions in example embodiments of the ECO ADVANTAGE;

[0038] FIGURE 15a show a data flow diagram illustrating refunding or cancelling transactions in example embodiments of the ECO ADVANTAGE;

[0039] FIGURE 15b shows a logic flow diagram illustrating refunding or cancelling transactions in example embodiments of the ECO ADVANTAGE;

[0040] FIGURE 16 shows a table diagram illustrating using ECO ADVANTAGE for health insurance in example embodiments of the ECO ADVANTAGE; [ 0041] FIGURES I7a-b show screenshot diagrams illustrating enrolling a merchant in example embodiments of the ECO ADVANTAGE; [ 0042 ] FIGURE 18 shows a screenshot diagram illustrating creating a region in example embodiments of the ECO ADVANTAGE; [ 0043 ] FIGURE 19 shows a screenshot diagram illustrating creating categories in example embodiments of the ECO ADVANTAGE; [ 0044] FIGURES 2oa-b show screenshot diagrams illustrating donating ecos in example embodiments of the ECO ADVANTAGE; [ 0045 ] FIGURES 2ia-b show screenshot diagrams illustrating user profiles and eco balances in example embodiments of the ECO ADVANTAGE; [ 0046 ] FIGURES 22a-b show diagrams illustrating user navigation and check-in in example embodiments of the ECO ADVANTAGE; [ 0047] FIGURE 23 shows a block diagram illustrating embodiments of an ECO ADVANTAGE controller. [ 0048 ] The leading number of each reference number within the drawings indicates the figure in which that reference number is introduced and/or detailed. As such, a detailed discussion of reference number 101 would be found and/or introduced in Figure 1. Reference number 201 is introduced in Figure 2, etc.

1 DETAILED DESCRIPTION

2 ECO ADVANTAGE

3 [ 0049 ] FIGURE la shows a block diagram illustrating example embodiments of

4 the ECO ADVANTAGE. In some implementations, a consumer 101 may want to be able

5 to find an easy way to purchase inexpensive products and/or services without having to

6 handle a variety of discount program accounts, or without having to worry about a loss

7 in service quality due to the nature of the discount. A merchant 102 may also wish to

8 find more customers to serve, without having to create costly or complicating discounts,

9 and without having to risk a large amount of money on expensive marketing campaigns

10 with unpredictable returns. In some implementations, ECO ADVANTAGE 103 may

11 bring such merchants and consumers together in order to offer inexpensive products

12 and/or services to consumers, while increasing the number of consumers for the

13 merchant and while not requiring the merchant to invest in expensive marketing or

14 heavily discount their products. In some implementations ECO ADVANTAGE may bring

15 other benefits to merchants such as using installed capacity in a more equalized manner,

16 taking advantage of underused installed capacity, and fixed costs for growth without

17 capital investment. In some implementations ECO ADVANTAGE may enroll merchants is that provide goods, services or both.

19 [ 0050 ] FIGURE lb shows a block diagram illustrating example embodiments of

20 the ECO ADVANTAGE. In some implementations, a group of people in a party 104 may

21 wish to pay a bill 105 at a restaurant participating in ECO ADVANTAGE 107. One

22 person and/or couple in the party 106 may also be enrolled in ECO ADVANTAGE, and

23 may pay at least a part of the bill using a unit (e.g. transaction value modifiers, which

24 may include "ecos," value points, and/or the like) provided by ECO ADVANTAGE, and

25 may receive ecos for performing the transaction. The user may also be able to donate

26 108 ecos to the other members of the party, so that they may also enroll log in ECO

27 ADVANTAGE and use their ecos in subsequent transactions. [ 0051 ] In some implementations, ECO ADVANTAGE may also donate predetermined blocks of ecos to early adoption users in order to encourage them to invite friends to ECO ADVANTAGE. In some implementations, the donated ecos may only be used for donations to other potential users. [ 0052 ] In some implementations ECO ADVANTAGE may control how many ecos a user may utilize at a particular merchant based on the merchant capacity at particular times of day, particular days of the week, particular seasons and/or holidays during a year, total transaction amount, intended products and/or services, total transactions to date, total ecos to date, available capacity, growth potential and/or the like. In some implementations, for example, a user purchasing a meal during the day may be able to use a higher number of ecos (e.g. 30% of the transaction amount may be paid in ecos) at a merchant that does not have many customers during the day, and may be able to use a lower number of ecos (e.g. 15% of the transaction amount may be paid in ecos) at a merchant that has many customers during the day. [ 0053 ] In some implementations, once a user makes a purchase at a merchant, the user may earn ecos which may be utilized in subsequent transactions. For example, if a user buys a meal for $100, the user may receive some number of ecos during the transaction. In some implementations, the amount of ecos received may be equal to the amount the user pays out-of-pocket for a transaction. For example, if a user purchases a meal for $100 but uses 20 ecos to pay for part of the meal (thereby only paying $80 out- of-pocket for the meal), the user may receive 80 ecos from the transaction. In other implementations, the amount of ecos the user receives may be a percentage of the total transaction, a percentage of the amount the user pays out-of-pocket, a percentage according to merchant, a fixed amount, and/or the like. In some implementations, such limitations may be determined by the ECO ADVANTAGE or the merchant(s) involved, and/or a like entity. [ 0054 ] In some implementations, these ecos may not be used with the merchant from which they were issued. For example, a user may purchase a TV from Best Buy and receive 100 ecos from the transaction. In some implementations, these 100 ecos may be marked in an ECO ADVANTAGE Database as being from Best Buy, and in subsequent purchases at Best Buy, the user may not be able to use those 100 ecos for said purchases. The user, however, may be able to use the 100 ecos at other merchants for other purchases; for example, the user may be able to use the 100 ecos towards a transaction at Radio Shack, Whole Foods, and/or the like. In some implementations, the merchant(s) that the user may use the ecos with may not be in the same industry or category as the merchant from which the user received its ecos; for example, even though the user may have received its ecos from Best Buy, the user may not be restricted to using them at a similar electronics store, and/or the like. In some implementations the user may be able to spend the ecos at any other merchant other than Best Buy. [0055] In other implementations, the user may be restricted to the types of merchants that the ecos may be spent at. For example, in other implementations, a user who receives ecos from a Best Buy in New York City may not be able to spend the ecos in an area other than New York City, may not be able to spend the ecos at merchant of a different industry and/or category (e.g. electronics) than Best Buy, and/or the like. In some implementations, such limitations may be determined by the merchant, ECO ADVANTAGE, and/or a like entity. In some implementations, example industries and/or categories supported by ECO ADVANTAGE may include: Accessories, Advertising and Marketing, Animal Clinic and Hospital, Arts and Crafts, Auto Body Shop, Auto Dealer, Auto Electric Shop, Auto Parts Store, Bakery, Beauty Clinic, Book Wholesale, Bookstore, Building Supplies, Camera and Photo, Car-Wash, Ceilings/ Partition, Cell Phone Provider, Children's Store, Chocolate Shop, Clothing Repair, Coffee Shop, Computer and Accessories, Convenience Store, Cosmetics, Costume Shop, Courier Service, Dairy Products, Delicatessen, Diner, Do-It- Yourself Store, Durable Medical Equipment, DVD and Movies, Electrical Parts, Electronic and Video Game, Eletro/electronic Repair and Maintenance, Eyeglasses and Sunglasses, Fabric and Upholstery Store, Fast Graphic Service, Furniture Store, Gas Station, Gift Store, Gourmet and Specialty Food Store, Grocery Store, Gym, Hardware Store, Heating and Air Conditioning, Home and Gardening, Home and Kitchen Goods, Home Appliance, Home Improvement, Home Phone Provider, Hotels, Ice Cream Parlour, Janitorial / Cleaning Supplies, Jewelry, Kids Party Place, Kids Tutoring, Language School or Learning Center, Laundry and Dry Cleaning, Leisure and Tourism, Light Fixture, Lingerie and Intimate Apparel, Locksmith, Luggage and Suitcase Store, Men's Fashion, Motels, Motorcycle Dealer, Movie Theater, Moving Service, Musical Instrument Shop, Natural Food Store, Nautical Store, Nightclub / Disco, Office Supplies, Paint Store, Party Supply Store, Perfumery, Personal Development Course, Pet Shop, Pharmacy, Plastic Surgery, Refrigeration Shop, Restaurant (all kinds), Rotisserie, Rug and Curtain Shop, School, Shoe Repair, Shoe Store, SPA, Specialty Pharmacy, Sporting Goods, Sport Tickets, Supermarket, Surgical Equipment, Swimwear Fashion, Technical Course, Theaters, Tickets (ShowsConcerts), Toy Store, Travel Agency, Visual Communication, Winery, Women's Fashion, and/or the like. [0056 ] In some implementations, ecos may also have an expiration date, in which they are deactivated once the expiration date has passed. In some implementations, donating and/or otherwise regifting ecos that are about to expire may reset the expiration date of the ecos. [0057] In some implementations, the user may also receive bonus blocks from referring other consumers to ECO ADVANTAGE (see FIGS. 6a-d). In some implementations bonus blocks may be blocks of money paid to the user by ECO ADVANTAGE as a result of bringing new users to ECO ADVANTAGE, and may be used in conjunction with ecos towards a purchase at any participating merchant. For example, in addition to the 20 ecos paid towards the $100 Best Buy transaction, a user may be able to use a $20 bonus block towards the purchase, lowering the out-of-pocket cost further (e.g. to $60). In some implementations there may be a variety of different types of bonus blocks, such as invite bonus blocks (e.g. bonus blocks for inviting other users), merchant bonus blocks (e.g. bonus blocks issued by merchants), and/or the like. [0058 ] The term "place of business", as herein used, means all the different geographic and non-physical locations where or through which an associated merchant conducts transactions, including shops, department stores, medical clinics, restaurants, pet shops, beauty parlors, traveling agencies, offices, hospitals, cabs, retailers, distributors, producers, manufacturers, kiosks, shopping centers, fairs, shows, cruise ships, flea markets, public markets - and also catalogs, websites, any device with private network or internet access: computer, personal computer, network device, workstation computer, handheld computer, tablet, smart phone, mobile phone, voice phone, POS electronic terminal, smart TV, set-top box, and/or the like. [0059]

[0060] FIGURE 2a shows a data flow diagram illustrating performing a transaction in example embodiments of the ECO ADVANTAGE. In some implementations, a user 201 may interact with a merchant 202 via initiating a transaction for a product and/or service with the merchant 205. In some implementations, the user may initiate the transaction via the Point of Sales (PoS) device at the merchant location, via a merchant kiosk, via a personal electronic device (e.g. computer connected to a website, mobile device connected to an ECO ADVANTAGE application, and/or the like). In some implementations, the user may provide information to the merchant including the user's ID in ECO ADVANTAGE, the user's PIN (and/or a like form of authentication), and/or the like. In some implementations, the PoS device may also provide information such as the transaction amount, products and/or services being purchase, refunded, and/or the like, atmospherics at the time of the transaction, and/or like information. In some implementations, the merchant may send this information to the ECO ADVANTAGE server 203 via an eco request message 206. In some implementations, an exemplary XML-encoded eco request message 206 may take a form similar to the following:

POST /eco_request_message.php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

Content-Type: Application/XML

Content-Length: 788

<?XML version = "1 . 0" encoding = "UTF-8"?>

<ecoRequest>

<merchantld>2033</merchantld>

<userld>102557952</userld>

<userIdType>SSN</userIdType >

<ecold>3074</ecold>

<posld>4088</posld>

<processingCode>683034</processingCode>

<origDocNumberx/origDocNumber>

<nsu>572052</nsu>

<mcc>6432</mcc>

<merchantCapacity>27</merchantCapacity> <transactionAmount>100.0</transactionAmount>

<minTransactionSize>10</minTransactionSize>

<maxTransactionSize>500</maxTransactionSize>

<transactionSize>l</transactionSize>

<productData>broiled crabs</productData>

<atmospherics>

<dateTime>03/07/2013 03:39 PM</dateTime>

<seating_pref>n_smoking</seating_pref>

<party_size>2</party_size>

<reserv_date>02/28/2013 03:39 PM</reserv_date>

<weather>70F , sunny</weather>

<product_pref>steak</product_pref>

</atmospherics>

</ecoRequest>

[0061] In some implementations, sensitive information (e.g. the user PIN and/or the like) may be encrypted. In some implementations, the ECO ADVANTAGE server may look 207 for the merchant and the user using the information obtained in the eco request message, and may determine whether both entities are already enrolled in ECO ADVANTAGE. In some implementations, Grails code for looking up the user and merchant data mat take a form similar to the following:

def merchant = Merchant. get(params.merchantld);

if (!merchant) {

log.warn("Merchant not found with value ' ${params .merchant} '") ; return sendError( ' exception .merchant . not .found ') ;

} elseif ( !merchant. enabled || ! merchant . confirmed) {

log.warn("Merchant inactive with value ' ${params .merchant} '") ; return sendError( 'exception. merchant. inactive' )

} elseif (merchant . accountLocked) {

log.warn("Merchant account locked with value ' ${params .merchant} '")

return sendError( ' exception .merchant . locked ')

} def schedule = merchant. getSchedules() def user = User.get(params.userld) if (!user) {

log.warn("User not found with value ' ${params . userld} '") ;

return sendError(' exception . user . not .found ' )

}elseif ( ! user .enabled || !user. confirmed) {

log.warn("User inactive with value '${params . userld} '") ;

return sendError( 'exception. user. inactive' )

} elseif (user.accountLocked) {

log.warn("User account locked with value ' ${params . userld} '") return sendError(' exception . user . locked ' )

}

[0062] The server may access the ECO ADVANTAGE database 209, via querying the database 208 for user and merchant records corresponding to the user and merchant specified in eco request 206. [0063] In some implementations, ECO ADVANTAGE may query merchant 20QC and user 2oqd tables of the ECO ADVANTAGE database in order to determine whether such records exist. In some implementations, the ECO ADVANTAGE database may return a user/merchant result 210 which may contain the found records pertaining to the user and/or merchant involved in the transaction. In some implementations, the user/merchant result 210 may take a form similar to the following:

merchant [

id: 2033,

name: "NY some salon inc.",

mail: "ny@somesalon.com",

document: "32135743134",

dateCreated: "05/05/2012",

username: "salon",

password: encrypt( "salonl23" ) ,

enabled: true,

accountLocked : false,

confirmed: true,

phoneNumber: 254145451,

contact: "some joseph",

openingTimes : "24h",

officialWebsite : "www.somesalon.com", region: 254,

minConsumption : 10,

maxConsumption : 500,

bank: "225",

bankAgency: "2541-9",

bankAccount: "123212121-3"

] user [

id: 1025,

name: "John Tavares",

mail: "john@somecompany.com",

document: "336525544",

dateCreated: "05/05/2012",

username: "john",

password: encrypt(" johnl23"),

enabled: true,

accountLocked : false,

confirmed: true,

phoneNumber: "654258225"

]

[0064] In some implementations, ECO ADVANTAGE may use these records to determine 211 a number of calculations, such as the number of ecos the user may use towards the transaction, the number and amount of bonus blocks the user may use towards the transaction, and/or the like. In some implementations, this may be determined based on the user check-in, based on the merchant's atmospherics, based on a merchant's eco schedule, based on the merchants current available capacity, projected available capacity, growth potential, and/or the like. In some implementations, Grails code for determining said calculations may resemble the following:

/* def merchant = Merchant. get(params.merchantld) */

/* def schedule = merchant. getSchedulesQ */

/* def user = User.get(params.userld) */ def eco = Eco.getEcoFromCurrentSchedule(schedule) Checkin checkin = user .getLastCheckin(transaction .merchantld) if (checkin. isValidForTransaction(transaction .merchantld, Now(), transaction) { eco = Eco.updateEcoScheduleWithCheckin(eco, checkin)

}

checkin. markCheckingOutQ def saving = eco. saving

def minTransactionSize = eco. minTransactionSize

def maxTransactionSize = eco. maxTransactionSize

def quantity = transaction. quantity

def realValue = transaction .transactionAmount if ((realValue < minTransactionSize ) && (realValue > maxTransactionSize )) {

error "Amount must be between ${minTransactionSize} and ${maxTransactionSize}"

} def amountOfEcos = calculateValueToPayWithEco(realValue, saving, transaction)

def balanceForMerchant = getBalanceForMerchant(transaction.user, transaction .merchant) if (amountOfEcos > balanceForMerchant) {

error "User insufficient balance"

return

} def amountDuelnDollars = calculateValueToPayWithRealMoney(realValue, saving, transaction)

BonusBlock bonusBlock = user.getValidBonusBlockQ

if (bonusBlock) {

if (amountDuelnDollars > bonusBlock. value) {

if (bonusBlock. isEligibleFor(transaction) {

amountDuelnDollars = amountDuelnDollars - bonusBlock. value }

}

} public static BigDecimal calculateValueToPayWithEco(BigDecimal realValue, Double saving_s Integer quantity = 1){

if( ! realValue || ! saving || realValue == 0 | | saving == 0) {

return 0;

}

return Math.round((realValue * quantity) - (realValue. divide (1 + (saving / 100), 2, RoundingMode.HALFJJP)) * quantity);

} public static BigDecimal calculateValueToPayWithRealMoney(BigDecimal realValue, Double saving, Transaction transaction) {

if( ! realValue || ! saving || realValue == 0 | | saving == 0) {

return 0;

}

return (realValue * quantity)

calculateValueToPayWithEco(realValue, saving, transaction)

} def getBalanceQ {

def result = 0;

def userBalance = Transaction .executeQuery(

"select sum(value * signal) as balance from Transaction " +

"where user. id = :userld " +

" and date <= :date ",

[userld: userld, date: new DateQ]); return result;

} def getBalanceForMerchant(User user, Merchant merchant) { def result = 0;

def balance = this. getBalanceQ;

def merchantAdjustBalance = UserMerchantAdjust .executeQuery(

"select sum(value) from UserMerchantAdjust " + "where user. id = :userld " +

" and merchant. id = :merchantld " + and adjustDate <= :date

[userld: user. id, merchantld: merchant .id, date: new Date()])?.first() if ( ! merchantAdjustBalance) {

merchantAdjustBalance = 0;

} return balance + merchantAdjustBalance;

}

[ o o 65 ] In some implementations, the merchant's eco schedule may be a schedule that outlines the percentage of a given transaction at the merchant that may be paid by the user with ecos. In some implementations this schedule may be based on information such as the merchant's atmospherics, volume of transactions, products of transaction, based on user's total transaction by period or to date, total ecos usage by period or to date, total ecos donated by period or to date, total ecos donated and used by period or to date, number of active friends by period or to date, some factor thereof, and/or the like (see FIGS. 5a-d for more information).

[0066] In some implementations, the ECO ADVANTAGE server may send this information to the merchant via an eco response 212. In some implementations an XML-encoded eco response may take a form similar to the following:

POST /eco_request_message.php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

Content-Type: Application/XML

Content-Length: 788

<?XML version = "1 . 0" encoding = "UTF-8"?>

<ecoResponse>

<UID>da6c5cdf4e90b2961873f7b2e863415</UID>

<transactionId>635467</transactionId>

<transactionAmount>100.0</transactionAmount>

<merchantld>2033</merchantld>

<ecoSaving>20%</ecoSaving>

<userEcoBalance>109K/userEcoBalance>

<amountDuelnDollars>77.0</amountDueInDollars> <userEcoUsage>23</userEcoUsage>

<userBonusBlockUsage>0</userBonusBlockUsage>

<atmospherics>

<dateTime>03/07/2013 03:39 PM</dateTime>

<seating_pref>n_smoking</seating_pref>

<party_size>2</party_size>

<reserv_date>02/28/2013 03:39 PM</reserv_date>

<weather>70F , sunny</weather>

<product_pref>steak</product_pref>

</atmospherics>

<ecoResponse>

[ o o 67] In some implementations, the merchant may use the information obtained to display 213 the updated transaction information to the user, which may include the user's eco balance, the number of ecos that may be used in the transaction, the new transaction balance if ecos are applied, the user's new ecos balance should the ecos be applied, and/or the like. In some implementations, the merchant may use the information may include the user's bonus block balance, the bonus blocks that may be used in the transaction, the transaction balance if bonus blocks are applied, the user's new bonus blocks balance should the bonus blocks be applied, and/or the like. The user may confirm 214 the transaction and the use of ecos. In some implementations the user may confirm the use of bonus blocks independently. In some implementations the user may confirm via pressing a button and/or the like on a PoS terminal at the merchant, or via a mobile application, SMS, a website, NFC/RFID and/or like proximity tags, UTP devices, internet-enabled electronic devices, and/or the like. In some implementations the merchant may send a payment request 215 to an acquirer 204 in order to initiate the processing of the transaction. In some implementations, the acquirer may directly procure funds for the merchant; in other implementations, the acquirer may be an intermediate between the merchant and another acquiring entity (e.g., another acquiring bank, and/or the like). In some implementations, the payment request 215 may be an XML-encoded, encrypted message and may take a form similar to the following:

POST /payment_request_message.php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com Content-Type: Application/XML

Content-Length: 788

<?XML version = "1 . 0" encoding

<paymentRequest>

<UID>da6c5cdf4e90b2961873f7b2e863415</UID>

<transactionId>635467</transactionId>

<merchantld>2033</merchantld>

<posld>4088</posld>

<amountDuelnDollars >77.0</amountDueInDollars>

<dateTime>03/07/2013 03:39 PM</dateTime>

<userCard>3214 3578 3568 3542</userCard>

</paymentRequest>

[0068 ] In some implementations, the acquirer may only receive the transaction balance (e.g., the out-of-pocket cost after ecos and/or bonus blocks have been applied to the transaction total). In some implementations the acquirer may use the information in the transaction request in order to generate messages to the various payment entities who may be involved in the procurement of the user's payment 216. For example, the acquirer may interact with the user's issuing bank, the merchant's bank account, one or more other acquiring entities, and/or the like, in order to process the transaction. In some implementations those entities may be another acquirer, another financial institution, payment gateway, online payment service (e.g., PayPal), Electronic Funds Transfer Network (e.g., Swift), and/or the like. In some implementations, Grails code for processing the transaction may take a form similar to the following:

Card card = Card.get(userCard);

Merchant merchant = Merchant .get(merchantld)

Try {

beginTransaction( )

card .debit (amountDuelnDollars)

merchant . credit (amountDuelnDollars)

commitTransaction ( ) ;

return true;

} catch (Exception) {

rollbackTransaction( ) ;

return false; 1 [0069] Once processed, the acquirer may send a transaction confirmation 217 to

2 the merchant, indicating whether the transaction was approved (e.g. successful) or

3 declined (e.g. failed). In some implementations, the transaction confirmation may take a

4 form similar to the following:

5 POST /transaction_confirmation_message.php HTTP/1.1

6 Host: www.ECOADVANTAGEprocess.com

7 Content-Type: Application/XML

8 Content-Length: 788

9 <?XML version = "1.0" encoding = "UTF-8"?>

10 <paymentConfirmation>

11 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>

12 <transactionId>635467</transactionId>

13 <merchantld>2033</merchantld>

14 <posld>4088</posld>

15 <amounDueInDollars>77.0</amountDueInDollars>

16 <debitCreditAmount>77.0</debitCreditAmount>

17 <cashAmount>0.0</cashAmount>

18 <totalAmount>100</totalAmount>

19 <dateTime>03/07/2013 03:40 PM</dateTime>

20 <approved>true</approved>

21 </paymentConfirmation>

22 [oo7o ] In some implementations, the merchant may provide a transaction receipt

23 218 to the user, indicating the user's new eco balance and/or like information. In some

24 implementations, the receipt may be printed and/or displayed on the merchant's PoS

25 device. In some implementations the receipt may take a form similar to the following:

26 DOCUMENT: NNN . NNN . NNN-NN ID EAS :

27 ORIGINAL VALUE: VVV.VW,VV

28 BONUS BLOCK VALUE: VVV.VVV,VV

29 ECONOMY: ΕΕΕ.ΕΕΕ,ΕΕ

30 VALUE PPPPPPPPPP: ΤΤΤ.ΤΤΤ,ΤΤ

31 NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN

32 ECO BALANCE: ΒΒΒ.ΒΒΒ,ΒΒ

33 FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF [0071] The merchant may also forward 21Q the transaction confirmation to ECO ADVANTAGE. In some implementations transaction confirmation 21Q may take a form similar to the following:

<transactionConfirmation>

<UID>da6c5cdf4e90b2961873f7b2e863415</UID>

<transactionId>635467</transactionId>

<merchantld>2033</merchantld>

<posld>4088</posld>

<amounInDollars>77.0</amountDuelnDollars>

<debitCreditAmount>77.0</debitCreditAmount>

<cashAmount>0.0</cashAmount>

<dateTime>03/07/2013 03:40 PM</dateTime>

<approved>true</approved>

</transactionConfirmation>

[0072] ECO ADVANTAGE may use the confirmation to update 220 the user's account (e.g. by deducting the ecos used in the transaction, by adding to the user account new ecos identified as being from the merchant, and/or the like). In some implementations Grails code for updating the user's account may take a form similar to the following:

Transaction transaction = Transaction .get(transactionld)

User user = transaction. getUserQ

Merchant merchant = transaction. getMerchantQ

long ecoUsage = transaction. getEcoUsage()

long bonusBlockUsage = transaction. getBonusBlockUsage( )

long amountDuelnDollars = transaction. getAmountDuelnDollarsQ Try {

beginTransaction( )

user .debitEco(ecoUsage)

user .debitBonusBlock( bonusBlockUsage)

user.creditEco(amountDueInDollars, merchant)

commitTransactionQ;

} catch (Exception) {

rollbackTransactionQ;

return false; }

[0073] ECO ADVANTAGE may also update 221 the merchant's account (e.g. linking the merchant account to a record of the transaction, updating the merchant's BI information and schedules, atmospherics, and/or the like). In some implementations Grails code for updating the merchant account may take a form similar to the following: Transaction transaction = Transaction .get(transactionld)

Merchant merchant = transaction. getMerchantQ

User user = transaction. getUserQ

long ecoUsage = transaction. getEcoUsage()

long bonusBlockUsage = transaction. getBonusBlockUsage( )

def historyTransaction = new HistoryTransaction(transaction, merchant, user, ecoUsage, bonusBlockUsage)

historyTransaction . save( )

[ o o 74 ] In some implementations, ECO ADVANTAGE may also monitor the status of various transactions, and may reverse, retry, and/or otherwise handle incomplete transactions if found in the ECO ADVANTAGE database's records, based on predetermined criteria.

[0075] FIGURE 2b shows a logic flow diagram illustrating performing a transaction in example embodiments of the ECO ADVANTAGE. In some implementations, a user may initiate a transaction with a merchant 226 by providing information such as the user's UID, the user's PIN, and/or the like. The merchant may receive 227 the user's information, and may send it to ECO ADVANTAGE, which may be prompted to use the information 228 to verify that the user is in ECO ADVANTAGE. In some implementations, ECO ADVANTAGE may query the ECO ADVANTAGE Database 22Q to determine if there is a merchant and/or a user record for the entities involved. If a merchant record is not found 230, the merchant may be prompted to enroll in ECO ADVANTAGE (see FIGS. 4b-c). If a merchant record is found but there is no valid PoS record 2 1 for the merchant, the merchant may be prompted to submit PoS information and/or to update PoS settings and/or configurations if necessary (see FIG. 4c). If the merchant record is found and there is a valid PoS record for it, but there is no record for the user 232, ECO ADVANTAGE may prompt the merchant to allow the user to enroll in ECO ADVANTAGE (see FIG. 3b). [0076] If a user record is found, ECO ADVANTAGE may retrieve from the user record the user's eco balance 233, and may determine which ecos are marked as being from the merchant involved in the transaction. As mentioned above, in some implementations, ecos marked as being from the merchant involved may not be usable for the transaction. In addition, ECO ADVANTAGE may retrieve from the user record any available bonus blocks, and may determine which may be used towards the purchase. ECO ADVANTAGE may calculate 2 4 the number of ecos that may be applied to the transaction in general, based on the merchant's eco schedule in its merchant record, and/or the like. ECO ADVANTAGE may send the user's eco balance, the merchant's eco schedule, the amount of ecos that the user may use towards the particular transaction, the remaining balance, and/or the like, to the merchant. [0077] After obtaining 2 this information, the merchant may prompt the user to authorize the use of its ecos and/or bonus blocks, and to authorize charging the rest to a credit/debit card stored in ECO ADVANTAGE, a new credit/debit card, authorize paying the balance in cash, and/or the like. The user may authorize 236 the transaction, including authorizing the use of ecos, bonus blocks, and/or a debit/credit card, and may use the merchant's PoS device to authorize the transaction. The merchant may send 2 7 the amount to be charged to the user to the merchant's acquirer for procurement. In some implementations, the acquirer may receive 238 the transaction information, and may forward the pertinent information to the user's issuing bank 23Q in order to procure the funds. In other implementations, the acquirer may forward the information to a different entity, such as another acquirer and/or a like entity who will directly interact with the user's issuer. In some implementations, the acquirer may receive a response 240 from the issuer and/or like entity, indicating whether the procurement of funds was successful or not. The acquirer may forward this information to the merchant, who, if the transaction was unsuccessful 241, may forward 248 the notification of the failed transaction to ECO ADVANTAGE 24Q and the user 250, who may be prompted to retry the transaction. In some implementations ECO ADVANTAGE may also mark all records related to the transaction record as being incomplete and in need of further action. If the transaction was successful, the merchant may forward 242 the notification of the successful transaction to ECO ADVANTAGE, which may create 243 a transaction record for the transaction and store the record in the ECO ADVANTAGE Database. ECO ADVANTAGE may also update the merchant 245 and user 244 accounts records. In some implementations, the merchant record may be updated with a link to the transaction record, updated eco and usage schedule information, BI information, and/or the like. In some implementations updating the merchant record may also involve queuing later services, such as reconciliation, reporting, updating BI user information, and/or the like. In some implementations, updating the user record may involve updating the user record via deducting the ecos and/or bonus blocks used in the transaction, crediting new ecos to the user (said ecos being marked as coming from the merchant), and/or the like. In some implementations, the amount of new ecos received may be a predetermined amount based at least partially on the transaction amount. In some implementations ECO ADVANTAGE may forward 246 the notification of the successful transaction to the user, who may receive the notification 247 and may store the notification for future reference.

[0078 ] FIGURE 2c shows a data flow diagram illustrating performing an online transaction in example embodiments of the ECO ADVANTAGE. In some implementations, the user may choose products and/or services on a merchant website, application, or SMS 252 to purchase via a personal computer, mobile device, merchant kiosk, and/or a like electronic device separate from a merchant PoS device. The online merchant 270 may collect from the user choices product IDs, a running total of the user's transaction balance, the user's ID and login credentials for the merchant website (e.g. username and password), atmospherics for the merchant, and/or the like. The merchant may also send an eco request 253 to ECO ADVANTAGE. In some implementations the eco request may take a form similar to the following:

POST /eco_request_message.php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

[0079] Content-Type: Application/XML

Content-Length: 788

<?XML version = "1.0" encoding = "UTF-8"?>

<ecoRequest>

<UID>da6c5cdf4e90b2961873f7b2e863415</UID>

<transaction!d>635467</transactionId> 1 <transactionAmount>100.0</transactionAmount>

2 <merchantld>2033</merchantld>

3 <userld>102557952</userld>

4 <userIdType>SSN</userIdType >

5 <deviceld>961873f7b2e863415da6c5cdf4e90b2</deviceld>

6 <processingCode>683034</processingCode>

7 <origDocNumberx/origDocNumber>

8 <nsu>572052</nsu>

9 <mcc>6432</mcc>

10 <merchantCapacity>27</merchantCapacity>

11 <minTransactionSize>10</minTransactionSize>

12 <maxTransactionSize>500</maxTransactionSize>

13 <transactionSize>l</transactionSize>

14 <productData>

15 <sku>6483953</sku>

16 <description >television</description

17 </productData>

18 <atmospherics>

19 <dateTime>03/07/2013 03:39 PM</dateTime>

20 <seating_pref>n_smoking</seating_pref>

21 <party_size>2</party_size>

22 <reserv_date>02/28/2013 03:39 PM</reserv_date>

23 <weather>70F , sunny</weather>

24 <product_pref>steak</product_pref>

25 </atmospherics>

26 </ecoRequest>

27 [0080] In some implementations, sensitive information (e.g. the user PIN and/or

28 the like) may be encrypted. Similar to FIGURE 2a, ECO ADVANTAGE may send a query

29 2 to the ECO ADVANTAGE database 209, and may retrieve merchant and user data

30 254, and use the data provided in the query result 256 to determine 257 the amount of

31 ecos the user may apply to the purchase, the number of ecos and/or bonus blocks the

32 user has in its eco and/or bonus block balances, and/or the like. The ECO ADVANTAGE

33 may send an eco response 258 back to the online merchant with said information. In

34 some implementations the eco response may take a form similar to that of eco response

35 212 in FIGURE 2a. In some implementations, the online merchant may generate a page 1 for the user which displays 25Q the user's eco and/or bonus block balances, transaction

2 balance remaining, and/or like information to the user, and prompts the user to confirm

3 the transaction given said information.

4 [ 0081 ] The user may confirm the transaction 260, and any information the online

5 merchant has collected from the user (e.g. user ID, user authorization, and/or the like)

6 may be sent to the acquirer 204 via payment request 261, which may take a form similar

7 to that of payment request 215 in FIGURE 2a. In some implementations the acquirer

8 may also be a Payment Gateway, which may be a bank, an online payment service (e.g.

9 PayPal), electronic funds transfer, and/or the like. The acquirer may process the

10 transaction information and procure payment 262 via sending a transaction request 263

11 to another payment entity 271 (e.g. the user's issuer, another acquiring entity, and/or

12 the like) for processing. The payment entity may send back to the acquirer a transaction

13 response 264, which may indicate whether the transaction was successfully processed or

14 not. The acquirer may forward this notification via transaction confirmation 265, which

15 the online merchant may use to generate a receipt page 266, and which the online

16 merchant may use to generate an electronic receipt that it may send to the user's ECO

17 ADVANTAGE, email address, and/or the like. The online merchant may also forward is the transaction confirmation to ECO ADVANTAGE 267, and ECO ADVANTAGE may

19 use the confirmation information to update 268 the user's eco and/or bonus block

20 balances (e.g. deducting used ecos and/or bonus blocks, crediting new ecos, and/or the

21 like), and to update 269 the merchant's account in a manner similar to FIGURE 2a. in

22 some implementations, ECO ADVANTAGE may receive the transaction confirmation

23 directly from the acquirer.

24 [ 0082 ] FIGURE 2d shows a logic flow diagram illustrating performing an online

25 transaction in example embodiments of the ECO ADVANTAGE. In some

26 implementations, a user may initiate a transaction with a merchant 2Q8 by providing

27 information such as the user's UID, the user's PIN, and/or the like. The merchant may

28 receive 272 the user's information, and may send it to ECO ADVANTAGE, which may be

29 prompted to use the information 27 to verify that the user is in ECO ADVANTAGE. In

30 some implementations, ECO ADVANTAGE may query the ECO ADVANTAGE database

31 274 to determine if there is a merchant and/or a user record for the entities involved. If a merchant record is not found 275, the merchant may be prompted to enroll in ECO ADVANTAGE (see FIGS. 4b-c). If a merchant record is found but there is no valid PoS record 27Q for the merchant, the merchant may be prompted to submit PoS information and/or to update PoS settings and/or configurations if necessary (see FIG. 4c). If the merchant record is found and there is a valid PoS record for it, but there is no record for the user 277, ECO ADVANTAGE may prompt the merchant to allow the user to enroll in ECO ADVANTAGE (see FIG. 3b). [0083] If a user record is found, ECO ADVANTAGE may retrieve from the user record the user's eco balance 278, and may determine which ecos are marked as being from the merchant involved in the transaction. As mentioned above, in some implementations, ecos marked as being from the merchant involved may not be usable for the transaction. In addition, ECO ADVANTAGE may retrieve from the user record any available bonus blocks, and may determine which may be used towards the purchase. ECO ADVANTAGE may calculate 27Q the number of ecos that may be applied to the transaction in general, based on the merchant's eco schedule in its merchant record, and/or the like. ECO ADVANTAGE may generate and send 280 the user's eco balance, the merchant's eco schedule, the amount of ecos that the user may use towards the particular transaction, the remaining balance, and/or the like, to the merchant. [0084] After receiving 281 this information, the merchant may prompt the user to authorize the use of its ecos and/or bonus blocks, and to authorize charging the rest to a credit/debit card stored in ECO ADVANTAGE, a new credit/debit card, authorize paying the balance in cash, and/or the like, via generating a transaction confirmation page 282 which contains the user's transaction information (e.g. current eco and/or bonus block balances, balances after transaction is authorized, and/or the like). The user may authorize 283 the transaction, including authorizing the use of ecos, bonus blocks, and/or a debit/credit card via the confirmation page. The merchant may send 284 the amount to be charged to the user to the merchant's acquirer for procurement. In some implementations, the acquirer may receive 285 the transaction information, and may forward the pertinent information to the user's issuing bank 286 in order to procure the funds. In other implementations, the acquirer may forward the information to a different entity, such as another acquirer, another bank, an online payment service, an 1 electronic funds transfer service, and/or the like, and/or a like entity who will directly

2 interact with the user's issuer. In some implementations, the acquirer may receive a

3 response 287 from the issuer and/or like entity, indicating whether the procurement of

4 funds was successful or not. The acquirer may forward this information to the merchant,

5 who, if the transaction was unsuccessful 288, may forward 295 the notification of the

6 failed transaction to ECO ADVANTAGE 296 and the user 297, who may be prompted to

7 retry the transaction. If the transaction was successful, the merchant may forward 289

8 the notification of the successful transaction to ECO ADVANTAGE, which may create

9 290 a transaction record for the transaction and store the record in the ECO0 ADVANTAGE Database. ECO ADVANTAGE may also update the merchant 292 and1 user 291 accounts records. In some implementations, the merchant record may be2 updated with a link to the transaction record, updated eco schedule information, BI3 information, and/or the like. In some implementations, updating the user record may4 involve updating the user record via deducting the ecos and/or bonus blocks used in the5 transaction, crediting new ecos to the user (said ecos being marked as coming from the6 merchant), and/or the like. In some implementations, the amount of new ecos received7 may be a predetermined amount based at least partially on the transaction amount. In8 some implementations ECO ADVANTAGE may forward 293 the notification of the9 successful transaction to the user, who may receive the notification 294 and may store0 the notification for future reference.

1 [0085] FIGURE 3a shows a data flow diagram illustrating performing an online2 transaction without an ECO ADVANTAGE account in example embodiments of the ECO3 ADVANTAGE. In some implementations, a user 301 may initiate 302 a transaction with4 a merchant 303 via providing transaction information to the merchant, and a unique5 user PIN and/or identifier (e.g. a social security number, phone number, and/or the6 like). In some implementations, the merchant may send an eco request 304 to ECO7 ADVANTAGE 30 (which may take a form similar to eco request 206), indicating that a8 person at the merchant would like to initiate a transaction. In some implementations,9 sensitive information (e.g. the user PIN and/or the like) may be encrypted. In some0 implementations eco request 304 may be similar to eco request 206. ECO ADVANTAGE1 may look up 306 the merchant and the user in the ECO ADVANTAGE database in order to determine whether either entity is in the database, via send a user and merchant information query 307 to the user 3o8d and merchant 308c tables of the ECO ADVANTAGE database 308. In some implementations a PHP-encoded user and merchant query 07 may take a form similar user/merchant query 208. [0086 ] In some implementations, the ECO ADVANTAGE database may send a user and merchant response 30Q to ECO ADVANTAGE indicating whether the records were successfully found, and the information requested. In some implementations, the user and merchant response 30Q may take a form similar to the following:

merchant [

id: 2033,

name: "NY some salon inc.",

mail: "ny@somesalon.com",

document: "32135743134",

dateCreated: "05/05/2012",

username: "salon",

password: "salonl23",

enabled: true,

accountLocked : false,

confirmed: true,

phoneNumber: 254145451,

contact: "some joseph",

openingTimes : "24h",

officialWebsite : "www.somesalon.com",

region: 254,

minConsumption : 1,

maxConsumption : 5,

bank: "225",

bankAgency: "2541-9",

bankAccount: "123212121-3"

]

user [

] 1 [0087] If a user account was not found (e.g., if the user does not yet have an

2 account with ECO ADVANTAGE), ECO ADVANTAGE may generate 310 a temporary

3 user ID/authorization code for the user, which may be used to keep track of the

4 transaction details, and/or to allow the user to enroll in ECO ADVANTAGE. In some

5 implementations Grails code for generating the temporary user ID may take a form

6 similar to the following:

7 TemporaryUser tempUser = new TemporaryUser(

8 authorizationCode : <auto-increment> ,

9 uniqueNumber: userPersonalUniqueNumber,

10 document: userdocument ,

11 userDocumentType: "SSN",

12 initialBalance : receivedEcos

13 dateCreated: <today>,

14 )

15 tempUser.save()

16 [0088 ] In some implementations, ECO ADVANTAGE may send an eco response

17 311 to the merchant. An XML-encoded eco response 311 may take a form similar to the

18 following:

19 POST /eco_response.php HTTP/1.1

20 Host: www.ECOADVANTAGEprocess.com

21 Content-Type: Application/XML

22 Content-Length: 788

23 <?XML version = "1 . 0" encoding = "UTF-8"?>

24 <ecoResponse>

25 <authorizationCode>109654324</authorizationCode>

26 <ecosCouldBeUsed>23</ecosCouldBeUsed>

27 < receivedEcos >77</receivedEcos>

28 <ecoSaving>20%</ecoSaving>

29 <ecoResponse>

30 [0089 ] In some implementations, the merchant may print or display 312 the

31 information received from ECO ADVANTAGE for the user, so that the user may register 1 for an ECO ADVANTAGE account and use the ecos he received via the transaction. In

2 some implementations the printed and/or displayed information may take a form

3 similar to the following:

4 AUTHORIZATION CODE: NNNNNNNNN

5 IF YOU WERE ENROLLED, YOU'D HAVE

6 SAVED ON THIS TRANSACTION: PP%

7 OR ECO AMOUNT: WVVVVVVVV,VV

8 ECOS RECEIVED: WVVVVVVVV,VV

9 AMOUNT PAYABLE: VVVVVVVVVV, VV

10 CANCEL ENTER

11 [0090] In some implementations ECO ADVANTAGE may monitor 320 the

12 temporary user ID to see if the user has created an account, and may choose to

13 deactivate the user's account after a pre-specified period of inactivity. The user may

14 submit an application request 313 to ECO ADVANTAGE, or may submit an application

15 request 314 to the merchant, who may forward the application request 315 to ECO

16 ADVANTAGE. In some implementations, an XML-encoded application request 313,

17 14, or 315 may take a form similar to the following:

18 POST /application_request.php HTTP/1.1

19 Host: www.ECOADVANTAGEprocess.com

20 Content-Type: Application/XML

21 Content-Length: 788

22 <?XML version = "1.0" encoding = "UTF-8"?>

23 <applicationRequest>

24 <authorizationCode>109654324</authorizationCode>

25 <userld>102557952</userld>

26 <userIdType>SSN</userIdType >

27 <userFirstName>Peter</userFirstName>

28 <userLastName>Tavares</userLastName>

29 <userLastName>Tavares</userLastName>

30 <email>petertavares@somecompany . com</email>

31 /*<streetAddress>Tavares Street, 44</streetAddress>

32 <paymentMethod>debitcard , creditcard</paymentMethod>

33 <userInterests>eletronics , restaurants</userlnterests>

34 <userDevices>iphone, tablet</userDevices>*/ </applicationRequest>

[0091] In some implementations, the user's application information in the application request may be used to instantiate 316 a user account on ECO ADVANTAGE. In some implementations Grails code for instantiating the user account may take a form similar to the following:

TemporaryUser tempUser = TemporaryUser.getByAuthorizationCode(authorizationCode) if (tempUser) {

def user = new User();

user .document = tempUser .document;

user. name = applicationRequest . userFirstName + " " + applicationRequest .userLastName;

user. mail = applicationRequest .email;

user. password = applicationRequest . password;

user. address = applicationRequest . streetAddress;

user.paymentMethod = applicationRequest . paymentMethod;

user. interests = applicationRequest .userlnterests;

user. devices = applicationRequest .devices;

user .enabled : true;

user.accountLocked: false;

user. confirmed: false;

user.saveQ user . creditEco(tempUser . receivedEcos)

} else {

sendError("authorizationcode . not .found")

}

[0092] ECO ADVANTAGE may also credit to the user's new account the number of ecos specified in the user's authorization code/temp ID. ECO ADVANTAGE may send a confirmation of enrollment to the user (e.g., via a message 319 directly to the user, or via a message to the merchant 317, which may be forwarded to the user 318). In some implementations, an XML-encoded status of enrollment message may take a form similar to the following:

POST /enrollment_message.php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

Content-Type: Application/XML 1 Content-Length: 788

2 <?XML version = "1 . 0" encoding = "UTF-8"?>

3 <userApplicationResponse>

4 <authorizationCode>109654324</authorizationCode>

5 <approved>true</approved>

6 <ecoBalance>77</ecoBalance>

7 </userApplicationResponse>

8 [0093] FIGURE 3b shows a logic flow diagram illustrating performing an online

9 transaction without an ECO ADVANTAGE account in example embodiments of the ECO

10 ADVANTAGE. In some implementations, ECO ADVANTAGE may store 321 a

11 transaction record and generate a transaction ID for the record. ECO ADVANTAGE may

12 also generate a temporary user record 322, with a temporary user ID, authentication

13 code, a reference to the stored transaction, and/or like information. In some

14 implementations, ECO ADVANTAGE may calculate 323 the number of ecos associated

15 with the temporary account, and may send the eco information to the merchant, who

16 may receive and print and/or display 324 the user's authorization code and/or temp ID,

17 the amount of ecos that could have been applied to the merchant's transaction, the

18 amount of ecos to be received from the transaction, the total ecos accrued for the user

19 should he enroll, and/or like information. The user, upon obtaining 325 the data

20 provided by the merchant, may be given the opportunity to create an account with ECO

21 ADVANTAGE so that he may use his ecos in the system. If the user wants the account

22 326, the user may provide application information 328, such as the user's name,

23 address, email, password, and/or the like to the merchant. In some implementations,

24 the merchant may process 32Q the application via sending it in a message to ECO

25 ADVANTAGE 330· In some implementations, the user may also send the application

26 information directly 331 to ECO ADVANTAGE via an electronic device separate from

27 the merchant and/or its PoS device. ECO ADVANTAGE may convert the user's

28 temporary account 332 into a normal user account, and may update the new account

29 with the application data and/or like information. ECO ADVANTAGE may also credit a

30 predetermined number of ecos 333 to the user based on the transaction performed, and

31 in some implementations these ecos may be marked as being from the merchant where

32 the transaction originated. ECO ADVANTAGE may generate a status notification 334 ^m order to notify other entities in the process that the enrollment was successful, to provide the user's current eco balance, and/or the like. In some implementations ECO ADVANTAGE may send this status notification to the merchant 335, who may forward the notification to the user after logging the data. In other implementations, ECO ADVANTAGE may send the notification directly to the user, via mail, email, SMS, and/or the like. In some implementations, if the user chooses not to create an account, ECO ADVANTAGE may deactivate the temporary user record 327 in the ECO ADVANTAGE database. In some implementations, the user may be able to view his newly-created account via a profile user interface similar to that in FIGURE 21a.

[0094] FIGURE 4a shows a data flow diagram illustrating enrolling a merchant in example embodiments of the ECO ADVANTAGE. In some implementations, the merchant 401 may wish to enroll in ECO ADVANTAGE via sending an enrollment request 402 to ECO ADVANTAGE with an indication that the merchant would like to get information and/or an application for enrollment, and/or the like. ECO ADVANTAGE may send an enrollment request form 404, which may take a form similar to those in FIGURES 17a or 17b, depending upon whether the enrollment form is electronic or physical. In some implementations, the merchant may fill out the enrollment request form and send it back to ECO ADVANTAGE via a request form message 405. In some implementations the request form message 405 may be an XML- encoded message similar to the following :

POST /request_form_message.php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

Content-Type: Application/XML

Content-Length: 788

<?XML version = "1 . 0" encoding = "UTF-8"?>

<merchantApplicationMessage>

<Document>02545225441000188</Document>

<MerchantName>Italian Restaurant</MerchantName>

<StreetAddress>16 avenue, 20</StreetAddress>

<BankInformation>

<BankNumber>254</BankNumber>

<Agency>3652-8</Agency>

<Account>2525414-5</Account> </BankInformation>

<Biography>

The Italian restaurant opened 10 years ago

and since then has been serving Italian food every day.

</Biography>

<Links>

< Link>http : //wwww. Italian -restaurant . com</Link>

</Links>

<PosID>5467754</PosID>

<ListOfPeriods>

<Period type="slow">

<DayRange>Mon , Tue, Wed</DayRange>

<TimeRange>18PM-22PM</TimeRange>

</Period>

</ListOfPeriods>

<Capacity>150</Capacity>

<atmospherics>

<dateTime>03/07/2013 03:39 PM</dateTime>

</atmospherics>

</merchantApplicationMessage>

[0095] In some implementations, ECO ADVANTAGE may wish to perform a check (e.g. financial, quality, and/or the like) 406 on the merchant before enrolling the merchant in the program, and may send a check request 407 to a merchant agent 408 in order to run a check on the merchant. In some implementations, the merchant agent may be another electronic entity (e.g. web-crawler entity, robot, and/or the like) that may collect, aggregate, and analyze various types of information about various merchants both inside and outside of ECO ADVANTAGE. In some implementations, the check request message 407 may be an XML-encoded message may include check parameters for the merchant to use during aggregation (e.g. merchant to search for, sources to search, and/or the like). [0096] In some implementations, the merchant agent may aggregate financial information, quality information, background information, and/or like information about the merchant 409, and may return this information to ECO ADVANTAGE via a merchant check response 410, which may include the merchant check data. [0097] In some implementations, ECO ADVANTAGE, after receiving the merchant check, may generate a merchant account record 411 for the merchant if the merchant has met a pre-specified threshold of quality and is approved for ECO ADVANTAGE, and may enroll the merchant in the program. In some implementations, Grails code for creating the merchant account may take a form similar to the following: MerchantRequest merchantRequest = MerchantRequest .getByDocument(XMLmerchant .document) if (request) {

if (request .qualityCheckPending == false

&& request .financialCheckPending == false

&& request . approved == true) {

Merchant merchant = new Merchant(merchantRequest.*)

merchant .enabled = true;

merchant . accountLocked = false;

merchant . confirmed = false;

merchant . login = XMLmerchant .email;

merchant . password = VoucherUtil.generatePassword()

merchant . save( )

foreach(period in Merchant . ListOfPeriod) {

new MerchantPeriod (merchant ^ period) . save( )

}

request .enrollmentPending = false;

request . save( )

}

} else {

sendError("merchantrequest . not .found")

}

[0098] ECO ADVANTAGE may instantiate 412 the merchant account record, merchant eco schedule, and/or the like via storing the information in the schedules 413b and merchant 413d tables of the ECO ADVANTAGE database 413. In some implementations, ECO ADVANTAGE may also update the regions, categories, and/or the like in ECO ADVANTAGE via updating the categories 413a and regions 413c tables of the ECO ADVANTAGE database.

[0099] In some implementations, ECO ADVANTAGE may send a notification 414 to the merchant indicating that the merchant has successfully enrolled in the system. In 1 some implementations, the notification of account creation 414 may be an XML-

2 encoded message that may include the merchant's new ECO ADVANTAGE credentials

3 and/or like enrollment information.

4 [ 00100 ] In some implementations, the merchant may need to update its PoS

5 settings and/or configuration in order to properly communicate with ECO

6 ADVANTAGE during transactions. In some implementations, the merchant may send a

7 PoS (e.g. place of business or point-of-sales) configuration settings request 415 to ECO

8 ADVANTAGE indicating a desire to update PoS settings, and including the merchant's

9 current configuration, settings, and/or like information. In some implementations, the

10 PoS configuration settings request 415 may be an XML-encoded message that may

11 include information about the merchant's current PoS configuration, settings,

12 infrastructure, and/or the like.

13 ECO ADVANTAGE may, after receiving the merchant's existing PoS information,

14 generate a PoS configuration for the merchant 416 based on the infrastructure and/or

15 the like that the merchant already has, and may generate training manual, tutorial,

16 and/or like materials for the merchant so that its PoS settings may be updated

17 accordingly. In some implementations, ECO ADVANTAGE may instantiate a PoS

18 settings record 417 in the ECO ADVANTAGE database, and may send a PoS

19 configuration settings response 418, detailing the new generated settings, configuration,

20 and/or the like. In some implementations, the PoS configuration settings response 418

21 may include ECO ADVANTAGE'S suggestions for the merchant's PoS configuration,

22 settings, and/or the like, along with training materials and/or like resources. In some

23 implementations PoS configuration settings response 418 may be sent to the merchant's

24 acquirer 420; in other implementations it may be sent to the merchant directly. If it is

25 sent to the merchant directly, the merchant may forward the PoS configurations settings

26 via a message 419 to the merchant's acquirer. The acquirer may update, restart, and test

27 421 the merchant's PoS 422 based on the new configuration, settings, and/or the like.

28 The merchant may send a confirmation 423 to ECO ADVANTAGE when the PoS has

29 been successfully configured.

30 [ 00101] FIGURES 4b-c show logic flow diagrams illustrating enrolling a merchant

31 in example embodiments of the ECO ADVANTAGE. In some implementations, the merchant may submit 424 a request to enroll in ECO ADVANTAGE to ECO ADVANTAGE, who may receive the request and generate 425 a template or customized enrollment form for the merchant. In some implementations, ECO ADVANTAGE may send 426 the enrollment form to the merchant, who may receive 427 the enrollment form and may submit 428 an application to enroll in ECO ADVANTAGE, which may include identification information, merchant sales information, product information, merchant payment information, atmospherics, industry information, and/or a variety of other types of merchant-related data. In some implementations, ECO ADVANTAGE may receive the application and generate a query 429 to merchant agents enrolled in ECO ADVANTAGE in order to obtain background materials on the merchant. In some implementations, once ECO ADVANTAGE has sent 4 0 the query to the merchant, the merchant may receive the merchant's information 431 and may begin to aggregate information 4 2 regarding the merchant, such as financial, quality, and/or like data. In some implementations, merchant information may be aggregated from accredited financial review organizations, peer review services, client review services, and/or the like. In some implementations, the merchant agent may generate 433 a background check based on the aggregated data, and may send 434 the background check based on the aggregated data. ECO ADVANTAGE May receive 435 the background check for the merchant, and may parse 436 the background check in order to find potentially alarming information regarding the merchant (e.g. if the merchant has a poor credit score, has a low client review score on a number of prominent social review websites, and/or the like). If the merchant meets a number of pre-specified criteria (e.g. credit thresholds, peer review thresholds, and/or the like) 437, ECO ADVANTAGE may generate a merchant account record 440 in the ECO ADVANTAGE database using the information obtained in the merchant's enrollment application, and may generate 441 an initial eco schedule for the merchant using the merchant's provided data (see FIGURES 5a-b for further details). In some implementations the eco schedule may be used to determine how many ecos a consumer may use in a transaction at the merchant at particular times of the day, particular days of the week, and/or the like. [ 00102 ] As shown in FIGURE 4c, ECO ADVANTAGE may also generate a confirmation notification 442 indicating that the merchant has been successfully enrolled, and may end 443 said confirmation to the merchant. Once the merchant received 444 the confirmation, the merchant may generate a survey 445 of the merchant's current PoS infrastructure, resources, configurations, settings, and/or the like, and may submit 445 the survey to ECO ADVANTAGE. In some implementations, ECO ADVANTAGE may receive 447 the survey and may determine new PoS (e.g. Place of Sales, place of business, or Point of Sales device) configurations, settings, infrastructure, and/or the like 448 based on the merchant's submitted infrastructure and the infrastructure and/or configuration needs of ECO ADVANTAGE. If ECO ADVANTAGE can successfully determine new settings for the merchant's PoS 449, ECO ADVANTAGE may also generate and/or retrieve 453 the proper training manuals, configuration tutorials, and/or the like, along with promotions for the new settings and/or infrastructure, and may generate a new PoS record in the ECO ADVANTAGE database containing the determined configuration, settings, and/or the like and a reference to the merchant account record. ECO ADVANTAGE may also send 455 the new configuration, settings, and/or the like, along with the training manuals, tutorials, promotions, and/or the like, to the merchant 456 for the merchant's records. The merchant may also forward 457 the settings to the merchant's acquirer, which may receive 458 the new PoS configuration and/or the like and may instantiate 45Q a new PoS system using the suggested configuration, settings, infrastructure, and/or the like. The acquirer may restart the PoS, test the new suggested configuration 460, and may send a notification 461 to ECO ADVANTAGE when the PoS is successfully configured. ECO ADVANTAGE may receive 462 the notification and store it for future reference in the PoS and/or merchant record. [ 00103 ] In some implementations, if the merchant does not meet the pre-specified enrollment criteria at 437, ECO ADVANTAGE may reject the merchant 438, and may send a notification to the merchant 43Q indicating that the merchant was rejected by ECO ADVANTAGE, but is encouraged to try to enroll again at a later date. In some implementations the notification may also include reasons for rejection, including citing a poor credit score, poor peer reviews, and/or the like. If ECO ADVANTAGE cannot determine new PoS settings for the merchant, ECO ADVANTAGE may generate and send a failure message 450 to the merchant indicating that ECO ADVANTAGE could not generate a suitable configuration for the merchant given the information provided, and may also indicate what major changes the merchant could make to its existing infrastructure and/or the like before ECO ADVANTAGE can determine a suitable configuration. After the merchant receives the message 451, the merchant may obtain different PoS infrastructure and/or the like, and may re-submit a PoS survey to ECO ADVANTAGE indicating the changes in the PoS infrastructure, configuration, and/or the like. [ 00104] FIGURE 5a shows a data flow diagram illustrating creating and updating regions and categories in example embodiments of the ECO ADVANTAGE. In some implementations, a merchant agent 501 may determine a region 502 in ECO ADVANTAGE to analyze. In some implementations, the region may be based on geographic, cultural, industrial, and/or like constraints. The merchant may search for merchants in each region to obtain data from, and may obtain aggregate data 505 from brick and mortar merchants 503 as well as online merchants 504 already enrolled in ECO ADVANTAGE. In some implementations, the merchant agent may send the aggregate information obtained about each merchant to ECO ADVANTAGE via a region/merchant survey message 506. In some implementations, an XML-encoded region/merchant survey message 506 may be an XML-encoded message and may take a form similar to the following:

POST /region_merchant_survey_message . php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

Content-Type: Application/XML

Content-Length: 788

<?XML version = "1 . 0" encoding = "UTF-8"?>

<regionMerchantSurvey>

<surveyld>11254878</surveyld>

<surveyDateTime>03/07/2013 03:39 PM</surveyDateTime>

<merchantSurveyList>

<merchantSurvey>

<merchantSurveySeqNumber>K/merchantSurveySeqNumber >

<merchantld>2033</merchantld>

<MerchantDocument>021451125488</MerchantDocument>

<MerchantAggregateSalesx/MerchantAggregateSales>

<AverageConsumerSpent >84.5</AverageConsumerSpent>

<ProductServicePurchasex/ProductServicePurchase>

<ListOfPeriods>

<Period type="idle"> <DayRange>Mon , l e, Wed, Thu, Fri</DayRange>

<TimeRange>03PM-06PM</TimeRange>

</Period>

<Period type="slow">

<DayRange>Mon , Tue, Wed</DayRange>

<TimeRange>06PM-10PM</TimeRange>

</Period>

<Period type="peak" >

<DayRange>Thu , Fri</DayRange>

<TimeRange>11AM-03PM, 06PM- 10PM</TimeRange>

</Period>

</ListOfPeriods>

<GPSCoordinates >1.65254125411, -5.698564545</GPSCoordinates> <productData>

<sku>56673953</skuxdescription>hair cut</description> </productData>

<RetailSearchesx/RetailSearches>

<MarketDataAggregatesx/MarketDataAggregates>

<CensusDatax/CensusData>

<Photox/Photo>

<Videox/Video>

<Descriptionx/Description>

<MerchantSite>http: //www. Italian -restaurant . com</MerchantSite> <Email>admin@italian- restaurant . com</Email>

<SocialNetworkinsPage>www.facebook. com/ItalianRestaurant</SocialN etworkinsPage>

<MerchantContactInformation ></MerchantContactInformation >

</merchantSurvey>

<merchantSurvey>

<merchantSurveySeqNumber>2</merchantSurveySeqNumber >

<merchantId x/merchantId >

<MerchantDocument>021451125475</MerchantDocument>

</merchantSurvey>

<merchantSurvey>

<merchantSurveySeqNumber>${n}</merchantSurveySeqNumber >

</merchantSurvey>

</merchantSurveyList>

<dateTime>03/07/2013 03:39 PM</dateTime>

</regionMerchantSurvey>

[00105] In some implementations, ECO ADVANTAGE may parse the data in the survey 508, and may perform analytics 50Q on the data received (e.g. determine which merchants sell the most of a particular product at which times of the day, week, and/or the like, determine which merchants are best known by consumers, and/or the like). ECO ADVANTAGE may update the merchant profile 510, eco schedule, and/or the like for merchants being analyzed. ECO ADVANTAGE may create and/or update region and category information 511 in the ECO ADVANTAGE database based on the merchant information via sending an update query 512 to the ECO ADVANTAGE database 513. In 1 some implementations, an ECO ADVANTAGE administrator may be able to create

2 and/or update regions and categories via administrative user interfaces such as those in

3 FIGURES i8 and 19.

4 [ 00106 ] FIGURES 5b-d show logic flow diagrams illustrating creating and

5 updating regions and categories in example embodiments of the ECO ADVANTAGE. In

6 some implementations, the merchant agent may define a region based on geographic,

7 cultural, industrial, and/or like factors 514, and may search for merchants for merchants

8 enrolled in ECO ADVANTAGE 515. For each merchant 516 being analyzed, the

9 merchant agent may retrieve merchant data 517 such as the merchant's inventory,

10 merchant transaction history, the merchant location, and/or like data from the

11 merchant, and may aggregate data for another if there are more merchants 518. If all the

12 merchants have been analyzed, the merchant agent generate a regional merchant survey

13 based on the merchant data aggregated 519, and may send 520 the regional merchant

14 survey to ECO ADVANTAGE, in some implementations, ECO ADVANTAGE may receive

15 521 the survey, and may parse 522 the data in the survey so that ECO ADVANTAGE may

16 perform analytics on the merchant data 523 (e.g. average sale peaks for each merchant,

17 determine demographics of most common consumers for each merchant, and/or the

18 like. ECO ADVANTAGE may generate individual and/or average eco schedules for each

19 merchant 524 based on the data, wherein the individual schedules may be purely based

20 on the merchant's sales and/or like data, and wherein the average schedules may be

21 based on the aggregate sales and/or the like data of all merchants analyzed. After ECO

22 ADVANTAGE has updated merchant records 2 with updated aggregated information,

23 updated eco schedules, and/or the like, ECO ADVANTAGE may compare the merchant's

24 capacity 526 (e.g. ability to take on new clientele, consumers, and/or the like) to a

25 predetermined threshold of over-capacity. If the merchant is not over capacity 527, ECO

26 ADVANTAGE may make no changes. If the merchant is over capacity, ECO

27 ADVANTAGE may generate a request 528 for data on non-enrolled merchants in the

28 same industry/category as the enrolled merchant, and which are within the merchant's

29 region, and may send 529 the request to the merchant agent. In some implementations,

30 after the merchant agent receives the request 530, the merchant agent may aggregate

31 531 a list of merchants meeting the specified criteria (e.g. category, region, and/or the like), and may, for each merchant 532, aggregate qualitative and quantitative merchant data 533 (see FIGURE 4b for further details), and may add the data 534 to a collective list of merchant prospects for ECO ADVANTAGE. When all merchants have been processed 535, the merchant agent may generate and send the aggregated data 36 of all merchants found to ECO ADVANTAGE, which may, upon receiving 561 the aggregated data, rank 537 the merchants based on pre-specified criteria (e.g. the average and/or total number of customers for the merchant, the merchant's current capacity, the merchant's financial reputation, and/or the like). ECO ADVANTAGE may select 8 the best-ranked merchant on the list and may determine whether the merchant can meet predetermined ECO ADVANTAGE requirements 539. if the merchant would not meet the requirements, ECO ADVANTAGE may select the next best merchant on the list 540, and may perform the same check on the next best merchant. If a merchant meets ECO ADVANTAGE requirements, ECO ADVANTAGE may generate 541 and send 542 an enrollment invitation to the merchant (see FIGURES 4b-c for more detail). In some implementations, after the merchant has enrolled, ECO ADVANTAGE may update 4.3 the region and category that the new merchant belongs to, in order to show that a merchant has been added to both. [ 00107] In some implementations, after performing analytics on enrolled merchants, ECO ADVANTAGE may also wish to compare the population 544 of a particular region to a predetermined population threshold. If the region is deemed to be overpopulated 545, ECO ADVANTAGE may with to divide the region such that each sub-region is not overpopulated. In some implementations this may be done via determining a geographical, demographic, and/or like demarcation category 546 to divide the region by. In some implementations, the demarcation category may include area codes, zip codes, voting districts, wealth pockets, and/or the like. In some implementations, if there is more than one variant of the demarcation category in the region 547 (e.g., if there is more than one area code and/or the like in the region), ECO ADVANTAGE may split the existing region 550 by the one or more variant in the region (e.g. may split the region into two or more sub-regions based on the two or more area codes in the region, and/or the like). If there is only one variant of the demarcation category (e.g. only one area code in the region), ECO ADVANTAGE may determine the 1 latitude and longitude of the center of the region 48 using a region map and/or region

2 location data points, and may split the region 54 Q into quadrants centered on the

3 determined center of the region. In some implementations, ECO ADVANTAGE may

4 designate each new sub-region 551 and may update records related to each new region

5 2 (e.g. category records, merchant records, and/or the like) as being connected with

6 the new region. For each new sub-region 553, ECO ADVANTAGE may also check to

7 determine if the sub-region is also over-populated 4 based on ECO ADVANTAGE'S

8 predetermined threshold, and may similarly split the sub-region if it is over-populated.

9 If not, and if there are no other sub-regions to verify 555, ECO ADVANTAGE may, for0 each new region 556, gather new region information 557 (.g. demographics, industries,1 and/or the like), may update 558 the region's categories, records, and/or the like based2 on the gathered information, and may gather updated information f f Q of merchants3 currently enrolled and in the region (see FIGURES 5a-c for more details). ECO4 ADVANTAGE may continue to do this for each new region until it there are not any new5 regions left to check 560. 6 [ 00108 ] FIGURES 6a-b show data flow diagrams illustrating friend invitations and7 donations in example embodiments of the ECO ADVANTAGE. In some8 implementations, a user 601 may indicate at a merchant PoS device, merchant kiosk, via9 an electronic device 602, and/or using like technology that he would like to donate ecos.0 In some implementations the user may be encouraged to donate ecos that are close to1 expiring after a time period defined by ECO ADVANTAGE, and may be able to donate2 either to charities, organizations, and/or the like, or to friends in the form of a referral3 program. In some implementations the user may send a balance request 603 to ECO4 ADVANTAGE 604, which may ask for the user's current balance, including ecos that will5 expire soon. In some implementations the balance request 603 may be an XML-encoded6 message and may take a form similar to the following:

7 POST /balance_request.php HTTP/1.1

8 Host: www.ECOADVANTAGEprocess.com

9 Content-Type: Application/XML

0 Content-Length: 788

1 <?XML version = "1 . 0" encoding = "UTF-8"?>

2 <balanceRequest> <userld>102557952</userld>

<userIdType>SSN</userIdType >

<ecold>3074</ecold>

<Document>06998524500</Document>

<dateTime>03/07/2013 03:39 PM</dateTime>

</balanceRequest>

[00109] In some implementations, ECO ADVANTAGE may send a balance response 605 which may contain the user's eco balance, expiration date data for all of the ecos, and/or the like. In some implementations the balance response 605 may be an XML-encoded response and may take a form similar to the following:

POST /balance_response.php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

Content-Type: Application/XML

Content-Length: 788

<?XML version = "1.0" encoding = "UTF-8"?>

<balanceResponse>

<userld>102557952</userld>

<userIdType>SSN</userIdType >

<ecold>3074</ecold>

<Document>06998524500</Document>

<ListOfBalance>

<Balance>

<Value>77</Value>

<ExpirationDate>05/15/2013</ExpirationDate>

</Balance>

<Balance>

<Value>200</Value>

<ExpirationDate>06/15/2013</ExpirationDate>

</Balance>

</List0fBalance>

</balanceResponse>

[00110] In some implementations, the user may be able to view his ecos balance via an ecos balance user interface similar to that in FIGURE 21b, and may, using an interface similar to that in FIGURES 2oa-b, choose a number of ecos to donate to a friend, and may send a gift request 606 to ECO ADVANTAGE. In some implementations the gift request 606 may be an XML-encoded message which may take a form similar to the following:

POST /gift_request.php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

Content-Type: Application/XML

Content-Length: 788

<?XML version = "1.0" encoding = "UTF-8"?>

<giftRequest>

<UID>32134321354321345312</UID>

<EcoBlockAmount>400</EcoBlockAmount>

<FriendID>02541478744</FriendID>

<Email>peter@friend . com</Email>

<PhoneNumber>1465448874</PhoneNumber>

</giftRequest>

[ O O I I I] In some implementations, ECO ADVANTAGE may be able to determine whether the friend is already enrolled or not 607, and may allocate 608 the user- specified number of ecos in the user's balance as ecos to be donated to the friend. In some implementations, Grails code for checking for friend enrollment and allocating ecos may take a form similar to the following:

def userGift

User user = User .getByDocument(friendID)

if (user) {

userGift = user

} else {

userGift = TemporaryUser.create(friendID)

}

User user = User.getByDocument(userld)

def userBalance = user.getBalanceQ if (userBalance > ecoBlockAmount) {

sendError("insufficient .funds .for .gifting")

} else {

user . blockForDonation (ecoBlockAmount, UID)

} 1 [ 00112 ] In some implementations, ECO ADVANTAGE may send an allocation

2 confirmation request 60Q to the user. In some implementations the user may confirm

3 610 the gift allocation, which may trigger a confirmation response 611 to be sent to ECO

4 ADVANTAGE, indicating that the user has confirmed the gift allocation to the specified

5 recipient. In some implementations, an XML-encoded confirmation response 611 may

6 take a form similar to the following:

7 POST /confirmation_response.php HTTP/1.1

8 Host: www.ECOADVANTAGEprocess.com

9 Content-Type: Application/XML

10 Content-Length: 788

11 <?XML version = "1 . 0" encoding = "UTF-8"?>

12 <giftConfirmation>

13 <UID>32134321354321345312</UID>

14 <EcoBlockAmount>500</EcoBlockAmount>

15 <FriendID>02541478744</FriendID>

16 <Confirm>true</Confirm>

17 </giftConfirmation>

18 [ 00113 ] ECO ADVANTAGE may send a gift notification 612 to friend 613

19 containing information regarding the eco gift. In some implementations gift notification

20 612 may be sent via physical mail, email, and/or the like, and may take a form similar to

21 the following:

22 From: john@friend.com

23 To: peter@friend.com

24 Subject: You won a gift from John

25

26 Are you getting 400 ecos to spend using Eco Advantage

27

28 Sign up to take advantage

29

30 GiftID: 32134321354321345312

31 UserlD: 02541478744

32 [ 00114 ] The friend may send an enrollment request 614 to ECO ADVANTAGE with

33 information necessary to create an account for the friend. In some implementations, an

34 XML-encoded friend enrollment request may take a form similar to application request 313, 314, or 315. In some implementations, sensitive information (e.g. the user PIN and/or the like) may be encrypted.

[ooii5] In some implementations, ECO ADVANTAGE may instantiate 615 a user account for the friend using the enrollment data provided, via sending a user account insert query 616 to the users 6i7d table of the ECO ADVANTAGE database 617. In some implementations, ECO ADVANTAGE may transfer 618 the block of ecos from the user to the friend (e.g. by moving the ecos to the friend's new account, designating them as "donation ecos," resetting the expiration date for the ecos donated, and/or like record- updating). In some implementations, example Grails code for transferring the ecos may take a form similar to the following:

DonationBlock donation = DonationBlock.getbyUID(UID)

User userFrom = donation . userFrom

User userTo = donation . userTo

userFrom. donate(UID, userTo)

[ 00116 ] In some implementations, ecos designated as being donated may not be donated again by any user, and may only be able to be spent. In some implementations, ECO ADVANTAGE may update records via ecos update 6iQ. [ 00117] In some implementations, ECO ADVANTAGE may send a confirmation to the user 621 indicating that the user's ecos have successfully been transferred to the friend, along with a confirmation to friend 620 indicating that the donated ecos have been successfully transferred to the friend's new account. [ 00118 ] Referring to FIGURE 6b, in some implementations, friend 613 may use the donated ecos 622 in a plurality of transactions (see FIGURES 2a-d for more details). ECO ADVANTAGE may monitor 623 the spending of the user's donated ecos, and may, when the friend has spend some predetermined amount of the donated ecos 624, allocate an invite bonus block to the user's account, via sending an invite bonus block update 625 to the ECO ADVANTAGE database. In some implementations, Grails code for monitoring the spending of donated ecos may take a form similar to the following: def listOfDonation = Donation .findbyBonusBlockld(null) foreach (donation in listOfDonation) { def userFrom = donation . userFrom

def userTo = donation . userTo

def amount = donaction . amount

def date = donation .date def usedAmountSinceDonation transaction .getByUserAndSinceDate(userTo, date) call eligibleForBonusBlock(donation, usedAmountSinceDonation) }

[ 00119 ] In some implementations, Grails code for allocating invite bonus blocks may take a form similar to the following:

function eligibleForBonusBlock( donation, usedAmountSinceDonation) {

if ( usedAmountSinceDonation >= (donation . amount * ecoAdvantageConfig.donationFactor)) {

def bonusBlockld = donation . userFrom. creditBonusBlock( ) donation . bonusBlockld = bonusBlockld;

donation . save( )

}

}

[ 00120 ] In some implementations, the bonus block update query 625 may be a PHP-encoded insert statement. [ 00121 ] In some implementations, the user may receive confirmation 626 that the invite bonus block has been credited to the user's account, which may include the value of the invite bonus block, the date it was credited, and/or the like. The user may participate in a qualifying transaction 627, such as a purchase transaction at an enrolled merchant 628 (see FIGURES 2a-d). In some implementations, a qualifying transaction may include a transaction where the combination of using ecos and bonus blocks will result in a transaction balance (e.g. using ecos and/or bonus blocks does not result in a free purchase and/or the like), a transaction that reaches a bonus block threshold (e.g. a minimum value at which a user can use bonus blocks towards a transaction), a transaction initiated at a particular merchant, in a particular region, in a particular category, for a particular product, at a particular time of day, on a particular day of the 1 week, after a predetermined amount of ecos have been used by the user, after the user

2 has donated a predetermined amount of ecos, and/or the like.

3 [ 00122 ] In some implementations, if the friend has not spent a predetermined

4 amount of the donated ecos after a predetermined time period, ECO ADVANTAGE may

5 send a message to the friend and/or user indicating that the donated ecos have not been

6 spent, and may include current eco percentages for various merchants and/or the like in

7 order to incentivize the spending of the donated ecos. The message may be sent via

8 physical mail, email, text, private messages through ECO ADVANTAGE, and/or the like.

9 [ 00123] In some implementations, the merchant may send an eco request 62Q

10 (which may resemble eco message 206), and receive eco response 630 (which may

11 resemble eco message 212), and which may contain information regarding the user's

12 newly-obtained invite bonus block. In some implementations, the merchant may allow

13 the user to apply 632, in addition to available ecos, the newly obtained invite bonus

14 blocks to the remaining purchase balance. In some implementations the merchant may

15 print and/or display the ecos and/or invite bonus block balances for the user, and may

16 prompt the user to confirm and/or authenticate the transaction. The merchant may

17 process the transaction similarly to that in FIGURES 2a-d.

18 [ 00124 ] FIGURES 6c-d show logic flow diagrams illustrating friend invitations and

19 donations in example embodiments of the ECO ADVANTAGE. In some

20 implementations, the user may obtain 633 his ecos balance, along with an indication of

21 which ecos will expire soon and which can be donated to other parties. The user may

22 choose a block of expiring ecos 634 to donate, and may use his electronic device (and/or

23 a device provided by the merchant, e.g. a merchant's PoS device) to generate and send

24 635 a gift request to ECO ADVANTAGE indicating the friend to donate to and the

25 amount of ecos to donate. In some implementations ECO ADVANTAGE may receive

26 636 the gift request, and may determine whether the friend is enrolled in ECO

27 ADVANTAGE 637. ECO ADVANTAGE may generate and send a transfer confirmation

28 638 to the user, which may include friend identification information (and may contain

29 friend account information, if the friend is enrolled in ECO ADVANTAGE). The user

30 may receive 63Q the gift transfer confirmation, and may decide whether to confirm the

31 transaction or not 640. If the user would like to confirm the transfer, ECO ADVANTAGE may, if the friend is enrolled 641, transfer the specified block of ecos to the friend 642, may update the user's and friend's balances, may mark the transferred ecos as "donated ecos" 643 and reset the expiration dates of the donated ecos, and/or take care of other transfer details. ECO ADVANTAGE may notify the user and the friend 644 that the ecos were successfully transferred from the user to the friend. [ 00125] If the friend is not enrolled, ECO ADVANTAGE may instead allocate a block of the user's ecos 645 to be donated to the friend, and may prepare and send a template or customized enrollment form 646 to the friend. The friend may receive the enrollment form 647, along with the amount of ecos being donated to them, from whom, and/or the like. If the friend declines to enroll 648, ECO ADVANTAGE may deactivate the enrollment invitation 649, and may send a notification to the user that his enrollment invite has been deactivated 650 because the friend did not wish to enroll in ECO ADVANTAGE. If the friend chooses to enroll 648, the friend may do so by completing and submitting the enrollment form 651 to ECO ADVANTAGE, which may create a user account 652 for the friend based on the provided enrollment data in the friend's submitted enrollment form. ECO ADVANTAGE may transfer 653 the allocated block of ecos to be donated from the user account to the friend's new account, and may update the user's and friend's eco balances. ECO ADVANTAGE may mark the transferred ecos as "donation ecos" 654, along with resetting their expiration date and/or the like. The user may be notified of a successful eco donation 655. [ 00126 ] In some implementations, the friend may use the donated ecos in one or more subsequent transactions 656 (see FIGURES 2a-d for more details), which may be monitored 657 by ECO ADVANTAGE. If ECO ADVANTAGE finds that the friend has spent some pre-defined number and/or percentage of the donated ecos 658, it may allocate 65Q a predetermined invite bonus block value to the user, and may update the user's account 660 with the allocated invite bonus block. ECO ADVANTAGE may generate may generate 661 and send 662 a confirmation message to the user indicating that a predetermined number ecos donated by the user have been spent, that the user is consequently receiving an invite bonus block, the user's current ecos and invite bonus block balances, and/or the like, the user may receive 663 the confirmation and may subsequently make a purchase and/or initiate a transaction 664 at a merchant enrolled 1 in ECO ADVANTAGE. The merchant may request from ECO ADVANTAGE 665 the

2 user's transaction information, including the user's eco and invite bonus block balances,

3 and/or the like, and may receive and print and/or display 666 said user transaction

4 information for the user so that the user may confirm the transaction. If the user

5 confirms the use of his ecos and the new invite bonus block 667, the merchant may

6 complete 668 the transaction via applying the ecos and invite bonus block to the

7 transaction balance, and may update the user's ecos and invite bonus block balances in

8 the ECO ADVANTAGE database.

9 [ 00127] FIGURE 7a shows a data flow diagram illustrating slow commit, credit-

10 only transactions in example embodiments of the ECO ADVANTAGE. In some

11 implementations, a user 701 may send a transaction initiation request 703 (which may

12 take a form similar to transaction initiation 205) to the merchant 704 using the

13 merchant's PoS device and/or a user electronic device 702. In some implementations,

14 sensitive information (e.g. the user PIN and/or the like) may be encrypted. In some

15 implementations, the merchant may send an eco request 705 to the ECO ADVANTAGE

16 706. In some implementations, eco request 705 may take a form similar to eco request

17 206. ECO ADVANTAGE may look up the user's and merchant's records using the user

18 ID (UID) and the merchant ID 707, respectively, and may determine which and how

19 many ecos and bonus blocks the user may apply to his transaction (e.g. based on the

20 merchant's eco schedule, the user's eco and bonus block balances, and/or the like), and

21 may determine the state of a user confirmation setting. If the confirmation setting is set

22 to "true," ECO ADVANTAGE may require the user to confirm his transaction before

23 initiating any portion of it. In some implementations the confirmation setting may be

24 set by the user, by a merchant (e.g., to require verification at the merchant), and/or the

25 like, in some implementations, for example, some merchants may require verification

26 before a transaction based on information contained in the ecos response (e.g. just

27 received ecos from a distant location and/or like fraud triggers). In some

28 implementations ECO ADVANTAGE may send an eco response 708 back to the

29 merchant, which may take a form similar to eco response 212. In some

30 implementations, the merchant may display and/or print 70Q the ecos information for

31 the user, who may review the information 710 and confirm the transaction, including 1 the ecos and/or bonus blocks to be used in the transaction. In some implementations

2 confirming the transaction may include authenticating the transaction, e.g., via

3 providing a password, user PIN, positive identification (e.g. birthday, last four digits of

4 cellphone number or SSN, street address, and/or the like). In some implementations the

5 user may choose to pay for the transaction using a credit card, debit card, prepaid card,

6 travel card, voucher cards, and/or the like. The merchant may send a payment request

7 711 to the merchant's acquirer 713, which may ask the entity to process the transaction.

8 In some implementations, payment request 711 may take a form similar to the following:

9 POST /payment_request.php HTTP/1.1

0 Host: www.ECOADVANTAGEprocess.com

1 Content-Type: Application/XML

2 Content-Length: 788

3 <?XML version = "1 . 0" encoding = "UTF-8"?>

4 <paymentRequest>

5 <posld>4088</posld>

6 <merchantld>2033</merchantld>

7 <amountDuelnDollars>77.0</amountDueInDollars>

8 <dateTime>03/07/2013 03:39 PM</dateTime>

9 <userCard>3214 3578 3568 3542</userCard>

0 </paymentRequest>

1 [00128] In some implementations payment request 711 may only include the2 transaction balance after ecos and/or bonus blocks have been applied. The acquirer may3 prepare 712 the transaction and procure payment via sending a transaction request 7144 to a bank entity 715 (e.g. the user's issuing bank, another acquirer, and/or the like). 5 [00129] The bank may send a transaction response 716 to the acquirer, which may6 indicate whether or not the transaction was approved and/or processed, or whether the7 transaction was declined. The acquirer may forward this information to ECO8 ADVANTAGE via transaction confirmation 717, which may take a form similar to9 transaction confirmation 219, or may forward the information to the merchant via0 transaction confirmation 718 (which may take a form similar to transaction1 confirmation 219), who may forward the information via transaction confirmation 7192 to ECO ADVANTAGE. In some implementations, the entity the acquirer forwards the3 confirmation to may depend on the security of the entities, entity resources, and/or the4 like. In some implementations ECO ADVANTAGE may not receive the confirmation5 (e.g., via the acquirer or the merchant). In some implementations, transaction confirmation 719 may take a form similar to transaction confirmation 219. Once ECO ADVANTAGE has received a transaction confirmation, it may debit 720 the used ecos and bonus blocks from the user's balances, may credit to the user with new ecos equal to a predetermined amount related to the transaction amount, and may update the user's balances. In some implementations, Grails code for updating the user's balances may take a form similar to the following:

Transaction transaction = Transaction .get(transactionld)

User user = transaction. getUserQ

Merchant merchant = transaction. getMerchantQ

long ecoUsage = transaction. getEcoUsage()

long bonusBlockUsage = transaction. getBonusBlockUsage( )

Try {

beginTransaction( )

user .debitEco(ecoUsage)

user .debitBonusBlock( bonusBlockUsage)

commitTransactionQ;

} catch (Exception) {

rollbackTransactionQ;

return false;

}

[00130] ECO ADVANTAGE may also update the merchant account record 721, including updating BI information, transaction data, the merchant's usage schedule, atmospherics, and/or the like. In some implementations, Grails code for updating the user's balances may take a form similar to the following:

Transaction transaction = Transaction .get(transactionld)

User user = transaction. getUserQ

Merchant merchant = transaction. getMerchantQ

long amountDuelnDollars = transaction. getAmountDuelnDollarsQ

Try {

beginTransaction( )

user.creditEco(amountDueInDollars, merchant)

commitTransactionQ;

} catch (Exception) {

rollbackTransactionQ; return false;

}

[ 00131 ] ECO ADVANTAGE may send an eco credit confirmation 722 to the merchant in order to indicate that the transaction was successful and that the user's balances have been updated. In some implementations, eco credit confirmation 722 may take a form similar to the following:

POST /eco_credit_confirmation.php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

Content-Type: Application/XML

Content-Length: 788

<?XML version = "1 . 0" encoding = "UTF-8"?>

<ecoCreditConfirmation>

<UID>da6c5cdf4e90b2961873f7b2e863415</UID>

<newEcos>77</newEcos>

<bonusBlock>0</BonusBlock>

<usedEcos>23</usedEcos>

<EcoBalance>109K/EcoBalance>

<ecoCreditConfirmation>

[ 00132 ] In some implementations, the merchant may use the eco credit confirmation to generate and send a transaction receipt 723 to the user, which may contain information similar to the following:

DOCUMENT: NNN . NNN . NNN-NN ID EAS :

USED EC0S: VVV.WV,VV

USED BONUS BLOCKS: VVV.WV,VV

NEW EC0S: ΕΕΕ.ΕΕΕ,ΕΕ

NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN ECO BALANCE: ΒΒΒ.ΒΒΒ,ΒΒ

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

[ 00133 ] In some implementations, ECO ADVANTAGE may also monitor the status of various transactions, and may reverse, retry, and/or otherwise handle incomplete transactions if found in the ECO ADVANTAGE database's records, based on predetermined criteria. 1 [ 00134 ] FIGURE 7b shows a logic flow diagram illustrating slow commit, credit-

2 only transactions in example embodiments of the ECO ADVANTAGE. In some

3 implementations, a user may initiate 724 a transaction with an enrolled merchant, via

4 providing transaction input to a merchant. The merchant may receive the user input and

5 transaction information 725, and may generate and send a request to ECO

6 ADVANTAGE for the user's eco and/or bonus block balances. In some implementations,

7 ECO ADVANTAGE may receive 726 the request for the user's eco and bonus block

8 balance, and may retrieve from the ECO ADVANTAGE database 727 the user's available

9 ecos, bonus blocks, and/or the like to determine which and how many ecos and bonus

10 blocks may be applied to the current transaction, as well as to determine the user's

11 confirmation setting. If the confirmation setting is on 728, ECO ADVANTAGE may

12 generate 729 and send 730 a response to the merchant indicating the user's eco and/or

13 bonus block balances and/or like transaction information. The merchant may receive

14 the balance information 731 and forward the information to the user via displaying

15 and/or printing the transaction information for the user and asking the user to confirm

16 the transaction. The user may authenticate 732 the transaction and the use of his ecos

17 and/or bonus blocks towards the purchase using his password, user PIN, and/or a like

18 form of identification. In some implementations, the merchant may generate and send a

19 payment request 733 with the user's payment information, the transaction balance after

20 subtracting the applied ecos and/or bonus blocks to the original transaction amount,

21 and/or like information to an acquirer for procurement. In some implementations the

22 acquirer may receive 734 the user's payment information, transaction data, and/or the

23 like, and may request the transaction balance 735 from the user's issuing bank.

24 [ 00135 ] If the acquirer can successfully procures the funds 736, the acquirer may

25 obtain the funds 737 and may send a confirmation to the merchant (and in some

26 implementations, to ECO ADVANTAGE) indicating that the transaction was successfully

27 processed. In some implementations the merchant may, if the transaction was

28 successful 739, forward the success notification to ECO ADVANTAGE, which may

29 obtain the confirmation of a successful transaction 743 and may use the confirmation to

30 debit the ecos and/or bonus blocks used in the transaction, credit to the user's account

31 744 a predetermined amount related to the transaction amount, and may update the user's balance, as well as updating merchant and transaction records 745 using the information described in 721 and/or like information.

[o o i36] If the acquirer cannot successfully procure the funds 736, the acquirer may send a notification of transaction failure 738 to the merchant (and, in some implementations, to ECO ADVANTAGE). The merchant may, after determining the transaction was not successful 739, send a notification to the user 740, along with a prompt to retry the transaction (e.g. with a different payment method and or the like). In some implementations the merchant may also forward the notification to ECO ADVANTAGE which, after obtaining the notification of transaction failure 741, may mark all related records (e.g. transaction records and/or the like) 742 as being incomplete until the transaction is successfully processed, until the user cancels the transaction, and/or the like. In some implementations, ECO ADVANTAGE may also monitor the status of various transactions, and may reverse, retry, and/or otherwise handle incomplete transactions if found in the ECO ADVANTAGE database's records, based on predetermined criteria.

[00137] FIGURE 8a shows a data flow diagram illustrating fast commit, credit- only transactions in example embodiments of the ECO ADVANTAGE. In some implementations, a user 801 may send a transaction initiation request 803 to the merchant 804 using the merchant's PoS device and/or a user electronic device 802. In some implementations, sensitive information (e.g. the user PIN and/or the like) may be encrypted. In some implementations, the transaction initiation request may take a form similar transaction initiation 205, or may take a form similar to the following:

POST / transaction_intitation_request .php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

Content-Type: Application/XML

Content-Length: 788

<?XML version = "1 . 0" encoding = "UTF-8"?>

<InitiateTransactionRequest>

<UID>32134321354321345312</UID>

<ProductData>haircut</ProductData>

<TransactionAmount>100</TransactionAmount>

<UserPIN>3214 3558 1587 9877</UserPIN> < /InitiateTransactionRequest >

[o o i38] In some implementations, sensitive information (e.g. the user PIN and/or the like) may be encrypted. In some implementations, the merchant may send an eco request 805 to the ECO ADVANTAGE 806. In some implementations, eco request 805 may take a form similar to eco request 206. ECO ADVANTAGE may look up the user's and merchant's records using the user ID (UID) and the merchant ID 807, respectively, and may determine which and how many ecos and bonus blocks the user may apply to his transaction (e.g. based on the merchant's eco schedule, the user's eco and bonus block balances, and/or the like), and may determine the state of a user confirmation setting. If the confirmation setting is set to "false," ECO ADVANTAGE may not require the user to confirm his transaction before initiating any portion of it. In some implementations ECO ADVANTAGE may debit 808 the used ecos and bonus blocks from the user's balances, may credit to the user with new ecos equal to a predetermined amount related to the transaction amount, and may update the user's balances. ECO ADVANTAGE may also update the merchant account record 809, including updating BI information, transaction data, the merchant's usage schedule, atmospherics, and/or the like.

[00139] ECO ADVANTAGE may send an eco response 810 back to the merchant, which may take a form similar to eco response 212. The merchant may send a payment request 811 to the merchant's acquirer 813, which may ask the entity to process the transaction. In some implementations, payment request 811 may take a form similar to payment request 215. The acquirer may prepare 812 the transaction and procure payment via sending a transaction request 814 to a bank entity 815 (e.g. the user's issuing bank, another acquirer, and/or the like). In some implementations, the transaction request 814 may take a form similar to transaction request 714. The bank may send a transaction response 816 to the acquirer, which may indicate whether or not the transaction was approved and/or processed, or whether the transaction was declined. The acquirer may forward this information to ECO ADVANTAGE via transaction confirmation 819, which may take a form similar to transaction confirmation 219, or may forward the information to the merchant via transaction confirmation 817 (which may take a form similar to transaction confirmation 219), who 1 may forward the information via transaction confirmation 818 to ECO ADVANTAGE. In

2 some implementations, transaction confirmation 818 may take a form similar to

3 transaction confirmation 719. In some implementations, the merchant may use the eco

4 credit confirmation to generate and send a transaction receipt 820 to the user, which

5 may contain information similar to transaction receipt 723. In some implementations,

6 ECO ADVANTAGE may also monitor the status of various transactions, and may

7 reverse, retry, and/or otherwise handle incomplete transactions if found in the ECO

8 ADVANTAGE database's records, based on predetermined criteria.

9 [ 00140 ] FIGURE 8b shows a logic flow diagram illustrating fast commit, credit-

10 only transactions in example embodiments of the ECO ADVANTAGE. In some

11 implementations, a user may initiate 821 a transaction with an enrolled merchant, via

12 providing transaction input to a merchant. The merchant may receive the user input and

13 transaction information 822, and may generate and send a request to ECO

14 ADVANTAGE for the user's eco and/or bonus block balances. In some implementations,

15 ECO ADVANTAGE may receive 82 the request for the user's eco and bonus block

16 balance, and may retrieve from the ECO ADVANTAGE database 824 the user's available

17 ecos, bonus blocks, and/or the like to determine which and how many ecos and bonus is blocks may be applied to the current transaction, as well as to determine the user's

19 confirmation setting. If the confirmation setting is off 825, ECO ADVANTAGE may

20 calculate and automatically debit 826 from the user's account the ecos and/or bonus

21 blocks that the user may apply to the purchase. ECO ADVANTAGE may also subtract

22 the ecos and bonus blocks being used from the transaction total 827, and may credit to

23 the user's account a number of ecos equal to a predetermined amount based on the

24 transaction balance and/or total. ECO ADVANTAGE may generate a transaction record

25 828 encapsulating the original transaction amount, the user and merchant involved, the

26 amount of ecos and/or bonus blocks used in the transaction, the remaining transaction

27 balance, the date of the transaction, and/or like information, and may update the

28 merchant records 829 with the transaction data and/or like data as described in 809,

29 and/or like information. In some implementations, ECO ADVANTAGE may generate a

30 transaction receipt 831 to send to the merchant who, once it has received 832 the

31 transaction receipt and the remaining balance, may generate 849 and send 833 a 1 payment request with the user's payment information, the transaction balance after

2 subtracting the applied ecos and/or bonus blocks to the original transaction amount,

3 and/or like information to an acquirer for procurement. In some implementations the

4 acquirer may receive 834 the user's payment information, transaction data, and/or the

5 like, and may generate and send a request to the user's issuing bank 835 for the

6 transaction balance.

7 [00141] If the acquirer can successfully procures the funds 836, the acquirer may

8 obtain the funds 837 and may send a confirmation to the merchant (and in some

9 implementations, to ECO ADVANTAGE) indicating that the transaction was successfully

10 processed. In some implementations the merchant may, if it receives a notification 838

11 indicating a successful transaction, print and/or display a transaction receipt 83Q for the

12 user, and may generate 840 and send 841 a transaction confirmation message to ECO

13 ADVANTAGE indicating that the transaction was successful. ECO ADVANTAGE may,

14 after receiving 842 the transaction confirmation, save the confirmation within the

15 transaction record in the ECO ADVANTAGE database in order to mark the transaction

16 as completed.

17 [ 00142 ] If the acquirer cannot successfully procure the funds 836, the acquirer

18 may send a notification of transaction failure 843 to the merchant (and, in some

19 implementations, to ECO ADVANTAGE). The merchant may, after receiving 844 the

20 notification of a failed transaction, generate and send 845 a transaction confirmation to

21 ECO ADVANTAGE indicating the transaction failed, and may also display and/or print

22 846 a notification of transaction failure for the user and/or may prompt the user to retry

23 the transaction (e.g. with a different payment method and/or the like). ECO

24 ADVANTAGE may receive 847 the transaction confirmation message and mark the

25 transaction as incomplete and necessary to retry, and mark related records (e.g. the

26 user's record, the merchant's record and/or the like) as also being incomplete 848. In

27 some implementations, ECO ADVANTAGE may also monitor the status of various

28 transactions, and may reverse, retry, and/or otherwise handle incomplete transactions if

29 found in the ECO ADVANTAGE database's records, based on predetermined criteria.

30 [ 00143 ] In some implementations, ECO ADVANTAGE and/or the merchant may

31 prompt the user to confirm after the transaction has been committed and processed. In 1 such implementations, if the user confirms the transaction, the user may receive

2 transaction receipt 820. If the user declines the transaction, ECO ADVANTAGE may

3 cancel the processed transaction (see FIGURES i5a-b).

4 [ 00144 ] FIGURE 9a shows a data flow diagram illustrating merchant reconciliation

5 in example embodiments of the ECO ADVANTAGE. In some implementations, ECO

6 ADVANTAGE 901 may determine the balance owed to a merchant in ECO ADVANTAGE

7 902 (e.g. based on incomplete transaction records and/or the like), and may generate a

8 batch payment request to the acquirer. In some implementations, ECO ADVANTAGE

9 may send a batch payment request 903 to an acquirer 904· In some implementations,0 an exemplary batch payment request 903 may take a form similar to the following:

1 POST / batch_payment_request.php HTTP/1.1

2 Host: www.ECOADVANTAGEprocess.com

3 Content-Type: Application/XML

4 Content-Length: 788

5 <?XML version = "1 . 0" encoding = "UTF-8"?>

6 <batchPaymentRequest>

<listOfPaymentRequest >

<paymentRequest >

<id>125414</id>

<ecoadvantage>true</merchantId >

<balanceOwed>8547.00</balanceOwed>

<requestDate>05/13/2013</requestDate>

</paymentRequest>

<paymentRequest >

<id>125415</id>

<acquirer>2033</merchantId>

<balanceOwed>54871.00</balanceOwed>

<requestDate>05/13/2013</requestDate>

</paymentRequest>

<paymentRequest >

<id>125416</id>

<merchantld>2034</merchantld>

<balanceOwed>125.00</balanceOwed>

<requestDate>05/13/2013</requestDate> </paymentRequest>

<paymentRequest >

<id>125417</id>

<merchantld>2035</merchantld>

<balanceOwed>588.00</balanceOwed>

<requestDate>05/13/2013</requestDate>

</paymentRequest>

</listOfPaymentRequest >

</batchPaymentRequest>

[ 00145 ] The acquirer may perform 905 reconciliation with various payment entities via sending a payment instruction message 906 to the user's issuing bank 907 and an acquirer payment instruction message 908 to an acquiring bank 909. In some implementations, the issuer bank may send a bill 910 to the user 911, who may view the bill in the merchant location or via the user's electronic device 912. The user may send a payment indication 913 to the issuer in order to indicate that the issuer should provide the funds for the payment. [ 00146 ] The issuer may send a merchant payment message 914 to the merchant's bank 915, which may include the funds requested for the payment being processed. The issuer may also send an acquirer payment 916 to the acquiring bank 909, which may include a payment to the acquirer for processing the transaction. The acquiring bank may, using the acquirer payment instructions 908 and the acquirer payment 916, calculate a payment value to be sent to ECO ADVANTAGE 918, and may send the ECO ADVANTAGE Payment 917 to ECO ADVANTAGE. In some implementations, ECO ADVANTAGE may also send a confirmation request to the acquirer containing a request date, in order to determine whether the batch payment was successful. In some implementations, ECO ADVANTAGE may receive a confirmation once the payment has been processed at the ECO ADVANTAGE bank, which may include a confirmation that the transaction was successfully processed, the transaction ID for each transaction from the acquirer, and/or the like, for each transaction in the batch. [ 00147] FIGURE 9b shows a logic flow diagram illustrating merchant reconciliation in example embodiments of the ECO ADVANTAGE. In some implementations, for each acquirer connected to ECO ADVANTAGE 919, ECO ADVANTAGE may check every merchant 920 that uses the acquirer to see if any reconciliation is necessary for the merchant. ECO ADVANTAGE may query 921 the database for transaction data, merchant data, the merchant's eco schedule, the acquirer's earning percentage, the maximum amount of total funds that the acquirer can process at the time, and/or the like. For each transaction in the transaction data that is unreconciled 922, ECO ADVANTAGE may calculate the transaction total for the transaction, and may also calculate what the acquirer's running transaction total at the time, the merchant's running transaction total at the time, and the ECO ADVANTAGE transaction total at the time would be if the transaction is reconciled 923 at the time. If the transaction is not processable 924 (e.g., if the projected totals do not exceed the maximum amount of total funds that may be processed by the acquirer at the time), ECO ADVANTAGE may determine whether there are other unreconciled transactions 928 (e.g. in case another unreconciled transaction may be processable), and may continue to check each unreconciled transaction in the database. [ 00148 ] If the transaction is processable, ECO ADVANTAGE may also check to determine whether the projected totals would be less than the merchant's maximum amount of possible funds to process 925. If not, ECO ADVANTAGE may determine whether there are any other unreconciled transactions to process 928. If the projected totals are also less than the merchant's maximum processable funds amount, ECO ADVANTAGE may update the actual calculated running totals 926 to reflect the calculated running total of the merchant, acquirer, ECO ADVANTAGE, and/or the like once the transaction is processed. ECO ADVANTAGE may also keep a running total for different payment methods, such as the total amount of funds to be received from credit/debit cards, the total amount of funds received in cash, the total amount of funds received in ecos, and/or the like. ECO ADVANTAGE may update 927 the ECO ADVANTAGE database records with the totals calculated at the time, and may update the transaction record to reflect that the transaction has been reconciled. Once all transactions have been checked, ECO ADVANTAGE may update 929 the running total for the acquirer based on the merchant's totals and may check to see if there are any other merchants to process 930. If so, ECO ADVANTAGE may calculate the same totals for the remaining merchants; if not, ECO ADVANTAGE may prepare 931 a batch payment request to an acquirer using the data obtained from all the processed merchants, and may send Q32 the batch payment request to the acquirer for payment processing. If there are other acquirers Q33 to process, ECO ADVANTAGE may repeat the process for each other acquirer connected with ECO ADVANTAGE.

[ooi49] In some implementations, Grails code for processing the batch payment may take a form similar to the following:

def totalEcoAdvantage = 0

def batchPayment = [] def listOfAquirer = Acquirer. findAHQ foreach(aquirer in listOfAquirer) { def totalAcquirer = 0 def listOfMerchant = Merchant .findbyAquirerer(acquirer) foreach(merchant in listOfMerchant) { def totalMerchandFund = 0

def totalMerchant = 0 def listOfTransaction

Transaction .findByAcquirerAndMerchant(acquirer, merchant) foreach(transaction in listOfTransaction) { if (NOT transaction . reconciled) { def totalTransaction = transaction . calculateTotal( ) totalMerchant = totalMerchant + transaction . calculateTotalMerchant ( )

totalAcquirer = totalAcquirer + transaction . calculateTotalAcquirer( )

totalEcoAdvantage = totalEcoAdvantage + transaction . calculateTotalEcoAdv( ) if (totalMerchandFund + totalMerchant <

SystemSetting.getMaxFundToMerchantO) { Reconcilation reconcilation = new ReconcilationQ

reconcilation .merchant = merchant

reconcilation . acquirer = acquirer

reconcilation .date = today()

reconcilation .totalTransaction = totalTransaction

reconcilation .totalMerchant = transaction. calculateTotalMerchantQ reconcilation .totalAcquirer = transaction . calculateTotalAcquirer( ) reconcilation .totalEcoAdvantage = transaction . calculateTotalEcoAdv( ) reconcilation .totalCash = transaction. calculateTotalCashQ

reconcilation .totalCard = transaction. calculateTotalCardQ

reconcilation .totalEco = transaction . calculateTotalEco( )

reconcilation. save() transaction . reconciled = true

transaction . save( ) ;

totalMerchandFund =+ totalMerchant }

}

} PaymentRequest paymentRequest = new PaymentRequestQ;

paymentRequest .merchant = merchant;

paymentRequest . balanceOwed = totalMerchant;

paymentRequest . requestDate = new Date();

paymentRequest . confirmed = false;

paymentRequest . save( )

batchPayment.push(payment: paymentRequest) } PaymentRequest paymentRequest = new PaymentRequestQ; paymentRequest . acquirer = acquirer;

paymentRequest . balanceOwed = totalAcquirer;

paymentRequest . requestDate = new Date();

paymentRequest . confirmed = false;

paymentRequest . save( )

batchPayment.push(payment: paymentRequest)

} PaymentRequest paymentRequest = new PaymentRequestQ;

paymentRequest .ecoAdvantage = true;

paymentRequest . balanceOwed = totalEcoAdvantage;

paymentRequest . requestDate = new Date();

paymentRequest . confirmed = false;

paymentRequest . save( )

batchPayment.push(payment: paymentRequest) render batchPayment as XML;

[00150] FIGURE 10a shows a data flow diagram illustrating slow commit, cash and credit transactions in example embodiments of the ECO ADVANTAGE. In some implementations, a user 1001 may send a transaction initiation request 1003 to the merchant 1004 using the merchant's PoS device and/or a user electronic device 1002. In some implementations, sensitive information (e.g. the user PIN and/or the like) may be encrypted. In some implementations, the merchant may send an eco request 1005 to the ECO ADVANTAGE 1006. In some implementations, eco request 1005 may take a form similar to eco request 206. ECO ADVANTAGE may look up the user's and merchant's records using the user ID (UID) and the merchant ID 1007, respectively, and may determine which and how many ecos and bonus blocks the user may apply to his transaction (e.g. based on the merchant's eco schedule, the user's eco and bonus block balances, and/or the like), and may determine the state of a user confirmation setting. If the confirmation setting is set to "true," ECO ADVANTAGE may require the user to confirm his transaction before initiating any portion of it. In some implementations ECO ADVANTAGE may send an eco response 1008 back to the merchant, which may take a form similar to eco response 212. 1 [00151] In some implementations, the merchant may display and/or print lOOQ

2 the ecos information for the user, who may review the information 1010 and confirm the

3 transaction, including the ecos and/or bonus blocks to be used in the transaction. The

4 user may also choose to pay some part of the transaction with cash. In some

5 implementations, the cash payment may also be a check, gift coupon, pre-paid gift

6 voucher, community scrip, electronic fund transfer, a money card, money order, bank

7 transfer, bank payment slip, and/or a like payment method. In such cases, the merchant

8 may send a cash transaction confirmation message 1011 to ECO ADVANTAGE

9 indicating that the user has already paid part of the transaction balance in cash, and is

10 to pay the rest with a credit/debit card, and/or the like. ECO ADVANTAGE may debit

11 1012 the ecos and/or bonus blocks being used towards the transaction from the user

12 account, may credit the user account with a predetermined amount of ecos based on the

13 cash payment, and may update the user's balances.

14 [00152] The merchant may send a payment request 1013 to the merchant's

15 acquirer 1014, which may ask the entity to process the transaction. In some

16 implementations, payment request 1013 may take a form similar to payment request

17 215. The acquirer may prepare 1015 the transaction and procure payment via sending a

18 transaction request 1016 to a bank entity 1017 (e.g. the user's issuing bank, another

19 acquirer, and/or the like). The bank may send a transaction response 1018 to the

20 acquirer, which may indicate whether or not the transaction was approved and/or

21 processed, or whether the transaction was declined. The acquirer may forward this

22 information to ECO ADVANTAGE via transaction confirmation 1021, which may take a

23 form similar to the following:

24 POST /transaction_confirmation.php HTTP/1.1

25 Host: www.ECOADVANTAGEprocess.com

26 Content-Type: Application/XML

27 Content-Length: 788

28 <?XML version = "1 . 0" encoding = "UTF-8"?>

29 <paymentConfirmation>

30 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>

31 <transactionId>635467</transactionId>

32 <merchantld>2033</merchantld> <posld>4088</posld>

<amounDueInDollars>77.0</amountDuelnDollars>

<bonusBlockAmount>20</bonusBlockAmount>

<debitCreditAmount >27.0</debitCreditAmount>

<cashAmount>50.0</cashAmount>

<totalAmount>100</totalAmount>

<dateTime>03/07/2013 03:40 PM</dateTime>

<approved>true</approved>

</paymentConfirmation>

[00153] In some implementations the acquirer may forward the information to the merchant via transaction confirmation 101Q (which may take a form similar to transaction confirmation 219), who may forward the information via transaction confirmation 1020 to ECO ADVANTAGE. Once ECO ADVANTAGE has received a transaction confirmation, it may credit 1022 to the user with new ecos equal to a predetermined amount related to the credit/debit and/or the like transaction amount, and may update the user's balance. ECO ADVANTAGE may also update the merchant account record 1023, including updating BI information, transaction data, the merchant's usage schedule, atmospherics, and/or the like. In some implementations, the merchant may generate and send a transaction receipt 1024 to the user, which may contain information similar to transaction receipt 723. In some implementations, ECO ADVANTAGE may also monitor the status of various transactions, and may reverse, retry, and/or otherwise handle incomplete transactions if found in the ECO ADVANTAGE database's records, based on predetermined criteria. [00154] FIGURES lob-c show logic flow diagrams illustrating slow commit, cash and credit transactions in example embodiments of the ECO ADVANTAGE. In some implementations, a user may initiate 1025 a transaction with an enrolled merchant, via providing transaction input to a merchant. The merchant may receive the user input and transaction information 1026, and may generate and send 1027 a request to ECO ADVANTAGE for the user's eco and/or bonus block balances. In some implementations, ECO ADVANTAGE may receive 1028 the request for the user's eco and bonus block balance, and may retrieve from the ECO ADVANTAGE database 102Q the user's available ecos, bonus blocks, and/or the like to determine which and how many ecos and bonus blocks may be applied to the current transaction, as well as to determine the user's confirmation setting. If the confirmation setting is on 1030, ECO ADVANTAGE may generate 1031 and send 10 2 a response to the merchant indicating the user's eco and/or bonus block balances and/or like transaction information. The merchant may receive the balance information 1033 and forward the information to the user via displaying and/or printing the transaction information for the user and asking the user to confirm the transaction 1034. The user may authenticate 1035 the transaction and the use of his ecos and/or bonus blocks towards the purchase using his password, user PIN, and/or a like form of identification, and may pay some amount of the balance in cash. In some implementations, the merchant may generate and send a message 1036 to ECO ADVANTAGE indicating the user has both confirmed the use of his ecos and/or bonus blocks and wishes to pay for the transaction, and has paid at least a portion of the transaction balance in cash. Once ECO ADVANTAGE receives 1037 the message, it may debit 1038 from the user's account all of the used ecos and/or bonus blocks in the transaction, and may credit the user's account with new ecos equal to a predetermined amount based on the cash payment. [ 00155 ] In some implementations, the merchant may also generate and send a payment request 103Q with the user's payment information, the transaction balance after subtracting the applied ecos and/or bonus blocks and the partial cash payment from the original transaction amount, and/or like information to an acquirer for procurement. In some implementations the acquirer may receive 1040 the user's payment information, transaction data, and/or the like, and may authenticate the sender of the message 1041 and use the information to request the transaction balance from the user's issuing bank. [ 00156 ] If the acquirer can successfully procures the funds 1042, the acquirer may obtain the funds 1043 and may send a confirmation to the merchant (and in some implementations, to ECO ADVANTAGE) indicating that the transaction was successfully processed. In some implementations the merchant may, if it receives a notification 1044 indicating a successful transaction, print and/or display a transaction receipt 1045 for the user, and may generate 1046 and send 1047 a transaction confirmation message to ECO ADVANTAGE indicating that the transaction was successful. ECO ADVANTAGE may, after receiving 1047 the transaction confirmation, save the confirmation within the transaction record in the ECO ADVANTAGE database in order to mark the transaction as completed. ECO ADVANTAGE may also credit 1048 the user's account with a predetermined amount of new ecos based on the user's credit/debit payment, and may update the merchant and transaction records 104Q using the data in 1023 and/or like information in the ECO ADVANTAGE database to indicate that the full transaction amount has been processed and procured.

[ooi57] If the acquirer cannot successfully procure the funds 1042, the acquirer may send a notification of transaction failure 1050 to the merchant (and, in some implementations, to ECO ADVANTAGE). The merchant may, after receiving 1051 the notification of a failed transaction, generate and send 1052 a transaction confirmation to ECO ADVANTAGE indicating the transaction failed, and may also display and/or print 1053 a notification of transaction failure for the user and/or may prompt the user to retry the transaction (e.g. with a different payment method and/or the like). ECO ADVANTAGE may receive 1054 the transaction confirmation message and mark the transaction as incomplete and necessary to retry, and mark related records (e.g. the user's record, the merchant's record and/or the like) as also being incomplete 1055. In some implementations, ECO ADVANTAGE may also monitor the status of various transactions, and may reverse, retry, and/or otherwise handle incomplete transactions if found in the ECO ADVANTAGE database's records, based on predetermined criteria. [ 00158 ] FIGURE 11a shows a data flow diagram illustrating fast commit, cash and credit transaction in example embodiments of the ECO ADVANTAGE. In some implementations, a user 1101 may send a transaction initiation request 1103 to the merchant 1104 using the merchant's PoS device and/or a user electronic device 1102. In some implementations, sensitive information (e.g. the user PIN and/or the like) may be encrypted. In some implementations the user may also provide a cash payment to the merchant covering at least a part of the remaining transaction balance once the user's ecos and/or bonus blocks are applied. In some implementations, the cash payment may also be a check, gift coupon, pre-paid gift voucher, community scrip, electronic fund transfer, a money card, money order, bank transfer, bank payment slip, and/or a like payment method. In some implementations, the merchant may send an eco request 1 110 to the ECO ADVANTAGE 1106. In some implementations, eco request 1105 may

2 take a form similar to eco request 206. ECO ADVANTAGE may look up the user's and

3 merchant's records using the user ID (UID) and the merchant ID 1107, respectively, and

4 may determine which and how many ecos and bonus blocks the user may apply to his

5 transaction (e.g. based on the merchant's eco schedule, the user's eco and bonus block

6 balances, and/or the like), and may determine the state of a user confirmation setting. If

7 the confirmation setting is set to "false," ECO ADVANTAGE may not require the user to

8 confirm his transaction before initiating any portion of it. ECO ADVANTAGE may debit

9 1108 the ecos and/or bonus blocks being used towards the transaction from the user

10 account, may credit nog the user account with a predetermined amount of ecos based

11 on the cash payment, and may update the user's balances. In some implementations

12 Grails code for updating the user's balances may take a form similar to the following:

13 Transaction transaction = Transaction .get(transactionld)

14 User user = transaction. getUserQ

15 Merchant merchant = transaction. getMerchantQ

16 long ecoUsage = transaction. getEcoUsage()

17 long bonusBlockUsage = transaction. getBonusBlockUsage()

18 long amountPaidlnCash = transaction. getAmountPaidInCash()

19 Try {

20 beginTransaction( )

21 user .debitEco(ecoUsage)

22 user .debitBonusBlock( bonusBlockUsage)

23 user.creditEco(amountPaidInCash, merchant)

24 commitTransactionQ;

25 } catch (Exception) {

26 rollbackTransactionQ;

27 return false;

28 }

29 [00159] ECO ADVANTAGE may also update the merchant account record 1110,

30 including updating BI information, transaction data, the merchant's usage schedule,

31 atmospherics, and/or the like.

32 [00160] In some implementations ECO ADVANTAGE may send an eco response

33 1111 back to the merchant, which may take a form similar to eco response 212. In some implementations, the merchant may display and/or print 1112 the ecos information for the user via an ecos transaction receipt. The merchant may send a payment request 1113 to the merchant's acquirer 1114, which may ask the entity to process the transaction. In some implementations, payment request 1113 may take a form similar to paument request 1013. The acquirer may prepare 1115 the transaction and procure payment via sending a transaction request 1116 to a bank entity 1117 (e.g. the user's issuing bank, another acquirer, and/or the like). The bank may send a transaction response 1118 to the acquirer, which may indicate whether or not the transaction was approved and/or processed, or whether the transaction was declined. The acquirer may forward this information to ECO ADVANTAGE via transaction confirmation 1121, which may take a form similar to transaction confirmation 1021, or may forward the information to the merchant via transaction confirmation 111Q (which may take a form similar to transaction confirmation 219), who may forward the information via transaction confirmation 1120 to ECO ADVANTAGE. In some implementations, the merchant may generate and send a transaction receipt 1122 to the user, which may contain information similar to ttransaction receipt 1024. In some implementations, ECO ADVANTAGE may also monitor the status of various transactions, and may reverse, retry, and/or otherwise handle incomplete transactions if found in the ECO ADVANTAGE database's records, based on predetermined criteria. [ 00161 ] FIGURES nb-c show logic flow diagrams illustrating fast commit, cash and credit transactions in example embodiments of the ECO ADVANTAGE. In some implementations, a user may initiate 1150 a transaction with an enrolled merchant, via providing transaction input to a merchant. The merchant may receive the user input and transaction information 1123, and may generate and send 1124 a request to ECO ADVANTAGE for the user's eco and/or bonus block balances. In some implementations, ECO ADVANTAGE may receive 1125 the request for the user's eco and bonus block balance, and may retrieve from the ECO ADVANTAGE database 1126 the user's available ecos, bonus blocks, and/or the like to determine which and how many ecos and bonus blocks may be applied to the current transaction, as well as to determine the user's confirmation setting. If the confirmation setting is off 1127, ECO ADVANTAGE may debit 1128 the ecos and/or bonus blocks used in the transaction from the user's account, and may credit the user's account with a predetermined amount of new ecos, which may be based on the transaction amount (e.g. both the cash payment and the pending credit/debit card payment). ECO ADVANTAGE may also update the merchant account and transaction records 112Q using the information in mo and/or like information to add the transaction to the ECO ADVANTAGE database and to update the merchant's records based on the transaction data (e.g. update information described in mo). ECO ADVANTAGE may generate and send 1130 a response to the merchant indicating the user's eco and/or bonus block balances and/or like transaction information. After receiving 11 1 the response, the merchant may generate and send a transaction receipt 11 2 to the user containing the data from the transaction (e.g. transaction total, amount paid with cash, amount paid with a credit/debit card, amount of ecos and/or bonus blocks used, and/or the like), which may be sent and received 1133 by the user. [ 00162 ] In some implementations, the merchant may also generate and send a payment request 1134 with the user's payment information, the transaction balance after subtracting the applied ecos and/or bonus blocks and the partial cash payment from the original transaction amount, and/or like information to an acquirer for procurement. In some implementations the acquirer may receive 1135 the user's payment information, transaction data, and/or the like, and may authenticate the sender of the message 1136 and use the information to request the transaction balance from the user's issuing bank. [ 00163 ] If the acquirer can successfully procures the funds 1137, the acquirer may obtain the funds 1138 and may send a confirmation to the merchant (and in some implementations, to ECO ADVANTAGE) indicating that the transaction was successfully processed. In some implementations the merchant may, if it receives a notification 113Q indicating a successful transaction, print and/or display a transaction receipt 1140 for the user, and may generate 1141 and send 1142 a transaction confirmation message to ECO ADVANTAGE indicating that the transaction was successful. ECO ADVANTAGE may, after receiving 1143 the transaction confirmation, save the confirmation within the transaction record in the ECO ADVANTAGE database in order to mark the transaction as completed. 1 [ 00164 ] If the acquirer cannot successfully procure the funds 1137, the acquirer

2 may send a notification of transaction failure 1144 to the merchant (and, in some

3 implementations, to ECO ADVANTAGE). The merchant may, after receiving 1145 the

4 notification of a failed transaction, generate and send 1146 a transaction confirmation to

5 ECO ADVANTAGE indicating the transaction failed, and may also display and/or print

6 1147 a notification of transaction failure for the user and/or may prompt the user to

7 retry the transaction (e.g. with a different payment method and/or the like). ECO

8 ADVANTAGE may receive 1148 the transaction confirmation message and mark the

9 transaction as incomplete and necessary to retry, and mark related records (e.g. the0 user's record, the merchant's record and/or the like) as also being incomplete 1149. In1 some implementations, ECO ADVANTAGE may also monitor the status of various2 transactions, and may reverse, retry, and/or otherwise handle incomplete transactions if3 found in the ECO ADVANTAGE database's records, based on predetermined criteria. 4 [ 00165 ] FIGURE 12a shows a data flow diagram illustrating fast commit, cash only5 transactions in example embodiments of the ECO ADVANTAGE. In some6 implementations, a user 1201 may send a transaction initiation request 120 to the7 merchant 1204 using the merchant's PoS device and/or a user electronic device 1202. In8 some implementations, sensitive information (e.g. the user PIN and/or the like) may be9 encrypted. In some implementations the user may also provide a cash payment to the0 merchant covering the entirety of the remaining transaction balance once the user's ecos1 and/or bonus blocks are applied. In some implementations, the cash payment may also2 be a check, gift coupon, pre-paid gift voucher, community scrip, electronic fund transfer,3 a money card, money order, bank transfer, bank payment slip, and/or a like payment4 method. In some implementations, the merchant may send an eco request 1205 to the5 ECO ADVANTAGE 1206. In some implementations, eco request 1205 may take a form6 similar to eco request 206. ECO ADVANTAGE may look up the user's and merchant's7 records using the user ID (UID) and the merchant ID 1207, respectively, and may8 determine which and how many ecos and bonus blocks the user may apply to his9 transaction (e.g. based on the merchant's eco schedule, the user's eco and bonus block0 balances, and/or the like), and may determine the state of a user confirmation setting. If1 the confirmation setting is set to "true," ECO ADVANTAGE may require the user to 1 confirm his transaction before initiating any portion of it. ECO ADVANTAGE may debit

2 1208 the ecos and/or bonus blocks being used towards the transaction from the user

3 account, may credit the user account with a predetermined amount of ecos based on the

4 cash payment, and may update the user's balances. ECO ADVANTAGE may also update

5 the merchant account record 1209, including updating BI information, transaction data,

6 the merchant's usage schedule, atmospherics, and/or the like.

7 [ooi66] In some implementations ECO ADVANTAGE may send an eco response

8 1210 back to the merchant, which may take a form similar to eco response 212. In some

9 implementations, the merchant may display and/or print 1211 the ecos information for

10 the user via a transaction receipt which may take a form similar to transaction receipt

11 1122. The user may pay cash 1212 to the merchant, and the merchant may deposit 1213

12 the cash in the merchant's bank account.

13 [ 00167] FIGURE 12b shows a logic flow diagram illustrating fast commit, cash only

14 transactions in example embodiments of the ECO ADVANTAGE. In some

15 implementations, a user may initiate 1214 a transaction with an enrolled merchant, via

16 providing transaction input to a merchant. The merchant may receive the user input and

17 transaction information, and may generate and send 1215 a request to ECO

18 ADVANTAGE for the user's eco and/or bonus block balances. In some implementations,

19 ECO ADVANTAGE may receive the request for the user's eco and bonus block balance,

20 and may retrieve from the ECO ADVANTAGE database 1216 the user's available ecos,

21 bonus blocks, and/or the like to determine which and how many ecos and bonus blocks

22 may be applied to the current transaction, as well as to determine the user's

23 confirmation setting. If the confirmation setting is off 1217, ECO ADVANTAGE may

24 debit 1218 the ecos and/or bonus blocks used in the transaction from the user's account,

25 and may credit the user's account with a predetermined amount of new ecos, which may

26 be based on the cash payment).

27 [ 00168 ] ECO ADVANTAGE may also update the merchant account and transaction

28 records 121Q using the information from 120Q and/or like information to add the

29 transaction to the ECO ADVANTAGE database and to update the merchant's records

30 based on the transaction data (e.g. update information described in 1110). ECO

31 ADVANTAGE may generate and send 1220 a response to the merchant indicating the user's eco and/or bonus block balances and/or like transaction information. After receiving 1221 the response, the merchant may generate and send a transaction receipt to the user containing the data from the transaction (e.g. transaction total, amount paid with cash, amount of ecos and/or bonus blocks used, and/or the like). When the user receives 1222 the transaction receipt, the user may pay cash 1223 to the merchant. The merchant may receive the cash payment 1224 from the user, which may cover the transaction balance after the user's qualifying ecos and bonus blocks have been applied. The merchant may credit 1225 the cash payment to the merchant's bank account via depositing the cash in the merchant's bank account. [ 00169 ] In some implementations, ECO ADVANTAGE and/or the merchant may prompt the user to confirm after the transaction has been committed. In such implementations, if the user confirms the transaction, the user may receive transaction receipt 1211 and may pay for the transaction. If the user declines the transaction, ECO ADVANTAGE may reverse the committed transaction information in the ECO ADVANTAGE database. [ 00170 ] FIGURE 13a shows a data flow diagram illustrating slow commit, cash only transactions in example embodiments of the ECO ADVANTAGE. In some implementations, a user 1301 may send a transaction initiation request 1303 to the merchant 1304 using the merchant's PoS device and/or a user electronic device 1302. In some implementations, sensitive information (e.g. the user PIN and/or the like) may be encrypted. In some implementations, the merchant may send an eco request 1305 to the ECO ADVANTAGE 1306. In some implementations, eco request 1305 may take a form similar to eco request 206. [ 00171] ECO ADVANTAGE may look up the user's and merchant's records using the user ID (UID) and the merchant ID 1307, respectively, and may determine which and how many ecos and bonus blocks the user may apply to his transaction (e.g. based on the merchant's eco schedule, the user's eco and bonus block balances, and/or the like), and may determine the state of a user confirmation setting. If the confirmation setting is set to "true," ECO ADVANTAGE may require the user to confirm his transaction before initiating any portion of it. In some implementations ECO ADVANTAGE may send an eco response 1308 back to the merchant, which may take a 1 form similar to eco response 1210. In some implementations, the merchant may display

2 and/or print 13 QQ the ecos information for the user, who may review the information

3 1 10 and confirm the transaction (e.g. using a password, user PIN, and/or the like),

4 including the ecos and/or bonus blocks to be used in the transaction. The user may also

5 choose to pay the entirety of the transaction with cash. In some implementations, the

6 cash payment may also be a check, gift coupon, pre-paid gift voucher, community scrip,

7 electronic fund transfer, a money card, money order, bank transfer, bank payment slip,

8 and/or a like payment method. In some implementations, confirmation can also be

9 represented via a successful cash payment. In such cases, the merchant may deposit the

10 cash 1311 into its bank account, and may send a cash transaction confirmation message

11 1312 to ECO ADVANTAGE indicating that the user has already paid the transaction

12 balance in cash. ECO ADVANTAGE may debit 1313 the ecos and/or bonus blocks being

13 used towards the transaction from the user account, may credit the user account with a

14 predetermined amount of ecos based on the cash payment, and may update the user's

15 balances.

16 [ 00172 ] ECO ADVANTAGE may also update the merchant account record 1314,

17 including updating BI information, transaction data, the merchant's usage schedule,

18 atmospherics, and/or the like. In some implementations, the merchant may generate

19 and send a transaction receipt 1315 to the user, which may contain information similar

20 to transaction receipt 1211.

21 [ 00173 ] FIGURE 13b shows a logic flow diagram illustrating slow commit, cash

22 only transactions in example embodiments of the ECO ADVANTAGE. In some

23 implementations, a user may initiate 1316 a transaction with an enrolled merchant, via

24 providing transaction input to a merchant. The merchant may receive the user input and

25 transaction information 1317, and may generate and send a request to ECO

26 ADVANTAGE for the user's eco and/or bonus block balances. In some implementations,

27 ECO ADVANTAGE may receive the request for the user's eco and bonus block balance,

28 and may retrieve from the ECO ADVANTAGE database 1318 the user's available ecos,

29 bonus blocks, and/or the like to determine which and how many ecos and bonus blocks

30 may be applied to the current transaction, as well as to determine the user's

31 confirmation setting. If the confirmation setting is off 131Q, ECO ADVANTAGE may 1 generate and send 1320 a response to the merchant indicating the user's eco and/or

2 bonus block balances and/or like transaction information. The merchant may receive

3 the balance information 1 21 and forward the information to the user via displaying

4 and/or printing the ecos information for the user and asking the user to confirm the

5 transaction. The user may confirm 1 22 the transaction and the use of his ecos and/or

6 bonus blocks towards the purchase using his password, user PIN, and/or a like form of

7 identification, and may pay the transaction balance in cash.

8 [00174] In some implementations, the merchant may receive the cash payment

9 from the user 1323, which may be equal to the transaction balance after the user's ecos

10 and/or bonus blocks have been applied. The merchant may credit 1 24 the cash

11 payment to its account via depositing the cash payment in the merchant's bank account,

12 and may generate and send a confirmation of the cash deposit to ECO ADVANTAGE

13 and a transaction receipt to the user. In some implementations, the user may receive

14 1 2 the transaction receipt, and ECO ADVANTAGE may debit the used ecos and/or

15 bonus blocks from the user's balances 1 26 and may credit the user's account with a

16 predetermined amount of new ecos based on the cash payment and may update the

17 account. ECO ADVANTAGE may also update the merchant account 1 27 using the

18 information from 1 14 and/or like information and ECO ADVANTAGE'S transaction

19 records in order to update the merchant and transaction data stored in the ECO

20 ADVANTAGE database.

21 [00175] FIGURE 14a shows a data flow diagram illustrating merchant and partner

22 transactions in example embodiments of the ECO ADVANTAGE. In some

23 implementations, a partner 1401 may enroll in ECO ADVANTAGE via a process similar

24 to merchants (see FIGURES 4a-c). In some implementations partners may be retail

25 merchants, manufacturers, wholesalers, large distributors, and/or the like In some

26 implementations the partner may wish to determine a bulk amount of its products

27 and/or services, and may send an eco schedule request 1402 to ECO ADVANTAGE

28 1403. In some implementations, the eco schedule request 1402 may take a form similar

29 to the following:

30 POST / eco_schedule_request.php HTTP/1.1

31 Host: www.ECOADVANTAGEprocess.com Content-Type: Application/XML

Content-Length: 788

<?XML version = "1.0" encoding

<ecoScheduleRequest>

<partnerld>154</partnerld>

<deviceld>579524552</deviceld>

<userld>102557952</userld>

<userAuth>da6c5cdf4e90b2961873f7b2e863415</userAuth>

<origDocNumberx/origDocNumber>

<nsu>572052</nsu>

<mcc>6432</mcc>

<transactionAmount>100.0</transactionAmount>

<minTransactionSize>100</minTransactionSize>

<maxTransactionSize>5000</maxTransactionSize>

<transactionSize>l</transactionSize>

<productData>

<sku>56673858</sku>

<sku >56673953</sku xdescription >television</description >

<sku>5668590K/sku>

</productData>

<dateTime>03/07/2013 03:39 PM</dateTime>

</ecoScheduleRequest>

[00176] In some implementations, ECO ADVANTAGE may look up the partner in the ECO ADVANTAGE database using the partner's ID 1404, and may retrieve the partner's eco schedule for bulk amounts. In some implementations the eco schedule may be based on transaction and historic data, atmospherics, and/or the like. ECO ADVANTAGE may send an eco schedule response 1405 to the partner containing eco schedules and/or the like. In some implementations the eco schedule response 1405 may take a form similar to the following:

POST /eco_schedule_response.php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

Content-Type: Application/XML

Content-Length: 788

<?XML version = "1.0" encoding = "UTF-8"?>

<ecoScheduleResponse> <UID>da6c5cdf4e90b2961873f7b2e863415</UID>

<transactionId>635467</transactionId>

<partnerld>154</partnerld>

<ecoScheduleList>

<ecoUsage>

<sku>56673858</sku>

<quantity>100</quantity>

<percentage>15</percentage>

</ecoUsage>

<ecoUsage>

<sku>56673953</sku>

<description>television</description>

<quantity>500</quantity>

<percentage>20</percentage>

</ecoUsage>

<ecoUsage>

<sku>5668590K/sku>

<quantity>1000</quantity>

<percentage>30</percentage>

</ecoUsage>

</ecoScheduleList>

<startDateTime>03/03/2013 00:00 AM</startDateTime>

<endDateTime>04/04/2013 23:59 PM</endDateTime>

<dateTime>02/02/2013 03:39 PM</dateTime>

</ecoScheduleResponse>

[ 00177] The partner may use the information in the response to create a product/service bulk amount 1406 based on the promoter's eco schedule and/or other ECO ADVANTAGE parameters. [ 00178 ] In some implementations partners may also receive from ECO ADVANTAGE an allotment of ecos, bonus blocks, and/or the like that they may provide to employees and/or the like as part of an incentive program (e.g. as bonuses, rewards, and/or the like). In some implementations partners may open credit lines for employees, wherein the credit line may be equal to an amount of ecos given to employees / 10. In some implementations another ECO ADVANTAGE partner may buy from them some percentage of that amount (e.g. four times the amount and/or the like) in products and/or services, with SRP. In some implementations consumers may also be able to pay parts of transactions with partners with ecos. [00179] In other implementations, the partner may also have access to a B2B Marketplace interface (e.g. a website, application, and/or the like) which may allow the partner to launch new products, and/or provide like information. [00180] In some implementations ECO ADVANTAGE may provide a merchant with an allotment of ecos, bonus blocks, and/or the like to be used with participating partners. In some implementations the merchant may receive such allotments once (e.g. after meeting a milestone, e.g. providing a predetermined amount of ecos to its consumers and/or the like, after enrolling, and/or the like), or more than once over a period of time (e.g. weekly, monthly, annually, and/or the like, at some interval if the merchant meets predefined ECO ADVANTAGE criteria, and/or the like). In some implementations, a merchant 1407 may use the allotment of ecos to purchase a product and/or service from the partner, via choosing 1408 a product and/or service available for purchase from the partner. The partner may send an eco request 140Q to ECO ADVANTAGE in order to get the merchant's eco balance, updated partner eco schedules, and/or the like, in some implementations eco request 14 OQ may take a form similar to the following:

POST /eco_request.php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

Content-Type: Application/XML

Content-Length: 788

<?XML version = "1 . 0" encoding = "UTF-8"?>

<ecoRequest>

<partnerld>154</partnerld>

<merchantld>2033</merchantld>

<transactionAmount>100.0</transactionAmount>

<productData>

<sku>56673953</sku>

</productData>

<dateTime>03/07/2013 03:39 PM</dateTime>

</ecoRequest> [00181] ECO ADVANTAGE may look up 1410 the merchant to ensure it has an account in the ECO ADVANTAGE database, and to look up the partner for its available schedules and/or the like. In some implementations Grails code for looking up the merchant and partner may take a form similar to the following:

def partner = Partner. get(params. partnerld);

if (! partner) {

log.warn("Partner not found with value ' ${params . partnerld} '") ; return sendError( ' exception . partner .not .found ') ;

}elseif ( ! partner .enabled || !partner. confirmed) {

log.warn("Partner inactive with value ' ${params . partnerld} '") ; return sendError( 'exception. partner. inactive' );

} elseif (partner. accountLocked) {

log.warn("Partner account locked with value ' ${params . partnerld} '")

return sendError( ' exception . partner .locked ')

} def schedule = partner .getSchedulesQ def merchant = Merchant. get(params.merchantld)

if (!merchant) {

log.warn("Merchant not found with value ' ${params .merchant} '") return sendError( ' exception .merchant . not .found ')

} elseif ( !merchant. enabled || ! merchant . confirmed) {

log.warn("Merchant inactive with value ' ${params .merchant} '") return sendError( 'exception. merchant. inactive' )

} elseif (merchant . accountLocked) {

log.warn("Merchant account locked with value ' ${params .merchant} '")

return sendError( ' exception .merchant . locked ')

} def productData = merchant. getProductDataQ def balanceForPartner = getBalanceForPartner(transaction .merchant , transaction . partner) def amountOfEcos = calculateValueToPayWithEco(transaction, schedule, productData, balanceForPartner)

[00182] ECO ADVANTAGE may send an eco response 1411 to the partner with the requested information. In some implementations, eco response 1411 may take a form similar to the following:

POST /eco_response.php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

Content-Type: Application/XML

Content-Length: 788

<?XML version = "1.0" encoding = "UTF-8"?>

<ecoResponse>

<partnerld>154</partnerld>

<merchantld>2033</merchantld>

<transactionId>635467</transactionId>

<transactionAmount>100.0</transactionAmount>

<ecoSaving>20%</ecoSaving>

<ecoBalance>109K/ecoBalance>

<amountDuelnDollars>77.0</amountDueInDollars>

<ecoUsage>23</ecoUsage>

<dateTime>03/07/2013 03:39 PM</dateTime>

<ecoResponse>

[00183] The partner may send a transaction confirmation message 1412 to the merchant indicating the transaction balance and/or like transaction information, and prompting the merchant to confirm the transaction. In some implementations, the transaction confirmation message 1412 may take a form similar to the following:

POST /transaction_confirmation.php HTTP/1.1

Host: www.EC0ADVANTAGEprocess.com

Content-Type: Application/XML

Content-Length: 788

<?XML version = "1.0" encoding = "UTF-8"?>

<transactionConfirmation>

<partnerld>154</partnerld>

<merchantld>2033</merchantld>

<transactionId>635467</transactionId>

<status>Approved</status> <dateTime>03/07/2013 03:39 PM</dateTime>

</transactionConfirmation>

[ 00184] The merchant may confirm 1413 the transaction and the use of ecos towards the transaction, and the partner may prepare the transaction data 1414 to be sent to the partner's acquirer and/or a like payment entity for payment procurement. In some implementations, the partner may receive a transaction confirmation from the acquirer indicating whether or not the transaction was successful or not, and may forward this transaction confirmation via a message 1415 to ECO ADVANTAGE. In some implementations, ECO ADVANTAGE may, upon receiving a confirmation that the transaction was successful, debit the ecos used for the transaction from the merchant's account 1416, may credit the merchant's account with a new predetermined amount of ecos (the amount based at least partially on the amount the merchant pays for the transaction), and may update the merchant's balance. IN some implementations, updating the merchant's balance may take a form similar to the following:

Transaction transaction = Transaction .get(transactionld)

Merchant merchant = transaction. getMerchantQ

Partner partner = transaction. getPartnerQ

long ecoUsage = transaction. getEcoUsage()

long bonusBlockUsage = transaction. getBonusBlockUsage( )

long amountDuelnDollars = transaction. getAmountDuelnDollarsQ Try {

beginTransaction( )

merchant .debitEco(ecoUsage)

user .debitBonusBlock( bonusBlockUsage)

merchant . creditEco( amountDuelnDollars, partner)

commitTransactionQ;

} catch (Exception) {

rollbackTransactionQ; return false;

}

[00185] ECO ADVANTAGE may also update the partner's account record and transaction records, including creating a transaction record, updating the partner's BI information, transaction data, usage schedules using the transaction's date, time and atmospherics, and/or the like. In some implementations, Grails code for updating partner data may take a form similar to the following:

Transaction transaction = Transaction .get(transactionld)

Partner partner = transaction. getPartnerQ

Merchant merchant = transaction. getMerchantQ

long ecoUsage = transaction. getEcoUsage()

long bonusBlockUsage = transaction. getBonusBlockUsage( ) def historyTransaction = new HistoryTransaction(transaction, partner, merchant, ecoUsage, bonusBlockUsage)

historyTransaction . save( )

[00186] FIGURES 14D-C show logic flow diagrams illustrating merchant and partner transactions in example embodiments of the ECO ADVANTAGE. In some implementations, before a transaction, a partner may generate and send 1418 a request to ECO ADVANTAGE for its eco schedule information. ECO ADVANTAGE may receive 141Q the request for the partner's eco schedules, and may look up the partner's record using the partner ID included in the request. ECO ADVANTAGE may retrieve the partner's eco schedules and/or like partner information and use them to calculate the eco schedule to provide per bulk amount of the partner's products and/or services. ECO ADVANTAGE may generate and send 1421 a schedule response to the partner, who may receive the eco schedule response 1422 and may use the eco schedule per bulk amount received to create and/or update product and service bulk amounts.

[00187] In some implementations, a merchant may, at some point, initiate a transaction 1423 with a partner via choosing products and/or services to purchase. The partner may obtain 1424 the transaction information from the merchant, and may generate and send an eco request to ECO ADVANTAGE. ECO ADVANTAGE may receive the eco request 1425 from the partner and may look up the partner and the merchant using the partner and merchant IDs, respectively. If a partner record is not found, ECO ADVANTAGE may prompt the partner to enroll in ECO ADVANTAGE. If a partner record is found 1426, ECO ADVANTAGE may determine if a record for the merchant can be found. If the merchant record 1427 is not found, ECO ADVANTAGE may prompt the merchant to enroll in ECO ADVANTAGE (see FIGURES 4a-c for further detail). If the merchant's record can be found, ECO ADVANTAGE may retrieve 142Q the merchant's eco balance, and may use it to determine the number of ecos that can be applied to the transaction amount. ECO ADVANTAGE may also retrieve the partner's eco schedules, bulk amounts, and/or the like, and may send the partner and merchant data to the partner via an eco response 14. o to the merchant. The merchant may receive 1431 the eco response from ECO ADVANTAGE and may prompt the merchant to confirm the transaction given the merchant's eco information and the partner's current bulk amounts. Once the merchant has confirmed 1432 the transaction and the use of ecos, the partner may send 1433 the transaction balance (e.g. the transaction amount minus the ecos applied) to an acquirer for procurement.

[00188] In some implementations, if the acquirer notifies the partner 1434 that the procurement was a success, ECO ADVANTAGE may receive a notification indicating a successful transaction 1438, and may create and store a record of the transaction in the ECO ADVANTAGE database. ECO ADVANTAGE may debit 143Q the ecos used in the transaction from the merchant's account, and may credit the merchant's account with a predetermined amount of ecos based on the transaction amount and marked as being from the promoter. ECO ADVANTAGE may also update the merchant and partner's account records 1440 using the transaction information and/or like information in 1417, and/or like information.

[0018₉] In some implementations, if the procurement was not successful 1434, the merchant may receive a notification of transaction failure 1435, may be prompted to retry the transaction and/or the like. The partner may also forward the notification to ECO ADVANTAGE, which may receive the notice and store a transaction record for the transaction 1436. In some implementations the record may be marked as incomplete so that ECO ADVANTAGE may retry the transaction at a later time. In some implementations ECO ADVANTAGE may also mark 1437 related records (e.g. merchant and partner records, and/or the like) as being incomplete as a result of the failed transaction. [ 00190 ] FIGURE 15a show a data flow diagram illustrating refunding or cancelling transactions in example embodiments of the ECO ADVANTAGE. In some implementations, a user 1501 may indicate to a merchant 1503 that he may wish to cancel and/or obtain a refund for a transaction 1502, and may provide transaction information (e.g. transaction and/or order ID, the user's ID, and/or the like) to the merchant. In some implementations, sensitive information (e.g. the user PIN and/or the like) may be encrypted. The merchant may send a cancellation request 1504 to ECO ADVANTAGE 1505, including the provided transaction information. In some implementations, the cancellation request 1504 may take a forms similar to the following:

POST /cancellation_request.php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

Content-Type: Application/XML

Content-Length: 788

<?XML version = "1 . 0" encoding = "UTF-8"?>

<cancellationRequest>

<UID>da6c5cdf4e90b2961873f7b2e863415</UID>

<merchantld>2033</merchantld>

<posld>4088</posld>

<mcc>6432</mcc>

<transactionId>635467</transactionId>

<transactionDate>03/06/2013</transactionDate>

<transactionProcessingCodex/transactionProcessingCode>

<transactionDocNumberx/transactionDocNumber>

<transactionNsux/transactionNsu>

<dateTime>03/07/2013 01:39 PM</dateTime>

</cancellationRequest>

[ 00191 ] In some implementations, ECO ADVANTAGE may use the transaction ID and/or other provided data 1506 in order to locate the transaction record in the ECO ADVANTAGE database. In some implementations Grails code for locating the transaction may take a form similar to the following: 1 def transaction = Transaction .get(params .transactionid)

2 if( !transaction) {

3 log.warn("Transaction not found with value

4 ^f${params .transactionid} ' .")

5 return sendError( 'exception. transaction. not. found' )

6 } elseif ( !transaction.isCancellable()) {

7 log.warn("Transaction ^f${params .transactionid} ' cannot be

8 cancelled.-")

9 return sendError( 'exception. transaction. not. cancellable' )

10 }

11 [00192] ECO ADVANTAGE may determine the amount that the user paid in the

12 transaction, the number of ecos credited to the user during the transaction, the number

13 of ecos and/or bonus blocks the user spent towards the transaction, and/or the like

14 1507. In some implementations, Grails code for determining the transaction data may

15 take a form similar to the following:

16 def amountDuelnDollars = transaction . amountDuelnDollars

17 def newEcos = transaction .newEcos

18 def usedEcos = transacton .usedEcos

19 def usedBonusBlocks = transacton . usedBonusBlocks

20 [00193] ECO ADVANTAGE may use the information to determine the amount to

21 refund the user, how the user's ecos and or bonus block balances should be updated,

22 and/or the like, and may send this information to the merchant via a cancellation

23 response 1508. In some implementations the cancellation response 1508 may take a

24 form similar to the following:

25 POST /cancellation_response.php HTTP/1.1

26 Host: www.ECOADVANTAGEprocess.com

27 Content-Type: Application/XML

28 Content-Length: 788

29 <?XML version = "1.0" encoding = "UTF-8"?>

30 <cancellationResponse>

31 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>

32 <transactionId>635467</transactionId>

33 <AmountToRefundUser>${amountDueInDollars}</AmountToRefundUser>

34 <EcosToRefundUser>${usedEcos }</EcosToRefundUser>

35 <BonusBlocksToRefundUser>${usedBonusBlocks }</BonusBlocksToRefundUser> </cancellationResponse>

[ 00194 ] The merchant may print and/or display 150Q the amount of ecos to be refunded, the amount of real currency to be refunded, the amount of ecos to be rescinded from the user's account, and/or like information, and may prompt the user to confirm the transaction. The user may authenticate and/or confirm the refund and/or cancellation transaction 1510, and the merchant may send a refund request 1511 to its acquirer 1512 and/or a like entity in order to process the transaction. In some implementations, refund request 1511 may take a form similar to the following:

POST /refund_request.php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

Content-Type: Application/XML

Content-Length: 788

<?XML version = "1.0" encoding = "UTF-8"?>

<refundRequest>

<UID>da6c5cdf4e90b2961873f7b2e863415</UID>

<transactionId>635467</transactionId>

<merchantld>2033</merchantld>

<posld>4065</posld>

omountToBeRefunded>77.0</amountToBeRefunded>

<dateTime>03/07/2013 01:39 PM</dateTime>

</refundRequest>

[ 00195 ] The acquirer and/or like entity may authenticate the request 1513 and may cancel the previous transaction and/or perform like tasks in order to process the cancellation of the previous transaction. In some implementations the acquirer may send a refund response 1514 indicating whether or not the refund transaction was successful or not, and/or the like to the merchant, who may forward the refund response to ECO ADVANTAGE 1515. In some implementations refund response 1514, 1515, and 1516 may take a form similar to the following:

POST /refund_request.php HTTP/1.1

Host: www.ECOADVANTAGEprocess.com

Content-Type: Application/XML

Content-Length: 788

<?XML version = "1.0" encoding = "UTF-8"?>

<refundResponse> 1 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>

2 <transactionId>635467</transactionId>

3 <merchantld>2033</merchantld>

4 <posld>4065</posld>

5 <AmountToBeRefunded>77.0</AmountToBeRefunded>

6 <dateTime>03/07/2013 01:39 PM</dateTime>

7 <approved>true</approved>

8 </refundResponse>

9 [o o i96] In some implementations the acquirer may also send a refund response

10 1516 to ECO ADVANTAGE. In some implementations ECO ADVANTAGE may recredit

1 1 the user's account with the ecos and/or bonus blocks used in the cancelled transaction,

12 may rescind the ecos credited to the user in the cancelled transaction and/or the like

13 1517, and may update the user's balances and mark the related transaction record

14 and/or other related records as being cancelled or refunded. In some implementations

15 Grails code for updating the user's balances may take a form similar to the following:

16 Transaction transaction = Transaction .get(transactionld)

17 User user = transaction. getUserQ

18

19 Try {

20 beginTransaction( )

21 user . creditEco(transaction .usedEcos)

22 user . creditBonusBlocks(transaction . usedBonusBlocks)

23 user .debitEco(transaction .newEcos)

24 transaction . refunded = true;

25 transaction . save( )

26 commitTransactionQ;

27 } catch (Exception) {

28 rollbackTransactionQ;

29 return false;

30 }

31 [00197] The merchant may also send a transaction receipt 1518 to the user, which

32 may take a form similar to transaction receipt 1315.

33 [00198] FIGURE 15b shows a logic flow diagram illustrating refunding or

34 cancelling transactions in example embodiments of the ECO ADVANTAGE. In some implementations, a user may indicate to a merchant a desire to cancel and/or refund a transaction 1519. The merchant may obtain the request for a refund 1520 and may generate and send a request for the transaction's information to ECO ADVANTAGE, using the transaction ID and/or other data provided by the user. ECO ADVANTAGE may receive 1521 the request for information about the transaction and may use the transaction ID and/or like information 1522 in order to locate the proper transaction record in the ECO ADVANTAGE. ECO ADVANTAGE may determine from the transaction record 1523 the amount charged to the user, the amount of ecos and/or bonus blocks the user spent in the transaction, the amount of ecos the user gained from the transaction, and/or the like. ECO ADVANTAGE may then generate and send a response 1524 to the merchant with the information determined from the transaction record. [ 00199 ] The merchant, upon receiving the response 1525, may print and/or display the information received for the user to review, and may prompt the user to confirm the refund and/or transaction cancellation. If the user authenticates and/or otherwise confirms 1526 the transaction based on the displayed information, the merchant may send a message 1527 to an acquirer and/or like payment entity in order to have the refund transaction processed. In some implementations, the acquirer may receive 1528 the refund request, may authenticate 152Q the request, and may cancel 1530 the original payment transaction. [ 00200 ] If the cancellation is successful 1531, the acquirer may send a notification 1532 to the merchant indicating success in processing the refund. The merchant may receive the notification 1533, may forward the confirmation to ECO ADVANTAGE, and the user may receive from the merchant a transaction receipt 1534 indicating the refund confirmation and/or further transaction details. In some implementations, ECO ADVANTAGE may receive the transaction message, and may save the confirmation as a transaction record in the ECO ADVANTAGE database 1 3 for future reference. In some implementations, ECO ADVANTAGE may also re-credit the user's account with the ecos and/or bonus blocks used in the cancelled transaction 1526, may rescind any ecos given to the user in the original transaction, and may update the user's balances. ECO 1 ADVANTAGE may also mark all related records 1537 (e.g. transaction records and/or

2 the like) as being refunded.

3 [00201] If the cancellation is not successful 1531, the acquirer may send a

4 notification of transaction failure 1 .38 to the merchant, who may receive 153Q the

5 notification, and forward it to ECO ADVANTAGE. The user may also receive from the

6 merchant 1540 a notification that the refund transaction failed and that the user may

7 retry the refund transaction at a later date. ECO ADVANTAGE may receive the refund

8 failure notification 1541 and may mark the refund transaction record in the ECO

9 ADVANTAGE database in order to indicate that the transaction should be re-tried at a

10 later time. ECO ADVANTAGE may also mark all related records (e.g. transaction

11 records and/or the like) as being incomplete 1542.

12 [ 00202 ] FIGURE 16 shows a table diagram illustrating using ECO ADVANTAGE

13 for health insurance in example embodiments of the ECO ADVANTAGE. In some

14 implementations ECO ADVANTAGE may used to reduce a user's cost and/or wait time

15 for various healthcare payment options 1601. In some implementations, for example, a

16 user may be able to use a Public Option 1602, which may be affordable by all economic

17 strata 1606, as the cost to the patient 1608 may be $0, but may require a wait time for

18 appointments 1607 of six or more months, may only allow a physician to earn 160Q $10

19 per visit, and may cost $0 to a health insurance provider 1610.

20 [ 00203 ] In some implementations, if a user utilizes an HMO-like health insurance

21 plan 1603, the user may only be able to afford the plan if the user fits into the top few

22 (e.g. A, B, or C) economic strata, but the user may wait three or more months, may pay

23 $0-15 per visit, which may result in $15-35 earnings per visit for a physician and a $15-

24 35 cost to the health insurance provider.

25 [ 00204] In some implementations, a private 1604 health plan coupled with other

26 health insurance may reduce the wait time considerably, but may cost the user $120 (or

27 $200 if the user is uninsured, if, in some implementations, the user's insurance will

28 refund up to $80 in doctor visit expenses), resulting in only the top (e.g. A) economic

29 strata being able to afford the plan. Private health care plans, on the other hand, cost 1 $8o to a health insurance provider if the user is insured, and provide $130 in earnings

2 (post-tax) to a physician per visit.

3 [ 00205] In some implementations, a user enrolled in ECO ADVANTAGE 1605 may

4 be able to reduce the cost of his health insurance considerably, while still allowing a

5 physician to earn more per visit than would be possible if the user were only using a

6 Public Option or HMO-like plan. In some implementations, the user may only need to

7 wait a day (as opposed to the six or more months for the Public Option, or the three or

8 more months for an HMO-like plan) for an appointment, and may pay only $80 per visit

9 if uninsured (along with 120 ecos), and may pay only $0 and 120 ecos per visit if

10 insured, and if the user's insurance will refund up to $80 in medical expenses. ECO

11 ADVANTAGE may allow those in lower economic strata (e.g. B, C, D, E) to experience

12 the benefits of private health plans, as they would not need to pay as much for the

13 benefits. The physician may also earn $70 per visit with a patient using ECO

14 ADVANTAGE, as opposed to $10 or $15-35 if the patients were to use the Public Option

15 or the HMO and/or like plans (e.g. the only other options those economic strata would

16 be able to afford). The cost to the health insurance provider also remains at $80, which

17 would be the same cost if the patient were able to afford private health insurance.

18 [ 00206 ] FIGURES 22a-b show block diagrams illustrating checking into ECO

19 ADVANTAGE in some embodiments of an ECO ADVANTAGE. In some

20 implementations a user 2201 may, on his electronic device 2201, wish to log in 2203 to

21 ECO ADVANTAGE 2204, using his user credentials, GPS data, and/or the like. ECO

22 ADVANTAGE may determine whether the user has an account in ECO ADVANTAGE

23 2205, and may determine 2207 a list of selected merchants to provide to the user to

24 preliminary viewing based on the user's profile information, GPS data, the date and time

25 of the login, user schedules, suggestions for the user based on merchant feedback 2206,

26 atmospheric data, and/or the like. ECO ADVANTAGE may then send a login response

27 2208 to the user containing a list of merchants to view, a map of the user's preferred

28 region(s), categories for the user to browse through, merchant rankings and

29 suggestions, and/or the like. The user may look through the list of merchants (e.g. via a

30 list view or via interacting with the map contained in the login response) and select at

31 least one to obtain further information on via a merchant choice message 220Q to ECO ADVANTAGE. In some implementations ECO ADVANTAGE may retrieve eco statistics for the merchant 2210, such as the total number of ecos used from and/or at the merchant, the merchant's current eco schedule (and/or the schedule within a specified date range), and/or like information, and may also retrieve current deals 2211, the current eco %, the GPS data, and/or the like for the merchant. ECO ADVANTAGE may send the information to the user via an econometer response 2212. The user may then send a check-in request 2213 to ECO ADVANTAGE, which may include user identification information, the date and time of the check-in, the GPS coordinates of the user at the time of check-in, and/or like information. In some implementations ECO ADVANTAGE may share the user's check-in 2214 on social media websites (e.g. Facebook, Twitter, and/or the like), and/or may provide the user the opportunity to choose social networking websites to share the check-in data with. ECO ADVANTAGE may also send a check-in confirmation 2215 to the user to indicate whether or not the check-in was successful or not. [ 00207] In some implementations, ECO ADVANTAGE may use a Telemetry component to pull information from current real-time transactions and historic data about users, merchants, transactions, ecos, bonus blocks, donation, eco calculations, and/or the like. [ 00208 ] Using the BI and the analytics components in conjunction with the Telemetry component, ECO ADVANTAGE may process these types of data, and may produce individual and aggregated trend and skew per transaction data, user, merchant, eco schedule, usage schedule, region, category, grand-total entities data, and/or the like. ECO ADVANTAGE may also use these components to compare this trend and skew data with upper and lower thresholds, predicted plans, overall trends, and/or the like. [ 00209 ] ECO ADVANTAGE may then use the Telemetry and/or other components to trigger immediate action mechanisms on various components and entities, including the Eco Schedule Calculation Component, Merchant Managers, Economic Promoters, Merchants, Eco and Usage Schedules, and/or the like, in order to keep delivering the defined commercial intelligence. It may also trigger short and long term actions and/or action mechanisms on those components, as well as the Region/Category Management Component. The Merchant Information Aggregation Component, and the Merchant and User Enrollment Components. ECO ADVANTAGE may also use the Telemetry and/or other components for calibration of thresholds.

[00210] In some implementations, an Econometer Component may allow ECO ADVANTAGE to integrate different dimensions of the ECO ADVANTAGE data into benefits, may keep them organized, and may distribute this data to all components and entities as needed.

[00211] In some implementations ECO ADVANTAGE may use the Econometer Component and/or other components to pull information from current real-time transactions and historic data about users, merchants, transactions, ecos, bonus blocks, donations, eco calculations, and/or the like. The ECO ADVANTAGE may also use the Econometer Component to distribute this data to all available devices and entities.

[00212] For example, in some implementations, ECO ADVANTAGE may use this component to facilitate communications between merchant and user entities via the user's mobile device, a website, SMS, Push msg, email, PoS, and/or like forms of communication. ECO ADVANTAGE may also use the component and/or other components as an Eco Calculator (e.g., for specific merchants, for specific entities as a whole, and/or the like). In some implementations ECO ADVANTAGE may also use the component to calculate current and/or near future merchant eco schedules, in numeric and figurative representations.

[00213] In some implementations ECO ADVANTAGE may use this component to facilitate communications from ECO ADVANTAGE to a user via his mobile device, a website, SMS, Push msg, email, PoS, and/or like forms of communication. ECO ADVANTAGE may also use the component to keep track of each user's total transaction usage, total ecos usage, total bonus block usage, total ecos donation, all by period or to date, show graphs, %, ecos and bonus blocks balances, and/or like values, and may allow ECO ADVANTAGE to generate and/or provide reports of all these types of data.

[00214] In some implementations ECO ADVANTAGE may use this component to facilitate communications from ECO ADVANTAGE to a merchant via a merchant's mobile device, a website, SMS, Push msg, email, PoS, and/or like forms of communication. ECO ADVANTAGE may also use the component and/or other components to calculate transaction usage, ecos usage, bonus block usage, aggregated and by period, show graphs, %, balances, and/or like values, and may use the component to generate and/or provide reports of all these types of data. [ 00215] In some implementations ECO ADVANTAGE may also use the component to, via a mobile application, a website, and/or the like, provide the aggregated overall grand-total ecos usage (e.g., the total amount everybody already saved using the ECO ADVANTAGE SYSTEM to date), and/or like statistics to entities on ECO ADVANTAGE. [ 00216 ] Figure 22b demonstrates another exemplary implementations of checking into ECO ADVANTAGE and searching for merchants. ECO ADVANTAGE Controller [ 00217] FIGURE 23 shows a block diagram illustrating embodiments of a ECO ADVANTAGE controller. In this embodiment, the ECO ADVANTAGE controller 2301 may serve to aggregate, process, store, search, serve, identify, instruct, generate, match, and/or facilitate interactions with a computer through commerce and mutual benefit technologies, and/or other related data. [ 00218 ] Typically, users, which may be people and/or other systems, may engage information technology systems (e.g., computers) to facilitate information processing. In turn, computers employ processors to process information; such processors 2303 may be referred to as central processing units (CPU). One form of processor is referred to as a microprocessor. CPUs use communicative circuits to pass binary encoded signals acting as instructions to enable various operations. These instructions may be operational and/or data instructions containing and/or referencing other instructions and data in various processor accessible and operable areas of memory 2329 (e.g., registers, cache memory, random access memory, etc.). Such communicative instructions may be stored and/or transmitted in batches (e.g., batches of instructions) as programs and/or data components to facilitate desired operations. These stored instruction codes, e.g., programs, may engage the CPU circuit components and other motherboard and/or system components to perform desired operations. One type of program is a computer operating system, which, may be executed by CPU on a computer; the operating system enables and facilitates users to access and operate computer information technology and resources. Some resources that may be employed in information technology systems include: input and output mechanisms through which data may pass into and out of a computer; memory storage into which data may be saved; and processors by which information may be processed. These information technology systems may be used to collect data for later retrieval, analysis, and manipulation, which may be facilitated through a database program. These information technology systems provide interfaces that allow users to access and operate various system components. [ 00219 ] In one embodiment, the ECO ADVANTAGE controller 2301 may be connected to and/or communicate with entities such as, but not limited to: one or more users from user input devices 2311; peripheral devices 2312; an optional cryptographic processor device 2328; and/or a communications network 2313. [ 00220 ] Networks are commonly thought to comprise the interconnection and interoperation of clients, servers, and intermediary nodes in a graph topology. It should be noted that the term "server" as used throughout this application refers generally to a computer, other device, program, or combination thereof that processes and responds to the requests of remote users across a communications network. Servers serve their information to requesting "clients." The term "client" as used herein refers generally to a computer, program, other device, user and/or combination thereof that is capable of processing and making requests and obtaining and processing any responses from servers across a communications network. A computer, other device, program, or combination thereof that facilitates, processes information and requests, and/or furthers the passage of information from a source user to a destination user is commonly referred to as a "node." Networks are generally thought to facilitate the transfer of information from source points to destinations. A node specifically tasked with furthering the passage of information from a source to a destination is commonly called a "router." There are many forms of networks such as Local Area Networks (LANs), Pico networks, Wide Area Networks (WANs), Wireless Networks (WLANs), etc. For example, the Internet is generally accepted as being an interconnection of a 1 multitude of networks whereby remote clients and servers may access and interoperate

2 with one another.

3 [00221] The ECO ADVANTAGE controller 2301 may be based on computer

4 systems that may comprise, but are not limited to, components such as: a computer

5 systemization 2302 connected to memory 2329.

6 Computer Systemization

7 [00222] A computer systemization 2302 may comprise a clock 2330, central

8 processing unit ("CPU(s)" and/or "processor(s)" (these terms are used interchangeable

9 throughout the disclosure unless noted to the contrary)) 2303, a memory 2329 (e.g., a

10 read only memory (ROM) 2306, a random access memory (RAM) 2305, etc.), and/or an

11 interface bus 2307, and most frequently, although not necessarily, are all interconnected

12 and/or communicating through a system bus 2304 on one or more (mother)board(s)

13 2302 having conductive and/or otherwise transportive circuit pathways through which

14 instructions (e.g., binary encoded signals) may travel to effectuate communications,

15 operations, storage, etc. The computer systemization may be connected to a power

16 source 2386; e.g., optionally the power source may be internal. Optionally, a

17 cryptographic processor 2326 and/or transceivers (e.g., ICs) 2374 may be connected to

18 the system bus. In another embodiment, the cryptographic processor and/or

19 transceivers may be connected as either internal and/or external peripheral devices

20 2312 via the interface bus I/O. In turn, the transceivers may be connected to antenna(s)

^{21 2}375, thereby effectuating wireless transmission and reception of various

22 communication and/or sensor protocols; for example the antenna(s) may connect to: a

23 Texas Instruments WiLink WL1283 transceiver chip (e.g., providing 802.1m, Bluetooth

24 3.0, FM, global positioning system (GPS) (thereby allowing ECO ADVANTAGE

25 controller to determine its location)); Broadcom BCM4329FKUBG transceiver chip

26 (e.g., providing 802.1m, Bluetooth 2.1 + EDR, FM, etc.); a Broadcom BCM4750IUB8

27 receiver chip (e.g., GPS); an Infineon Technologies X-Gold 618-PMB9800 (e.g.,

28 providing 2G/3G HSDPA/HSUPA communications); and/or the like. The system clock

29 typically has a crystal oscillator and generates a base signal through the computer

30 systemization's circuit pathways. The clock is typically coupled to the system bus and various clock multipliers that will increase or decrease the base operating frequency for other components interconnected in the computer systemization. The clock and various components in a computer systemization drive signals embodying information throughout the system. Such transmission and reception of instructions embodying information throughout a computer systemization may be commonly referred to as communications. These communicative instructions may further be transmitted, received, and the cause of return and/or reply communications beyond the instant computer systemization to: communications networks, input devices, other computer systemizations, peripheral devices, and/or the like. It should be understood that in alternative embodiments, any of the above components may be connected directly to one another, connected to the CPU, and/or organized in numerous variations employed as exemplified by various computer systems. [ 00223 ] The CPU comprises at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests. Often, the processors themselves will incorporate various specialized processing units, such as, but not limited to: integrated system (bus) controllers, memory management control units, floating point units, and even specialized processing sub-units like graphics processing units, digital signal processing units, and/or the like. Additionally, processors may include internal fast access addressable memory, and be capable of mapping and addressing memory 2329 beyond the processor itself; internal memory may include, but is not limited to: fast registers, various levels of cache memory (e.g., level 1, 2, 3, etc.), RAM, etc. The processor may access this memory through the use of a memory address space that is accessible via instruction address, which the processor can construct and decode allowing it to access a circuit path to a specific memory address space having a memory state. The CPU may be a microprocessor such as: AMD's Athlon, Duron and/or Opteron; ARM's application, embedded and secure processors; IBM and/or Motorola's DragonBall and PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Core (2) Duo, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s). The CPU interacts with memory through instruction passing through conductive and/or transportive conduits (e.g., (printed) electronic and/or optic circuits) to execute stored instructions (i.e., program code) according to conventional data processing techniques. Such instruction passing facilitates communication within the ECO ADVANTAGE controller and beyond through various interfaces. Should processing requirements dictate a greater amount speed and/or capacity, distributed processors (e.g., Distributed ECO ADVANTAGE), mainframe, multi-core, parallel, and/or super-computer architectures may similarly be employed. Alternatively, should deployment requirements dictate greater portability, smaller Personal Digital Assistants (PDAs) may be employed. [ 00224 ] Depending on the particular implementation, features of the ECO ADVANTAGE may be achieved by implementing a microcontroller such as CAST'S R8051XC2 microcontroller; Intel's MCS 51 (i.e., 8051 microcontroller); and/or the like. Also, to implement certain features of the ECO ADVANTAGE, some feature implementations may rely on embedded components, such as: Application-Specific Integrated Circuit ("ASIC"), Digital Signal Processing ("DSP"), Field Programmable Gate Array ("FPGA"), and/or the like embedded technology. For example, any of the ECO ADVANTAGE component collection (distributed or otherwise) and/or features may be implemented via the microprocessor and/or via embedded components; e.g., via ASIC, coprocessor, DSP, FPGA, and/or the like. Alternately, some implementations of the ECO ADVANTAGE may be implemented with embedded components that are configured and used to achieve a variety of features or signal processing. [ 00225 ] Depending on the particular implementation, the embedded components may include software solutions, hardware solutions, and/or some combination of both hardware/ software solutions. For example, ECO ADVANTAGE features discussed herein may be achieved through implementing FPGAs, which are a semiconductor devices containing programmable logic components called "logic blocks", and programmable interconnects, such as the high performance FPGA Virtex series and/or the low cost Spartan series manufactured by Xilinx. Logic blocks and interconnects can be programmed by the customer or designer, after the FPGA is manufactured, to implement any of the ECO ADVANTAGE features. A hierarchy of programmable interconnects allow logic blocks to be interconnected as needed by the ECO ADVANTAGE system designer/administrator, somewhat like a one-chip programmable breadboard. An FPGA's logic blocks can be programmed to perform the operation of basic logic gates such as AND, and XOR, or more complex combinational operators such as decoders or mathematical operations. In most FPGAs, the logic blocks also include memory elements, which may be circuit flip-flops or more complete blocks of memory. In some circumstances, the ECO ADVANTAGE may be developed on regular FPGAs and then migrated into a fixed version that more resembles ASIC implementations. Alternate or coordinating implementations may migrate ECO ADVANTAGE controller features to a final ASIC instead of or in addition to FPGAs. Depending on the implementation all of the aforementioned embedded components and microprocessors may be considered the "CPU" and/or "processor" for the ECO ADVANTAGE. Power Source

[00226] The power source 2386 may be of any standard form for powering small electronic circuit board devices such as the following power cells: alkaline, lithium hydride, lithium ion, lithium polymer, nickel cadmium, solar cells, and/or the like. Other types of AC or DC power sources may be used as well. In the case of solar cells, in one embodiment, the case provides an aperture through which the solar cell may capture photonic energy. The power cell 2386 is connected to at least one of the interconnected subsequent components of the ECO ADVANTAGE thereby providing an electric current to all subsequent components. In one example, the power source 2386 is connected to the system bus component 2304. In an alternative embodiment, an outside power source 2386 is provided through a connection across the I/O 2308 interface. For example, a USB and/or IEEE 1394 connection carries both data and power across the connection and is therefore a suitable source of power. Interface Adapters

[00227] Interface bus(ses) 2307 may accept, connect, and/or communicate to a number of interface adapters, conventionally although not necessarily in the form of adapter cards, such as but not limited to: input output interfaces (I/O) 2308, storage interfaces 2309, network interfaces 2310, and/or the like. Optionally, cryptographic processor interfaces 2327 similarly may be connected to the interface bus. The interface bus provides for the communications of interface adapters with one another as well as with other components of the computer systemization. Interface adapters are adapted for a compatible interface bus. Interface adapters conventionally connect to the interface bus via a slot architecture. Conventional slot architectures may be employed, such as, but not limited to: Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and/or the like. [ 00228 ] Storage interfaces 2309 may accept, communicate, and/or connect to a number of storage devices such as, but not limited to: storage devices 2314, removable disc devices, and/or the like. Storage interfaces may employ connection protocols such as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet Interface) ((Ultra) (Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE), Institute of Electrical and Electronics Engineers (IEEE) 1394, fiber channel, Small Computer Systems Interface (SCSI), Universal Serial Bus (USB), and/or the like. [ 00229 ] Network interfaces 2310 may accept, communicate, and/or connect to a communications network 2313. Through a communications network 2313, the ECO ADVANTAGE controller is accessible through remote clients 2333b (e.g., computers with web browsers) by users 2333a. Network interfaces may employ connection protocols such as, but not limited to: direct connect, Ethernet (thick, thin, twisted pair 10/100/1000 Base T, and/or the like), Token Ring, wireless connection such as IEEE 8o2.na-x, and/or the like. Should processing requirements dictate a greater amount speed and/or capacity, distributed network controllers (e.g., Distributed ECO ADVANTAGE), architectures may similarly be employed to pool, load balance, and/or otherwise increase the communicative bandwidth required by the ECO ADVANTAGE controller. A communications network may be any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like. A network interface may be regarded as a specialized form of an input output interface. Further, multiple network 1 interfaces 2310 may be used to engage with various communications network types

2 2313. For example, multiple network interfaces may be employed to allow for the

3 communication over broadcast, multicast, and/or unicast networks.

4 [ 00230 ] Input Output interfaces (I/O) 2308 may accept, communicate, and/or

5 connect to user input devices 2311, peripheral devices 2312, cryptographic processor

6 devices 2328, and/or the like. I/O may employ connection protocols such as, but not

7 limited to: audio: analog, digital, monaural, RCA, stereo, and/or the like; data: Apple

8 Desktop Bus (ADB), IEEE I394a-b, serial, universal serial bus (USB); infrared; joystick;

9 keyboard; midi; optical; PC AT; PS/2; parallel; radio; video interface: Apple Desktop0 Connector (ADC), BNC, coaxial, component, composite, digital, Digital Visual Interface1 (DVI), high-definition multimedia interface (HDMI), RCA, RF antennae, S-Video, VGA,2 and/or the like; wireless transceivers: 802.na/b/g/n/x; Bluetooth; cellular (e.g., code3 division multiple access (CDMA), high speed packet access (HSPA(+)), high-speed4 downlink packet access (HSDPA), global system for mobile communications (GSM),5 long term evolution (LTE), WiMax, etc.); and/or the like. One typical output device may6 include a video display, which typically comprises a Cathode Ray Tube (CRT) or Liquid7 Crystal Display (LCD) based monitor with an interface (e.g., DVI circuitry and cable)s that accepts signals from a video interface, may be used. The video interface composites9 information generated by a computer systemization and generates video signals based0 on the composited information in a video memory frame. Another output device is a1 television set, which accepts signals from a video interface. Typically, the video interface2 provides the composited video information through a video connection interface that3 accepts a video display interface (e.g., an RCA composite video connector accepting an4 RCA composite video cable; a DVI connector accepting a DVI display cable, etc.). 5 [ 00231] User input devices 2311 often are a type of peripheral device 512 (see6 below) and may include: card readers, dongles, finger print readers, gloves, graphics7 tablets, joysticks, keyboards, microphones, mouse (mice), remote controls, retina8 readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors9 (e.g., accelerometers, ambient light, GPS, gyroscopes, proximity, etc.), styluses, and/or0 the like. 1 [ 00232 ] Peripheral devices 2312 may be connected and/or communicate to I/O

2 and/or other facilities of the like such as network interfaces, storage interfaces, directly

3 to the interface bus, system bus, the CPU, and/or the like. Peripheral devices may be

4 external, internal and/or part of the ECO ADVANTAGE controller. Peripheral devices

5 may include: antenna, audio devices (e.g., line-in, line-out, microphone input, speakers,

6 etc.), cameras (e.g., still, video, webcam, etc.), dongles (e.g., for copy protection,

7 ensuring secure transactions with a digital signature, and/or the like), external

8 processors (for added capabilities; e.g., crypto devices 528), force-feedback devices (e.g.,

9 vibrating motors), network interfaces, printers, scanners, storage devices, transceivers

10 (e.g., cellular, GPS, etc.), video devices (e.g., goggles, monitors, etc.), video sources,

11 visors, and/or the like. Peripheral devices often include types of input devices (e.g.,

12 cameras).

13 [ 00233 ] It should be noted that although user input devices and peripheral devices

14 may be employed, the ECO ADVANTAGE controller may be embodied as an embedded,

15 dedicated, and/or monitor-less (i.e., headless) device, wherein access would be provided

16 over a network interface connection.

17 [ 00234] Cryptographic units such as, but not limited to, microcontrollers, is processors 2326, interfaces 2327, and/or devices 2328 may be attached, and/or

19 communicate with the ECO ADVANTAGE controller. A MC68HC16 microcontroller,

20 manufactured by Motorola Inc., may be used for and/or within cryptographic units. The

21 MC68HC16 microcontroller utilizes a 16-bit multiply-and-accumulate instruction in the

22 16 MHz configuration and requires less than one second to perform a 512-bit RSA

23 private key operation. Cryptographic units support the authentication of

24 communications from interacting agents, as well as allowing for anonymous

25 transactions. Cryptographic units may also be configured as part of the CPU. Equivalent

26 microcontrollers and/or processors may also be used. Other commercially available

27 specialized cryptographic processors include: Broadcom's Crypt oNetX and other

28 Security Processors; nCipher's nShield; SafeNet's Luna PCI (e.g., 7100) series;

29 Semaphore Communications' 40 MHz Roadrunner 184; Sun's Cryptographic

30 Accelerators (e.g., Accelerator 6000 PCIe Board, Accelerator 500 Daughtercard); Via 1 Nano Processor (e.g., L2100, L2200, U2400) line, which is capable of performing 500+

2 MB/s of cryptographic instructions; VLSI Technology's 33 MHz 6868; and/or the like.

3 Memory

4 [00235] Generally, any mechanization and/or embodiment allowing a processor to

5 affect the storage and/or retrieval of information is regarded as memory 2329. However,

6 memory is a fungible technology and resource, thus, any number of memory

7 embodiments may be employed in lieu of or in concert with one another. It is to be

8 understood that the ECO ADVANTAGE controller and/or a computer systemization

9 may employ various forms of memory 2329. For example, a computer systemization

10 may be configured wherein the operation of on-chip CPU memory (e.g., registers), RAM,

11 ROM, and any other storage devices are provided by a paper punch tape or paper punch

12 card mechanism; however, such an embodiment would result in an extremely slow rate

13 of operation. In a typical configuration, memory 2329 will include ROM 2306, RAM

14 2305, and a storage device 2314. A storage device 2314 may be any conventional

15 computer system storage. Storage devices may include a drum; a (fixed and/or

16 removable) magnetic disk drive; a magneto-optical drive; an optical drive (i.e., Bluray,

17 CD ROM/RAM/Recordable (R)/ReWritable (RW), DVD R/RW, HD DVD R/RW etc.);

18 an array of devices (e.g., Redundant Array of Independent Disks (RAID)); solid state

19 memory devices (USB memory, solid state drives (SSD), etc.); other processor-readable

20 storage mediums; and/or other devices of the like. Thus, a computer systemization

21 generally requires and makes use of memory.

22 Component Collection

23 [00236] The memory 2329 may contain a collection of program and/or database

24 components and/or data such as, but not limited to: operating system component(s)

25 2315 (operating system); information server component(s) 2316 (information server);

26 user interface component(s) 2317 (user interface); Web browser component(s) 2318

27 (Web browser); database(s) 2319; mail server component(s) 2321; mail client

28 component(s) 2322; cryptographic server component(s) 2320 (cryptographic server);

29 the ECO ADVANTAGE component(s) 2335, including components 2348-2349; and/or 1 the like (i.e., collectively a component collection). These components may be stored and

2 accessed from the storage devices and/or from storage devices accessible through an

3 interface bus. Although non-conventional program components such as those in the

4 component collection, typically, are stored in a local storage device 2314, they may also

5 be loaded and/or stored in memory such as: peripheral devices, RAM, remote storage

6 facilities through a communications network, ROM, various forms of memory, and/or

7 the like.

8 Operating System

9 [00237] The operating system component 2315 is an executable program

10 component facilitating the operation of the ECO ADVANTAGE controller. Typically, the

11 operating system facilitates access of I/O, network interfaces, peripheral devices,

12 storage devices, and/or the like. The operating system may be a highly fault tolerant,

13 scalable, and secure system such as: Apple Macintosh OS X (Server); AT&T Plan 9; Be

14 OS; Unix and Unix-like system distributions (such as AT&T's UNIX; Berkley Software

15 Distribution (BSD) variations such as FreeBSD, NetBSD, OpenBSD, and/or the like;

16 Linux distributions such as Red Hat, Ubuntu, and/or the like); and/or the like operating

17 systems. However, more limited and/or less secure operating systems also may be

18 employed such as Apple Macintosh OS, IBM OS/2, Microsoft DOS, Microsoft Windows

19 2000/2003/3.1/95/98/CE/Millenium/NT/Vista/XP (Server), Palm OS, and/or the like.

20 An operating system may communicate to and/or with other components in a

21 component collection, including itself, and/or the like. Most frequently, the operating

22 system communicates with other program components, user interfaces, and/or the like.

23 For example, the operating system may contain, communicate, generate, obtain, and/or

24 provide program component, system, user, and/or data communications, requests,

25 and/or responses. The operating system, once executed by the CPU, may enable the

26 interaction with communications networks, data, I/O, peripheral devices, program

27 components, memory, user input devices, and/or the like. The operating system may

28 provide communications protocols that allow the ECO ADVANTAGE controller to

29 communicate with other entities through a communications network 2313. Various

30 communication protocols may be used by the ECO ADVANTAGE controller as a subcarrier transport mechanism for interaction, such as, but not limited to: multicast, TCP/IP, UDP, unicast, and/or the like. Information Server

[00238] An information server component 2316 is a stored program component that is executed by a CPU. The information server may be a conventional Internet information server such as, but not limited to Apache Software Foundation's Apache, Microsoft's Internet Information Server, and/or the like. The information server may allow for the execution of program components through facilities such as Active Server Page (ASP), ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, Common Gateway Interface (CGI) scripts, dynamic (D) hypertext markup language (HTML), FLASH, Java, JavaScript, Practical Extraction Report Language (PERL), Hypertext Pre-Processor (PHP), pipes, Python, wireless application protocol (WAP), WebObjects, and/or the like. The information server may support secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), messaging protocols (e.g., America Online (AOL) Instant Messenger (AIM), Application Exchange (APEX), ICQ, Internet Relay Chat (IRC), Microsoft Network (MSN) Messenger Service, Presence and Instant Messaging Protocol (PRIM), Internet Engineering Task Force's (IETF's) Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE), open XML-based Extensible Messaging and Presence Protocol (XMPP) (i.e., Jabber or Open Mobile Alliance's (OMA's) Instant Messaging and Presence Service (IMPS)), Yahoo! Instant Messenger Service, and/or the like. The information server provides results in the form of Web pages to Web browsers, and allows for the manipulated generation of the Web pages through interaction with other program components. After a Domain Name System (DNS) resolution portion of an HTTP request is resolved to a particular information server, the information server resolves requests for information at specified locations on the ECO ADVANTAGE controller based on the remainder of the HTTP request. For example, a request such as http://123.124.125.126/myInformation.html might have the IP portion of the request "123.124.125.126" resolved by a DNS server to an information server at that IP address; that information server might in turn further parse the http request for the "/mylnformation.html" portion of the request and resolve it to a location in memory containing the information "mylnformation.html." Additionally, other information serving protocols may be employed across various ports, e.g., FTP communications across port 21, and/or the like. An information server may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the information server communicates with the ECO ADVANTAGE database 2319, operating systems, other program components, user interfaces, Web browsers, and/or the like. [ 00239 ] Access to the ECO ADVANTAGE database may be achieved through a number of database bridge mechanisms such as through scripting languages as enumerated below (e.g., CGI) and through inter-application communication channels as enumerated below (e.g., CORBA, WebObjects, etc.). Any data requests through a Web browser are parsed through the bridge mechanism into appropriate grammars as required by the ECO ADVANTAGE. In one embodiment, the information server would provide a Web form accessible by a Web browser. Entries made into supplied fields in the Web form are tagged as having been entered into the particular fields, and parsed as such. The entered terms are then passed along with the field tags, which act to instruct the parser to generate queries directed to appropriate tables and/or fields. In one embodiment, the parser may generate queries in standard SQL by instantiating a search string with the proper join/select commands based on the tagged text entries, wherein the resulting command is provided over the bridge mechanism to the ECO ADVANTAGE as a query. Upon generating query results from the query, the results are passed over the bridge mechanism, and may be parsed for formatting and generation of a new results Web page by the bridge mechanism. Such a new results Web page is then provided to the information server, which may supply it to the requesting Web browser. [ 00240 ] Also, an information server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. 1 User Interface

2 [00241] Computer interfaces in some respects are similar to automobile operation

3 interfaces. Automobile operation interface elements such as steering wheels, gearshifts,

4 and speedometers facilitate the access, operation, and display of automobile resources,

5 and status. Computer interaction interface elements such as check boxes, cursors,

6 menus, scrollers, and windows (collectively and commonly referred to as widgets)

7 similarly facilitate the access, capabilities, operation, and display of data and computer

8 hardware and operating system resources, and status. Operation interfaces are

9 commonly called user interfaces. Graphical user interfaces (GUIs) such as the Apple

10 Macintosh Operating System's Aqua, IBM's OS/2, Microsoft's Windows

11 2000/2003/3.i/95/98/CE/Millenium/NT/XP/Vista/7 (i.e., Aero), Unix's X-Windows

12 (e.g., which may include additional Unix graphic interface libraries and layers such as K

13 Desktop Environment (KDE), mythTV and GNU Network Object Model Environment

14 (GNOME)), web interface libraries (e.g., ActiveX, AJAX, (D)HTML, FLASH, Java,

15 JavaScript, etc. interface libraries such as, but not limited to, Dojo, jQuery(UI),

16 MooTools, Prototype, script.aculo.us, SWFObject, Yahoo! User Interface, any of which

17 may be used and) provide a baseline and means of accessing and displaying information

18 graphically to users.

19 [00242] A user interface component 2317 is a stored program component that is

20 executed by a CPU. The user interface may be a conventional graphic user interface as

21 provided by, with, and/or atop operating systems and/or operating environments such

22 as already discussed. The user interface may allow for the display, execution,

23 interaction, manipulation, and/or operation of program components and/or system

24 facilities through textual and/or graphical facilities. The user interface provides a facility

25 through which users may affect, interact, and/or operate a computer system. A user

26 interface may communicate to and/or with other components in a component

27 collection, including itself, and/or facilities of the like. Most frequently, the user

28 interface communicates with operating systems, other program components, and/or the

29 like. The user interface may contain, communicate, generate, obtain, and/or provide

30 program component, system, user, and/or data communications, requests, and/or

31 responses. Web Browser

[00243] A Web browser component 2318 is a stored program component that is executed by a CPU. The Web browser may be a conventional hypertext viewing application such as Microsoft Internet Explorer or Netscape Navigator. Secure Web browsing may be supplied with I28bit (or greater) encryption by way of HTTPS, SSL, and/or the like. Web browsers allowing for the execution of program components through facilities such as ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web browser plug-in APIs (e.g., FireFox, Safari Plug-in, and/or the like APIs), and/or the like. Web browsers and like information access tools may be integrated into PDAs, cellular telephones, and/or other mobile devices. A Web browser may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the Web browser communicates with information servers, operating systems, integrated program components (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. Also, in place of a Web browser and information server, a combined application may be developed to perform similar operations of both. The combined application would similarly affect the obtaining and the provision of information to users, user agents, and/or the like from the ECO ADVANTAGE enabled nodes. The combined application may be nugatory on systems employing standard Web browsers. Mail Server

[00244] A mail server component 2321 is a stored program component that is executed by a CPU 2303. The mail server may be a conventional Internet mail server such as, but not limited to sendmail, Microsoft Exchange, and/or the like. The mail server may allow for the execution of program components through facilities such as ASP, ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, CGI scripts, Java, JavaScript, PERL, PHP, pipes, Python, WebObjects, and/or the like. The mail server may support communications protocols such as, but not limited to: Internet message access protocol (IMAP), Messaging Application Programming Interface (MAPI)/Microsoft Exchange, post office protocol (POP3), simple mail transfer protocol (SMTP), and/or the like. The mail server can route, forward, and process incoming and outgoing mail messages that have been sent, relayed and/or otherwise traversing through and/or to the ECO ADVANTAGE.

[00245] Access to the ECO ADVANTAGE mail may be achieved through a number of APIs offered by the individual Web server components and/or the operating system.

[00246] Also, a mail server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses. Mail Client [00247] A mail client component 2322 is a stored program component that is executed by a CPU 2303. The mail client may be a conventional mail viewing application such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook Express, Mozilla, Thunderbird, and/or the like. Mail clients may support a number of transfer protocols, such as: IMAP, Microsoft Exchange, POP3, SMTP, and/or the like. A mail client may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the mail client communicates with mail servers, operating systems, other mail clients, and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses. Generally, the mail client provides a facility to compose and transmit electronic mail messages. Cryptographic Server [00248] A cryptographic server component 2320 is a stored program component that is executed by a CPU 2303, cryptographic processor 2326, cryptographic processor interface 2327, cryptographic processor device 2328, and/or the like. Cryptographic processor interfaces will allow for expedition of encryption and/or decryption requests by the cryptographic component; however, the cryptographic component, alternatively, may run on a conventional CPU. The cryptographic component allows for the encryption and/or decryption of provided data. The cryptographic component allows for both symmetric and asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/or decryption. The cryptographic component may employ cryptographic techniques such as, but not limited to: digital certificates (e.g., X.509 authentication framework), digital signatures, dual signatures, enveloping, password access protection, public key management, and/or the like. The cryptographic component will facilitate numerous (encryption and/or decryption) security protocols such as, but not limited to: checksum, Data Encryption Standard (DES), Elliptical Curve Encryption (ECC), International Data Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash operation), passwords, Rivest Cipher (RC5), Rijndael, RSA (which is an Internet encryption and authentication system that uses an algorithm developed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA), Secure Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and/or the like. Employing such encryption security protocols, the ECO ADVANTAGE may encrypt all incoming and/or outgoing communications and may serve as node within a virtual private network (VPN) with a wider communications network. The cryptographic component facilitates the process of "security authorization" whereby access to a resource is inhibited by a security protocol wherein the cryptographic component effects authorized access to the secured resource. In addition, the cryptographic component may provide unique identifiers of content, e.g., employing and MD5 hash to obtain a unique signature for an digital audio file. A cryptographic component may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. The cryptographic component supports encryption schemes allowing for the secure transmission of information across a communications network to enable the ECO ADVANTAGE component to engage in secure transactions if so desired. The cryptographic component facilitates the secure accessing of resources on the ECO ADVANTAGE and facilitates the access of secured resources on remote systems; i.e., it may act as a client and/or server of secured resources. Most frequently, the cryptographic component communicates with information servers, operating systems, other program components, and/or the like. The cryptographic component may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. The ECO ADVANTAGE Database [00249] The ECO ADVANTAGE database component 2319 may be embodied in a database and its stored data. The database is a stored program component, which is executed by the CPU; the stored program component portion configuring the CPU to process the stored data. The database may be a conventional, fault tolerant, relational, scalable, secure database such as Oracle or Sybase. Relational databases are an extension of a flat file. Relational databases consist of a series of related tables. The tables are interconnected via a key field. Use of the key field allows the combination of the tables by indexing against the key field; i.e., the key fields act as dimensional pivot points for combining information from various tables. Relationships generally identify links maintained between tables by matching primary keys. Primary keys represent fields that uniquely identify the rows of a table in a relational database. More precisely, they uniquely identify rows of a table on the "one" side of a one-to-many relationship.

[00250] Alternatively, the ECO ADVANTAGE database may be implemented using various standard data-structures, such as an array, hash, (linked) list, struct, structured text file (e.g., XML), table, and/or the like. Such data-structures may be stored in memory and/or in (structured) files. In another alternative, an object-oriented database may be used, such as Frontier, ObjectStore, Poet, Zope, and/or the like. Object databases can include a number of object collections that are grouped and/or linked together by common attributes; they may be related to other object collections by some common attributes. Object-oriented databases perform similarly to relational databases with the exception that objects are not just pieces of data but may have other types of capabilities encapsulated within a given object. If the ECO ADVANTAGE database is implemented as a data-structure, the use of the ECO ADVANTAGE database 2319 may be integrated into another component such as the ECO ADVANTAGE component 2335. Also, the database may be implemented as a mix of data structures, objects, and relational structures. Databases may be consolidated and/or distributed in countless variations through standard data processing techniques. Portions of databases, e.g., tables, may be exported and/or imported and thus decentralized and/or integrated. [00251] In one embodiment, the database component 2319 includes several tables 23i9a-k, m-n, p-r. [ 00252] A users table 2319a includes fields such as, but not limited to: a user_ID, user_fhame, user_lname, user_ID_type, user_auth_code, user_email, user_address, user_date_created, user_pay_method, user_password, user_phone, user_interests, user_devices, user_confirmed, user_account_locked, user_enabled, user_username, and/or the like. The user table may support and/or track multiple user accounts on a ECO ADVANTAGE. A merchants table 2319b includes fields such as, but not limited to: merchant_ID, merchant_name, merchant_email, merchant_date_created, merchant_username, merchant_password, merchant_enabled, merchant_account_locked, merchant_confirmed, merchant_phone, merchant_contact, merchant_open_time, merchant_website, merchant_region, merchant_min_consumpt, merchant_max_consumpt, merchant_bank, merchant_bank_agency, merchant_bank_acct, and/or the like. The merchant table may support and/or track multiple merchant accounts on a ECO ADVANTAGE. An Economic Promoter table 2319c includes fields such as, but not limited to: ep_ID, ep_date_created, ep_ecos, ep_users, ep_region, ep_username, ep_password, and/or the like. The Economic Promoter table may support and/or track multiple Economic Promoter accounts on a ECO ADVANTAGE. A Merchant Agents table 23i9d includes fields such as, but not limited to: ma_ID, ma_name, ma_merchants, ma_region, ma_categories, ma_parameters, ma_agg_info, and/or the like. The Merchant Agent table may support and/or track multiple Merchant Agent accounts on a ECO ADVANTAGE. A partners table 2319ε includes fields such as, but not limited to: partner_ID, partner_name, partner_email, partner_date_created, partner_username, partner_password, partner_enabled, partner_account_locked, partner_confirmed, partner_phone, partner_contact, partner_open_time, partner_website, partner_region, partner_min_consumpt, partner_max_consumpt, partnerjbank, partner_bank_agency, partner_bank_acct, and/or the like. The partner table may support and/or track multiple partner accounts on a ECO ADVANTAGE. An ecos table 23i9f includes fields such as, but not limited to: eco_ID, eco_user_ID, eco_merchant_ID, eco_expiration, eco_donated, and/or the like. The ecos table may support and/or track multiple ecos on an ECO ADVANTAGE. A PoS table 23i9g includes fields such as, but not limited to: pos_ID, pos_infrastructure, pos_configuration, pos_settings, and/or the like. The PoS table may support and/or track multiple PoS devices on a ECO ADVANTAGE. A transactions table 2319b includes fields such as, but not limited to: transaction_ID, transaction_date, transaction_amount, transaction_user, transaction_merchant, transaction_ecos_paid, transaction_ecos_received, transaction_payment_method, transaction_atmospherics, and/or the like. The transaction table may support and/or track multiple transactions on a ECO ADVANTAGE. A transaction analytics table 23191 includes fields such as, but not limited to: ta_ID, ta_date, ta_results_merchants, ta_results_transactions, ta_results_ecos, ta_results_credit, ta_results_acquirer, ta_results_users, ta_results_ea, and/or the like. The transaction analytics table may support and/or track transaction analytics results on a ECO ADVANTAGE. An acquirers table 2319] includes fields such as, but not limited to: account_firstname, account_lastname, account_type, account_num, account_ balance_list, billingaddress_ linei, billingaddress_ line2, billing_zipcode, billing_state, shipping_preferences, shippingaddress_linei, shippingaddress_line2, shipping_ zipcode, shipping_state, and/or the like. The acquirer table may support and/or track multiple acquirer accounts on a ECO ADVANTAGE. An issuers table 2319k includes fields such as, but not limited to: issuer_id, issuer_name, issuer_address, ip_address, mac_address, auth_key, port_num, security_settings_list, and/or the like. The issuer table may support and/or track multiple issuer accounts on a ECO ADVANTAGE. A bonus blocks table 2319m includes fields such as, but not limited to: bb_ID, bb_user_ID, bb_merchant_ID, bb_expiration, bb_type, and/or the like. The bonus blocks table may support and/or track multiple bonus blocks on a ECO ADVANTAGE. A regions table 2319η includes fields such as, but not limited to: region_ID, region_name, region_geography, region_demographics, region_demarcations, region_mer chants, region_users, region_partners, region_epromoters, region_mmanagers, region_categories, and/or the like. The regions table may support and/or track multiple regions on a ECO ADVANTAGE. A categories table 2319P includes fields such as, but not limited to: category_ID, category_interests, category_merchants, category_users, category_region, and/or the like. The categories table may support and/or track multiple categories on a ECO ADVANTAGE. A schedules table 2^i q includes fields such as, but not limited to: schedule_ID, schedule_annual, schedule_monthly, schedule_weekly, schedule_daily, schedule_special_schedules, schedule_entity_ID and/or the like. The schedules table may support and/or track multiple eco schedules on a ECO ADVANTAGE. A BI information table 23i9r includes fields such as, but not limited to: bi_id, bi_transactions, bi_analytics,and/or the like. The BI information table may support and/or track BI information on a ECO ADVANTAGE. [ 00253 ] In one embodiment, the ECO ADVANTAGE database may interact with other database systems. For example, employing a distributed database system, queries and data access by search ECO ADVANTAGE component may treat the combination of the ECO ADVANTAGE database, an integrated data security layer database as a single database entity. [ 00254] In one embodiment, user programs may contain various user interface primitives, which may serve to update the ECO ADVANTAGE. Also, various accounts may require custom database tables depending upon the environments and the types of clients the ECO ADVANTAGE may need to serve. It should be noted that any unique fields may be designated as a key field throughout. In an alternative embodiment, these tables have been decentralized into their own databases and their respective database controllers (i.e., individual database controllers for each of the above tables). Employing standard data processing techniques, one may further distribute the databases over several computer systemizations and/or storage devices. Similarly, configurations of the decentralized database controllers may be varied by consolidating and/or distributing the various database components 23i9a-k, m-n, p-r. The ECO ADVANTAGE may be configured to keep track of various settings, inputs, and parameters via database controllers. [ 00255 ] The ECO ADVANTAGE database may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the ECO ADVANTAGE database communicates with the ECO ADVANTAGE component, other program components, and/or the like. The database may contain, retain, and provide information regarding other nodes and data. The ECO ADVANTAGES [00256] The ECO ADVANTAGE component 2335 is a stored program component that is executed by a CPU. In one embodiment, the ECO ADVANTAGE component incorporates any and/or all combinations of the aspects of the ECO ADVANTAGE that was discussed in the previous figures. As such, the ECO ADVANTAGE affects accessing, obtaining and the provision of information, services, transactions, and/or the like across various communications networks. The features and embodiments of the ECO ADVANTAGE discussed herein increase network efficiency by reducing data transfer requirements the use of more efficient data structures and mechanisms for their transfer and storage. As a consequence, more data may be transferred in less time, and latencies with regard to transactions, are also reduced. In many cases, such reduction in storage, transfer time, bandwidth requirements, latencies, etc., will reduce the capacity and structural infrastructure requirements to support the ECO ADVANTAGE'S features and facilities, and in many cases reduce the costs, energy consumption/requirements, and extend the life of ECO ADVANTAGE'S underlying infrastructure; this has the added benefit of making the ECO ADVANTAGE more reliable. Similarly, many of the features and mechanisms are designed to be easier for users to use and access, thereby broadening the audience that may enjoy/employ and exploit the feature sets of the ECO ADVANTAGE; such ease of use also helps to increase the reliability of the ECO ADVANTAGE. In addition, the feature sets include heightened security as noted via the Cryptographic components 2320, 2326, 2328 and throughout, making access to the features and data more reliable and secure.

[00257] The ECO ADVANTAGE transforms transaction and user, merchant, and payment data inputs via ECO ADVANTAGE Transaction Processing Component 2341, User Enrollment Component 2342, Merchant Enrollment Component 2343, Eco Schedule Calculation Component 2344, Merchant Information Aggregation and Analytics Component 2345, PoS Configuration Component 2346, User Invitation Component 2347, Region/Category Management Component 2348, Reconciliation 1 Component 2349, Partner Enrollment Component 2350, Ecos Donation Component

2 2351, and Econometer Telemetry Component 2352, into eco, transaction, and region

3 analytics outputs.

4 [00258] The ECO ADVANTAGE component enabling access of information

5 between nodes may be developed by employing standard development tools and

6 languages such as, but not limited to: Apache components, Assembly, ActiveX, binary

7 executables, (ANSI) (Objective-) C (++), C# and/or .NET, database adapters, CGI

8 scripts, Java, JavaScript, mapping tools, procedural and object oriented development

9 tools, PERL, PHP, Python, shell scripts, SQL commands, web application server0 extensions, web development environments and libraries (e.g., Microsoft's ActiveX;1 Adobe AIR, FLEX & FLASH; AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI);2 MooTools; Prototype; script.aculo.us; Simple Object Access Protocol (SOAP);3 SWFObject; Yahoo! User Interface; and/or the like), WebObjects, and/or the like. In4 one embodiment, the ECO ADVANTAGE server employs a cryptographic server to5 encrypt and decrypt communications. The ECO ADVANTAGE component may6 communicate to and/or with other components in a component collection, including7 itself, and/or facilities of the like. Most frequently, the ECO ADVANTAGE component8 communicates with the ECO ADVANTAGE database, operating systems, other program9 components, and/or the like. The ECO ADVANTAGE may contain, communicate,0 generate, obtain, and/or provide program component, system, user, and/or data1 communications, requests, and/or responses. 2 Distributed ECO ADVANTAGES 3 [00259] The structure and/or operation of any of the ECO ADVANTAGE node4 controller components may be combined, consolidated, and/or distributed in any5 number of ways to facilitate development and/or deployment. Similarly, the component6 collection may be combined in any number of ways to facilitate deployment and/or7 development. To accomplish this, one may integrate the components into a common8 code base or in a facility that can dynamically load the components on demand in an9 integrated fashion. [00260] The component collection may be consolidated and/or distributed in countless variations through standard data processing and/or development techniques. Multiple instances of any one of the program components in the program component collection may be instantiated on a single node, and/or across numerous nodes to improve performance through load-balancing and/or data-processing techniques. Furthermore, single instances may also be distributed across multiple controllers and/or storage devices; e.g., databases. All program component instances and controllers working in concert may do so through standard data processing communication techniques.

[00261] The configuration of the ECO ADVANTAGE controller will depend on the context of system deployment. Factors such as, but not limited to, the budget, capacity, location, and/or use of the underlying hardware resources may affect deployment requirements and configuration. Regardless of if the configuration results in more consolidated and/or integrated program components, results in a more distributed series of program components, and/or results in some combination between a consolidated and distributed configuration, data may be communicated, obtained, and/or provided. Instances of components consolidated into a common code base from the program component collection may communicate, obtain, and/or provide data. This may be accomplished through intra- application data processing communication techniques such as, but not limited to: data referencing (e.g., pointers), internal messaging, object instance variable communication, shared memory space, variable passing, and/or the like.

[00262] If component collection components are discrete, separate, and/or external to one another, then communicating, obtaining, and/or providing data with and/or to other component components may be accomplished through inter-application data processing communication techniques such as, but not limited to: Application Program Interfaces (API) information passage; (distributed) Component Object Model ((D)COM), (Distributed) Object Linking and Embedding ((D)OLE), and/or the like), Common Object Request Broker Architecture (CORBA), Jini local and remote application program interfaces, JavaScript Object Notation (JSON), Remote Method Invocation (RMI), SOAP, process pipes, shared files, and/or the like. Messages sent between discrete component components for inter-application communication or within memory spaces of a singular component for intra-application communication may be facilitated through the creation and parsing of a grammar. A grammar may be developed by using development tools such as lex, yacc, XML, and/or the like, which allow for grammar generation and parsing capabilities, which in turn may form the basis of communication messages within and between components.

[00263] For example, a grammar may be arranged to recognize the tokens of an HTTP post command, e.g.:

w3c -post http : // . . . Valuel [00264] where Valuei is discerned as being a parameter because "http://" is part of the grammar syntax, and what follows is considered part of the post value. Similarly, with such a grammar, a variable "Valuei" may be inserted into an "http://" post command and then sent. The grammar syntax itself may be presented as structured data that is interpreted and/or otherwise used to generate the parsing mechanism (e.g., a syntax description text file as processed by lex, yacc, etc.). Also, once the parsing mechanism is generated and/or instantiated, it itself may process and/or parse structured data such as, but not limited to: character (e.g., tab) delineated text, HTML, structured text streams, XML, and/or the like structured data. In another embodiment, inter-application data processing protocols themselves may have integrated and/or readily available parsers (e.g., JSON, SOAP, and/or like parsers) that may be employed to parse (e.g., communications) data. Further, the parsing grammar may be used beyond message parsing, but may also be used to parse: databases, data collections, data stores, structured data, and/or the like. Again, the desired configuration will depend upon the context, environment, and requirements of system deployment.

[00265] For example, in some implementations, the ECO ADVANTAGE controller may be executing a PHP script implementing a Secure Sockets Layer ("SSL") socket server via the information server, which listens to incoming communications on a server port to which a client may send data, e.g., data encoded in JSON format. Upon identifying an incoming communication, the PHP script may read the incoming message from the client device, parse the received JSON-encoded text data to extract information from the JSON-encoded text data into PHP script variables, and store the data (e.g., client identifying information, etc.) and/or extracted information in a relational database accessible using the Structured Query Language ("SQL"). An exemplary listing, written substantially in the form of PHP/SQL commands, to accept JSON- encoded input data from a client device via a SSL connection, parse the data to extract variables, and store the data to a database, is provided below:

<?PHP

header( 'Content-Type: text/plain'); // set ip address and port to listen to for incoming data

$address = '192.168.0.100';

$port = 255; // create a server-side SSL socket, listen for/accept incoming communication $sock = socket_create(AF_INET, S0CK_STREAM, 0);

socket_bind($sock, $address, $port) or die('Could not bind to address');

socket_listen($sock);

$client = socket_accept($sock) ; // read input data from client device in 1024 byte blocks until end of message do {

$input = "";

$input = socket_read($client, 1024);

$data .= $input;

} while($input != ""); // parse data to extract variables

$obj = json_decode($data, true); // store input data in a database

mysql_connect("201.408.185.132" ,$DBserver ,$password); // access database server mysql_select("CLIENT_DB.SQL"); // select database to append

mysql_query("INSERT INTO UserTable (transmission)

VALUES ($data)"); // add data to UserTable table in a CLIENT database

mysql_close("CLIENT_DB.SQL"); // close connection to database ?> [00266] Also, the following resources may be used to provide example embodiments regarding SOAP parser implementation:

http://www.xav. com/perl/site/lib/SOAP/Parser. html

http://publib . boulder . ibm. com/infocenter/tivihelp/v2rl/index. jsp?topic=/com. ibm . IBMDI . doc/referenceguide295. htm [00267] and other parser implementations:

http://publib . boulder . ibm. com/infocenter/tivihelp/v2rl/index. jsp?topic=/com. ibm . IBMDI . doc/referenceguide259. htm [ o o 268 ] all of which are hereby expressly incorporated by reference.

[00269] In order to address various issues and advance the art, the entirety of this application for ECO ADVANTAGE MEDIATION APPARATUSES, METHODS AND SYSTEMS (including the Cover Page, Title, Headings, Field, Background, Summary, Brief Description of the Drawings, Detailed Description, Claims, Abstract, Figures, Appendices, and otherwise) shows, by way of illustration, various embodiments in which the claimed innovations may be practiced. The advantages and features of the application are of a representative sample of embodiments only, and are not exhaustive and/or exclusive. They are presented only to assist in understanding and teach the claimed principles. It should be understood that they are not representative of all claimed innovations. As such, certain aspects of the disclosure have not been discussed herein. That alternate embodiments may not have been presented for a specific portion of the innovations or that further undescribed alternate embodiments may be available for a portion is not to be considered a disclaimer of those alternate embodiments. It will be appreciated that many of those undescribed embodiments incorporate the same principles of the innovations and others are equivalent. Thus, it is to be understood that other embodiments may be utilized and functional, logical, operational, organizational, structural and/or topological modifications may be made without departing from the scope and/or spirit of the disclosure. As such, all examples and/or embodiments are deemed to be non-limiting throughout this disclosure. Also, no inference should be drawn regarding those embodiments discussed herein relative to those not discussed herein other than it is as such for purposes of reducing space and repetition. For instance, it is to be understood that the logical and/or topological structure of any combination of any program components (a component collection), other components and/or any present feature sets as described in the figures and/or throughout are not limited to a fixed operating order and/or arrangement, but rather, any disclosed order is exemplary and all equivalents, regardless of order, are contemplated by the disclosure. Furthermore, it is to be understood that such features are not limited to serial execution, but rather, any number of threads, processes, services, servers, and/or the like that may execute asynchronously, concurrently, in parallel, simultaneously, synchronously, and/or the like are contemplated by the disclosure. As such, some of these features may be mutually contradictory, in that they cannot be simultaneously present in a single embodiment. Similarly, some features are applicable to one aspect of the innovations, and inapplicable to others. In addition, the disclosure includes other innovations not presently claimed. Applicant reserves all rights in those presently unclaimed innovations including the right to claim such innovations, file additional applications, continuations, continuations in part, divisions, and/or the like thereof. As such, it should be understood that advantages, embodiments, examples, functional, features, logical, operational, organizational, structural, topological, and/or other aspects of the disclosure are not to be considered limitations on the disclosure as defined by the claims or limitations on equivalents to the claims. It is to be understood that, depending on the particular needs and/or characteristics of a ECO ADVANTAGE individual and/or enterprise user, database configuration and/or relational model, data type, data transmission and/or network framework, syntax structure, and/or the like, various embodiments of the ECO ADVANTAGE, may be implemented that enable a great deal of flexibility and customization. For example, aspects of the ECO ADVANTAGE may be adapted for health care, travel services, Accessories, Advertising and Marketing, Animal Clinic and Hospital, Arts and Crafts, Auto Body Shop, Auto Dealer, Auto Electric Shop, Auto Parts Store, Bakery, Beauty Clinic, Book Wholesale, Bookstore, Building Supplies, Camera and Photo, Car- Wash, Ceilings/ Partition, Cell Phone Provider, Children's Store, Chocolate Shop, Clothing Repair, Coffee Shop, Computer and Accessories, Convenience Store, Cosmetics, Costume Shop, Courier Service, Dairy Products, Delicatessen, Diner, Do-It- Yourself Store, Durable Medical Equipment, DVD and Movies, Electrical Parts, Electronic and Video Game, Eletro/electronic Repair and Maintenance, Eyeglasses and Sunglasses, Fabric and Upholstery Store, Fast Graphic Service, Furniture Store, Gas Station, Gift Store, Gourmet and Specialty Food Store, Grocery Store, Gym, Hardware Store, Heating and Air Conditioning, Home and Gardening, Home and Kitchen Goods, Home Appliance, Home Improvement, Home Phone Provider, Hotels, Ice Cream Parlour, Janitorial / Cleaning Supplies, Jewelry, Kids Party Place, Kids Tutoring, Language School or Learning Center, Laundry and Dry Cleaning, Leisure and Tourism, Light Fixture, Lingerie and Intimate Apparel, Locksmith, Luggage and Suitcase Store, Men's Fashion, Motels, Motorcycle Dealer, Movie Theater, Moving Service, Musical Instrument Shop, Natural Food Store, Nautical Store, Nightclub / Disco, Office Supplies, Paint Store, Party Supply Store, Perfumery, Personal Development Course, Pet Shop, Pharmacy, Plastic Surgery, Refrigeration Shop, Restaurant (all kinds), Rotisserie, Rug and Curtain Shop, School, Shoe Repair, Shoe Store, SPA, Specialty Pharmacy, Sporting Goods, Sport Tickets, Supermarket, Surgical Equipment, Swimwear Fashion, Technical Course, Theaters, Tickets (ShowsConcerts), Toy Store, Visual Communication, Winery, Women's Fashion, and/or the like. While various embodiments and discussions of the ECO ADVANTAGE have included commerce transactions between merchants and users, however, it is to be understood that the embodiments described herein may be readily configured and/or customized for a wide variety of other applications and/or implementations. [ 00270 ] In some implementations, some embodiments may include: [ 00271 ] 1. A processor-implemented method for mutual benefits, comprising:

receiving a request for a user's transaction value modifier (TVM) balance and a merchant's current TVM schedule from a merchant;

receiving a TVM transaction confirmation indicating a transaction has been successfully processed, and TVM transaction data; debiting from a user's account an amount of TVM s received from another merchant in a previous transaction for use in the transaction; crediting to the user's account an amount of TVMs based on the TVM transaction data; and generating via a processor a TVM transaction record and storing the TVM transaction data in the TVM transaction record. [ 00272 ] 2. The method of embodiment 1, further comprising: updating via the processor the merchant's current TVM schedule in the database using the TVM record. [ 00273 ] 3. The method of embodiment 1, wherein a TVM is an eco, a value identifier, or a subsequent value transaction modifier. [ 00274 ] 4. The method of embodiment 1, wherein the user's TVM balance is updated after receiving the TVM transaction confirmation. [ 00275 ] 5. The method of embodiment 1, wherein the user's TVM balance is updated before receiving the TVM transaction confirmation. [ 00276 ] 6. The method of embodiment 1, wherein the TVM transaction comprises paying at least a portion of the transaction amount in TVMs and at least a portion of the transaction amount with a payment device. [ 00277] 7. The method of embodiment 6, wherein the payment device is one of a credit card, debit card, or prepaid card. [ 00278 ] 8. The method of embodiment 1, wherein the TVM transaction comprises paying at least a portion of the transaction amount in TVMs and at least a portion of the transaction amount with cash. [ 00279 ] 9. The method of embodiment 1, wherein the TVM transaction comprises paying at least a portion of the transaction amount in TVMs, at least a portion of the transaction amount with cash, and at least a portion of the transaction amount with a payment device. [ 00280 ] 10. The method of embodiment 9, wherein the payment device is one of a credit card, debit card, or prepaid card. [ 00281] 11. The method of embodiment 1, wherein the credited transaction value modifiers can only be used in subsequent transactions. [ 00282] 12. The method of embodiment 11, wherein the credited transaction value modifiers is marked as originating from the merchant; and wherein the transaction value modifiers cannot be used in subsequent transactions at the merchant from which they originated. [ 00283 ] 13. The method of embodiment 1, further comprising: sending the user's TVM balance and the merchant's current TVM schedule to the merchant. [ o o 284] 14. A processor-implemented method for mutual benefits, comprising: sending to the user the user's TVM balance and an indication that at least some TVMs in the user's TVMs balance will expire; receiving a request to donate expiring TVMs to a designated friend; allocating via a processor the user's expiring TVMs to be donated to the designated friend; sending a TVM donation message to the designated friend; receiving from the designated friend an enrollment request; generating via a processor a new user account for the designated friend; transferring the allocated expiring TVMs to the designated friend's new user account; and sending a confirmation of the transfer to the user and to the designated friend. [ 00285 ] 15. The method of embodiment 14, further comprising: monitoring the spending of the user's donated TVMs by the designated friend; and allocating via a processor an invite bonus block to the user's account when a predetermined number of the user's donated TVMs have been spent. [ 00286 ] 16. The method of embodiment 14, further comprising: receiving a request from a user for user transaction value modifier (TVM) balance information; [ 00287] 17. The method of embodiment 15, wherein the mutual benefit enrollment request further comprises an amount of TVM gifted by an economic promoter. [00288 ] 18. The method of embodiment 17, wherein the economic promoter obtains a percentage of the amount of TVMs donated to the friend. [00289 ] 19. The method of embodiment 18, wherein a merchant manager gifts TVMs to the economic promoter and obtains a percentage of the amount of TVMs gifted to the friend. [ 00290 ] 20. A processor-implemented method for mutual benefits, comprising: receiving an indication of preliminary interest in a mutual benefit program; providing to the merchant a mutual benefit enrollment request form; receiving a mutual benefit enrollment request from a merchant for the mutual benefit program; sending a mutual benefit enrollment form to the merchant; receiving from the merchant a completed mutual benefit enrollment form; sending a request to a merchant agent requesting background material on the merchant; receiving background material on the merchant from the merchant agent; analyzing the background material from the merchant agent;enrolling the merchant in the mutual benefit program if the background material meets predetermined criteria; generating a merchant account for the merchant; and sending the merchant a confirmation of enrollment in the mutual benefits program. [ o o 291 ] 21. The method of embodiment 20, further comprising: receiving from a merchant a survey of current point-of-sales (PoS) infrastructure and settings configurations; determining a new PoS configuration for the merchant based on mutual benefit program specifications; and sending the new PoS configuration and the training materials to the merchant for implementation. [ 00292 ] 22. The method of embodiment 21, further comprising: generating training materials for the new PoS configuration. [ 00293 ] 23. A processor-implemented method for mutual benefits, comprising: receiving a request for a user's value point balance and a merchant's current value point schedule from a merchant; receiving a value point transaction confirmation indicating a transaction has been successfully processed and value point transaction data; debiting from a user's account an amount of value points received from another merchant in a previous transaction for use in the transaction; crediting to the user's account an amount of value points based on the value point transaction data; and generating via a processor a value point transaction record and storing the value point transaction data in the value point transaction record. [ 00294 ] 24. The method of embodiment 23, further comprising: updating via the processor the merchant's current value point schedule in the database using the value point record. [ 00295 ] 25. A processor-implemented method for mutual benefits, comprising: receiving a product bulk amount from a partner; receiving a request for a merchant's transaction value modifier (TVM) balance and a partner's current TVM schedule from a partner; sending the merchant's TVM balance and the partner's current TVM schedule to the partner; receiving a TVM transaction confirmation indicating a transaction involving purchasing at least one product bulk amount has been successfully processed and TVM transaction data; debiting from the merchant's account an amount of TVMs used in the transaction; crediting to the merchant's account an amount of TVM based on the TVM transaction data; generating via a processor a TVM transaction record and storing the TVM transaction data in the TVM transaction record; and updating via the processor the merchant's current TVM schedule in the database using the TVM transaction record. [ 00296 ] 26. A processor-implemented method for mutual benefits, comprising: receiving aggregated entity data in a mutual benefits program within a defined geo- demographical region; performing performance analytics on the entity data; determining demarcation indicia to divide a region if the region is overpopulated; splitting the region based on the geo-demographical demarcation indicia into sub- regions; receiving updated demographic and industry data on each sub-region; and generating new merchant categories for each sub-region based on the updated demographic and industry data. [ 00297] 27. The method of embodiment 26, wherein the entity is at least one of a merchant or demographic data. [ 00298 ] 28. A processor-implemented method for mutual benefits, comprising: receiving aggregated entity data in a mutual benefits program within a defined geo- demographical region; performing performance analytics on the entity data; determining enrollment criteria for enrolling at least one merchant in the mutual benefits program if at least one merchant in the region is over-capacity; sending a mutual benefit enrollment form to a merchant not enrolled in the mutual benefits program; receiving from the merchant not enrolled in the mutual benefits program a completed mutual benefit enrollment form; enrolling the merchant in the mutual benefits program; and updating the region record in a database to include the enrolled merchant. [ 00299 ] 29. The method of embodiment 28, wherein the entity is at least one of a merchant or demographic data. [ 00300 ] 30. The method of embodiment 28, wherein the enrollment criteria may include the category that the at least one merchant in the region which is over-capacity. [ 00301] 31. A system for mutual benefits, comprising: means for receiving a request for a user's transaction value modifier (TVM) balance and a merchant's current TVM schedule from a merchant; means for receiving a TVM transaction confirmation indicating a transaction has been successfully processed, and TVM transaction data; means for debiting from a user's account an amount of TVMs received from another merchant in a previous transaction for use in the transaction; means for crediting to the user's account an amount of TVMs based on the TVM transaction data; and means for generating via a processor a TVM transaction record and storing the TVM transaction data in the TVM transaction record. [ 00302 ] 32. The system of embodiment 31, further comprising: means for updating via the processor the merchant's current TVM schedule in the database using the TVM record. [ 00303 ] 33. The system of embodiment 31, wherein a TVM is an eco, a value identifier, or a subsequent value transaction modifier. [ 00304] 34. The system of embodiment 31, wherein the user's TVM balance is updated after receiving the TVM transaction confirmation. [ 00305 ] 35. The system of embodiment 31, wherein the user's TVM balance is updated before receiving the TVM transaction confirmation. [ 00306 ] 36. The system of embodiment 31, wherein the TVM transaction comprises paying at least a portion of the transaction amount in TVMs and at least a portion of the transaction amount with a payment device. [ 00307] 37. The system of embodiment 36, wherein the payment device is one of a credit card, debit card, or prepaid card. [ 00308 ] 38. The system of embodiment 31, wherein the TVM transaction comprises paying at least a portion of the transaction amount in TVMs and at least a portion of the transaction amount with cash. [ 00309 ] 39. The system of embodiment 31, wherein the TVM transaction comprises paying at least a portion of the transaction amount in TVMs, at least a portion of the transaction amount with cash, and at least a portion of the transaction amount with a payment device. [ 00310 ] 40. The system of embodiment 39, wherein the payment device is one of a credit card, debit card, or prepaid card. [ 00311 ] 41. The system of embodiment 31, wherein the credited transaction value modifiers can only be used in subsequent transactions. [ 00312 ] 42. The system of embodiment 41, wherein the credited transaction value modifiers is marked as originating from the merchant; and wherein the transaction value modifiers cannot be used in subsequent transactions at the merchant from which they originated. [ 00313 ] 43. The system of embodiment 31, further comprising: means for sending the user's TVM balance and the merchant's current TVM schedule to the merchant. [ o o 314 ] 44. A system for mutual benefits, comprising: means for sending to the user the user's TVM balance and an indication that at least some TVMs in the user's TVMs balance will expire; means for receiving a request to donate expiring TVMs to a designated friend; means for allocating via a processor the user's expiring TVMs to be donated to the designated friend; means for sending a TVM donation message to the designated friend; means for receiving from the designated friend an enrollment request; means for generating via a processor a new user account for the designated friend; means for transferring the allocated expiring TVMs to the designated friend's new user account; and means for sending a confirmation of the transfer to the user and to the designated friend. [ 00315 ] 45. The system of embodiment 44, further comprising: means for monitoring the spending of the user's donated TVMs by the designated friend; and means for allocating via a processor an invite bonus block to the user's account when a predetermined number of the user's donated TVMs have been spent. [ 00316 ] 46. The system of embodiment 44, further comprising: means for receiving a request from a user for user transaction value modifier (TVM) balance information; [ 00317] 47. The system of embodiment 45, wherein the mutual benefit enrollment request further comprises an amount of TVM gifted by an economic promoter. [ 00318 ] 48. The system of embodiment 47, wherein the economic promoter obtains a percentage of the amount of TVMs donated to the friend. [ 00319 ] 49. The system of embodiment 48, wherein a merchant manager gifts TVMs to the economic promoter and obtains a percentage of the amount of TVMs gifted to the friend. [ 00320 ] 50. A system for mutual benefits, comprising: means for receiving an indication of preliminary interest in a mutual benefit program; means for providing to the merchant a mutual benefit enrollment request form;

means for receiving a mutual benefit enrollment request from a merchant for the mutual benefit program;

means for sending a mutual benefit enrollment form to the merchant;

means for receiving from the merchant a completed mutual benefit enrollment form; means for sending a request to a merchant agent requesting background material on the merchant;

means for receiving background material on the merchant from the merchant agent; means for analyzing the background material from the merchant agent;

means for enrolling the merchant in the mutual benefit program if the background material meets predetermined criteria;

means for generating a merchant account for the merchant; and

means for sending the merchant a confirmation of enrollment in the mutual benefits program.

[00321] 5i. The system of emb odiment 5 o , further comprising :

means for receiving from a merchant a survey of current point-of-sales (PoS) infrastructure and settings configurations;

means for determining a new PoS configuration for the user based on mutual benefit program specifications; and

means for sending the new PoS configuration and the training materials to the merchant for implementation.

[ o o 322 ] 52. The system of embodiment 51, further comprising:

means for generating training materials for the new PoS configuration.

[00323] 53. A system for mutual benefits, comprising:

means for receiving a request for a user's value point balance and a merchant's current value point schedule from a merchant; means for receiving a value point transaction confirmation indicating a transaction has been successfully processed and value point transaction data;

means for debiting from a user's account an amount of value points received from another merchant in a previous transaction for use in the transaction;

means for crediting to the user's account an amount of value points based on the value point transaction data; and

means for generating via a processor a value point transaction record and storing the value point transaction data in the value point transaction record.

[00324] 54. The system of embodiment 53, further comprising:

means for updating via the processor the merchant's current value point schedule in the database using the value point record.

[00325] 55. A system for mutual benefits, comprising:

means for receiving a product bulk amount from a partner;

means for receiving a request for a merchant's transaction value modifier (TVM) balance and a partner's current TVM schedule from a partner;

means for sending the merchant's TVM balance and the partner's current TVM schedule to the partner;

means for receiving a TVM transaction confirmation indicating a transaction involving purchasing at least one product bulk amount has been successfully processed and TVM transaction data;

means for debiting from the merchant's account an amount of TVMs used in the transaction;

means for crediting to the merchant's account an amount of TVM based on the TVM transaction data;

means for generating via a processor a TVM transaction record and storing the TVM transaction data in the TVM transaction record; and means for updating via the processor the merchant's current TVM schedule in the database using the TVM transaction record.

[ 00326 ] 56. A system for mutual benefits, comprising:

means for receiving aggregated entity data in a mutual benefits program within a defined geo-demographical region;

means for performing performance analytics on the entity data;

means for determining demarcation indicia to divide a region if the region is overpopulated;

means for splitting the region based on the geo-demographical demarcation indicia into sub-regions;

means for receiving updated demographic and industry data on each sub-region; and means for generating new merchant categories for each sub-region based on the updated demographic and industry data.

[ 00327] 57. The system of embodiment 56, wherein the entity is at least one of a merchant or demographic data.

[ 00328 ] 58. A system for mutual benefits, comprising:

means for receiving aggregated entity data in a mutual benefits program within a defined geo-demographical region;

means for performing performance analytics on the entity data;

means for determining enrollment criteria for enrolling at least one merchant in the mutual benefits program if at least one merchant in the region is over-capacity;

means for sending a mutual benefit enrollment form to a merchant not enrolled in the mutual benefits program;

means for receiving from the merchant not enrolled in the mutual benefits program a completed mutual benefit enrollment form;

means for enrolling the merchant in the mutual benefits program; and

means for updating the region record in a database to include the enrolled merchant. [ 00329 ] 59. The system of embodiment 58, wherein the entity is at least one of a merchant or demographic data. [ 00330 ] 60. The system of embodiment 58, wherein the enrollment criteria may include the category that the at least one merchant in the region which is over-capacity. [ 00331] 61. A mutual benefits non-transitory computer-readable medium storing processor-executable instructions, said instructions executable by a processor to: receive a request for a user's transaction value modifier (TVM) balance and a merchant's current TVM schedule from a merchant; receive a TVM transaction confirmation indicating a transaction has been successfully processed, and TVM transaction data; debit from a user's account an amount of TVMs received from another merchant in a previous transaction for use in the transaction; credit to the user's account an amount of TVMs based on the TVM transaction data; and generate via a processor a TVM transaction record and storing the TVM transaction data in the TVM transaction record. [ 00332 ] 62. The medium of embodiment 61, further comprising instructions to: update via the processor the merchant's current TVM schedule in the database using the TVM record. [ 00333 ] 63. The medium of embodiment 61, wherein a TVM is an eco, a value identifier, or a subsequent value transaction modifier. [ 00334] 64. The medium of embodiment 61, wherein the user's TVM balance is updated after receiving the TVM transaction confirmation. [ 00335 ] 65. The medium of embodiment 61, wherein the user's TVM balance is updated before receiving the TVM transaction confirmation. [ 00336 ] 66. The medium of embodiment 61, wherein the TVM transaction comprises paying at least a portion of the transaction amount in TVMs and at least a portion of the transaction amount with a payment device. [00337] 67. The medium of embodiment 66, wherein the payment device is one of a credit card, debit card, or prepaid card.

[00338] 68. The medium of embodiment 61, wherein the TVM transaction comprises paying at least a portion of the transaction amount in TVMs and at least a portion of the transaction amount with cash.

[00339] 69. The medium of embodiment 61, wherein the TVM transaction comprises paying at least a portion of the transaction amount in TVMs, at least a portion of the transaction amount with cash, and at least a portion of the transaction amount with a payment device.

[00340] 70. The medium of embodiment 69, wherein the payment device is one of a credit card, debit card, or prepaid card.

[00341] 71. The medium of embodiment 61, wherein the credited transaction value modifiers can only be used in subsequent transactions.

[ o o 342 ] 72. The medium of embodiment 71, wherein the credited transaction value modifiers is marked as originating from the merchant; and

wherein the transaction value modifiers cannot be used in subsequent transactions at the merchant from which they originated.

[00343] 73· The medium of embodiment 61, further comprising instructions to: send the user's TVM balance and the merchant's current TVM schedule to the merchant.

[00344] 74· A mutual benefits non -transitory computer-readable medium storing processor-executable instructions, said instructions executable by a processor to:

send to the user the user's TVM balance and an indication that at least some TVMs in the user's TVMs balance will expire;

receive a request to donate expiring TVMs to a designated friend;

allocate via a processor the user's expiring TVMs to be donated to the designated friend; send a TVM donation message to the designated friend;

receive from the designated friend an enrollment request; generate via a processor a new user account for the designated friend;

transfer the allocated expiring TVMs to the designated friend's new user account; and send a confirmation of the transfer to the user and to the designated friend.

[00345] 75· The medium of embodiment 74, further comprising instructions to: monitor the spending of the user's donated TVMs by the designated friend; and allocate via a processor an invite bonus block to the user's account when a predetermined number of the user's donated TVMs have been spent.

[ o o 346 ] 76. The medium of embodiment 74, further comprising instructions to: receive a request from a user for user transaction value modifier (TVM) balance information.

[00347] 77· The medium of embodiment 75, wherein the mutual benefit enrollment request further comprises an amount of TVM gifted by an economic promoter.

[00348] 78. The medium of embodiment 77, wherein the economic promoter obtains a percentage of the amount of TVMs donated to the friend.

[00349] 79· The medium of embodiment 78, wherein a merchant manager gifts TVMs to the economic promoter and obtains a percentage of the amount of TVMs gifted to the friend.

[00350] 80. A mutual benefits non-transitory computer-readable medium storing processor-executable instructions, said instructions executable by a processor to:

receive an indication of preliminary interest in a mutual benefit program;

provide to the merchant a mutual benefit enrollment request form;

receive a mutual benefit enrollment request from a merchant for the mutual benefit program;

send a mutual benefit enrollment form to the merchant;

receive from the merchant a completed mutual benefit enrollment form;

send a request to a merchant agent requesting background material on the merchant; 1 receive background material on the merchant from the merchant agent;

2 analyze the background material from the merchant agent;

3 enroll the merchant in the mutual benefit program if the background material meets

4 predetermined criteria;

5 generate a merchant account for the merchant; and

6 send the merchant a confirmation of enrollment in the mutual benefits program.

I [ 00351] 81. The medium of embodiment 80, further comprising instructions to:

8 receive from a merchant a survey of current point-of-sales (PoS) infrastructure and

9 settings configurations;

10 determine a new PoS configuration for the user based on mutual benefit program

I I specifications; and

12 send the new PoS configuration and the training materials to the merchant for

13 implementation.

14 [ 00352 ] 82. The medium of embodiment 81, further comprising instructions to:

15 generate training materials for the new PoS configuration.

16 [ 00353 ] 83. A non-transitory computer-readable medium storing processor-

17 executable instructions, said instructions executable by a processor to: is receive a request for a user's value point balance and a merchant's current value point

19 schedule from a merchant;

20 receive a value point transaction confirmation indicating a transaction has been

21 successfully processed and value point transaction data;

22 debit from a user's account an amount of value points received from another merchant

23 in a previous transaction for use in the transaction;

24 credit to the user's account an amount of value points based on the value point

25 transaction data; and

26 generate via a processor a value point transaction record and storing the value point

27 transaction data in the value point transaction record. [00354] 84. The medium of embodiment 83, further comprising instructions to: update via the processor the merchant's current value point schedule in the database using the value point record.

[00355] 85. A mutual benefits non-transitory computer-readable medium storing processor-executable instructions, said instructions executable by a processor to:

receive a product bulk amount from a partner;

receive a request for a merchant's transaction value modifier (TVM) balance and a partner's current TVM schedule from a partner;

send the merchant's TVM balance and the partner's current TVM schedule to the partner;

receive a TVM transaction confirmation indicating a transaction involving purchasing at least one product bulk amount has been successfully processed and TVM transaction data;

debit from the merchant's account an amount of TVMs used in the transaction;

credit to the merchant's account an amount of TVM based on the TVM transaction data; generate via a processor a TVM transaction record and storing the TVM transaction data in the TVM transaction record; and

update via the processor the merchant's current TVM schedule in the database using the TVM transaction record.

[00356] 86. A mutual benefits non-transitory computer-readable medium storing processor-executable instructions, said instructions executable by a processor to:

receive aggregated entity data in a mutual benefits program within a defined geo- demographical region;

perform performance analytics on the entity data;

determine demarcation indicia to divide a region if the region is overpopulated;

split the region based on the geo-demographical demarcation indicia into sub-regions; receive updated demographic and industry data on each sub-region; and generate new merchant categories for each sub-region based on the updated demographic and industry data.

[00357] 87. The medium of embodiment 86, wherein the entity is at least one of a merchant or demographic data.

[00358] 88. A mutual benefits non-transitory computer-readable medium storing processor-executable instructions, said instructions executable by a processor to:

receive aggregated entity data in a mutual benefits program within a defined geo- demographical region;

perform performance analytics on the entity data;

determine enrollment criteria for enrolling at least one merchant in the mutual benefits program if at least one merchant in the region is over-capacity;

send a mutual benefit enrollment form to a merchant not enrolled in the mutual benefits program;

receive from the merchant not enrolled in the mutual benefits program a completed mutual benefit enrollment form;

enroll the merchant in the mutual benefits program; and

update the region record in a database to include the enrolled merchant.

[00359] 89. The medium of embodiment 88, wherein the entity is at least one of a merchant or demographic data.

[00360] 90. The medium of embodiment 88, wherein the enrollment criteria may include the category that the at least one merchant in the region which is over-capacity.

[ o o 361 ] 91. An apparatus for mutual benefits, comprising:

a processor; and

a memory disposed in communication with the processor and storing processor- executable instructions to:

receive a request for a user's transaction value modifier (TVM) balance and a merchant's current TVM schedule from a merchant; receive a TVM transaction confirmation indicating a transaction has been successfully processed, and TVM transaction data;

debit from a user's account an amount of TVMs received from another merchant in a previous transaction for use in the transaction;

credit to the user's account an amount of TVMs based on the TVM transaction data; and

generate via a processor a TVM transaction record and storing the TVM transaction data in the TVM transaction record.

[ o o 362 ] 92. The apparatus of embodiment 91, further comprising instructions to:

update via the processor the merchant's current TVM schedule in the database using the TVM record.

[00363] 93. The apparatus of embodiment 91, wherein a TVM is an eco, a value identifier, or a subsequent value transaction modifier.

[00364] 94. The apparatus of embodiment 91, wherein the user's TVM balance is updated after receiving the TVM transaction confirmation.

[00365] 95. The apparatus of embodiment 91, wherein the user's TVM balance is updated before receiving the TVM transaction confirmation.

[00366] 96. The apparatus of embodiment 91, wherein the TVM transaction comprises paying at least a portion of the transaction amount in TVMs and at least a portion of the transaction amount with a payment device.

[00367] 97. The apparatus of embodiment 96, wherein the payment device is one of a credit card, debit card, or prepaid card.

[00368] 98. The apparatus of embodiment 91, wherein the TVM transaction comprises paying at least a portion of the transaction amount in TVMs and at least a portion of the transaction amount with cash.

[00369] 99. The apparatus of embodiment 91, wherein the TVM transaction comprises paying at least a portion of the transaction amount in TVMs, at least a portion of the transaction amount with cash, and at least a portion of the transaction amount with a payment device. [ 00370 ] 100. The apparatus of embodiment 99, wherein the payment device is one of a credit card, debit card, or prepaid card. [ 00371 ] 101. The apparatus of embodiment 91, wherein the credited transaction value modifiers can only be used in subsequent transactions. [ 00372 ] 102. The apparatus of embodiment 101, wherein the credited transaction value modifiers is marked as originating from the merchant; and wherein the transaction value modifiers cannot be used in subsequent transactions at the merchant from which they originated. [ 00373 ] !03· The apparatus of embodiment 91, further comprising instructions to: send the user's TVM balance and the merchant's current TVM schedule to the merchant. [ 00374 ] 104. An apparatus for mutual benefits, comprising: a processor; and a memory disposed in communication with the processor and storing processor- executable instructions to: send to the user the user's TVM balance and an indication that at least some TVMs in the user's TVMs balance will expire; receive a request to donate expiring TVMs to a designated friend; allocating via a processor the user's expiring TVMs to be donated to the designated friend; send a TVM donation message to the designated friend; receive from the designated friend an enrollment request; generate via a processor a new user account for the designated friend; transfer the allocated expiring TVMs to the designated friend's new user account; and send a confirmation of the transfer to the user and to the designated friend. [00375] 105. The apparatus of embodiment 104, further comprising instructions to: monitor the spending of the user's donated TVMs by the designated friend; and allocate via a processor an invite bonus block to the user's account when a predetermined number of the user's donated TVMs have been spent. [00376 ] 106. The apparatus of embodiment 104, further comprising instructions to:

receive a request from a user for user transaction value modifier (TVM) balance information; [00377] 107. The apparatus of embodiment 105, wherein the mutual benefit enrollment request further comprises an amount of TVM gifted by an economic promoter. [00378 ] 108. The apparatus of embodiment 107, wherein the economic promoter obtains a percentage of the amount of TVMs donated to the friend. [00379 ] 109. The apparatus of embodiment 108, wherein a merchant manager gifts TVMs to the economic promoter and obtains a percentage of the amount of TVMs gifted to the friend. [00380 ] 110. An apparatus for mutual benefits, comprising:

a processor; and a memory disposed in communication with the processor and storing processor- executable instructions to:

receive an indication of preliminary interest in a mutual benefit program; provide to the merchant a mutual benefit enrollment request form; receive a mutual benefit enrollment request from a merchant for the mutual benefit program; send a mutual benefit enrollment form to the merchant; receive from the merchant a completed mutual benefit enrollment form; send a request to a merchant agent requesting background material on the merchant; receive background material on the merchant from the merchant agent; analyze the background material from the merchant agent; enroll the merchant in the mutual benefit program if the background material meets predetermined criteria; generate a merchant account for the merchant; and send the merchant a confirmation of enrollment in the mutual benefits program. [ 00381 ] 111. The apparatus of embodiment 110, further comprising instructions to: receive from a merchant a survey of current point-of-sales (PoS) infrastructure and settings configurations; determine a new PoS configuration for the user based on mutual benefit program specifications; and send the new PoS configuration and the training materials to the merchant for implementation. [ 00382 ] 112. The apparatus of embodiment 111, further comprising instructions to: generate training materials for the new PoS configuration. [ 00383 ] 113. An apparatus for mutual benefits, comprising: a processor; and a memory disposed in communication with the processor and storing processor- executable instructions to: receive a request for a user's value point balance and a merchant's current value point schedule from a merchant; receive a value point transaction confirmation indicating a transaction has been successfully processed and value point transaction data; debit from a user's account an amount of value points received from another merchant in a previous transaction for use in the transaction; credit to the user's account an amount of value points based on the value point transaction data; and generate via a processor a value point transaction record and storing the value point transaction data in the value point transaction record. [00384] 114. The apparatus of embodiment 113, further comprising instructions to: update via the processor the merchant's current value point schedule in the database using the value point record. [00385] 115. An apparatus for mutual benefits, comprising: a processor; and a memory disposed in communication with the processor and storing processor- executable instructions to: receive a product bulk amount from a partner; receive a request for a merchant's transaction value modifier (TVM) balance and a partner's current TVM schedule from a partner; send the merchant's TVM balance and the partner's current TVM schedule to the partner; receive a TVM transaction confirmation indicating a transaction involving purchasing at least one product bulk amount has been successfully processed and TVM transaction data; debit from the merchant's account an amount of TVMs used in the transaction; credit to the merchant's account an amount of TVM based on the TVM transaction data; generate via a processor a TVM transaction record and storing the TVM transaction data in the TVM transaction record; and update via the processor the merchant's current TVM schedule in the database using the TVM transaction record. [00386 ] 116. An apparatus for mutual benefits, comprising:

a processor; and a memory disposed in communication with the processor and storing processor- executable instructions to: receive aggregated entity data in a mutual benefits program within a defined geo-demographical region; perform performance analytics on the entity data; determine demarcation indicia to divide a region if the region is overpopulated; split the region based on the geo-demographical demarcation indicia into sub-regions; receive updated demographic and industry data on each sub-region; and generate new merchant categories for each sub-region based on the updated demographic and industry data. [00387] 117. The apparatus of embodiment 116, wherein the entity is at least one of a merchant or demographic data. [00388 ] 118. An apparatus for mutual benefits, comprising: a processor; and a memory disposed in communication with the processor and storing processor- executable instructions to: receive aggregated entity data in a mutual benefits program within a defined geo-demographical region; perform performance analytics on the entity data; determine enrollment criteria for enrolling at least one merchant in the mutual benefits program if at least one merchant in the region is over-capacity; send a mutual benefit enrollment form to a merchant not enrolled in the mutual benefits program; receive from the merchant not enrolled in the mutual benefits program a completed mutual benefit enrollment form; enroll the merchant in the mutual benefits program; and update the region record in a database to include the enrolled merchant. [00389 ] 119. The apparatus of embodiment 118, wherein the entity is at least one of a merchant or demographic data. [00390 ] 120. The apparatus of embodiment 118, wherein the enrollment criteria may include the category that the at least one merchant in the region which is over- capacity.

Claims

CLAI MS

What is claimed is:

l. A processor-implemented method for mutual benefits, comprising:

receiving a request for a user's eco balance and a account holder's current eco schedule from a account holder;

receiving a eco allocation confirmation indicating an eco allocation has been successfully processed, and eco data;

extracting from a user's account an amount of ecos received from another account holder in a previous eco exchange for use in the allocation;

wherein the user's account may store ecos from a disparate assortment of account holders, and wherein the user therefore does not need to maintain disparate benefits accounts;

adding to the user's account an amount of ecos based on the eco data; and generating via a processor a eco record and storing the eco data in the eco record. 2. The method of claim l, further comprising:

updating via the processor the account holder's current eco schedule in the database using the eco record.

3. The method of claim 1, wherein the user's eco balance is updated after receiving the eco allocation confirmation.

4. The method of claim 1, wherein the user's eco balance is updated before receiving the eco allocation confirmation.

5. The method of claim 1, wherein the added ecos can only be used in subsequent exchanges.

6. The method of claim 5, wherein the added ecos is marked as originating from the account holder; and

wherein the ecos cannot be used in subsequent exchanges at the account holder from which they originated.

7. The method of claim 1, further comprising:

sending the user's ecos balance and the account holder's current ecos schedule to the account holder.

8. A processor-implemented method for mutual benefits, comprising:

sending to the user the user's eco balance and an indication that at least some ecos in the user's ecos balance will expire;

receiving a request to donate expiring ecos to a designated friend;

allocating via a processor the user's expiring ecos to be donated to the designated friend;

sending a eco donation message to the designated friend;

receiving from the designated friend an enrollment request;

generating via a processor a new user account for the designated friend;

transferring the allocated expiring ecos to the designated friend's new user account; and

sending a confirmation of the transfer to the user and to the designated friend. 9. The method of claim 8, further comprising:

monitoring the spending of the user's donated ecos by the designated friend; and allocating via a processor an invite bonus block to the user's account when a predetermined number of the user's donated ecoss have been spent.

10. The method of claim 8, further comprising: receiving a request from a user for user eco balance information;

11. The method of claim 9, wherein the mutual benefit enrollment request further comprises an amount of eco gifted by a promoter.

12. The method of claim 11, wherein the promoter obtains a percentage of the amount of ecos donated to the friend.

13. The method of claim 12, wherein a account holder manager gifts ecos to the promoter and obtains a percentage of the amount of ecos gifted to the friend.

14. A processor-implemented method for mutual benefits, comprising:

receiving an indication of preliminary interest in a mutual benefit program;

providing to the account holder a mutual benefit enrollment request form;

receiving a mutual benefit enrollment request from a account holder for the mutual benefit program;

sending a mutual benefit enrollment form to the account holder;

receiving from the account holder a completed mutual benefit enrollment form; sending a request to a account holder agent requesting background material on the account holder;

receiving background material on the account holder from the account holder agent;

analyzing the background material from the account holder agent;

enrolling the account holder in the mutual benefit program if the background material meets predetermined criteria;

generating a account holder account for the account holder; and

sending the account holder a confirmation of enrollment in the mutual benefits program.

15. The method of claim 14, further comprising:

receiving from a account holder a survey of current infrastructure and settings configurations;

determining a new configuration for the account holder based on mutual benefit program specifications; and

sending the new configuration and the training materials to the account holder for implementation.

16. The method of claim 15, further comprising:

generating training materials for the new configuration.

17. A processor-implemented method for mutual benefits, comprising:

receiving a request for a user's value point balance and a account holder's current value point schedule from a account holder;

receiving a value point allocation confirmation indicating an ecohas been successfully processed and value point data;

extracting from a user's account an amount of value points received from another account holder in a previous exchange for use in the allocation;

adding to the user's account an amount of value points based on the value point data; and

generating via a processor a value point record and storing the value point data in the value point record.

18. The method of claim 17, further comprising:

updating via the processor the account holder's current value point schedule in the database using the value point record.

19. A processor-implemented method for mutual benefits, comprising: receiving a product bulk amount from a partner;

receiving a request for a account holder's eco balance and a partner's current eco schedule from a partner;

sending the account holder's eco balance and the partner's current eco schedule to the partner;

receiving a eco transaction confirmation indicating a transaction involving purchasing at least one product bulk amount has been successfully processed and eco transaction data;

extracting from the account holder's account an amount of ecos used in the transaction;

adding to the account holder's account an amount of eco based on the eco data; generating via a processor an eco record and storing the eco data in the eco record; and

updating via the processor the account holder's current eco schedule in the database using the eco record.

20. A processor-implemented method for mutual benefits, comprising:

receiving aggregated entity data in a mutual benefits program within a defined geo-demographical region;

performing performance analytics on the entity data;

determining demarcation indicia to divide a region if the region is overpopulated; splitting the region based on the geo-demographical demarcation indicia into sub-regions;

receiving updated demographic and industry data on each sub-region; and generating new account holder categories for each sub-region based on the updated demographic and industry data.

21. The method of claim 20, wherein the entity is at least one of a account holder or demographic data.

22. A processor-implemented method for mutual benefits, comprising:

receiving aggregated entity data in a mutual benefits program within a defined geo-demographical region;

performing performance analytics on the entity data;

determining enrollment criteria for enrolling at least one account holder in the mutual benefits program if at least one account holder in the region is over-capacity; sending a mutual benefit enrollment form to a account holder not enrolled in the mutual benefits program;

receiving from the account holder not enrolled in the mutual benefits program a completed mutual benefit enrollment form;

enrolling the account holder in the mutual benefits program; and

updating the region record in a database to include the enrolled account holder. 23. The method of claim 22, wherein the entity is at least one of a account holder or demographic data.

24. The method of claim 22, wherein the enrollment criteria may include the category that the at least one account holder in the region which is over-capacity.

25. The method of claim 1, wherein the ecos may be used in an exchange with a health care provider and a patient, and

wherein the exchange reduces the cost of health care for the patient.

26. The method of claim 1, wherein the ecos may be used in an exchange with a health insurance provider and a health care provider.

27. A system for mutual benefits, comprising:

means for receiving a request for a user's eco balance and a account holder's current eco schedule from a account holder;

means for receiving a eco allocation confirmation indicating an eco allocation has been successfully processed, and eco data;

means for extracting from a user's account an amount of ecos received from another account holder in a previous eco exchange for use in the allocation;

wherein the user's account may store ecos from a disparate assortment of account holders, and wherein the user therefore does not need to maintain disparate benefits accounts;

means for adding to the user's account an amount of ecos based on the eco data; and

means for generating via a processor a eco record and storing the eco data in the eco record.

28. The system of claim 27, further comprising:

means for updating via the processor the account holder's current eco schedule in the database using the eco record.

29. The system of claim 27, wherein the user's eco balance is updated after receiving the eco allocation confirmation.

30. The system of claim 27, wherein the user's eco balance is updated before receiving the eco allocation confirmation.

31. The system of claim 27, wherein the added ecos can only be used in subsequent exchanges.

32. The system of claim 31, wherein the added ecos are marked as originating from the account holder; and

wherein the ecos cannot be used in subsequent exchanges at the account holder from which they originated.

33. The system of claim 27, further comprising:

means for sending the user's eco balance and the account holder's current eco schedule to the account holder.

34. A system for mutual benefits, comprising:

means for sending to the user the user's eco balance and an indication that at least some ecos in the user's ecos balance will expire;

means for receiving a request to donate expiring ecos to a designated friend; means for allocating via a processor the user's expiring ecos to be donated to the designated friend;

means for sending a eco donation message to the designated friend;

means for receiving from the designated friend an enrollment request;

means for generating via a processor a new user account for the designated friend;

means for transferring the allocated expiring ecos to the designated friend's new user account; and

means for sending a confirmation of the transfer to the user and to the designated friend.

35. The system of claim 34, further comprising: means for monitoring the spending of the user's donated ecos by the designated friend; and

means for allocating via a processor an invite bonus block to the user's account when a predetermined number of the user's donated ecos have been spent.

36. The system of claim 34, further comprising:

means for receiving a request from a user for user ecoeco balance information; 37. The system of claim 35, wherein the mutual benefit enrollment request further comprises an amount of eco gifted by a promoter.

38. The system of claim 37, wherein the promoter obtains a percentage of the amount of ecos donated to the friend.

39. The system of claim 38, wherein a account holder manager gifts ecos to the promoter and obtains a percentage of the amount of ecos gifted to the friend.

40. A system for mutual benefits, comprising:

means for receiving an indication of preliminary interest in a mutual benefit program;

means for providing to the account holder a mutual benefit enrollment request form;

means for receiving a mutual benefit enrollment request from a account holder for the mutual benefit program;

means for sending a mutual benefit enrollment form to the account holder;

means for receiving from the account holder a completed mutual benefit enrollment form;

means for sending a request to a account holder agent requesting background material on the account holder; means for receiving background material on the account holder from the account holder agent;

means for analyzing the background material from the account holder agent; means for enrolling the account holder in the mutual benefit program if the background material meets predetermined criteria;

means for generating a account holder account for the account holder; and means for sending the account holder a confirmation of enrollment in the mutual benefits program.

41. The system of claim 40, further comprising:

means for receiving from a account holder a survey of current infrastructure and settings configurations;

means for determining a new configuration for the account holder based on mutual benefit program specifications; and

means for sending the new configuration and the training materials to the account holder for implementation.

42. The system of claim 41, further comprising:

means for generating training materials for the new configuration.

43. A system for mutual benefits, comprising:

means for receiving a value point allocation confirmation indicating an ecohas been successfully processed and value point data;

means for extracting from a user's account an amount of value points received from another account holder in a previous exchange for use in the allocation;

means for adding to the user's account an amount of value points based on the value point data; and means for generating via a processor a value point record and storing the value point data in the value point record.

account holderaccount holderaccount holder

44. The system of claim 43, further comprising:

means for updating via the processor the account holder's current value point schedule in the database using the value point record.

45. A system for mutual benefits, comprising:

means for receiving a product bulk amount from a partner;

means for receiving a request for a account holder's eco balance and a partner's current eco schedule from a partner;

means for sending the account holder's eco balance and the partner's current eco schedule to the partner;

means for receiving a eco transaction confirmation indicating a transaction involving purchasing at least one product bulk amount has been successfully processed and eco transaction data;

means for extracting from the account holder's account an amount of ecos used in the transaction;

means for adding to the account holder's account an amount of eco based on the eco data;

means for generating via a processor an eco record and storing the eco data in the eco record; and

means for updating via the processor the account holder's current eco schedule in the database using the eco record. account holderaccount holderaccount holderaccount holderaccount holder56. A system for mutual benefits, comprising:

means for receiving aggregated entity data in a mutual benefits program within a defined geo-demographical region;

means for performing performance analytics on the entity data;

means for determining demarcation indicia to divide a region if the region is overpopulated;

means for splitting the region based on the geo-demographical demarcation indicia into sub-regions;

means for receiving updated demographic and industry data on each sub-region; and

means for generating new account holder categories for each sub-region based on the updated demographic and industry data.

46. The system of claim 45, wherein the entity is at least one of a account holder or demographic data.

47. A system for mutual benefits, comprising:

means for receiving aggregated entity data in a mutual benefits program within a defined geo-demographical region;

means for performing performance analytics on the entity data;

means for determining enrollment criteria for enrolling at least one account holder in the mutual benefits program if at least one account holder in the region is over-capacity;

means for sending a mutual benefit enrollment form to a account holder not enrolled in the mutual benefits program; means for receiving from the account holder not enrolled in the mutual benefits program a completed mutual benefit enrollment form;

means for enrolling the account holder in the mutual benefits program; and means for updating the region record in a database to include the enrolled account holder.

48. The system of claim 47, wherein the entity is at least one of a account holder or demographic data.

49. The system of claim 47, wherein the enrollment criteria may include the category that the at least one account holder in the region which is over-capacity.

50. The system of claim 27, wherein the ecos may be used in an exchange with a health care provider and a patient, and

wherein the exchange reduces the cost of health care for the patient.

51. The system of claim 27, wherein the ecos may be used in an exchange with a health insurance provider and a health care provider.

52. A mutual benefits non-transitory computer-readable medium storing processor-executable instructions, said instructions executable by a processor to:

receive a request for a user's eco balance and a account holder's current eco schedule from a account holder;

receive a eco allocation confirmation indicating an eco allocationhas been successfully processed, and eco data;

extract from a user's account an amount of ecos received from another account holder in a previous eco exchange for use in the allocation; wherein the user's account may store ecos from a disparate assortment of account holders, and wherein the user therefore does not need to maintain disparate benefits accounts;

add to the user's account an amount of ecos based on the eco data; and

generate via a processor a eco record and storing the eco data in the eco record. ecoaccount holderecoaccount holderecoecoecoaccount holderecoecoecoecoeco62. The medium of claim 52, further comprising instructions to:

update via the processor the account holder's current eco schedule in the database using the eco record.

53. The medium of claim 52, wherein the user's eco balance is updated after receiving the eco allocation confirmation.

54. The medium of claim 52, wherein the user's eco balance is updated before receiving the eco allocation confirmation.

55. The medium of claim 52, wherein the added ecos can only be used in subsequent exchanges.

56. The medium of claim 55, wherein the added ecos are marked as originating from the account holder; and

wherein the ecos cannot be used in subsequent exchanges at the account holder from which they originated.

57. The medium of claim 52, further comprising instructions to:

send the user's eco balance and the account holder's current eco schedule to the account holder.

58. A mutual benefits non-transitory computer-readable medium storing processor-executable instructions, said instructions executable by a processor to: send to the user the user's eco balance and an indication that at least some ecos in the user's ecos balance will expire;

receive a request to donate expiring ecos to a designated friend;

allocate via a processor the user's expiring ecos to be donated to the designated friend;

send a eco donation message to the designated friend;

receive from the designated friend an enrollment request;

generate via a processor a new user account for the designated friend;

transfer the allocated expiring ecos to the designated friend's new user account; and

send a confirmation of the transfer to the user and to the designated friend.

59. The medium of claim 58, further comprising instructions to:

monitor the spending of the user's donated ecos by the designated friend; and allocate via a processor an invite bonus block to the user's account when a predetermined number of the user's donated ecos have been spent.

60. The medium of claim 58, further comprising instructions to:

receive a request from a user for user ecoeco balance information.

61. The medium of claim 59, wherein the mutual benefit enrollment request further comprises an amount of eco gifted by a promoter.

62. The medium of claim 61, wherein the promoter obtains a percentage of the amount of ecos donated to the friend.

63. The medium of claim 62, wherein a account holder manager gifts ecos to the promoter and obtains a percentage of the amount of ecos gifted to the friend.

64. A mutual benefits non-transitory computer-readable medium storing processor-executable instructions, said instructions executable by a processor to:

receive an indication of preliminary interest in a mutual benefit program;

provide to the account holder a mutual benefit enrollment request form;

receive a mutual benefit enrollment request from a account holder for the mutual benefit program;

send a mutual benefit enrollment form to the account holder;

receive from the account holder a completed mutual benefit enrollment form; send a request to a account holder agent requesting background material on the account holder;

receive background material on the account holder from the account holder agent;

analyze the background material from the account holder agent;

enroll the account holder in the mutual benefit program if the background material meets predetermined criteria;

generate a account holder account for the account holder; and

send the account holder a confirmation of enrollment in the mutual benefits program.

65. The medium of claim 64, further comprising instructions to:

receive from a account holder a survey of current infrastructure and settings configurations;

determine a new configuration for the account holder based on mutual benefit program specifications; and send the new configuration and the training materials to the account holder for implementation.

66. The medium of claim 65, further comprising instructions to:

generate training materials for the new configuration.

67. A processor-implemented non-transitory computer-readable medium storing processor-executable instructions, said instructions executable by a processor to::

receive a value point allocation confirmation indicating an ecohas been successfully processed and value point data;

extract from a user's account an amount of value points received from another account holder in a previous exchange for use in the allocation;

add to the user's account an amount of value points based on the value point data; and

generate via a processor a value point record and storing the value point data in the value point record.

account holderaccount holderaccount holder84. The medium of claim 67, further comprising instructions to:

update via the processor the account holder's current value point schedule in the database using the value point record.

68. A mutual benefits non-transitory computer-readable medium storing processor-executable instructions, said instructions executable by a processor to:

receive a product bulk amount from a partner;

receive a request for a account holder's eco balance and a partner's current eco schedule from a partner; send the account holder's eco balance and the partner's current eco schedule to the partner;

receive a eco transaction confirmation indicating a transaction involving purchasing at least one product bulk amount has been successfully processed and eco transaction data;

extract from the account holder's account an amount of ecos used in the transaction;

add to the account holder's account an amount of eco based on the eco data; generate via a processor an eco record and storing the eco data in the eco record; and

update via the processor the account holder's current eco schedule in the database using the eco record.account holderaccount holderaccount holderaccount holderaccount holder86. A mutual benefits non-transitory computer-readable medium storing processor-executable instructions, said instructions executable by a processor to:

receive aggregated entity data in a mutual benefits program within a defined geo- demographical region;

perform performance analytics on the entity data;

determine demarcation indicia to divide a region if the region is overpopulated; split the region based on the geo-demographical demarcation indicia into sub- regions;

receive updated demographic and industry data on each sub-region; and generate new account holder categories for each sub-region based on the updated demographic and industry data.

69. The medium of claim 68, wherein the entity is at least one of a account holder or demographic data.

70. A mutual benefits non-transitory computer-readable medium storing processor-executable instructions, said instructions executable by a processor to:

receive aggregated entity data in a mutual benefits program within a defined geo- demographical region;

perform performance analytics on the entity data;

determine enrollment criteria for enrolling at least one account holder in the mutual benefits program if at least one account holder in the region is over-capacity; send a mutual benefit enrollment form to a account holder not enrolled in the mutual benefits program;

receive from the account holder not enrolled in the mutual benefits program a completed mutual benefit enrollment form;

enroll the account holder in the mutual benefits program; and

update the region record in a database to include the enrolled account holder. 71. The medium of claim 70, wherein the entity is at least one of a account holder or demographic data.

72. The medium of claim 70, wherein the enrollment criteria may include the category that the at least one account holder in the region which is over-capacity.

73. The medium of claim 52, wherein the ecos may be used in an exchange with a health care provider and a patient, and

wherein the exchange reduces the cost of health care for the patient.

74. The medium of claim 52, wherein the ecos may be used in an exchange with a health insurance provider and a health care provider.

75. An apparatus for mutual benefits, comprising:

a processor; and

a memory disposed in communication with the processor and storing processor- executable instructions to:

receive a request for a user's eco balance and a account holder's current eco schedule from a account holder;

receive a eco allocation confirmation indicating an eco allocationhas been successfully processed, and eco data;

extract from a user's account an amount of ecos received from another account holder in a previous eco exchange for use in the allocation;

wherein the user's account may store ecos from a disparate assortment of account holders, and wherein the user therefore does not need to maintain disparate benefits accounts;

add to the user's account an amount of ecos based on the eco data; and generate via a processor a eco record and storing the eco data in the eco record.

76. The apparatus of claim 75, further comprising instructions to:

update via the processor the account holder's current eco schedule in the database using the eco record.

77. The apparatus of claim 75, wherein the user's eco balance is updated after receiving the eco transaction confirmation.

78. The apparatus of claim 75, wherein the user's eco balance is updated before receiving the eco transaction confirmation.

79. The apparatus of claim 75, wherein the added ecos can only be used in subsequent exchanges.

80. The apparatus of claim 79, wherein the added ecos are marked as originating from the account holder; and

wherein the ecos cannot be used in subsequent exchanges at the account holder from which they originated.

81. The apparatus of claim 75, further comprising instructions to:

send the user's eco balance and the account holder's current eco schedule to the account holder.

82. An apparatus for mutual benefits, comprising:

a processor; and

a memory disposed in communication with the processor and storing processor- executable instructions to:

send to the user the user's eco balance and an indication that at least some ecos in the user's ecos balance will expire;

receive a request to donate expiring ecos to a designated friend;

allocating via a processor the user's expiring ecos to be donated to the designated friend;

send a eco donation message to the designated friend;

receive from the designated friend an enrollment request;

generate via a processor a new user account for the designated friend; transfer the allocated expiring ecos to the designated friend's new user account; and

send a confirmation of the transfer to the user and to the designated friend.

83. The apparatus of claim 82, further comprising instructions to:

monitor the spending of the user's donated ecos by the designated friend; and allocate via a processor an invite bonus block to the user's account when a predetermined number of the user's donated ecos have been spent.

84. The apparatus of claim 82, further comprising instructions to:

receive a request from a user for user ecoeco balance information;

85. The apparatus of claim 83, wherein the mutual benefit enrollment request further comprises an amount of eco gifted by a promoter.

86. The apparatus of claim 85, wherein the promoter obtains a percentage of the amount of ecos donated to the friend.

87. The apparatus of claim 86, wherein a account holder manager gifts ecos to the promoter and obtains a percentage of the amount of ecos gifted to the friend.

88. An apparatus for mutual benefits, comprising:

a processor; and

a memory disposed in communication with the processor and storing processor- executable instructions to:

receive an indication of preliminary interest in a mutual benefit program; provide to the account holder a mutual benefit enrollment request form; receive a mutual benefit enrollment request from a account holder for the mutual benefit program;

send a mutual benefit enrollment form to the account holder; receive from the account holder a completed mutual benefit enrollment form; send a request to a account holder agent requesting background material on the account holder; receive background material on the account holder from the account holder agent;

analyze the background material from the account holder agent;

enroll the account holder in the mutual benefit program if the background material meets predetermined criteria;

generate a account holder account for the account holder; and send the account holder a confirmation of enrollment in the mutual benefits program. 89. The apparatus of claim 88, further comprising instructions to:

receive from a account holder a survey of current infrastructure and settings configurations;

determine a new configuration for the account holder based on mutual benefit program specifications; and

send the new configuration and the training materials to the account holder for implementation.

90. The apparatus of claim 89, further comprising instructions to:

generate training materials for the new configuration. 91. An apparatus for mutual benefits, comprising:

a processor; and

a memory disposed in communication with the processor and storing processor- executable instructions to:receive a request for a user's value point balance and a account holder's current value point schedule from a account holder;

receive a value point allocation confirmation indicating an ecohas been successfully processed and value point data; extract from a user's account an amount of value points received from another account holder in a previous exchange for use in the allocation;

add to the user's account an amount of value points based on the value point data; and

generate via a processor a value point record and storing the value point data in the value point record.

account holderaccount holderaccount holderii4. The apparatus of claim 91, further comprising instructions to: update via the processor the account holder's current value point schedule in the database using the value point record.

92. An apparatus for mutual benefits, comprising:

a processor; and

a memory disposed in communication with the processor and storing processor- executable instructions to:

receive a product bulk amount from a partner;

receive a request for a account holder's eco balance and a partner's current eco schedule from a partner;

send the account holder's eco balance and the partner's current eco schedule to the partner;

receive a eco transaction confirmation indicating a transaction involving purchasing at least one product bulk amount has been successfully processed and eco transaction data;

extract from the account holder's account an amount of ecos used in the transaction; add to the account holder's account an amount of eco based on the eco data;

generate via a processor an eco record and storing the eco data in the eco record; and

update via the processor the account holder's current eco schedule in the database using the eco record.

93. An apparatus for mutual benefits, comprising:

a processor; and

a memory disposed in communication with the processor and storing processor- executable instructions to:

receive aggregated entity data in a mutual benefits program within a defined geo-demographical region;

perform performance analytics on the entity data;

determine demarcation indicia to divide a region if the region is overpopulated;

split the region based on the geo-demographical demarcation indicia into sub-regions;

receive updated demographic and industry data on each sub-region; and generate new account holder categories for each sub-region based on the updated demographic and industry data.

94. The apparatus of claim 93, wherein the entity is at least one of a account holder or demographic data.

95. An apparatus for mutual benefits, comprising:

a processor; and a memory disposed in communication with the processor and storing processor- executable instructions to:

receive aggregated entity data in a mutual benefits program within a defined geo-demographical region;

perform performance analytics on the entity data;

determine enrollment criteria for enrolling at least one account holder in the mutual benefits program if at least one account holder in the region is over-capacity;

send a mutual benefit enrollment form to a account holder not enrolled in the mutual benefits program;

receive from the account holder not enrolled in the mutual benefits program a completed mutual benefit enrollment form;

enroll the account holder in the mutual benefits program; and update the region record in a database to include the enrolled account holder. 96. The apparatus of claim 95, wherein the entity is at least one of a account holder or demographic data.

97. The apparatus of claim 95, wherein the enrollment criteria may include the category that the at least one account holder in the region which is over-capacity.

98. The apparatus of claim 75, wherein the ecos may be used in an exchange with a health care provider and a patient, and

wherein the exchange reduces the cost of health care for the patient.

99. The apparatus of claim 75, wherein the ecos may be used in an exchange with a health insurance provider and a health care provider. loo. A program which makes a processor execute a prodecure for mutual benefits, comprising:

receiving a request for a user's eco balance and a account holder's current eco schedule from a account holder;

receiving a eco allocation confirmation indicating an eco allocationhas been successfully processed, and eco data;

extracting from a user's account an amount of ecos received from another account holder in a previous eco exchange for use in the allocation;

wherein the user's account may store ecos from a disparate assortment of account holders, and wherein the user therefore does not need to maintain disparate benefits accounts;

adding to the user's account an amount of ecos based on the eco data; and generating via a processor a eco record and storing the eco data in the eco record. loi. The program of claim l, further comprising:

updating via the processor the account holder's current eco schedule in the database using the eco record.

102. The program of claim 100, wherein the user's eco balance is updated after receiving the eco allocation confirmation.

103. The program of claim 100, wherein the user's eco balance is updated before receiving the eco allocation confirmation.

104. The program of claim 100, wherein the added ecos can only be used in subsequent exchanges.

105. The program of claim 104, wherein the added ecos is marked as originating from the account holder; and wherein the ecos cannot be used in subsequent exchanges at the account holder from which they originated.

io6. The program of claim 100, further comprising:

sending the user's ecos balance and the account holder's current ecos schedule to the account holder.

107. A program which makes a processor execute a prodecure for mutual benefits, comprising:

sending to the user the user's eco balance and an indication that at least some ecos in the user's ecos balance will expire;

receiving a request to donate expiring ecos to a designated friend;

allocating via a processor the user's expiring ecos to be donated to the designated friend;

sending a eco donation message to the designated friend;

receiving from the designated friend an enrollment request;

generating via a processor a new user account for the designated friend;

transferring the allocated expiring ecos to the designated friend's new user account; and

sending a confirmation of the transfer to the user and to the designated friend. 108. The program of claim 107, further comprising:

monitoring the spending of the user's donated ecos by the designated friend; and allocating via a processor an invite bonus block to the user's account when a predetermined number of the user's donated ecoss have been spent.

109. The program of claim 107, further comprising:

receiving a request from a user for user eco balance information; no. The program of claim 108, wherein the mutual benefit enrollment request further comprises an amount of eco gifted by a promoter.

in. The program of claim no, wherein the promoter obtains a percentage of the amount of ecos donated to the friend.

112. The program of claim in, wherein a account holder manager gifts ecos to the promoter and obtains a percentage of the amount of ecos gifted to the friend.

113. A program which makes a processor execute a prodecure for mutual benefits, comprising:

receiving an indication of preliminary interest in a mutual benefit program;

providing to the account holder a mutual benefit enrollment request form;

receiving a mutual benefit enrollment request from a account holder for the mutual benefit program;

sending a mutual benefit enrollment form to the account holder;

receiving from the account holder a completed mutual benefit enrollment form; sending a request to a account holder agent requesting background material on the account holder;

receiving background material on the account holder from the account holder agent;

analyzing the background material from the account holder agent;

enrolling the account holder in the mutual benefit program if the background material meets predetermined criteria;

generating a account holder account for the account holder; and

sending the account holder a confirmation of enrollment in the mutual benefits program.

114. The program of claim 113, further comprising:

receiving from a account holder a survey of current infrastructure and settings configurations;

determining a new configuration for the account holder based on mutual benefit program specifications; and

sending the new configuration and the training materials to the account holder for implementation.

115. The program of claim 114, further comprising:

generating training materials for the new configuration.

116. A processor-implemented program for mutual benefits, comprising:

receiving a request for a user's value point balance and a account holder's current value point schedule from a account holder;

receiving a value point allocation confirmation indicating an ecohas been successfully processed and value point data;

extracting from a user's account an amount of value points received from another account holder in a previous exchange for use in the allocation;

adding to the user's account an amount of value points based on the value point data; and

generating via a processor a value point record and storing the value point data in the value point record.

117. The program of claim 116, further comprising:

updating via the processor the account holder's current value point schedule in the database using the value point record. ii8. A program which makes a processor execute a prodecure for mutual benefits, comprising:

receiving a product bulk amount from a partner;

receiving a request for a account holder's eco balance and a partner's current eco schedule from a partner;

sending the account holder's eco balance and the partner's current eco schedule to the partner;

receiving a eco transaction confirmation indicating a transaction involving purchasing at least one product bulk amount has been successfully processed and eco transaction data;

extracting from the account holder's account an amount of ecos used in the transaction;

adding to the account holder's account an amount of eco based on the eco data; generating via a processor an eco record and storing the eco data in the eco record; and

updating via the processor the account holder's current eco schedule in the database using the eco record.

119. A program which makes a processor execute a prodecure for mutual benefits, comprising:

receiving aggregated entity data in a mutual benefits program within a defined geo-demographical region;

performing performance analytics on the entity data;

determining demarcation indicia to divide a region if the region is overpopulated; splitting the region based on the geo-demographical demarcation indicia into sub-regions;

receiving updated demographic and industry data on each sub-region; and generating new account holder categories for each sub-region based on the updated demographic and industry data.

120. The program of claim 119, wherein the entity is at least one of a account holder or demographic data.

121. A processor-implemented program for mutual benefits, comprising:

receiving aggregated entity data in a mutual benefits program within a defined geo-demographical region;

performing performance analytics on the entity data;

determining enrollment criteria for enrolling at least one account holder in the mutual benefits program if at least one account holder in the region is over-capacity; sending a mutual benefit enrollment form to a account holder not enrolled in the mutual benefits program;

receiving from the account holder not enrolled in the mutual benefits program a completed mutual benefit enrollment form;

enrolling the account holder in the mutual benefits program; and

updating the region record in a database to include the enrolled account holder. 122. The program of claim 121, wherein the entity is at least one of a account holder or demographic data.

123. The program of claim 121, wherein the enrollment criteria may include the category that the at least one account holder in the region which is over-capacity.

124. The program of claim 100, wherein the ecos may be used in an exchang with a health care provider and a patient, and

wherein the exchange reduces the cost of health care for the patient.

125. The program of claim 100, wherein the ecos may be used in an exchang with a health insurance provider and a health care provider.