CA2874072A1 - Eco advantage mediation apparatuses, methods and systems - Google Patents
Eco advantage mediation apparatuses, methods and systems Download PDFInfo
- Publication number
- CA2874072A1 CA2874072A1 CA2874072A CA2874072A CA2874072A1 CA 2874072 A1 CA2874072 A1 CA 2874072A1 CA 2874072 A CA2874072 A CA 2874072A CA 2874072 A CA2874072 A CA 2874072A CA 2874072 A1 CA2874072 A1 CA 2874072A1
- Authority
- CA
- Canada
- Prior art keywords
- eco
- user
- account holder
- ecos
- account
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Strategic Management (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Finance (AREA)
- Theoretical Computer Science (AREA)
- Marketing (AREA)
- Accounting & Taxation (AREA)
- General Business, Economics & Management (AREA)
- Game Theory and Decision Science (AREA)
- Entrepreneurship & Innovation (AREA)
- Human Resources & Organizations (AREA)
- Operations Research (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
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 ADVANTAGE MEDIATION APPARATUSES, METHODS
2 AND SYSTEMS
3 [0001] This application for letters patent disclosure document describes inventive
4 aspects that include various novel innovations (hereinafter "disclosure") and contains 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.
[0 0 0 2 ] 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/00U5 1318827-2004 which in turn claims priority to Patent Cooperation Treaty 14 patent application serial no. PCT/BR2012/000148, filed May 21, 2012, entitled "SISTEMA DE INTERMEDIACAO MUTUA DE VANTAGENS," attorney docket no.
16 P200015.
17 [0003] The entire contents of the aforementioned applications are herein 18 expressly incorporated by reference.
[0004] The present innovations generally address exchanging purchase benefits, 21 and more particularly, include ECO ADVANTAGE MEDIATION APPARATUSES, 22 METHODS AND SYSTEMS.
1 [0 005] However, in order to develop a reader's understanding of the innovations, 2 disclosures have been compiled into a single description to illustrate and clarify how 3 aspects of these innovations operate independently, interoperate as between individual 4 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 6 further compliance with 35 U.S.C. 112.
8 [0006] Merchants can provide coupons or discounts to products in order to sell 9 more stock. Coupons and discounts can be of a particular merchant-specified value.
BRIEF DESCRIPTION OF THE DRAWINGS
11 [0 0 0 7] The accompanying appendices and/or drawings illustrate various non-12 limiting, example, innovative aspects in accordance with the present descriptions:
13 [0008] FIGURE la shows a block diagram illustrating example embodiments of 14 the ECO ADVANTAGE;
[0009] FIGURE ib shows a block diagram illustrating example embodiments of 16 the ECO ADVANTAGE;
17 [0010] FIGURE 2a shows a data flow diagram illustrating performing a 18 transaction in example embodiments of the ECO ADVANTAGE;
19 [0011] FIGURE 2h shows a logic flow diagram illustrating performing a transaction in example embodiments of the ECO ADVANTAGE;
21 [0012] FIGURE 2c shows a data flow diagram illustrating performing an online 22 transaction in example embodiments of the ECO ADVANTAGE;
23 [0013] FIGURE 2d shows a logic flow diagram illustrating performing an online 24 transaction in example embodiments of the ECO ADVANTAGE;
1 [0014] FIGURE 3a shows a data flow diagram illustrating performing a 2 transaction without an ECO ADVANTAGE account in example embodiments of the ECO
3 ADVANTAGE;
4 [0015] FIGURE 3b shows a logic flow diagram illustrating performing a transaction without an ECO ADVANTAGE account in example embodiments of the ECO
6 ADVANTAGE;
7 [o 016] FIGURE 4a shows a data flow diagram illustrating enrolling a merchant in 8 example embodiments of the ECO ADVANTAGE;
9 [0017] FIGURES 4b-c show logic flow diagrams illustrating enrolling a merchant in example embodiments of the ECO ADVANTAGE;
ii [o 018] FIGURE 5a shows a data flow diagram illustrating creating and updating 12 regions and categories in example embodiments of the ECO ADVANTAGE;
13 [0019] FIGURES 5b-d show logic flow diagrams illustrating creating and 14 updating regions and categories in example embodiments of the ECO
ADVANTAGE;
15[o 020] FIGURES 6a-b show data flow diagrams illustrating friend invitations and 16 donations in example embodiments of the ECO ADVANTAGE;
17 [0021] FIGURES 6c-d show logic flow diagrams illustrating friend invitations and 18 donations in example embodiments of the ECO ADVANTAGE;
19 [0022] FIGURE 7a shows a data flow diagram illustrating slow commit, credit-only transactions in example embodiments of the ECO ADVANTAGE;
21 [0023] FIGURE 7b shows a logic flow diagram illustrating slow commit, credit-22 only transactions in example embodiments of the ECO ADVANTAGE;
23 [o 024] FIGURE 8a shows a data flow diagram illustrating fast commit, credit-24 only transactions in example embodiments of the ECO ADVANTAGE;
[0025] FIGURE 8b shows a logic flow diagram illustrating fast commit, credit-26 only transactions in example embodiments of the ECO ADVANTAGE;
27[o 026] FIGURE 9a shows a data flow diagram illustrating merchant reconciliation 28 in example embodiments of the ECO ADVANTAGE;
1 [0027] FIGURE 9b shows a logic flow diagram illustrating merchant 2 reconciliation in example embodiments of the ECO ADVANTAGE;
3 [0028] FIGURE Ina shows a data flow diagram illustrating slow commit, cash and 4 credit transactions in example embodiments of the ECO ADVANTAGE;
[0029] FIGURES lob-c show logic flow diagrams illustrating slow commit, cash 6 and credit transactions in example embodiments of the ECO ADVANTAGE;
7 [o 030] FIGURE na shows a data flow diagram illustrating fast commit, cash and 8 credit transaction in example embodiments of the ECO ADVANTAGE;
9 [0031] FIGURES nb-c show logic flow diagrams illustrating fast commit, cash and credit transactions in example embodiments of the ECO ADVANTAGE;
ii [0032] FIGURE 12a shows a data flow diagram illustrating fast commit, cash only 12 transactions in example embodiments of the ECO ADVANTAGE;
13 [0033] FIGURE 1213 shows a logic flow diagram illustrating fast commit, cash only 14 transactions in example embodiments of the ECO ADVANTAGE;
[0034] FIGURE 13a shows a data flow diagram illustrating slow commit, cash 16 only transactions in example embodiments of the ECO ADVANTAGE;
17 [0035] FIGURE 13b shows a logic flow diagram illustrating slow commit, cash 18 only transactions in example embodiments of the ECO ADVANTAGE;
19 [0o36] FIGURE izia shows a data flow diagram illustrating merchant and partner transactions in example embodiments of the ECO ADVANTAGE;
21 [0037] FIGURES 14b-c show logic flow diagrams illustrating merchant and 22 partner transactions in example embodiments of the ECO ADVANTAGE;
23 [0o38] FIGURE 15a show a data flow diagram illustrating refunding or cancelling 24 transactions in example embodiments of the ECO ADVANTAGE;
[0039] FIGURE 15b shows a logic flow diagram illustrating refunding or 26 cancelling transactions in example embodiments of the ECO ADVANTAGE;
27 [004o] FIGURE 16 shows a table diagram illustrating using ECO ADVANTAGE
28 for health insurance in example embodiments of the ECO ADVANTAGE;
1 [0 041] FIGURES 17a-b show screenshot diagrams illustrating enrolling a 2 merchant in example embodiments of the ECO ADVANTAGE;
3 [0042] FIGURE 18 shows a screenshot diagram illustrating creating a region in 4 example embodiments of the ECO ADVANTAGE;
[0 0 0 2 ] 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/00U5 1318827-2004 which in turn claims priority to Patent Cooperation Treaty 14 patent application serial no. PCT/BR2012/000148, filed May 21, 2012, entitled "SISTEMA DE INTERMEDIACAO MUTUA DE VANTAGENS," attorney docket no.
16 P200015.
17 [0003] The entire contents of the aforementioned applications are herein 18 expressly incorporated by reference.
[0004] The present innovations generally address exchanging purchase benefits, 21 and more particularly, include ECO ADVANTAGE MEDIATION APPARATUSES, 22 METHODS AND SYSTEMS.
1 [0 005] However, in order to develop a reader's understanding of the innovations, 2 disclosures have been compiled into a single description to illustrate and clarify how 3 aspects of these innovations operate independently, interoperate as between individual 4 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 6 further compliance with 35 U.S.C. 112.
8 [0006] Merchants can provide coupons or discounts to products in order to sell 9 more stock. Coupons and discounts can be of a particular merchant-specified value.
BRIEF DESCRIPTION OF THE DRAWINGS
11 [0 0 0 7] The accompanying appendices and/or drawings illustrate various non-12 limiting, example, innovative aspects in accordance with the present descriptions:
13 [0008] FIGURE la shows a block diagram illustrating example embodiments of 14 the ECO ADVANTAGE;
[0009] FIGURE ib shows a block diagram illustrating example embodiments of 16 the ECO ADVANTAGE;
17 [0010] FIGURE 2a shows a data flow diagram illustrating performing a 18 transaction in example embodiments of the ECO ADVANTAGE;
19 [0011] FIGURE 2h shows a logic flow diagram illustrating performing a transaction in example embodiments of the ECO ADVANTAGE;
21 [0012] FIGURE 2c shows a data flow diagram illustrating performing an online 22 transaction in example embodiments of the ECO ADVANTAGE;
23 [0013] FIGURE 2d shows a logic flow diagram illustrating performing an online 24 transaction in example embodiments of the ECO ADVANTAGE;
1 [0014] FIGURE 3a shows a data flow diagram illustrating performing a 2 transaction without an ECO ADVANTAGE account in example embodiments of the ECO
3 ADVANTAGE;
4 [0015] FIGURE 3b shows a logic flow diagram illustrating performing a transaction without an ECO ADVANTAGE account in example embodiments of the ECO
6 ADVANTAGE;
7 [o 016] FIGURE 4a shows a data flow diagram illustrating enrolling a merchant in 8 example embodiments of the ECO ADVANTAGE;
9 [0017] FIGURES 4b-c show logic flow diagrams illustrating enrolling a merchant in example embodiments of the ECO ADVANTAGE;
ii [o 018] FIGURE 5a shows a data flow diagram illustrating creating and updating 12 regions and categories in example embodiments of the ECO ADVANTAGE;
13 [0019] FIGURES 5b-d show logic flow diagrams illustrating creating and 14 updating regions and categories in example embodiments of the ECO
ADVANTAGE;
15[o 020] FIGURES 6a-b show data flow diagrams illustrating friend invitations and 16 donations in example embodiments of the ECO ADVANTAGE;
17 [0021] FIGURES 6c-d show logic flow diagrams illustrating friend invitations and 18 donations in example embodiments of the ECO ADVANTAGE;
19 [0022] FIGURE 7a shows a data flow diagram illustrating slow commit, credit-only transactions in example embodiments of the ECO ADVANTAGE;
21 [0023] FIGURE 7b shows a logic flow diagram illustrating slow commit, credit-22 only transactions in example embodiments of the ECO ADVANTAGE;
23 [o 024] FIGURE 8a shows a data flow diagram illustrating fast commit, credit-24 only transactions in example embodiments of the ECO ADVANTAGE;
[0025] FIGURE 8b shows a logic flow diagram illustrating fast commit, credit-26 only transactions in example embodiments of the ECO ADVANTAGE;
27[o 026] FIGURE 9a shows a data flow diagram illustrating merchant reconciliation 28 in example embodiments of the ECO ADVANTAGE;
1 [0027] FIGURE 9b shows a logic flow diagram illustrating merchant 2 reconciliation in example embodiments of the ECO ADVANTAGE;
3 [0028] FIGURE Ina shows a data flow diagram illustrating slow commit, cash and 4 credit transactions in example embodiments of the ECO ADVANTAGE;
[0029] FIGURES lob-c show logic flow diagrams illustrating slow commit, cash 6 and credit transactions in example embodiments of the ECO ADVANTAGE;
7 [o 030] FIGURE na shows a data flow diagram illustrating fast commit, cash and 8 credit transaction in example embodiments of the ECO ADVANTAGE;
9 [0031] FIGURES nb-c show logic flow diagrams illustrating fast commit, cash and credit transactions in example embodiments of the ECO ADVANTAGE;
ii [0032] FIGURE 12a shows a data flow diagram illustrating fast commit, cash only 12 transactions in example embodiments of the ECO ADVANTAGE;
13 [0033] FIGURE 1213 shows a logic flow diagram illustrating fast commit, cash only 14 transactions in example embodiments of the ECO ADVANTAGE;
[0034] FIGURE 13a shows a data flow diagram illustrating slow commit, cash 16 only transactions in example embodiments of the ECO ADVANTAGE;
17 [0035] FIGURE 13b shows a logic flow diagram illustrating slow commit, cash 18 only transactions in example embodiments of the ECO ADVANTAGE;
19 [0o36] FIGURE izia shows a data flow diagram illustrating merchant and partner transactions in example embodiments of the ECO ADVANTAGE;
21 [0037] FIGURES 14b-c show logic flow diagrams illustrating merchant and 22 partner transactions in example embodiments of the ECO ADVANTAGE;
23 [0o38] FIGURE 15a show a data flow diagram illustrating refunding or cancelling 24 transactions in example embodiments of the ECO ADVANTAGE;
[0039] FIGURE 15b shows a logic flow diagram illustrating refunding or 26 cancelling transactions in example embodiments of the ECO ADVANTAGE;
27 [004o] FIGURE 16 shows a table diagram illustrating using ECO ADVANTAGE
28 for health insurance in example embodiments of the ECO ADVANTAGE;
1 [0 041] FIGURES 17a-b show screenshot diagrams illustrating enrolling a 2 merchant in example embodiments of the ECO ADVANTAGE;
3 [0042] FIGURE 18 shows a screenshot diagram illustrating creating a region in 4 example embodiments of the ECO ADVANTAGE;
5 [0043] FIGURE 19 shows a screenshot diagram illustrating creating categories in
6 example embodiments of the ECO ADVANTAGE;
7 [0044] FIGURES 2oa-b show screenshot diagrams illustrating donating ecos in
8 example embodiments of the ECO ADVANTAGE;
9 [0045] FIGURES 21a-b show screenshot diagrams illustrating user profiles and eco balances in example embodiments of the ECO ADVANTAGE;
ii [ o 046] FIGURES 22a-b show diagrams illustrating user navigation and check-in 12 in example embodiments of the ECO ADVANTAGE;
13 [0047] FIGURE 23 shows a block diagram illustrating embodiments of an ECO
14 ADVANTAGE controller.
[0048] The leading number of each reference number within the drawings 16 indicates the figure in which that reference number is introduced and/or detailed. As 17 such, a detailed discussion of reference number 101 would be found and/or introduced 18 in Figure 1. Reference number 201 is introduced in Figure 2, etc.
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 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 with unpredictable returns. In some implementations, ECO ADVANTAGE 103 may ii 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 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 18 that provide goods, services or both.
19 [0050] FIGURE ib shows a block diagram illustrating example embodiments of 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 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 109 in ECO
27 ADVANTAGE and use their ecos in subsequent transactions.
1 [o 0 5 1 ] In some implementations, ECO ADVANTAGE may also donate 2 predetermined blocks of ecos to early adoption users in order to encourage them to 3 invite friends to ECO ADVANTAGE. In some implementations, the donated ecos may 4 only be used for donations to other potential users.
[0052] In some implementations ECO ADVANTAGE may control how many ecos 6 a user may utilize at a particular merchant based on the merchant capacity at particular 7 times of day, particular days of the week, particular seasons and/or holidays during a 8 year, total transaction amount, intended products and/or services, total transactions to 9 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 ii use a higher number of ecos (e.g. 30% of the transaction amount may be paid in ecos) at 12 a merchant that does not have many customers during the day, and may be able to use a 13 lower number of ecos (e.g. 15% of the transaction amount may be paid in ecos) at a 14 merchant that has many customers during the day.
[0053] In some implementations, once a user makes a purchase at a merchant, 16 the user may earn ecos which may be utilized in subsequent transactions.
For example, 17 if a user buys a meal for $loo, the user may receive some number of ecos during the 18 transaction. In some implementations, the amount of ecos received may be equal to the 19 amount the user pays out-of-pocket for a transaction. For example, if a user purchases a meal for $loo but uses 20 ecos to pay for part of the meal (thereby only paying $8o out-21 of-pocket for the meal), the user may receive 80 ecos from the transaction.
In other 22 implementations, the amount of ecos the user receives may be a percentage of the total 23 transaction, a percentage of the amount the user pays out-of-pocket, a percentage 24 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, 26 and/or a like entity.
27 [0054] In some implementations, these ecos may not be used with the merchant 28 from which they were issued. For example, a user may purchase a TV from Best Buy and 29 receive loo ecos from the transaction. In some implementations, these loo ecos may be marked in an ECO ADVANTAGE Database as being from Best Buy, and in subsequent 31 purchases at Best Buy, the user may not be able to use those 100 ecos for said purchases.
1 The user, however, may be able to use the loo ecos at other merchants for other 2 purchases; for example, the user may be able to use the wo ecos towards a transaction 3 at Radio Shack, Whole Foods, and/or the like. In some implementations, the 4 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 6 though the user may have received its ecos from Best Buy, the user may not be restricted 7 to using them at a similar electronics store, and/or the like. In some implementations 8 the user may be able to spend the ecos at any other merchant other than Best Buy.
9 [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 ii who receives ecos from a Best Buy in New York City may not be able to spend the ecos in 12 an area other than New York City, may not be able to spend the ecos at merchant of a 13 different industry and/or category (e.g. electronics) than Best Buy, and/or the like. In 14 some implementations, such limitations may be determined by the merchant, ECO
ADVANTAGE, and/or a like entity. In some implementations, example industries 16 and/or categories supported by ECO ADVANTAGE may include: Accessories, 17 Advertising and Marketing, Animal Clinic and Hospital, Arts and Crafts, Auto Body 18 Shop, Auto Dealer, Auto Electric Shop, Auto Parts Store, Bakery, Beauty Clinic, Book 19 Wholesale, Bookstore, Building Supplies, Camera and Photo, Car-Wash, Ceilings/
Partition, Cell Phone Provider, Children's Store, Chocolate Shop, Clothing Repair, 21 Coffee Shop, Computer and Accessories, Convenience Store, Cosmetics, Costume Shop, 22 Courier Service, Dairy Products, Delicatessen, Diner, Do-It-Yourself Store, Durable 23 Medical Equipment, DVD and Movies, Electrical Parts, Electronic and Video Game, 24 Eletro/electronic Repair and Maintenance, Eyeglasses and Sunglasses, Fabric and Upholstery Store, Fast Graphic Service, Furniture Store, Gas Station, Gift Store, 26 Gourmet and Specialty Food Store, Grocery Store, Gym, Hardware Store, Heating and 27 Air Conditioning, Home and Gardening, Home and Kitchen Goods, Home Appliance, 28 Home Improvement, Home Phone Provider, Hotels, Ice Cream Parlour, Janitorial /
29 Cleaning Supplies, Jewelry, Kids Party Place, Kids Tutoring, Language School or Learning Center, Laundry and Dry Cleaning, Leisure and Tourism, Light Fixture, 31 Lingerie and Intimate Apparel, Locksmith, Luggage and Suitcase Store, Men's Fashion, 1 Motels, Motorcycle Dealer, Movie Theater, Moving Service, Musical Instrument Shop, 2 Natural Food Store, Nautical Store, Nightclub / Disco, Office Supplies, Paint Store, 3 Party Supply Store, Perfumery, Personal Development Course, Pet Shop, Pharmacy, 4 Plastic Surgery, Refrigeration Shop, Restaurant (all kinds), Rotisserie, Rug and Curtain Shop, School, Shoe Repair, Shoe Store, SPA, Specialty Pharmacy, Sporting Goods, Sport 6 Tickets, Supermarket, Surgical Equipment, Swimwear Fashion, Technical Course, 7 Theaters, Tickets (ShowsConcerts), Toy Store, Travel Agency, Visual Communication, 8 Winery, Women's Fashion, and/or the like.
9 [0056] In some implementations, ecos may also have an expiration date, in which io they are deactivated once the expiration date has passed. In some implementations, ii donating and/or otherwise regifting ecos that are about to expire may reset the 12 expiration date of the ecos.
13 [0057] In some implementations, the user may also receive bonus blocks from 14 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
16 ADVANTAGE as a result of bringing new users to ECO ADVANTAGE, and may be used 17 in conjunction with ecos towards a purchase at any participating merchant.
For 18 example, in addition to the 20 ecos paid towards the $100 Best Buy transaction, a user 19 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 21 types of bonus blocks, such as invite bonus blocks (e.g. bonus blocks for inviting other 22 users), merchant bonus blocks (e.g. bonus blocks issued by merchants), and/or the like.
23 [0058] The term "place of business", as herein used, means all the different 24 geographic and non-physical locations where or through which an associated merchant conducts transactions, including shops, department stores, medical clinics, restaurants, 26 pet shops, beauty parlors, traveling agencies, offices, hospitals, cabs, retailers, 27 distributors, producers, manufacturers, kiosks, shopping centers, fairs, shows, cruise 28 ships, flea markets, public markets ¨ and also catalogs, websites, any device with private 29 network or internet access: computer, personal computer, network device, workstation computer, handheld computer, tablet, smart phone, mobile phone, voice phone, POS
31 electronic terminal, smart TV, set-top box, and/or the like.
1 [0 0 59]
2 [oo6o] FIGURE 2a shows a data flow diagram illustrating performing a 3 transaction in example embodiments of the ECO ADVANTAGE. In some 4 implementations, a user 201 may interact with a merchant 202 via initiating a 5 transaction for a product and/or service with the merchant 205. In some 6 implementations, the user may initiate the transaction via the Point of Sales (PoS) 7 device at the merchant location, via a merchant kiosk, via a personal electronic device 8 (e.g. computer connected to a website, mobile device connected to an ECO
9 ADVANTAGE application, and/or the like). In some implementations, the user may
ii [ o 046] FIGURES 22a-b show diagrams illustrating user navigation and check-in 12 in example embodiments of the ECO ADVANTAGE;
13 [0047] FIGURE 23 shows a block diagram illustrating embodiments of an ECO
14 ADVANTAGE controller.
[0048] The leading number of each reference number within the drawings 16 indicates the figure in which that reference number is introduced and/or detailed. As 17 such, a detailed discussion of reference number 101 would be found and/or introduced 18 in Figure 1. Reference number 201 is introduced in Figure 2, etc.
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 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 with unpredictable returns. In some implementations, ECO ADVANTAGE 103 may ii 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 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 18 that provide goods, services or both.
19 [0050] FIGURE ib shows a block diagram illustrating example embodiments of 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 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 109 in ECO
27 ADVANTAGE and use their ecos in subsequent transactions.
1 [o 0 5 1 ] In some implementations, ECO ADVANTAGE may also donate 2 predetermined blocks of ecos to early adoption users in order to encourage them to 3 invite friends to ECO ADVANTAGE. In some implementations, the donated ecos may 4 only be used for donations to other potential users.
[0052] In some implementations ECO ADVANTAGE may control how many ecos 6 a user may utilize at a particular merchant based on the merchant capacity at particular 7 times of day, particular days of the week, particular seasons and/or holidays during a 8 year, total transaction amount, intended products and/or services, total transactions to 9 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 ii use a higher number of ecos (e.g. 30% of the transaction amount may be paid in ecos) at 12 a merchant that does not have many customers during the day, and may be able to use a 13 lower number of ecos (e.g. 15% of the transaction amount may be paid in ecos) at a 14 merchant that has many customers during the day.
[0053] In some implementations, once a user makes a purchase at a merchant, 16 the user may earn ecos which may be utilized in subsequent transactions.
For example, 17 if a user buys a meal for $loo, the user may receive some number of ecos during the 18 transaction. In some implementations, the amount of ecos received may be equal to the 19 amount the user pays out-of-pocket for a transaction. For example, if a user purchases a meal for $loo but uses 20 ecos to pay for part of the meal (thereby only paying $8o out-21 of-pocket for the meal), the user may receive 80 ecos from the transaction.
In other 22 implementations, the amount of ecos the user receives may be a percentage of the total 23 transaction, a percentage of the amount the user pays out-of-pocket, a percentage 24 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, 26 and/or a like entity.
27 [0054] In some implementations, these ecos may not be used with the merchant 28 from which they were issued. For example, a user may purchase a TV from Best Buy and 29 receive loo ecos from the transaction. In some implementations, these loo ecos may be marked in an ECO ADVANTAGE Database as being from Best Buy, and in subsequent 31 purchases at Best Buy, the user may not be able to use those 100 ecos for said purchases.
1 The user, however, may be able to use the loo ecos at other merchants for other 2 purchases; for example, the user may be able to use the wo ecos towards a transaction 3 at Radio Shack, Whole Foods, and/or the like. In some implementations, the 4 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 6 though the user may have received its ecos from Best Buy, the user may not be restricted 7 to using them at a similar electronics store, and/or the like. In some implementations 8 the user may be able to spend the ecos at any other merchant other than Best Buy.
9 [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 ii who receives ecos from a Best Buy in New York City may not be able to spend the ecos in 12 an area other than New York City, may not be able to spend the ecos at merchant of a 13 different industry and/or category (e.g. electronics) than Best Buy, and/or the like. In 14 some implementations, such limitations may be determined by the merchant, ECO
ADVANTAGE, and/or a like entity. In some implementations, example industries 16 and/or categories supported by ECO ADVANTAGE may include: Accessories, 17 Advertising and Marketing, Animal Clinic and Hospital, Arts and Crafts, Auto Body 18 Shop, Auto Dealer, Auto Electric Shop, Auto Parts Store, Bakery, Beauty Clinic, Book 19 Wholesale, Bookstore, Building Supplies, Camera and Photo, Car-Wash, Ceilings/
Partition, Cell Phone Provider, Children's Store, Chocolate Shop, Clothing Repair, 21 Coffee Shop, Computer and Accessories, Convenience Store, Cosmetics, Costume Shop, 22 Courier Service, Dairy Products, Delicatessen, Diner, Do-It-Yourself Store, Durable 23 Medical Equipment, DVD and Movies, Electrical Parts, Electronic and Video Game, 24 Eletro/electronic Repair and Maintenance, Eyeglasses and Sunglasses, Fabric and Upholstery Store, Fast Graphic Service, Furniture Store, Gas Station, Gift Store, 26 Gourmet and Specialty Food Store, Grocery Store, Gym, Hardware Store, Heating and 27 Air Conditioning, Home and Gardening, Home and Kitchen Goods, Home Appliance, 28 Home Improvement, Home Phone Provider, Hotels, Ice Cream Parlour, Janitorial /
29 Cleaning Supplies, Jewelry, Kids Party Place, Kids Tutoring, Language School or Learning Center, Laundry and Dry Cleaning, Leisure and Tourism, Light Fixture, 31 Lingerie and Intimate Apparel, Locksmith, Luggage and Suitcase Store, Men's Fashion, 1 Motels, Motorcycle Dealer, Movie Theater, Moving Service, Musical Instrument Shop, 2 Natural Food Store, Nautical Store, Nightclub / Disco, Office Supplies, Paint Store, 3 Party Supply Store, Perfumery, Personal Development Course, Pet Shop, Pharmacy, 4 Plastic Surgery, Refrigeration Shop, Restaurant (all kinds), Rotisserie, Rug and Curtain Shop, School, Shoe Repair, Shoe Store, SPA, Specialty Pharmacy, Sporting Goods, Sport 6 Tickets, Supermarket, Surgical Equipment, Swimwear Fashion, Technical Course, 7 Theaters, Tickets (ShowsConcerts), Toy Store, Travel Agency, Visual Communication, 8 Winery, Women's Fashion, and/or the like.
9 [0056] In some implementations, ecos may also have an expiration date, in which io they are deactivated once the expiration date has passed. In some implementations, ii donating and/or otherwise regifting ecos that are about to expire may reset the 12 expiration date of the ecos.
13 [0057] In some implementations, the user may also receive bonus blocks from 14 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
16 ADVANTAGE as a result of bringing new users to ECO ADVANTAGE, and may be used 17 in conjunction with ecos towards a purchase at any participating merchant.
For 18 example, in addition to the 20 ecos paid towards the $100 Best Buy transaction, a user 19 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 21 types of bonus blocks, such as invite bonus blocks (e.g. bonus blocks for inviting other 22 users), merchant bonus blocks (e.g. bonus blocks issued by merchants), and/or the like.
23 [0058] The term "place of business", as herein used, means all the different 24 geographic and non-physical locations where or through which an associated merchant conducts transactions, including shops, department stores, medical clinics, restaurants, 26 pet shops, beauty parlors, traveling agencies, offices, hospitals, cabs, retailers, 27 distributors, producers, manufacturers, kiosks, shopping centers, fairs, shows, cruise 28 ships, flea markets, public markets ¨ and also catalogs, websites, any device with private 29 network or internet access: computer, personal computer, network device, workstation computer, handheld computer, tablet, smart phone, mobile phone, voice phone, POS
31 electronic terminal, smart TV, set-top box, and/or the like.
1 [0 0 59]
2 [oo6o] FIGURE 2a shows a data flow diagram illustrating performing a 3 transaction in example embodiments of the ECO ADVANTAGE. In some 4 implementations, a user 201 may interact with a merchant 202 via initiating a 5 transaction for a product and/or service with the merchant 205. In some 6 implementations, the user may initiate the transaction via the Point of Sales (PoS) 7 device at the merchant location, via a merchant kiosk, via a personal electronic device 8 (e.g. computer connected to a website, mobile device connected to an ECO
9 ADVANTAGE application, and/or the like). In some implementations, the user may
10 provide information to the merchant including the user's ID in ECO
ADVANTAGE, the ii user's PIN (and/or a like form of authentication), and/or the like. In some 12 implementations, the PoS device may also provide information such as the transaction 13 amount, products and/or services being purchase, refunded, and/or the like, 14 atmospherics at the time of the transaction, and/or like information. In some implementations, the merchant may send this information to the ECO ADVANTAGE
16 server 203 via an eco request message 206. In some implementations, an exemplary 17 XML-encoded eco request message 206 may take a form similar to the following:
18 POST /eco_request_message.php HTTP/1.1 19 Host: www.ECOADVANTAGEprocess.com Content-Type: Application/XML
21 Content-Length: 788 22 <?XML version = "1.0" encoding = "UTF-8"?>
23 <ecoRequest>
24 <merchantId>2033</merchantId>
<userId>102557952</userId>
26 <userIdType>SSN</userIdType >
27 <ecoId>3074</ecoId>
28 <posId>4088</posId>
29 <processingCode>683034</processingCode>
<origDocNumber></origDocNumber>
31 <nsu>572052</nsu>
32 <mcc>6432</mcc>
33 <merchantCapacity>27</merchantCapacity>
ADVANTAGE, the ii user's PIN (and/or a like form of authentication), and/or the like. In some 12 implementations, the PoS device may also provide information such as the transaction 13 amount, products and/or services being purchase, refunded, and/or the like, 14 atmospherics at the time of the transaction, and/or like information. In some implementations, the merchant may send this information to the ECO ADVANTAGE
16 server 203 via an eco request message 206. In some implementations, an exemplary 17 XML-encoded eco request message 206 may take a form similar to the following:
18 POST /eco_request_message.php HTTP/1.1 19 Host: www.ECOADVANTAGEprocess.com Content-Type: Application/XML
21 Content-Length: 788 22 <?XML version = "1.0" encoding = "UTF-8"?>
23 <ecoRequest>
24 <merchantId>2033</merchantId>
<userId>102557952</userId>
26 <userIdType>SSN</userIdType >
27 <ecoId>3074</ecoId>
28 <posId>4088</posId>
29 <processingCode>683034</processingCode>
<origDocNumber></origDocNumber>
31 <nsu>572052</nsu>
32 <mcc>6432</mcc>
33 <merchantCapacity>27</merchantCapacity>
11 1 <transactionAmount>100.0</transactionAmount>
2 <minTransactionSize>10</minTransactionSize>
3 <maxTransactionSize>500</maxTransactionSize>
4 <transactionSize>1</transactionSize>
<productData>broiled crabs</productData>
6 <atmospherics>
7 <dateTime>03/07/2013 03:39 PM</dateTime>
8 <seating_pref>n_smoking</seating_pref>
9 <party_size>2</party_size>
<reserv_date>02/28/2013 03:39 PM</reserv_date>
11 <weather>70F, sunny</weather>
2 <minTransactionSize>10</minTransactionSize>
3 <maxTransactionSize>500</maxTransactionSize>
4 <transactionSize>1</transactionSize>
<productData>broiled crabs</productData>
6 <atmospherics>
7 <dateTime>03/07/2013 03:39 PM</dateTime>
8 <seating_pref>n_smoking</seating_pref>
9 <party_size>2</party_size>
<reserv_date>02/28/2013 03:39 PM</reserv_date>
11 <weather>70F, sunny</weather>
12 <product_pref>steak</product_pref>
13 </atmospherics>
14 </ecoRequest>
[0061] In some implementations, sensitive information (e.g. the user PIN
and/or 16 the like) may be encrypted. In some implementations, the ECO ADVANTAGE
server 17 may look 207 for the merchant and the user using the information obtained in the eco 18 request message, and may determine whether both entities are already enrolled in ECO
19 ADVANTAGE. In some implementations, Grails code for looking up the user and merchant data mat take a form similar to the following:
21 def merchant = Merchant.get(params.merchantId);
22 if (!merchant) {
23 log.warn("Merchant not found with value '${params.merchant}'");
24 return sendErroWexception.merchant.not.found');
1 elseif (!merchant.enabled 11 !merchant.confirmed) {
26 log.warn("Merchant inactive with value '${params.merchant}'");
27 return sendErroWexception.merchant.inactive');
28 1 elseif (merchant.accountLocked) {
29 log.warn("Merchant account locked with value W '${params.merchant}'");
31 return sendErroWexception.merchant.locked');
32 }
34 def schedule = merchant.getSchedules() 36 def user = User.get(params.userId);
1 if (!user) {
2 log.warn("User not found with value '${params.userId}'");
3 return sendErroWexception.user.not.found');
4 lelseif (!user.enabled 11 !user.confirmed) {
log.warn("User inactive with value '${params.userId}'");
6 return sendErroWexception.user.inactive');
7 1 elseif (user.accountLocked) {
8 log.warn("User account locked with value '${params.userId}'");
9 return sendErroWexception.user.locked');
11 [o o6 2] The server may access the ECO ADVANTAGE database 209, via querying 12 the database 208 for user and merchant records corresponding to the user and 13 merchant specified in eco request 206.
14 [0 063] In some implementations, ECO ADVANTAGE may query merchant 209c and user 209d tables of the ECO ADVANTAGE database in order to determine whether 16 such records exist. In some implementations, the ECO ADVANTAGE database may 17 return a user/merchant result 210 which may contain the found records pertaining to 18 the user and/or merchant involved in the transaction. In some implementations, the 19 user/merchant result 210 may take a form similar to the following:
merchant [
21 id: 2033, 22 name: "NY some salon inc.", 23 mail: "ny@somesalon.com", 24 document: "32135743134", dateCreated: "05/05/2012", 26 username: "salon", 27 password: encrypt("salon123"), 28 enabled: true, 29 accountLocked: false, W confirmed: true, 31 phoneNumber: 254145451, 32 contact: "some joseph", 33 openingTimes: "24h", 34 officialWebsite: "www.somesalon.com", 1 region: 254, 2 minConsumption: 10, 3 maxConsumption: 500, 4 bank: "225", bankAgency: "2541-9", 6 bankAccount: "123212121-3"
9 user [
M id: 1025, 11 name: "John Tavares", 12 mail: "john@somecompany.com", M document: "336525544", 14 dateCreated: "05/05/2012", M username: "john", M password: encrypt("john123"), 17 enabled: true, M accountLocked: false, 19 confirmed: true, 20 phoneNumber: "654258225"
21 ]
22 [0064] In some implementations, ECO ADVANTAGE may use these records to 23 determine 211 a number of calculations, such as the number of ecos the user may use 24 towards the transaction, the number and amount of bonus blocks the user may use 25 towards the transaction, and/or the like. In some implementations, this may be 26 determined based on the user check-in, based on the merchant's atmospherics, based on 27 a merchant's eco schedule, based on the merchants current available capacity, projected 28 available capacity, growth potential, and/or the like. In some implementations, Grails 29 code for determining said calculations may resemble the following:
a) /* def merchant = Merchant.get(params.merchantId); */
31 /* def schedule =
merchant.getSchedules() */
32 /* def user =
User.get(params.userId); */
34 def eco = Eco.getEcoFromCurrentSchedule(schedule) 1 Checkin checkin = user.getLastCheckin(transaction.merchantId) 2 if (checkin.isValidForTransaction(transaction.merchantId, Now(), transaction) {
4 eco = Eco.updateEcoScheduleWithCheckin(eco, checkin) }
6 checkin.markCheckingOut() 8 def saving = eco.saving 9 def minTransactionSize = eco.minTransactionSize def maxTransactionSize = eco.maxTransactionSize 11 def quantity = transaction.quantity 12 def realValue = transaction.transactionAmount 14 if ((realValue < minTransactionSize ) && (realValue >
maxTransactionSize )) {
error "Amount must be between ${minTransactionSize} and 17 ${maxTransactionSize}"
def amountOfEcos = calculateValueToPayWithEco(realValue, saving, 21 transaction) 22 def balanceForMerchant =
getBalanceForMerchant(transaction.user, 23 transaction.merchant) if (amountOfEcos > balanceForMerchant) {
26 error "User insufficient balance"
27 return 28 }
def amountDueInDollars = calculateValueToPayWithRealMoney(realValue, saving, transaction) 33 BonusBlock bonusBlock = user.getValidBonusBlock() 34 if (bonusBlock) {
if (amountDueInDollars > bonusBlock.value) {
36 if (bonusBlock.isEligibleFor(transaction) {
37 amountDueInDollars = amountDueInDollars -bonusBlock.value 38 }
/
2 public static BigDecimal calculateValueToPayWithEco(BigDecimal 3 realValue, Double saving, Integer quantity = 1){
4 if(!realValue 11 !saving 11 realValue == 0 11 saving == 0) {
5 return 0;
6 }
7 return Math.round((realValue * quantity) - (realValue.divide (1 +
8 (saving / 100), 2, RoundingMode.HALF_UP)) * quantity);
11 public static BigDecimal calculateValueToPayWithRealMoney(BigDecimal 12 realValue, Double saving, Transaction transaction) {
M if(!realValue 11 !saving 11 realValue == 0 11 saving == 0) {
14 return 0;
M }
M return (realValue * quantity) -17 calculateValueToPayWithEco(realValue, saving, transaction) M /
def getBalance() {
21 def result = 0;
22 def userBalance = Transaction.executeQuery( 23 "select sum(value * signal) as balance from 24 Transaction " +
"where user.id = :userId " +
26 " and date <= :date ", 27 [userId: userId, date: new Date()]);
29 return result;
}
32 def getBalanceForMerchant(User user, Merchant merchant) {
33 def result = 0;
34 def balance = this.getBalance();
def merchantAdjustBalance = UserMerchantAdjust.executeQuery( 36 "select sum(value) from UserMerchantAdjust " +
37 "where user.id = :userId " +
38 " and merchant.id = :merchantId " +
1 " and adjustDate <= :date ", 2 [userId: user.id, merchantId: merchant.id, date:
new 3 Date()])?.first();
if (!merchantAdjustBalance) {
6 merchantAdjustBalance = 0;
7 }
9 return balance + merchantAdjustBalance;
}
11 [0065] In some implementations, the merchant's eco schedule may be a schedule 12 that outlines the percentage of a given transaction at the merchant that may be paid by 13 the user with ecos. In some implementations this schedule may be based on information 14 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 16 date, total ecos donated by period or to date, total ecos donated and used by period or to 17 date, number of active friends by period or to date, some factor thereof, and/or the like 18 (see FIGS. 5a-d for more information).
19 [ o o 6 6] In some implementations, the ECO ADVANTAGE server may send this information to the merchant via an eco response 212. In some implementations an 21 XML-encoded eco response may take a form similar to the following:
22 POST /eco_request_message.php HTTP/1.1 23 Host: www.ECOADVANTAGEprocess.com 24 Content-Type: Application/XML
Content-Length: 788 26 <?XML version = "1.0" encoding = "UTF-8"?>
27 <ecoResponse>
28 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
29 <transactionId>635467</transactionId>
<transactionAmount>100.0</transactionAmount>
31 <merchantId>2033</merchantId>
32 <ecoSaving>20%</ecoSaving>
33 <userEcoBalance>1091</userEcoBalance>
34 <amountDueInDollars>77.0</amountDueInDollars>
1 <userEcoUsage>23</userEcoUsage>
2 <userBonusBlockUsage>0</userBonusBlockUsage>
3 <atmospherics>
4 <dateTime>03/07/2013 03:39 PM</dateTime>
<seating_pref>n_smoking</seating_pref>
6 <party_size>2</party_size>
7 <reserv_date>02/28/2013 03:39 PM</reserv_date>
8 <weather>70F, sunny</weather>
9 <product_pref>steak</product_pref>
</atmospherics>
11 <ecoResponse>
12 [0067] In some implementations, the merchant may use the information obtained 13 to display 213 the updated transaction information to the user, which may include the 14 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 16 applied, and/or the like. In some implementations, the merchant may use the 17 information may include the user's bonus block balance, the bonus blocks that may be 18 used in the transaction, the transaction balance if bonus blocks are applied, the user's 19 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 21 may confirm the use of bonus blocks independently. In some implementations the user 22 may confirm via pressing a button and/or the like on a PoS terminal at the merchant, or 23 via a mobile application, SMS, a website, NFC/RFID and/or like proximity tags, UTP
24 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 26 processing of the transaction. In some implementations, the acquirer may directly 27 procure funds for the merchant; in other implementations, the acquirer may be an 28 intermediate between the merchant and another acquiring entity (e.g., another 29 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 31 following:
32 POST /payment_request_message.php HTTP/1.1 33 Host: www.ECOADVANTAGEprocess.com 1 Content-Type: Application/XML
2 Content-Length: 788 3 <?XML version = "1.0" encoding = "UTF-8"?>
4 <paymentRequest>
<UID>da6c5cdf4e90b2961873f7b2e863415</UID>
6 <transactionId>635467</transactionId>
7 <merchantId>2033</merchantId>
8 <posId>4088</posId>
9 <amountDueInDollars>77.0</amountDueInDollars>
<dateTime>03/07/2013 03:39 PM</dateTime>
11 <userCard>3214 3578 3568 3542</userCard>
12 </paymentRequest>
13 [0068] In some implementations, the acquirer may only receive the transaction 14 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 16 the transaction request in order to generate messages to the various payment entities 17 who may be involved in the procurement of the user's payment 216. For example, the 18 acquirer may interact with the user's issuing bank, the merchant's bank account, one or 19 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 21 institution, payment gateway, online payment service (e.g., PayPal), Electronic Funds 22 Transfer Network (e.g., Swift), and/or the like. In some implementations, Grails code 23 for processing the transaction may take a form similar to the following:
24 Card card = Card.get(userCard);
Merchant merchant = Merchant.get(merchantId) 26 Try{
27 beginTransaction() 28 card.debit(amountDueInDollars) 29 merchant.credit(amountDueInDollars) commitTransaction();
31 return true;
32 I catch (Exception) {
33 rollbackTransaction();
34 return false;
}
1 [0 069] 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:
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"?>
<paymentConfirmation>
11 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
12 <transactionId>635467</transactionId>
13 <merchantId>2033</merchantId>
14 <posId>4088</posId>
<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>
<approved>true</approved>
21 </paymentConfirmation>
22 [0070] 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
device. In some implementations the receipt may take a form similar to the following:
26 DOCUMENT: NNN.NNN.NNN-NN ID EAS: IIIIII
27 ORIGINAL VALUE: VVV.VVV,VV
28 BONUS BLOCK VALUE: VVV.VVV,VV
29 ECONOMY: EEE.EEE,EE
VALUE PPPPPPPPPP: TTT.TTT,TT
32 ECO BALANCE: BBB.BBB,BB
1 [0 0 71] The merchant may also forward 219 the transaction confirmation to ECO
2 ADVANTAGE. In some implementations transaction confirmation 219 may take a form 3 similar to the following:
4 <transactionConfirmation>
5 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
6 <transactionId>635467</transactionId>
7 <merchantId>2033</merchantId>
8 <posId>4088</posId>
9 <amounInDollars>77.0</amountDueInDollars>
10 <debitCreditAmount>77.0</debitCreditAmount>
11 <cashAmount>0.0</cashAmount>
12 <dateTime>03/07/2013 03:40 PM</dateTime>
M <approyed>true</approyed>
14 </transactionConfirmation>
M [01072] ECO ADVANTAGE may use the confirmation to update 220 the user's 16 account (e.g. by deducting the ecos used in the transaction, by adding to the user 17 account new ecos identified as being from the merchant, and/or the like).
In some 18 implementations Grails code for updating the user's account may take a form similar to 19 the following:
20 Transaction transaction = Transaction.get(transactionId) 21 User user = transaction.getUser() 22 Merchant merchant = transaction.getMerchant() 23 long ecoUsage = transaction.getEcoUsage() 24 long bonusBlockUsage = transaction.getBonusBlockUsage() long amountDueInDollars = transaction.getAmountDueInDollars() 27 Try{
28 beginTransaction() 29 user.debitEco(ecoUsage) user.debitBonusBlock(bonusBlockUsage) 31 user.creditEco(amountDueInDollars, merchant) 32 commitTransaction();
33 I catch (Exception) {
34 rollbackTransaction();
return false;
1 }
2 [0073] ECO ADVANTAGE may also update 221 the merchant's account (e.g.
3 linking the merchant account to a record of the transaction, updating the merchant's BI
4 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:
6 Transaction transaction = Transaction.get(transactionId) 7 Merchant merchant = transaction.getMerchant() 8 User user = transaction.getUser() 9 long ecoUsage = transaction.getEcoUsage() long bonusBlockUsage = transaction.getBonusBlockUsage() 11 def historyTransaction = new HistoryTransaction(transaction, merchant, user, 12 ecoUsage, bonusBlockUsage) 13 historyTransaction.save() 14 [i)(1)74.] In some implementations, ECO ADVANTAGE may also monitor the status of various transactions, and may reverse, retry, and/or otherwise handle incomplete 16 transactions if found in the ECO ADVANTAGE database's records, based on 17 predetermined criteria.
18 [0075] FIGURE 2h shows a logic flow diagram illustrating performing a 19 transaction in example embodiments of the ECO ADVANTAGE. In some implementations, a user may initiate a transaction with a merchant 226 by providing 21 information such as the user's UID, the user's PIN, and/or the like. The merchant may 22 receive 227 the user's information, and may send it to ECO ADVANTAGE, which may be 23 prompted to use the information 228 to verify that the user is in ECO
ADVANTAGE. In 24 some implementations, ECO ADVANTAGE may query the ECO ADVANTAGE Database 229 to determine if there is a merchant and/or a user record for the entities involved. If 26 a merchant record is not found 230, the merchant may be prompted to enroll in ECO
27 ADVANTAGE (see FIGS. 4b-c). If a merchant record is found but there is no valid PoS
28 record 231 for the merchant, the merchant may be prompted to submit PoS
information 29 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 31 the user 232, ECO ADVANTAGE may prompt the merchant to allow the user to enroll in 32 ECO ADVANTAGE (see FIG. 3b).
1 [0 076] If a user record is found, ECO ADVANTAGE may retrieve from the user 2 record the user's eco balance 233, and may determine which ecos are marked as being 3 from the merchant involved in the transaction. As mentioned above, in some 4 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 6 any available bonus blocks, and may determine which may be used towards the 7 purchase. ECO ADVANTAGE may calculate 234 the number of ecos that may be applied 8 to the transaction in general, based on the merchant's eco schedule in its merchant 9 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 ii particular transaction, the remaining balance, and/or the like, to the merchant.
12 [o 0 7 7 ] After obtaining 235 this information, the merchant may prompt the user 13 to authorize the use of its ecos and/or bonus blocks, and to authorize charging the rest 14 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, 16 including authorizing the use of ecos, bonus blocks, and/or a debit/credit card, and may 17 use the merchant's PoS device to authorize the transaction. The merchant may send 237 18 the amount to be charged to the user to the merchant's acquirer for procurement. In 19 some implementations, the acquirer may receive 238 the transaction information, and may forward the pertinent information to the user's issuing bank 239 in order to 21 procure the funds. In other implementations, the acquirer may forward the information 22 to a different entity, such as another acquirer and/or a like entity who will directly 23 interact with the user's issuer. In some implementations, the acquirer may receive a 24 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, 26 who, if the transaction was unsuccessful 241, may forward 248 the notification of the 27 failed transaction to ECO ADVANTAGE 249 and the user 250, who may be prompted to 28 retry the transaction. In some implementations ECO ADVANTAGE may also mark all 29 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 31 of the successful transaction to ECO ADVANTAGE, which may create 243 a transaction 1 record for the transaction and store the record in the ECO ADVANTAGE
Database. ECO
2 ADVANTAGE may also update the merchant 245 and user 244 accounts records. In 3 some implementations, the merchant record may be updated with a link to the 4 transaction record, updated eco and usage schedule information, BI
information, and/or the like. In some implementations updating the merchant record may also involve 6 queuing later services, such as reconciliation, reporting, updating BI user information, 7 and/or the like. In some implementations, updating the user record may involve 8 updating the user record via deducting the ecos and/or bonus blocks used in the 9 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 ii may be a predetermined amount based at least partially on the transaction amount. In 12 some implementations ECO ADVANTAGE may forward 246 the notification of the 13 successful transaction to the user, who may receive the notification 247 and may store 14 the notification for future reference.
[0078] FIGURE 2c shows a data flow diagram illustrating performing an online 16 transaction in example embodiments of the ECO ADVANTAGE. In some 17 implementations, the user may choose products and/or services on a merchant website, 18 application, or SMS 252 to purchase via a personal computer, mobile device, merchant 19 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 21 user's transaction balance, the user's ID and login credentials for the merchant website 22 (e.g. username and password), atmospherics for the merchant, and/or the like. The 23 merchant may also send an eco request 253 to ECO ADVANTAGE. In some 24 implementations the eco request may take a form similar to the following:
POST /eco_request_message.php HTTP/1.1 26 Host: www. ECOADVANTAGE proces s . com 27 [0079] Content-Type: Application/XML
28 Content-Length: 788 29 <?XML version = "1.0" encoding = "UTF-8"?>
<ecoRequest>
31 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
32 <transactionId>635467</transactionId>
1 <transactionAmount>100.0</transactionAmount>
2 <merchantId>2033</merchantId>
3 <userId>102557952</userId>
4 <userIdType>SSN</userIdType >
<deviceId>961873f7b2e863415da6c5cdf4e90b2</deviceId>
6 <processingCode>683034</processingCode>
7 <origDocNumber></origDocNumber>
8 <nsu>572052</nsu>
9 <mcc>6432</mcc>
<merchantCapacity>27</merchantCapacity>
11 <minTransactionSize>10</minTransactionSize>
12 <maxTransactionSize>500</maxTransactionSize>
13 <transactionSize>1</transactionSize>
14 <productData>
<sku>6483953</sku>
16 <description>television</description>
17 </productData>
18 <atmospherics>
19 <dateTime>03/07/2013 03:39 PM</dateTime>
<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>
</atmospherics>
26 </ecoRequest>
27 [o 080] 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 255 to the ECO ADVANTAGE database 209, and may retrieve merchant and user data 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 212 in FIGURE 2a. In some implementations, the online merchant may generate a page 1 for the user which displays 259 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 ii 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
[0061] In some implementations, sensitive information (e.g. the user PIN
and/or 16 the like) may be encrypted. In some implementations, the ECO ADVANTAGE
server 17 may look 207 for the merchant and the user using the information obtained in the eco 18 request message, and may determine whether both entities are already enrolled in ECO
19 ADVANTAGE. In some implementations, Grails code for looking up the user and merchant data mat take a form similar to the following:
21 def merchant = Merchant.get(params.merchantId);
22 if (!merchant) {
23 log.warn("Merchant not found with value '${params.merchant}'");
24 return sendErroWexception.merchant.not.found');
1 elseif (!merchant.enabled 11 !merchant.confirmed) {
26 log.warn("Merchant inactive with value '${params.merchant}'");
27 return sendErroWexception.merchant.inactive');
28 1 elseif (merchant.accountLocked) {
29 log.warn("Merchant account locked with value W '${params.merchant}'");
31 return sendErroWexception.merchant.locked');
32 }
34 def schedule = merchant.getSchedules() 36 def user = User.get(params.userId);
1 if (!user) {
2 log.warn("User not found with value '${params.userId}'");
3 return sendErroWexception.user.not.found');
4 lelseif (!user.enabled 11 !user.confirmed) {
log.warn("User inactive with value '${params.userId}'");
6 return sendErroWexception.user.inactive');
7 1 elseif (user.accountLocked) {
8 log.warn("User account locked with value '${params.userId}'");
9 return sendErroWexception.user.locked');
11 [o o6 2] The server may access the ECO ADVANTAGE database 209, via querying 12 the database 208 for user and merchant records corresponding to the user and 13 merchant specified in eco request 206.
14 [0 063] In some implementations, ECO ADVANTAGE may query merchant 209c and user 209d tables of the ECO ADVANTAGE database in order to determine whether 16 such records exist. In some implementations, the ECO ADVANTAGE database may 17 return a user/merchant result 210 which may contain the found records pertaining to 18 the user and/or merchant involved in the transaction. In some implementations, the 19 user/merchant result 210 may take a form similar to the following:
merchant [
21 id: 2033, 22 name: "NY some salon inc.", 23 mail: "ny@somesalon.com", 24 document: "32135743134", dateCreated: "05/05/2012", 26 username: "salon", 27 password: encrypt("salon123"), 28 enabled: true, 29 accountLocked: false, W confirmed: true, 31 phoneNumber: 254145451, 32 contact: "some joseph", 33 openingTimes: "24h", 34 officialWebsite: "www.somesalon.com", 1 region: 254, 2 minConsumption: 10, 3 maxConsumption: 500, 4 bank: "225", bankAgency: "2541-9", 6 bankAccount: "123212121-3"
9 user [
M id: 1025, 11 name: "John Tavares", 12 mail: "john@somecompany.com", M document: "336525544", 14 dateCreated: "05/05/2012", M username: "john", M password: encrypt("john123"), 17 enabled: true, M accountLocked: false, 19 confirmed: true, 20 phoneNumber: "654258225"
21 ]
22 [0064] In some implementations, ECO ADVANTAGE may use these records to 23 determine 211 a number of calculations, such as the number of ecos the user may use 24 towards the transaction, the number and amount of bonus blocks the user may use 25 towards the transaction, and/or the like. In some implementations, this may be 26 determined based on the user check-in, based on the merchant's atmospherics, based on 27 a merchant's eco schedule, based on the merchants current available capacity, projected 28 available capacity, growth potential, and/or the like. In some implementations, Grails 29 code for determining said calculations may resemble the following:
a) /* def merchant = Merchant.get(params.merchantId); */
31 /* def schedule =
merchant.getSchedules() */
32 /* def user =
User.get(params.userId); */
34 def eco = Eco.getEcoFromCurrentSchedule(schedule) 1 Checkin checkin = user.getLastCheckin(transaction.merchantId) 2 if (checkin.isValidForTransaction(transaction.merchantId, Now(), transaction) {
4 eco = Eco.updateEcoScheduleWithCheckin(eco, checkin) }
6 checkin.markCheckingOut() 8 def saving = eco.saving 9 def minTransactionSize = eco.minTransactionSize def maxTransactionSize = eco.maxTransactionSize 11 def quantity = transaction.quantity 12 def realValue = transaction.transactionAmount 14 if ((realValue < minTransactionSize ) && (realValue >
maxTransactionSize )) {
error "Amount must be between ${minTransactionSize} and 17 ${maxTransactionSize}"
def amountOfEcos = calculateValueToPayWithEco(realValue, saving, 21 transaction) 22 def balanceForMerchant =
getBalanceForMerchant(transaction.user, 23 transaction.merchant) if (amountOfEcos > balanceForMerchant) {
26 error "User insufficient balance"
27 return 28 }
def amountDueInDollars = calculateValueToPayWithRealMoney(realValue, saving, transaction) 33 BonusBlock bonusBlock = user.getValidBonusBlock() 34 if (bonusBlock) {
if (amountDueInDollars > bonusBlock.value) {
36 if (bonusBlock.isEligibleFor(transaction) {
37 amountDueInDollars = amountDueInDollars -bonusBlock.value 38 }
/
2 public static BigDecimal calculateValueToPayWithEco(BigDecimal 3 realValue, Double saving, Integer quantity = 1){
4 if(!realValue 11 !saving 11 realValue == 0 11 saving == 0) {
5 return 0;
6 }
7 return Math.round((realValue * quantity) - (realValue.divide (1 +
8 (saving / 100), 2, RoundingMode.HALF_UP)) * quantity);
11 public static BigDecimal calculateValueToPayWithRealMoney(BigDecimal 12 realValue, Double saving, Transaction transaction) {
M if(!realValue 11 !saving 11 realValue == 0 11 saving == 0) {
14 return 0;
M }
M return (realValue * quantity) -17 calculateValueToPayWithEco(realValue, saving, transaction) M /
def getBalance() {
21 def result = 0;
22 def userBalance = Transaction.executeQuery( 23 "select sum(value * signal) as balance from 24 Transaction " +
"where user.id = :userId " +
26 " and date <= :date ", 27 [userId: userId, date: new Date()]);
29 return result;
}
32 def getBalanceForMerchant(User user, Merchant merchant) {
33 def result = 0;
34 def balance = this.getBalance();
def merchantAdjustBalance = UserMerchantAdjust.executeQuery( 36 "select sum(value) from UserMerchantAdjust " +
37 "where user.id = :userId " +
38 " and merchant.id = :merchantId " +
1 " and adjustDate <= :date ", 2 [userId: user.id, merchantId: merchant.id, date:
new 3 Date()])?.first();
if (!merchantAdjustBalance) {
6 merchantAdjustBalance = 0;
7 }
9 return balance + merchantAdjustBalance;
}
11 [0065] In some implementations, the merchant's eco schedule may be a schedule 12 that outlines the percentage of a given transaction at the merchant that may be paid by 13 the user with ecos. In some implementations this schedule may be based on information 14 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 16 date, total ecos donated by period or to date, total ecos donated and used by period or to 17 date, number of active friends by period or to date, some factor thereof, and/or the like 18 (see FIGS. 5a-d for more information).
19 [ o o 6 6] In some implementations, the ECO ADVANTAGE server may send this information to the merchant via an eco response 212. In some implementations an 21 XML-encoded eco response may take a form similar to the following:
22 POST /eco_request_message.php HTTP/1.1 23 Host: www.ECOADVANTAGEprocess.com 24 Content-Type: Application/XML
Content-Length: 788 26 <?XML version = "1.0" encoding = "UTF-8"?>
27 <ecoResponse>
28 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
29 <transactionId>635467</transactionId>
<transactionAmount>100.0</transactionAmount>
31 <merchantId>2033</merchantId>
32 <ecoSaving>20%</ecoSaving>
33 <userEcoBalance>1091</userEcoBalance>
34 <amountDueInDollars>77.0</amountDueInDollars>
1 <userEcoUsage>23</userEcoUsage>
2 <userBonusBlockUsage>0</userBonusBlockUsage>
3 <atmospherics>
4 <dateTime>03/07/2013 03:39 PM</dateTime>
<seating_pref>n_smoking</seating_pref>
6 <party_size>2</party_size>
7 <reserv_date>02/28/2013 03:39 PM</reserv_date>
8 <weather>70F, sunny</weather>
9 <product_pref>steak</product_pref>
</atmospherics>
11 <ecoResponse>
12 [0067] In some implementations, the merchant may use the information obtained 13 to display 213 the updated transaction information to the user, which may include the 14 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 16 applied, and/or the like. In some implementations, the merchant may use the 17 information may include the user's bonus block balance, the bonus blocks that may be 18 used in the transaction, the transaction balance if bonus blocks are applied, the user's 19 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 21 may confirm the use of bonus blocks independently. In some implementations the user 22 may confirm via pressing a button and/or the like on a PoS terminal at the merchant, or 23 via a mobile application, SMS, a website, NFC/RFID and/or like proximity tags, UTP
24 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 26 processing of the transaction. In some implementations, the acquirer may directly 27 procure funds for the merchant; in other implementations, the acquirer may be an 28 intermediate between the merchant and another acquiring entity (e.g., another 29 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 31 following:
32 POST /payment_request_message.php HTTP/1.1 33 Host: www.ECOADVANTAGEprocess.com 1 Content-Type: Application/XML
2 Content-Length: 788 3 <?XML version = "1.0" encoding = "UTF-8"?>
4 <paymentRequest>
<UID>da6c5cdf4e90b2961873f7b2e863415</UID>
6 <transactionId>635467</transactionId>
7 <merchantId>2033</merchantId>
8 <posId>4088</posId>
9 <amountDueInDollars>77.0</amountDueInDollars>
<dateTime>03/07/2013 03:39 PM</dateTime>
11 <userCard>3214 3578 3568 3542</userCard>
12 </paymentRequest>
13 [0068] In some implementations, the acquirer may only receive the transaction 14 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 16 the transaction request in order to generate messages to the various payment entities 17 who may be involved in the procurement of the user's payment 216. For example, the 18 acquirer may interact with the user's issuing bank, the merchant's bank account, one or 19 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 21 institution, payment gateway, online payment service (e.g., PayPal), Electronic Funds 22 Transfer Network (e.g., Swift), and/or the like. In some implementations, Grails code 23 for processing the transaction may take a form similar to the following:
24 Card card = Card.get(userCard);
Merchant merchant = Merchant.get(merchantId) 26 Try{
27 beginTransaction() 28 card.debit(amountDueInDollars) 29 merchant.credit(amountDueInDollars) commitTransaction();
31 return true;
32 I catch (Exception) {
33 rollbackTransaction();
34 return false;
}
1 [0 069] 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:
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"?>
<paymentConfirmation>
11 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
12 <transactionId>635467</transactionId>
13 <merchantId>2033</merchantId>
14 <posId>4088</posId>
<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>
<approved>true</approved>
21 </paymentConfirmation>
22 [0070] 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
device. In some implementations the receipt may take a form similar to the following:
26 DOCUMENT: NNN.NNN.NNN-NN ID EAS: IIIIII
27 ORIGINAL VALUE: VVV.VVV,VV
28 BONUS BLOCK VALUE: VVV.VVV,VV
29 ECONOMY: EEE.EEE,EE
VALUE PPPPPPPPPP: TTT.TTT,TT
32 ECO BALANCE: BBB.BBB,BB
1 [0 0 71] The merchant may also forward 219 the transaction confirmation to ECO
2 ADVANTAGE. In some implementations transaction confirmation 219 may take a form 3 similar to the following:
4 <transactionConfirmation>
5 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
6 <transactionId>635467</transactionId>
7 <merchantId>2033</merchantId>
8 <posId>4088</posId>
9 <amounInDollars>77.0</amountDueInDollars>
10 <debitCreditAmount>77.0</debitCreditAmount>
11 <cashAmount>0.0</cashAmount>
12 <dateTime>03/07/2013 03:40 PM</dateTime>
M <approyed>true</approyed>
14 </transactionConfirmation>
M [01072] ECO ADVANTAGE may use the confirmation to update 220 the user's 16 account (e.g. by deducting the ecos used in the transaction, by adding to the user 17 account new ecos identified as being from the merchant, and/or the like).
In some 18 implementations Grails code for updating the user's account may take a form similar to 19 the following:
20 Transaction transaction = Transaction.get(transactionId) 21 User user = transaction.getUser() 22 Merchant merchant = transaction.getMerchant() 23 long ecoUsage = transaction.getEcoUsage() 24 long bonusBlockUsage = transaction.getBonusBlockUsage() long amountDueInDollars = transaction.getAmountDueInDollars() 27 Try{
28 beginTransaction() 29 user.debitEco(ecoUsage) user.debitBonusBlock(bonusBlockUsage) 31 user.creditEco(amountDueInDollars, merchant) 32 commitTransaction();
33 I catch (Exception) {
34 rollbackTransaction();
return false;
1 }
2 [0073] ECO ADVANTAGE may also update 221 the merchant's account (e.g.
3 linking the merchant account to a record of the transaction, updating the merchant's BI
4 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:
6 Transaction transaction = Transaction.get(transactionId) 7 Merchant merchant = transaction.getMerchant() 8 User user = transaction.getUser() 9 long ecoUsage = transaction.getEcoUsage() long bonusBlockUsage = transaction.getBonusBlockUsage() 11 def historyTransaction = new HistoryTransaction(transaction, merchant, user, 12 ecoUsage, bonusBlockUsage) 13 historyTransaction.save() 14 [i)(1)74.] In some implementations, ECO ADVANTAGE may also monitor the status of various transactions, and may reverse, retry, and/or otherwise handle incomplete 16 transactions if found in the ECO ADVANTAGE database's records, based on 17 predetermined criteria.
18 [0075] FIGURE 2h shows a logic flow diagram illustrating performing a 19 transaction in example embodiments of the ECO ADVANTAGE. In some implementations, a user may initiate a transaction with a merchant 226 by providing 21 information such as the user's UID, the user's PIN, and/or the like. The merchant may 22 receive 227 the user's information, and may send it to ECO ADVANTAGE, which may be 23 prompted to use the information 228 to verify that the user is in ECO
ADVANTAGE. In 24 some implementations, ECO ADVANTAGE may query the ECO ADVANTAGE Database 229 to determine if there is a merchant and/or a user record for the entities involved. If 26 a merchant record is not found 230, the merchant may be prompted to enroll in ECO
27 ADVANTAGE (see FIGS. 4b-c). If a merchant record is found but there is no valid PoS
28 record 231 for the merchant, the merchant may be prompted to submit PoS
information 29 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 31 the user 232, ECO ADVANTAGE may prompt the merchant to allow the user to enroll in 32 ECO ADVANTAGE (see FIG. 3b).
1 [0 076] If a user record is found, ECO ADVANTAGE may retrieve from the user 2 record the user's eco balance 233, and may determine which ecos are marked as being 3 from the merchant involved in the transaction. As mentioned above, in some 4 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 6 any available bonus blocks, and may determine which may be used towards the 7 purchase. ECO ADVANTAGE may calculate 234 the number of ecos that may be applied 8 to the transaction in general, based on the merchant's eco schedule in its merchant 9 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 ii particular transaction, the remaining balance, and/or the like, to the merchant.
12 [o 0 7 7 ] After obtaining 235 this information, the merchant may prompt the user 13 to authorize the use of its ecos and/or bonus blocks, and to authorize charging the rest 14 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, 16 including authorizing the use of ecos, bonus blocks, and/or a debit/credit card, and may 17 use the merchant's PoS device to authorize the transaction. The merchant may send 237 18 the amount to be charged to the user to the merchant's acquirer for procurement. In 19 some implementations, the acquirer may receive 238 the transaction information, and may forward the pertinent information to the user's issuing bank 239 in order to 21 procure the funds. In other implementations, the acquirer may forward the information 22 to a different entity, such as another acquirer and/or a like entity who will directly 23 interact with the user's issuer. In some implementations, the acquirer may receive a 24 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, 26 who, if the transaction was unsuccessful 241, may forward 248 the notification of the 27 failed transaction to ECO ADVANTAGE 249 and the user 250, who may be prompted to 28 retry the transaction. In some implementations ECO ADVANTAGE may also mark all 29 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 31 of the successful transaction to ECO ADVANTAGE, which may create 243 a transaction 1 record for the transaction and store the record in the ECO ADVANTAGE
Database. ECO
2 ADVANTAGE may also update the merchant 245 and user 244 accounts records. In 3 some implementations, the merchant record may be updated with a link to the 4 transaction record, updated eco and usage schedule information, BI
information, and/or the like. In some implementations updating the merchant record may also involve 6 queuing later services, such as reconciliation, reporting, updating BI user information, 7 and/or the like. In some implementations, updating the user record may involve 8 updating the user record via deducting the ecos and/or bonus blocks used in the 9 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 ii may be a predetermined amount based at least partially on the transaction amount. In 12 some implementations ECO ADVANTAGE may forward 246 the notification of the 13 successful transaction to the user, who may receive the notification 247 and may store 14 the notification for future reference.
[0078] FIGURE 2c shows a data flow diagram illustrating performing an online 16 transaction in example embodiments of the ECO ADVANTAGE. In some 17 implementations, the user may choose products and/or services on a merchant website, 18 application, or SMS 252 to purchase via a personal computer, mobile device, merchant 19 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 21 user's transaction balance, the user's ID and login credentials for the merchant website 22 (e.g. username and password), atmospherics for the merchant, and/or the like. The 23 merchant may also send an eco request 253 to ECO ADVANTAGE. In some 24 implementations the eco request may take a form similar to the following:
POST /eco_request_message.php HTTP/1.1 26 Host: www. ECOADVANTAGE proces s . com 27 [0079] Content-Type: Application/XML
28 Content-Length: 788 29 <?XML version = "1.0" encoding = "UTF-8"?>
<ecoRequest>
31 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
32 <transactionId>635467</transactionId>
1 <transactionAmount>100.0</transactionAmount>
2 <merchantId>2033</merchantId>
3 <userId>102557952</userId>
4 <userIdType>SSN</userIdType >
<deviceId>961873f7b2e863415da6c5cdf4e90b2</deviceId>
6 <processingCode>683034</processingCode>
7 <origDocNumber></origDocNumber>
8 <nsu>572052</nsu>
9 <mcc>6432</mcc>
<merchantCapacity>27</merchantCapacity>
11 <minTransactionSize>10</minTransactionSize>
12 <maxTransactionSize>500</maxTransactionSize>
13 <transactionSize>1</transactionSize>
14 <productData>
<sku>6483953</sku>
16 <description>television</description>
17 </productData>
18 <atmospherics>
19 <dateTime>03/07/2013 03:39 PM</dateTime>
<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>
</atmospherics>
26 </ecoRequest>
27 [o 080] 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 255 to the ECO ADVANTAGE database 209, and may retrieve merchant and user data 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 212 in FIGURE 2a. In some implementations, the online merchant may generate a page 1 for the user which displays 259 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 ii 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
18 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 298 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 273 to verify that the user is in ECO
ADVANTAGE. In 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 1 a merchant record is not found 275, the merchant may be prompted to enroll in ECO
2 ADVANTAGE (see FIGS. 4b-c). If a merchant record is found but there is no valid PoS
3 record 279 for the merchant, the merchant may be prompted to submit PoS
information 4 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 6 the user 277, ECO ADVANTAGE may prompt the merchant to allow the user to enroll in 7 ECO ADVANTAGE (see FIG. 3b).
8 [ o o 8 3 ] If a user record is found, ECO ADVANTAGE may retrieve from the user 9 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 11 implementations, ecos marked as being from the merchant involved may not be usable 12 for the transaction. In addition, ECO ADVANTAGE may retrieve from the user record 13 any available bonus blocks, and may determine which may be used towards the 14 purchase. ECO ADVANTAGE may calculate 279 the number of ecos that may be applied to the transaction in general, based on the merchant's eco schedule in its merchant 16 record, and/or the like. ECO ADVANTAGE may generate and send 280 the user's eco 17 balance, the merchant's eco schedule, the amount of ecos that the user may use towards 18 the particular transaction, the remaining balance, and/or the like, to the merchant.
19 [o 084] 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 21 credit/debit card stored in ECO ADVANTAGE, a new credit/debit card, authorize paying 22 the balance in cash, and/or the like, via generating a transaction confirmation page 282 23 which contains the user's transaction information (e.g. current eco and/or bonus block 24 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, 26 and/or a debit/credit card via the confirmation page. The merchant may send 284 the 27 amount to be charged to the user to the merchant's acquirer for procurement. In some 28 implementations, the acquirer may receive 285 the transaction information, and may 29 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 31 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, 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 ECO
ADVANTAGE Database. ECO ADVANTAGE may also update the merchant 292 and ii user 291 accounts records. In some implementations, the merchant record may be 12 updated with a link to the transaction record, updated eco schedule information, BI
13 information, and/or the like. In some implementations, updating the user record may 14 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 16 merchant), and/or the like. In some implementations, the amount of new ecos received 17 may be a predetermined amount based at least partially on the transaction amount. In 18 some implementations ECO ADVANTAGE may forward 293 the notification of the 19 successful transaction to the user, who may receive the notification 294 and may store the notification for future reference.
21 [0085] FIGURE 3a shows a data flow diagram illustrating performing an online 22 transaction without an ECO ADVANTAGE account in example embodiments of the ECO
23 ADVANTAGE. In some implementations, a user 301 may initiate 302 a transaction with 24 a merchant 303 via providing transaction information to the merchant, and a unique user PIN and/or identifier (e.g. a social security number, phone number, and/or the 26 like). In some implementations, the merchant may send an eco request 304 to ECO
27 ADVANTAGE 305 (which may take a form similar to eco request 206), indicating that a 28 person at the merchant would like to initiate a transaction. In some implementations, 29 sensitive information (e.g. the user PIN and/or the like) may be encrypted.
In some implementations eco request 304 may be similar to eco request 206. ECO
ADVANTAGE
31 may look up 306 the merchant and the user in the ECO ADVANTAGE database in order 1 to determine whether either entity is in the database, via send a user and merchant 2 information query 307 to the user 308d and merchant 308c tables of the ECO
3 ADVANTAGE database 308. In some implementations a PHP-encoded user and 4 merchant query 307 may take a form similar user/merchant query 208.
[o 086] In some implementations, the ECO ADVANTAGE database may send a 6 user and merchant response '309 to ECO ADVANTAGE indicating whether the records 7 were successfully found, and the information requested. In some implementations, the 8 user and merchant response '309 may take a form similar to the following:
9 merchant [
M id: 2033, 11 name: "NY some salon inc.", 12 mail: "ny@somesalon.com", M document: "32135743134", 14 dateCreated: "05/05/2012", M username: "salon", M password: "salon123", 17 enabled: true, M accountLocked: false, 19 confirmed: true, 20 phoneNumber: 254145451, 21 contact: "some joseph", 22 openingTimes: "24h", 23 officialWebsite: "www.somesalon.com", 24 region: 254, 25 minConsumption: 1, 26 maxConsumption: 5, 27 bank: "225", 28 bankAgency: "2541-9", 29 bankAccount: "123212121-3"
ADVANTAGE. In 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 1 a merchant record is not found 275, the merchant may be prompted to enroll in ECO
2 ADVANTAGE (see FIGS. 4b-c). If a merchant record is found but there is no valid PoS
3 record 279 for the merchant, the merchant may be prompted to submit PoS
information 4 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 6 the user 277, ECO ADVANTAGE may prompt the merchant to allow the user to enroll in 7 ECO ADVANTAGE (see FIG. 3b).
8 [ o o 8 3 ] If a user record is found, ECO ADVANTAGE may retrieve from the user 9 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 11 implementations, ecos marked as being from the merchant involved may not be usable 12 for the transaction. In addition, ECO ADVANTAGE may retrieve from the user record 13 any available bonus blocks, and may determine which may be used towards the 14 purchase. ECO ADVANTAGE may calculate 279 the number of ecos that may be applied to the transaction in general, based on the merchant's eco schedule in its merchant 16 record, and/or the like. ECO ADVANTAGE may generate and send 280 the user's eco 17 balance, the merchant's eco schedule, the amount of ecos that the user may use towards 18 the particular transaction, the remaining balance, and/or the like, to the merchant.
19 [o 084] 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 21 credit/debit card stored in ECO ADVANTAGE, a new credit/debit card, authorize paying 22 the balance in cash, and/or the like, via generating a transaction confirmation page 282 23 which contains the user's transaction information (e.g. current eco and/or bonus block 24 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, 26 and/or a debit/credit card via the confirmation page. The merchant may send 284 the 27 amount to be charged to the user to the merchant's acquirer for procurement. In some 28 implementations, the acquirer may receive 285 the transaction information, and may 29 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 31 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, 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 ECO
ADVANTAGE Database. ECO ADVANTAGE may also update the merchant 292 and ii user 291 accounts records. In some implementations, the merchant record may be 12 updated with a link to the transaction record, updated eco schedule information, BI
13 information, and/or the like. In some implementations, updating the user record may 14 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 16 merchant), and/or the like. In some implementations, the amount of new ecos received 17 may be a predetermined amount based at least partially on the transaction amount. In 18 some implementations ECO ADVANTAGE may forward 293 the notification of the 19 successful transaction to the user, who may receive the notification 294 and may store the notification for future reference.
21 [0085] FIGURE 3a shows a data flow diagram illustrating performing an online 22 transaction without an ECO ADVANTAGE account in example embodiments of the ECO
23 ADVANTAGE. In some implementations, a user 301 may initiate 302 a transaction with 24 a merchant 303 via providing transaction information to the merchant, and a unique user PIN and/or identifier (e.g. a social security number, phone number, and/or the 26 like). In some implementations, the merchant may send an eco request 304 to ECO
27 ADVANTAGE 305 (which may take a form similar to eco request 206), indicating that a 28 person at the merchant would like to initiate a transaction. In some implementations, 29 sensitive information (e.g. the user PIN and/or the like) may be encrypted.
In some implementations eco request 304 may be similar to eco request 206. ECO
ADVANTAGE
31 may look up 306 the merchant and the user in the ECO ADVANTAGE database in order 1 to determine whether either entity is in the database, via send a user and merchant 2 information query 307 to the user 308d and merchant 308c tables of the ECO
3 ADVANTAGE database 308. In some implementations a PHP-encoded user and 4 merchant query 307 may take a form similar user/merchant query 208.
[o 086] In some implementations, the ECO ADVANTAGE database may send a 6 user and merchant response '309 to ECO ADVANTAGE indicating whether the records 7 were successfully found, and the information requested. In some implementations, the 8 user and merchant response '309 may take a form similar to the following:
9 merchant [
M id: 2033, 11 name: "NY some salon inc.", 12 mail: "ny@somesalon.com", M document: "32135743134", 14 dateCreated: "05/05/2012", M username: "salon", M password: "salon123", 17 enabled: true, M accountLocked: false, 19 confirmed: true, 20 phoneNumber: 254145451, 21 contact: "some joseph", 22 openingTimes: "24h", 23 officialWebsite: "www.somesalon.com", 24 region: 254, 25 minConsumption: 1, 26 maxConsumption: 5, 27 bank: "225", 28 bankAgency: "2541-9", 29 bankAccount: "123212121-3"
30 1
31
32
33 user [
34 1 1 [0 0 87] 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 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, document: userdocument, 11 userDocumentType: "SSN", 12 initialBalance: receivedEcos 13 dateCreated: <today>, 14 ) 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 Host: www.ECOADVANTAGEprocess.com 21 Content-Type: Application/XML
22 Content-Length: 788 23<?XML version = "1.0" encoding = "UTF-8"?>
24<ecoResponse>
<authorizationCode>109654324</authorizationCode>
26 <ecosCouldBeUsed>23</ecosCouldBeUsed>
27 <receivedEcos>77</receivedEcos>
28 <ecoSaving>20%</ecoSaving>
29<ecoResponse>
[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: VVVVVVVVVV,VV
8 ECOS RECEIVED: VVVVVVVVVV,VV
9AMOUNT PAYABLE: VVVVVVVVVV,VV
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 314, 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 <userId>102557952</userId>
26 <userIdType>SSN</userIdType >
27 <userFirstName>PeterquserFirstName>
28 <userLastName>TavaresquserLastName>
29 <userLastName>TavaresquserLastName>
30 <email>petertavares@somecompany.com</email>
31 /*<streetAddress>Tavares Street, 44</streetAddress>
32 <paymentMethod>debitcard, creditcard</paymentMethod>
33 <userInterests>eletronics, restaurants</userInterests>
34 <userDevices>iphone, tablet</userDevices>*/
1 </applicationRequest>
2 [0091] In some implementations, the user's application information in the 3 application request may be used to instantiate 316 a user account on ECO
4 ADVANTAGE. In some implementations Grails code for instantiating the user account may take a form similar to the following:
6 TemporaryUser tempUser =
TemporaryUser.getByAuthorizationCode(authorizationCode);
7 if (tempUser) {
8 def user = new User();
9 user.document = tempUser.document;
user.name = applicationRequest.userFirstName + " " +
11 applicationRequest.userLastName;
12 user.mail = applicationRequest.email;
13 user.password = applicationRequest.password;
14 user.address = applicationRequest.streetAddress;
user.paymentMethod = applicationRequest.paymentMethod;
16 user.interests = applicationRequest.userInterests;
17 user.devices = applicationRequest.devices;
18 user.enabled: true;
19 user.accountLocked: false;
user.confirmed: false;
21 user.save() 23 user.creditEco(tempUser.receivedEcos) 24 1 else {
sendError("authorizationcode.not.found") 26 }
27 [009 2] ECO ADVANTAGE may also credit to the user's new account the number 28 of ecos specified in the user's authorization code/temp ID. ECO ADVANTAGE
may send 29 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 31 implementations, an XML-encoded status of enrollment message may take a form 32 similar to the following:
33 POST /enrollment_message.php HTTP/1.1 34 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>
<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
ADVANTAGE. In some implementations, ECO ADVANTAGE may store 321 a ii 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 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 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 329 the application via sending it in a message to ECO
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 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 in 1 order to notify other entities in the process that the enrollment was successful, to 2 provide the user's current eco balance, and/or the like. In some implementations ECO
3 ADVANTAGE may send this status notification to the merchant 335, who may forward 4 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, 6 and/or the like. In some implementations, if the user chooses not to create an account, 7 ECO ADVANTAGE may deactivate the temporary user record 327 in the ECO
8 ADVANTAGE database. In some implementations, the user may be able to view his 9 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 ii example embodiments of the ECO ADVANTAGE. In some implementations, the 12 merchant 401 may wish to enroll in ECO ADVANTAGE via sending an enrollment 13 request 402 to ECO ADVANTAGE with an indication that the merchant would like to 14 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 16 to those in FIGURES 17a or 1713, depending upon whether the enrollment form is 17 electronic or physical. In some implementations, the merchant may fill out the 18 enrollment request form and send it back to ECO ADVANTAGE via a request form 19 message 405. In some implementations the request form message 405 may be an XML-encoded message similar to the following:
21 POST /request_form_message.php HTTP/1.1 22 Host: www.ECOADVANTAGEprocess.com 23 Content-Type: Application/XML
24 Content-Length: 788 <?XML version = "1.0" encoding = "UTF-8"?>
26 <merchantApplicationMessage>
27 <Document>02545225441000188</Document>
28 <MerchantName>Italian Restaurant</MerchantName>
29 <StreetAddress>16 avenue, 20</StreetAddress>
<BankInformation>
31 <BankNumber>254</BankNumber>
32 <Agency>3652-8</Agency>
33 <Account>2525414-5</Account>
1 </BankInformation>
2 <Biography>
3 The Italian restaurant opened 10 years ago 4 and since then has been serving Italian food every day.
</Biography>
6 <Links>
7 <Link>http://wwww.italian-restaurant.com</Link>
8 </Links>
9 <PosID>5467754</PosID>
<List0fPeriods>
11 <Period type="slow"
12 <DayRange>Mon, Tue, Wed</DayRange>
13 <TimeRange>18PM-22PM</TimeRange>
14 </Period>
</List0fPeriods>
16 <Capacity>150</Capacity>
17 <atmospherics>
18 <dateTime>03/07/2013 03:39 PM</dateTime>
19 </atmospherics>
</merchantApplicationMessage>
21 [01095] In some implementations, ECO ADVANTAGE may wish to perform a 22 check (e.g. financial, quality, and/or the like) 406 on the merchant before enrolling the 23 merchant in the program, and may send a check request 407 to a merchant agent 408 in 24 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 26 may collect, aggregate, and analyze various types of information about various 27 merchants both inside and outside of ECO ADVANTAGE. In some implementations, the 28 check request message 407 may be an XML-encoded message may include check 29 parameters for the merchant to use during aggregation (e.g. merchant to search for, sources to search, and/or the like).
31 [0096] In some implementations, the merchant agent may aggregate financial 32 information, quality information, background information, and/or like information 33 about the merchant 409, and may return this information to ECO ADVANTAGE
via a 34 merchant check response 410, which may include the merchant check data.
1 [0 0 9 7] In some implementations, ECO ADVANTAGE, after receiving the 2 merchant check, may generate a merchant account record 411 for the merchant if the 3 merchant has met a pre-specified threshold of quality and is approved for ECO
4 ADVANTAGE, and may enroll the merchant in the program. In some implementations, 5 Grails code for creating the merchant account may take a form similar to the following:
6 MerchantRequest merchantRequest =
MerchantRequest.getByDocument(XMLmerchant.document) 7 if (request) {
8 if (request.qualityCheckPending == false 9 && request.financialCheckPending == false M && request.approved == true) {
11 Merchant merchant = new Merchant(merchantRequest.*) 12 merchant.enabled = true;
M merchant.accountLocked = false;
14 merchant.confirmed = false;
M merchant.login = XMLmerchant.email;
M merchant.password = VoucherUtil.generatePassword() 17 merchant.save() M foreach(period in Merchant.List0fPeriod) {
19 new MerchantPeriod(merchant, period).save() 21 request.enrollmentPending = false;
22 request.save() 24 1 else {
25 sendError("merchantrequest.not.found") 26 }
27 [0098] ECO ADVANTAGE may instantiate 412 the merchant account record, 28 merchant eco schedule, and/or the like via storing the information in the schedules 41313 29 and merchant 413d tables of the ECO ADVANTAGE database 413. In some 30 implementations, ECO ADVANTAGE may also update the regions, categories, and/or 31 the like in ECO ADVANTAGE via updating the categories 413a and regions 413c tables 32 of the ECO ADVANTAGE database.
33 [009 9] In some implementations, ECO ADVANTAGE may send a notification 34 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
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 PoS configuration settings request 415 may be an XML-encoded message that may ii 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 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, 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 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.
[00101] FIGURES 4b-c show logic flow diagrams illustrating enrolling a merchant 31 in example embodiments of the ECO ADVANTAGE. In some implementations, the 1 merchant may submit 424 a request to enroll in ECO ADVANTAGE to ECO
2 ADVANTAGE, who may receive the request and generate 425 a template or customized 3 enrollment form for the merchant. In some implementations, ECO ADVANTAGE may 4 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 6 include identification information, merchant sales information, product information, 7 merchant payment information, atmospherics, industry information, and/or a variety of 8 other types of merchant-related data. In some implementations, ECO ADVANTAGE
9 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 11 implementations, once ECO ADVANTAGE has sent 430 the query to the merchant, the 12 merchant may receive the merchant's information 431 and may begin to aggregate 13 information 432 regarding the merchant, such as financial, quality, and/or like data. In 14 some implementations, merchant information may be aggregated from accredited financial review organizations, peer review services, client review services, and/or the 16 like. In some implementations, the merchant agent may generate 433 a background 17 check based on the aggregated data, and may send 434 the background check based on 18 the aggregated data. ECO ADVANTAGE May receive 435 the background check for the 19 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 21 score, has a low client review score on a number of prominent social review websites, 22 and/or the like). If the merchant meets a number of pre-specified criteria (e.g. credit 23 thresholds, peer review thresholds, and/or the like) 437, ECO ADVANTAGE may 24 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 26 an initial eco schedule for the merchant using the merchant's provided data (see 27 FIGURES 5a-b for further details). In some implementations the eco schedule may be 28 used to determine how many ecos a consumer may use in a transaction at the merchant 29 at particular times of the day, particular days of the week, and/or the like.
[o 0 1 0 2 ] As shown in FIGURE 4c, ECO ADVANTAGE may also generate a 31 confirmation notification 442 indicating that the merchant has been successfully 1 enrolled, and may end 443 said confirmation to the merchant. Once the merchant 2 received 444 the confirmation, the merchant may generate a survey 445 of the 3 merchant's current PoS infrastructure, resources, configurations, settings, and/or the 4 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 6 of Sales, place of business, or Point of Sales device) configurations, settings, 7 infrastructure, and/or the like 448 based on the merchant's submitted infrastructure 8 and the infrastructure and/or configuration needs of ECO ADVANTAGE. If ECO
9 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, ii configuration tutorials, and/or the like, along with promotions for the new settings 12 and/or infrastructure, and may generate a new PoS record in the ECO
ADVANTAGE
13 database containing the determined configuration, settings, and/or the like and a 14 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, 16 promotions, and/or the like, to the merchant 456 for the merchant's records. The 17 merchant may also forward 457 the settings to the merchant's acquirer, which may 18 receive 458 the new PoS configuration and/or the like and may instantiate 459 a new 19 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 21 send a notification 461 to ECO ADVANTAGE when the PoS is successfully configured.
22 ECO ADVANTAGE may receive 462 the notification and store it for future reference in 23 the PoS and/or merchant record.
24 [0 0 1 0 3] 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 26 send a notification to the merchant 439 indicating that the merchant was rejected by 27 ECO ADVANTAGE, but is encouraged to try to enroll again at a later date. In some 28 implementations the notification may also include reasons for rejection, including citing 29 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 31 send a failure message 450 to the merchant indicating that ECO ADVANTAGE
could not 1 generate a suitable configuration for the merchant given the information provided, and 2 may also indicate what major changes the merchant could make to its existing 3 infrastructure and/or the like before ECO ADVANTAGE can determine a suitable 4 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
6 ADVANTAGE indicating the changes in the PoS infrastructure, configuration, and/or 7 the like.
8 [ o 0104] FIGURE 5a shows a data flow diagram illustrating creating and updating 9 regions and categories in example embodiments of the ECO ADVANTAGE. In some implementations, a merchant agent 501 may determine a region 502 in ECO
11 ADVANTAGE to analyze. In some implementations, the region may be based on 12 geographic, cultural, industrial, and/or like constraints. The merchant may search for 13 merchants in each region to obtain data from, and may obtain aggregate data 505 from 14 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 16 aggregate information obtained about each merchant to ECO ADVANTAGE via a 17 region/merchant survey message 506. In some implementations, an XML-encoded 18 region/merchant survey message 506 may be an XML-encoded message and may take a 19 form similar to the following:
POST /region_merchant_survey_message.php HTTP/1.1 21 Host: www.ECOADVANTAGEprocess.com 22 Content-Type: Application/XML
23 Content-Length: 788 24<?XML version = "1.0" encoding = "UTF-8"?>
<regionMerchantSurvey>
26 <surveyId>11254878</surveyId>
27 <surveyDateTime>03/07/2013 03:39 PM</surveyDateTime>
28 <merchantSurveyList>
29 <merchantSurvey>
W <merchantSurveySeqNumber>1</merchantSurveySeqNumber >
31 <merchantId>2033</merchantId>
32 <MerchantDocument>021451125488</MerchantDocument>
33 <MerchantAggregateSales></MerchantAggregateSales>
34 <AverageConsumerSpent>84.5</AverageConsumerSpent>
<ProductServicePurchase></ProductServicePurchase>
36 <List0fPeriods>
37 <Period type="idle"
1 <DayRange>Mon, Tue, Wed, Thu, Fri</DayRange>
2 <TimeRange>03PM-06PM</TimeRange>
3 </Period>
4 <Period type="slow"
5 <DayRange>Mon, Tue, Wed</DayRange>
6 <TimeRange>06PM-10PM</TimeRange>
7 </Period>
8 <Period type="peak"
9 <DayRange>Thu, Fri</DayRange>
10 <TimeRange>11AM-03PM,06PM-10PM</TimeRange>
11 </Period>
12 </List0fPeriods>
13 <GPSCoordinates>1.65254125411,-5.698564545</GPSCoordinates>
14 <productData>
15 <sku>56673953</sku><description>hair cut</description>
16 </productData>
17 <RetailSearches></RetailSearches>
18 <MarketDataAggregates></MarketDataAggregates>
19 <CensusData></CensusData>
20 <Photo></Photo>
21 <Video></Video>
22 <Description></Description>
23 <MerchantSite>http://www.italian-restaurant.com</MerchantSite>
24 <Email>admin@italian-restaurant.com</Email>
<SocialNetworkinsPage>www.facebook.com/ItalianRestaurant</SocialN
26 etworkinsPage>
27 <MerchantContactInformation></MerchantContactInformation>
28 </merchantSurvey>
29 <merchantSurvey>
30 <merchantSurveySeqNumber>2</merchantSurveySeqNumber >
31 <merchantId></merchantId>
32 <MerchantDocument>021451125475</MerchantDocument>
33 ¨.
34 </merchantSurvey>
7 TemporaryUser tempUser = new TemporaryUser( 8 authorizationCode: <auto-increment>, 9 uniqueNumber: userPersonalUniqueNumber, document: userdocument, 11 userDocumentType: "SSN", 12 initialBalance: receivedEcos 13 dateCreated: <today>, 14 ) 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 Host: www.ECOADVANTAGEprocess.com 21 Content-Type: Application/XML
22 Content-Length: 788 23<?XML version = "1.0" encoding = "UTF-8"?>
24<ecoResponse>
<authorizationCode>109654324</authorizationCode>
26 <ecosCouldBeUsed>23</ecosCouldBeUsed>
27 <receivedEcos>77</receivedEcos>
28 <ecoSaving>20%</ecoSaving>
29<ecoResponse>
[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: VVVVVVVVVV,VV
8 ECOS RECEIVED: VVVVVVVVVV,VV
9AMOUNT PAYABLE: VVVVVVVVVV,VV
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 314, 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 <userId>102557952</userId>
26 <userIdType>SSN</userIdType >
27 <userFirstName>PeterquserFirstName>
28 <userLastName>TavaresquserLastName>
29 <userLastName>TavaresquserLastName>
30 <email>petertavares@somecompany.com</email>
31 /*<streetAddress>Tavares Street, 44</streetAddress>
32 <paymentMethod>debitcard, creditcard</paymentMethod>
33 <userInterests>eletronics, restaurants</userInterests>
34 <userDevices>iphone, tablet</userDevices>*/
1 </applicationRequest>
2 [0091] In some implementations, the user's application information in the 3 application request may be used to instantiate 316 a user account on ECO
4 ADVANTAGE. In some implementations Grails code for instantiating the user account may take a form similar to the following:
6 TemporaryUser tempUser =
TemporaryUser.getByAuthorizationCode(authorizationCode);
7 if (tempUser) {
8 def user = new User();
9 user.document = tempUser.document;
user.name = applicationRequest.userFirstName + " " +
11 applicationRequest.userLastName;
12 user.mail = applicationRequest.email;
13 user.password = applicationRequest.password;
14 user.address = applicationRequest.streetAddress;
user.paymentMethod = applicationRequest.paymentMethod;
16 user.interests = applicationRequest.userInterests;
17 user.devices = applicationRequest.devices;
18 user.enabled: true;
19 user.accountLocked: false;
user.confirmed: false;
21 user.save() 23 user.creditEco(tempUser.receivedEcos) 24 1 else {
sendError("authorizationcode.not.found") 26 }
27 [009 2] ECO ADVANTAGE may also credit to the user's new account the number 28 of ecos specified in the user's authorization code/temp ID. ECO ADVANTAGE
may send 29 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 31 implementations, an XML-encoded status of enrollment message may take a form 32 similar to the following:
33 POST /enrollment_message.php HTTP/1.1 34 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>
<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
ADVANTAGE. In some implementations, ECO ADVANTAGE may store 321 a ii 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 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 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 329 the application via sending it in a message to ECO
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 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 in 1 order to notify other entities in the process that the enrollment was successful, to 2 provide the user's current eco balance, and/or the like. In some implementations ECO
3 ADVANTAGE may send this status notification to the merchant 335, who may forward 4 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, 6 and/or the like. In some implementations, if the user chooses not to create an account, 7 ECO ADVANTAGE may deactivate the temporary user record 327 in the ECO
8 ADVANTAGE database. In some implementations, the user may be able to view his 9 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 ii example embodiments of the ECO ADVANTAGE. In some implementations, the 12 merchant 401 may wish to enroll in ECO ADVANTAGE via sending an enrollment 13 request 402 to ECO ADVANTAGE with an indication that the merchant would like to 14 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 16 to those in FIGURES 17a or 1713, depending upon whether the enrollment form is 17 electronic or physical. In some implementations, the merchant may fill out the 18 enrollment request form and send it back to ECO ADVANTAGE via a request form 19 message 405. In some implementations the request form message 405 may be an XML-encoded message similar to the following:
21 POST /request_form_message.php HTTP/1.1 22 Host: www.ECOADVANTAGEprocess.com 23 Content-Type: Application/XML
24 Content-Length: 788 <?XML version = "1.0" encoding = "UTF-8"?>
26 <merchantApplicationMessage>
27 <Document>02545225441000188</Document>
28 <MerchantName>Italian Restaurant</MerchantName>
29 <StreetAddress>16 avenue, 20</StreetAddress>
<BankInformation>
31 <BankNumber>254</BankNumber>
32 <Agency>3652-8</Agency>
33 <Account>2525414-5</Account>
1 </BankInformation>
2 <Biography>
3 The Italian restaurant opened 10 years ago 4 and since then has been serving Italian food every day.
</Biography>
6 <Links>
7 <Link>http://wwww.italian-restaurant.com</Link>
8 </Links>
9 <PosID>5467754</PosID>
<List0fPeriods>
11 <Period type="slow"
12 <DayRange>Mon, Tue, Wed</DayRange>
13 <TimeRange>18PM-22PM</TimeRange>
14 </Period>
</List0fPeriods>
16 <Capacity>150</Capacity>
17 <atmospherics>
18 <dateTime>03/07/2013 03:39 PM</dateTime>
19 </atmospherics>
</merchantApplicationMessage>
21 [01095] In some implementations, ECO ADVANTAGE may wish to perform a 22 check (e.g. financial, quality, and/or the like) 406 on the merchant before enrolling the 23 merchant in the program, and may send a check request 407 to a merchant agent 408 in 24 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 26 may collect, aggregate, and analyze various types of information about various 27 merchants both inside and outside of ECO ADVANTAGE. In some implementations, the 28 check request message 407 may be an XML-encoded message may include check 29 parameters for the merchant to use during aggregation (e.g. merchant to search for, sources to search, and/or the like).
31 [0096] In some implementations, the merchant agent may aggregate financial 32 information, quality information, background information, and/or like information 33 about the merchant 409, and may return this information to ECO ADVANTAGE
via a 34 merchant check response 410, which may include the merchant check data.
1 [0 0 9 7] In some implementations, ECO ADVANTAGE, after receiving the 2 merchant check, may generate a merchant account record 411 for the merchant if the 3 merchant has met a pre-specified threshold of quality and is approved for ECO
4 ADVANTAGE, and may enroll the merchant in the program. In some implementations, 5 Grails code for creating the merchant account may take a form similar to the following:
6 MerchantRequest merchantRequest =
MerchantRequest.getByDocument(XMLmerchant.document) 7 if (request) {
8 if (request.qualityCheckPending == false 9 && request.financialCheckPending == false M && request.approved == true) {
11 Merchant merchant = new Merchant(merchantRequest.*) 12 merchant.enabled = true;
M merchant.accountLocked = false;
14 merchant.confirmed = false;
M merchant.login = XMLmerchant.email;
M merchant.password = VoucherUtil.generatePassword() 17 merchant.save() M foreach(period in Merchant.List0fPeriod) {
19 new MerchantPeriod(merchant, period).save() 21 request.enrollmentPending = false;
22 request.save() 24 1 else {
25 sendError("merchantrequest.not.found") 26 }
27 [0098] ECO ADVANTAGE may instantiate 412 the merchant account record, 28 merchant eco schedule, and/or the like via storing the information in the schedules 41313 29 and merchant 413d tables of the ECO ADVANTAGE database 413. In some 30 implementations, ECO ADVANTAGE may also update the regions, categories, and/or 31 the like in ECO ADVANTAGE via updating the categories 413a and regions 413c tables 32 of the ECO ADVANTAGE database.
33 [009 9] In some implementations, ECO ADVANTAGE may send a notification 34 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
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 PoS configuration settings request 415 may be an XML-encoded message that may ii 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 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, 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 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.
[00101] FIGURES 4b-c show logic flow diagrams illustrating enrolling a merchant 31 in example embodiments of the ECO ADVANTAGE. In some implementations, the 1 merchant may submit 424 a request to enroll in ECO ADVANTAGE to ECO
2 ADVANTAGE, who may receive the request and generate 425 a template or customized 3 enrollment form for the merchant. In some implementations, ECO ADVANTAGE may 4 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 6 include identification information, merchant sales information, product information, 7 merchant payment information, atmospherics, industry information, and/or a variety of 8 other types of merchant-related data. In some implementations, ECO ADVANTAGE
9 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 11 implementations, once ECO ADVANTAGE has sent 430 the query to the merchant, the 12 merchant may receive the merchant's information 431 and may begin to aggregate 13 information 432 regarding the merchant, such as financial, quality, and/or like data. In 14 some implementations, merchant information may be aggregated from accredited financial review organizations, peer review services, client review services, and/or the 16 like. In some implementations, the merchant agent may generate 433 a background 17 check based on the aggregated data, and may send 434 the background check based on 18 the aggregated data. ECO ADVANTAGE May receive 435 the background check for the 19 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 21 score, has a low client review score on a number of prominent social review websites, 22 and/or the like). If the merchant meets a number of pre-specified criteria (e.g. credit 23 thresholds, peer review thresholds, and/or the like) 437, ECO ADVANTAGE may 24 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 26 an initial eco schedule for the merchant using the merchant's provided data (see 27 FIGURES 5a-b for further details). In some implementations the eco schedule may be 28 used to determine how many ecos a consumer may use in a transaction at the merchant 29 at particular times of the day, particular days of the week, and/or the like.
[o 0 1 0 2 ] As shown in FIGURE 4c, ECO ADVANTAGE may also generate a 31 confirmation notification 442 indicating that the merchant has been successfully 1 enrolled, and may end 443 said confirmation to the merchant. Once the merchant 2 received 444 the confirmation, the merchant may generate a survey 445 of the 3 merchant's current PoS infrastructure, resources, configurations, settings, and/or the 4 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 6 of Sales, place of business, or Point of Sales device) configurations, settings, 7 infrastructure, and/or the like 448 based on the merchant's submitted infrastructure 8 and the infrastructure and/or configuration needs of ECO ADVANTAGE. If ECO
9 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, ii configuration tutorials, and/or the like, along with promotions for the new settings 12 and/or infrastructure, and may generate a new PoS record in the ECO
ADVANTAGE
13 database containing the determined configuration, settings, and/or the like and a 14 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, 16 promotions, and/or the like, to the merchant 456 for the merchant's records. The 17 merchant may also forward 457 the settings to the merchant's acquirer, which may 18 receive 458 the new PoS configuration and/or the like and may instantiate 459 a new 19 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 21 send a notification 461 to ECO ADVANTAGE when the PoS is successfully configured.
22 ECO ADVANTAGE may receive 462 the notification and store it for future reference in 23 the PoS and/or merchant record.
24 [0 0 1 0 3] 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 26 send a notification to the merchant 439 indicating that the merchant was rejected by 27 ECO ADVANTAGE, but is encouraged to try to enroll again at a later date. In some 28 implementations the notification may also include reasons for rejection, including citing 29 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 31 send a failure message 450 to the merchant indicating that ECO ADVANTAGE
could not 1 generate a suitable configuration for the merchant given the information provided, and 2 may also indicate what major changes the merchant could make to its existing 3 infrastructure and/or the like before ECO ADVANTAGE can determine a suitable 4 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
6 ADVANTAGE indicating the changes in the PoS infrastructure, configuration, and/or 7 the like.
8 [ o 0104] FIGURE 5a shows a data flow diagram illustrating creating and updating 9 regions and categories in example embodiments of the ECO ADVANTAGE. In some implementations, a merchant agent 501 may determine a region 502 in ECO
11 ADVANTAGE to analyze. In some implementations, the region may be based on 12 geographic, cultural, industrial, and/or like constraints. The merchant may search for 13 merchants in each region to obtain data from, and may obtain aggregate data 505 from 14 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 16 aggregate information obtained about each merchant to ECO ADVANTAGE via a 17 region/merchant survey message 506. In some implementations, an XML-encoded 18 region/merchant survey message 506 may be an XML-encoded message and may take a 19 form similar to the following:
POST /region_merchant_survey_message.php HTTP/1.1 21 Host: www.ECOADVANTAGEprocess.com 22 Content-Type: Application/XML
23 Content-Length: 788 24<?XML version = "1.0" encoding = "UTF-8"?>
<regionMerchantSurvey>
26 <surveyId>11254878</surveyId>
27 <surveyDateTime>03/07/2013 03:39 PM</surveyDateTime>
28 <merchantSurveyList>
29 <merchantSurvey>
W <merchantSurveySeqNumber>1</merchantSurveySeqNumber >
31 <merchantId>2033</merchantId>
32 <MerchantDocument>021451125488</MerchantDocument>
33 <MerchantAggregateSales></MerchantAggregateSales>
34 <AverageConsumerSpent>84.5</AverageConsumerSpent>
<ProductServicePurchase></ProductServicePurchase>
36 <List0fPeriods>
37 <Period type="idle"
1 <DayRange>Mon, Tue, Wed, Thu, Fri</DayRange>
2 <TimeRange>03PM-06PM</TimeRange>
3 </Period>
4 <Period type="slow"
5 <DayRange>Mon, Tue, Wed</DayRange>
6 <TimeRange>06PM-10PM</TimeRange>
7 </Period>
8 <Period type="peak"
9 <DayRange>Thu, Fri</DayRange>
10 <TimeRange>11AM-03PM,06PM-10PM</TimeRange>
11 </Period>
12 </List0fPeriods>
13 <GPSCoordinates>1.65254125411,-5.698564545</GPSCoordinates>
14 <productData>
15 <sku>56673953</sku><description>hair cut</description>
16 </productData>
17 <RetailSearches></RetailSearches>
18 <MarketDataAggregates></MarketDataAggregates>
19 <CensusData></CensusData>
20 <Photo></Photo>
21 <Video></Video>
22 <Description></Description>
23 <MerchantSite>http://www.italian-restaurant.com</MerchantSite>
24 <Email>admin@italian-restaurant.com</Email>
<SocialNetworkinsPage>www.facebook.com/ItalianRestaurant</SocialN
26 etworkinsPage>
27 <MerchantContactInformation></MerchantContactInformation>
28 </merchantSurvey>
29 <merchantSurvey>
30 <merchantSurveySeqNumber>2</merchantSurveySeqNumber >
31 <merchantId></merchantId>
32 <MerchantDocument>021451125475</MerchantDocument>
33 ¨.
34 </merchantSurvey>
35 <merchantSurvey>
36 <merchantSurveySeqNumber4{n}</merchantSurveySeqNumber >
37 ¨.
38 </merchantSurvey>
39 </merchantSurveyList>
40 <dateTime>03/07/2013 03:39 PM</dateTime>
41 </regionMerchantSurvey>
42 [00105] In some implementations, ECO ADVANTAGE may parse the data in the
43 survey 508, and may perform analytics 509 on the data received (e.g.
determine which
determine which
44 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).
46 ECO ADVANTAGE may update the merchant profile 510, eco schedule, and/or the like 47 for merchants being analyzed. ECO ADVANTAGE may create and/or update region and 48 category information 511 in the ECO ADVANTAGE database based on the merchant 49 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 18 and 19.
4 [00106] FIGURES 5b-d show logic flow diagrams illustrating creating and 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, merchant transaction history, the merchant location, and/or like data from the ii 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 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 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 525 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 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, 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 1 like), and may, for each merchant 532, aggregate qualitative and quantitative merchant 2 data 533 (see FIGURE 4h for further details), and may add the data 534 to a collective 3 list of merchant prospects for ECO ADVANTAGE. When all merchants have been 4 processed 535, the merchant agent may generate and send the aggregated data 536 of all merchants found to ECO ADVANTAGE, which may, upon receiving 561 the aggregated 6 data, rank 537 the merchants based on pre-specified criteria (e.g. the average and/or 7 total number of customers for the merchant, the merchant's current capacity, the 8 merchant's financial reputation, and/or the like). ECO ADVANTAGE may select 538 the 9 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 ii the requirements, ECO ADVANTAGE may select the next best merchant on the list 540, 12 and may perform the same check on the next best merchant. If a merchant meets ECO
13 ADVANTAGE requirements, ECO ADVANTAGE may generate 541 and send 542 an 14 enrollment invitation to the merchant (see FIGURES 4b-c for more detail).
In some implementations, after the merchant has enrolled, ECO ADVANTAGE may update 543 16 the region and category that the new merchant belongs to, in order to show that a 17 merchant has been added to both.
18 [co co 1 co 7] In some implementations, after performing analytics on enrolled 19 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 21 overpopulated 545, ECO ADVANTAGE may with to divide the region such that each 22 sub-region is not overpopulated. In some implementations this may be done via 23 determining a geographical, demographic, and/or like demarcation category 546 to 24 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 26 implementations, if there is more than one variant of the demarcation category in the 27 region 547 (e.g., if there is more than one area code and/or the like in the region), ECO
28 ADVANTAGE may split the existing region 550 by the one or more variant in the region 29 (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 31 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 548 using a region map and/or region 2 location data points, and may split the region 549 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 552 (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 554 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, for each new region 556, gather new region information 557 (.g. demographics, industries, ii and/or the like), may update 558 the region's categories, records, and/or the like based 12 on the gathered information, and may gather updated information 559 of merchants 13 currently enrolled and in the region (see FIGURES 5a-c for more details).
ECO
14 ADVANTAGE may continue to do this for each new region until it there are not any new regions left to check 56o.
16 [00108] FIGURES 6a-b show data flow diagrams illustrating friend invitations and 17 donations in example embodiments of the ECO ADVANTAGE. In some 18 implementations, a user 601 may indicate at a merchant PoS device, merchant kiosk, via 19 an electronic device 602, and/or using like technology that he would like to donate ecos.
In some implementations the user may be encouraged to donate ecos that are close to 21 expiring after a time period defined by ECO ADVANTAGE, and may be able to donate 22 either to charities, organizations, and/or the like, or to friends in the form of a referral 23 program. In some implementations the user may send a balance request 603 to ECO
24 ADVANTAGE 604, which may ask for the user's current balance, including ecos that will expire soon. In some implementations the balance request 603 may be an XML-encoded 26 message and may take a form similar to the following:
27 POST /balance_request.php HTTP/1.1 28 Host: www.ECOADVANTAGEprocess.com 29 Content-Type: Application/XML
Content-Length: 788 31 <?XML version = "1.0" encoding = "UTF -8"?>
32 <balanceRequest>
1 <userId>102557952</userId>
2 <userIdType>SSN</userIdType >
3 <ecoId>3074</ecoId>
4 <Document>06998524500</Document>
<dateTime>03/07/2013 03:39 PM</dateTime>
6 </balanceRequest>
7 [00109] In some implementations, ECO ADVANTAGE may send a balance 8 response 605 which may contain the user's eco balance, expiration date data for all of 9 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:
11 POST /balance_response.php HTTP/1.1 12 Host: www.ECOADVANTAGEprocess.com 13 Content-Type: Application/XML
14 Content-Length: 788 <?XML version = "1.0" encoding = "UTF-8"?>
16 <balanceResponse>
17 <userId>102557952</userId>
18 <userIdType>SSN</userIdType >
19 <ecoId>3074</ecoId>
<Document>06998524500</Document>
21 <ListOfBalance>
22 <Balance>
23 <Value>77</Value>
24 <ExpirationDate>05/15/2013</ExpirationDate>
</Balance>
26 <Balance>
27 <Value>200</Value>
28 <ExpirationDate>06/15/2013</ExpirationDate>
29 </Balance>
</ListOfBalance>
31 </balanceResponse>
32 [00110] In some implementations, the user may be able to view his ecos balance 33 via an ecos balance user interface similar to that in FIGURE 21b, and may, using an 34 interface similar to that in FIGURES 20a-b, choose a number of ecos to donate to a friend, and may send a gift request 606 to ECO ADVANTAGE. In some implementations 1 the gift request 606 may be an XML-encoded message which may take a form similar to 2 the following:
3 POST /gift_request.php HTTP/1.1 4 Host: www.ECOADVANTAGEprocess.com 5 Content-Type: Application/XML
6 Content-Length: 788 7 <?XML version = "1.0" encoding = "UTF-8"?>
8 <giftRequest>
9 <UID>32134321354321345312</UID>
10 <EcoBlockAmount>400</EcoBlockAmount>
11 <FriendID>02541478744</FriendID>
12 <Email>peter@friend.com</Email>
13 <PhoneNumber>1465448874</PhoneNumber>
14 </giftRequest>
15 [00111] In some implementations, ECO ADVANTAGE may be able to determine 16 whether the friend is already enrolled or not 607, and may allocate 608 the user-17 specified number of ecos in the user's balance as ecos to be donated to the friend. In 18 some implementations, Grails code for checking for friend enrollment and allocating 19 ecos may take a form similar to the following:
20 def userGift 21 User user = User.getByDocument(friendID) 22 if (user) {
23 userGift = user 24 } else {
25 userGift = TemporaryUser.create(friendID) 26 }
27 User user = User.getByDocument(userId) 28 def userBalance = user.getBalance() 30 if (userBalance > ecoBlockAmount) {
31 sendError("insufficient.funds.for.gifting") 32 } else {
33 user.blockForDonation(ecoBlockAmount,UID) 34 }
1 [0 0 1 12 ] In some implementations, ECO ADVANTAGE may send an allocation 2 confirmation request 609 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 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
Content-Length: 788 11 <?XML version = "1.0" encoding = "UTF-8"?>
12 <giftConfirmation>
13 <UID>32134321354321345312qUID>
14 <EcoBlockAmount>500</EcoBlockAmount>
<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 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 26 Are you getting 400 ecos to spend using Eco Advantage 28 Sign up to take advantage GiftID: 32134321354321345312 31 UserID: 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 1 313, 314, or 315. In some implementations, sensitive information (e.g. the user PIN
2 and/or the like) may be encrypted.
3 [00115] In some implementations, ECO ADVANTAGE may instantiate 615 a user 4 account for the friend using the enrollment data provided, via sending a user account insert query 616 to the users 617d table of the ECO ADVANTAGE database 617. In some 6 implementations, ECO ADVANTAGE may transfer 618 the block of ecos from the user 7 to the friend (e.g. by moving the ecos to the friend's new account, designating them as 8 "donation ecos," resetting the expiration date for the ecos donated, and/or like record-9 updating). In some implementations, example Grails code for transferring the ecos may take a form similar to the following:
11 DonationBlock donation = DonationBlock.getbyUID(UID) 12 User userFrom = donation.userFrom 13 User userTo = donation.userTo 14 userFrom.donate(UID, userTo) [00116] In some implementations, ecos designated as being donated may not be 16 donated again by any user, and may only be able to be spent. In some implementations, 17 ECO ADVANTAGE may update records via ecos update 619.
18 [co co 117] In some implementations, ECO ADVANTAGE may send a confirmation to 19 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 21 been successfully transferred to the friend's new account.
22 [00118] Referring to FIGURE 6b, in some implementations, friend 613 may use the 23 donated ecos 622 in a plurality of transactions (see FIGURES 2a-d for more details).
24 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, 26 allocate an invite bonus block to the user's account, via sending an invite bonus block 27 update 625 to the ECO ADVANTAGE database. In some implementations, Grails code 28 for monitoring the spending of donated ecos may take a form similar to the following:
29 def list0fDonation = Donation.findbyBonusBlockId(null) 31 foreach (donation in list0fDonation) {
1 def userFrom = donation.userFrom 2 def userTo = donation.userTo 3 def amount = donaction.amount 4 def date = donation.date 6 def usedAmountSinceDonation =
7 transaction . getByUserAndSinceDate(userTo, date) 9 call eligibleForBonusBlock(donation, usedAmountSinceDonation) }
11 [00119] In some implementations, Grails code for allocating invite bonus blocks 12 may take a form similar to the following:
M function eligibleForBonusBlock( donation, usedAmountSinceDonation) {
14 if ( usedAmountSinceDonation >=
(donation.amount *
M ecoAdvantageConfig.donationFactor)) {
16 def bonusBlockId = donation.userFrom.creditBonusBlock() 17 donation.bonusBlockId = bonusBlockId;
18 donation.save() 19 }
}
21 [00120] In some implementations, the bonus block update query 625 may be a 22 PHP-encoded insert statement.
23 [00121] In some implementations, the user may receive confirmation 626 that the 24 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 26 participate in a qualifying transaction 627, such as a purchase transaction at an enrolled 27 merchant 628 (see FIGURES 2a-d). In some implementations, a qualifying transaction 28 may include a transaction where the combination of using ecos and bonus blocks will 29 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 31 minimum value at which a user can use bonus blocks towards a transaction), a 32 transaction initiated at a particular merchant, in a particular region, in a particular 33 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 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 629 io (which may resemble eco message 206), and receive eco response 630 (which may ii 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 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 [ o 0124] FIGURES 6c-d show logic flow diagrams illustrating friend invitations and 19 donations in example embodiments of the ECO ADVANTAGE. In some 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 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 may receive 639 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
1 may, if the friend is enrolled 641, transfer the specified block of ecos to the friend 642, 2 may update the user's and friend's balances, may mark the transferred ecos as "donated 3 ecos" 643 and reset the expiration dates of the donated ecos, and/or take care of other 4 transfer details. ECO ADVANTAGE may notify the user and the friend 644 that the ecos 5 were successfully transferred from the user to the friend.
6 [00125] If the friend is not enrolled, ECO ADVANTAGE may instead allocate a 7 block of the user's ecos 645 to be donated to the friend, and may prepare and send a 8 template or customized enrollment form 646 to the friend. The friend may receive the 9 enrollment form 647, along with the amount of ecos being donated to them, from whom, 10 and/or the like. If the friend declines to enroll 648, ECO ADVANTAGE may deactivate ii the enrollment invitation 649, and may send a notification to the user that his 12 enrollment invite has been deactivated 65o because the friend did not wish to enroll in 13 ECO ADVANTAGE. If the friend chooses to enroll 648, the friend may do so by 14 completing and submitting the enrollment form 651 to ECO ADVANTAGE, which may 15 create a user account 652 for the friend based on the provided enrollment data in the 16 friend's submitted enrollment form. ECO ADVANTAGE may transfer 653 the allocated 17 block of ecos to be donated from the user account to the friend's new account, and may 18 update the user's and friend's eco balances. ECO ADVANTAGE may mark the 19 transferred ecos as "donation ecos" 654, along with resetting their expiration date 20 and/or the like. The user may be notified of a successful eco donation 655.
21 [00126] In some implementations, the friend may use the donated ecos in one or 22 more subsequent transactions 656 (see FIGURES 2a-d for more details), which may be 23 monitored 657 by ECO ADVANTAGE. If ECO ADVANTAGE finds that the friend has 24 spent some pre-defined number and/or percentage of the donated ecos 658, it may 25 allocate 659 a predetermined invite bonus block value to the user, and may update the 26 user's account 660 with the allocated invite bonus block. ECO ADVANTAGE may 27 generate may generate 661 and send 662 a confirmation message to the user indicating 28 that a predetermined number ecos donated by the user have been spent, that the user is 29 consequently receiving an invite bonus block, the user's current ecos and invite bonus 30 block balances, and/or the like. the user may receive 663 the confirmation and may 31 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 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 [0 0 1 27] FIGURE 7a shows a data flow diagram illustrating slow commit, credit-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 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 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 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 implementations, the merchant may display and/or print 709 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 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 M Host: www.ECOADVANTAGEprocess.com 11 Content-Type: Application/XML
12 Content-Length: 788 M<?XML version = "1.0" encoding = "UTF-8"?>
14 <paymentRequest>
M <posId>4088</posId>
M <merchantId>2033</merchantId>
17 <amountDueInDollars>77.0</amountDueInDollars>
M <dateTime>03/07/2013 03:39 PM</dateTime>
19 <userCard>3214 3578 3568 3542</userCard>
20 </paymentRequest>
21 [00128] In some implementations payment request 711 may only include the 22 transaction balance after ecos and/or bonus blocks have been applied. The acquirer may 23 prepare 712 the transaction and procure payment via sending a transaction request 714 24 to a bank entity 715 (e.g. the user's issuing bank, another acquirer, and/or the like).
25 [00129] The bank may send a transaction response 716 to the acquirer, which may 26 indicate whether or not the transaction was approved and/or processed, or whether the 27 transaction was declined. The acquirer may forward this information to ECO
28 ADVANTAGE via transaction confirmation 717, which may take a form similar to 29 transaction confirmation 219, or may forward the information to the merchant via 30 transaction confirmation 718 (which may take a form similar to transaction 31 confirmation 219), who may forward the information via transaction confirmation 719 32 to ECO ADVANTAGE. In some implementations, the entity the acquirer forwards the 33 confirmation to may depend on the security of the entities, entity resources, and/or the 34 like. In some implementations ECO ADVANTAGE may not receive the confirmation 35 (e.g., via the acquirer or the merchant). In some implementations, transaction 1 confirmation 719 may take a form similar to transaction confirmation 219.
Once ECO
2 ADVANTAGE has received a transaction confirmation, it may debit 720 the used ecos 3 and bonus blocks from the user's balances, may credit to the user with new ecos equal to 4 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 6 take a form similar to the following:
7 Transaction transaction = Transaction.get(transactionId) 8 User user = transaction.getUser() 9 Merchant merchant = transaction.getMerchant() long ecoUsage = transaction.getEcoUsage() 11 long bonusBlockUsage = transaction.getBonusBlockUsage() 12 Try {
13 beginTransaction() 14 user.debitEco(ecoUsage) user.debitBonusBlock(bonusBlockUsage) 16 commitTransaction();
17 I catch (Exception) {
18 rollbackTransaction();
19 return false;
}
21 [00130] ECO ADVANTAGE may also update the merchant account record 721, 22 including updating BI information, transaction data, the merchant's usage schedule, 23 atmospherics, and/or the like. In some implementations, Grails code for updating the 24 user's balances may take a form similar to the following:
Transaction transaction = Transaction.get(transactionId) 26 User user = transaction.getUser() 27 Merchant merchant = transaction.getMerchant() 28 long amountDueInDollars = transaction.getAmountDueInDollars() 29 Try {
beginTransaction() 31 user.creditEco(amountDueInDollars, merchant) 32 commitTransaction();
33 I catch (Exception) {
34 rollbackTransaction();
1 return false;
2}
3 [00131] ECO ADVANTAGE may send an eco credit confirmation 722 to the 4 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 6 take a form similar to the following:
7 POST /eco_credit_confirmation.php HTTP/1.1 8 Host: www.ECOADVANTAGEprocess.com 9 Content-Type: Application/XML
Content-Length: 788 11 <?XML version = "1.0" encoding = "UTF-8"?>
12 <ecoCreditConfirmation>
13 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
14 <newEcos>77</newEcos>
<bonusBlock>0</BonusBlock>
16 <usedEcos>23</usedEcos>
17 <EcoBalance>1091</EcoBalance>
18 <ecoCreditConfirmation>
19 [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 21 contain information similar to the following:
22 DOCUMENT: NNN.NNN.NNN-NN ID EAS: IIIIII
23 USED ECOS: VVV.VVV,VV
24 USED BONUS BLOCKS: VVV.VVV,VV
NEW ECOS: EEE.EEE,EE
27 ECO BALANCE: BBB.BBB,BB
29 [00133] In some implementations, ECO ADVANTAGE may also monitor the status of various transactions, and may reverse, retry, and/or otherwise handle incomplete 31 transactions if found in the ECO ADVANTAGE database's records, based on 32 predetermined criteria.
1 [o 0 1 34 ] 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 1 user's balance, as well as updating merchant and transaction records 745 using the 2 information described in 721 and/or like information.
3 [0 co 13 6 ] If the acquirer cannot successfully procure the funds 736, the acquirer may 4 send a notification of transaction failure 738 to the merchant (and, in some implementations, to ECO ADVANTAGE). The merchant may, after determining the 6 transaction was not successful 739, send a notification to the user 740, along with a 7 prompt to retry the transaction (e.g. with a different payment method and or the like).
8 In some implementations the merchant may also forward the notification to ECO
9 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 11 incomplete until the transaction is successfully processed, until the user cancels the 12 transaction, and/or the like. In some implementations, ECO ADVANTAGE may also 13 monitor the status of various transactions, and may reverse, retry, and/or otherwise 14 handle incomplete transactions if found in the ECO ADVANTAGE database's records, based on predetermined criteria.
16 [00137] FIGURE 8a shows a data flow diagram illustrating fast commit, credit-17 only transactions in example embodiments of the ECO ADVANTAGE. In some 18 implementations, a user 801 may send a transaction initiation request 803 to the 19 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 21 encrypted. In some implementations, the transaction initiation request may take a form 22 similar transaction initiation 205, or may take a form similar to the following:
23 POST /transaction_intitation_request.php HTTP/1.1 24 Host: www.ECOADVANTAGEprocess.com Content-Type: Application/XML
26 Content-Length: 788 27<?XML version = "1.0" encoding = "UTF-8"?>
28<InitiateTransactionRequest>
29 <UID>32134321354321345312qUID>
<ProductData>haircut</ProductData>
31 <TransactionAmount>100</TransactionAmount>
32 <UserPIN>3214 3558 1587 9877</UserPIN>
1 </InitiateTransactionRequest>
2 [o 0138] In some implementations, sensitive information (e.g. the user PIN
and/or 3 the like) may be encrypted. In some implementations, the merchant may send an eco 4 request 805 to the ECO ADVANTAGE 806. In some implementations, eco request may take a form similar to eco request 206. ECO ADVANTAGE may look up the user's 6 and merchant's records using the user ID (UID) and the merchant ID 807, respectively, 7 and may determine which and how many ecos and bonus blocks the user may apply to 8 his transaction (e.g. based on the merchant's eco schedule, the user's eco and bonus 9 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 ii the user to confirm his transaction before initiating any portion of it. In some 12 implementations ECO ADVANTAGE may debit 808 the used ecos and bonus blocks 13 from the user's balances, may credit to the user with new ecos equal to a predetermined 14 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
16 information, transaction data, the merchant's usage schedule, atmospherics, and/or the 17 like.
18 [00139] ECO ADVANTAGE may send an eco response 810 back to the merchant, 19 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 21 transaction. In some implementations, payment request 811 may take a form similar to 22 payment request 215. The acquirer may prepare 812 the transaction and procure 23 payment via sending a transaction request 814 to a bank entity 815 (e.g.
the user's 24 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 26 may send a transaction response 816 to the acquirer, which may indicate whether or not 27 the transaction was approved and/or processed, or whether the transaction was 28 declined. The acquirer may forward this information to ECO ADVANTAGE via 29 transaction confirmation 819, which may take a form similar to transaction confirmation 219, or may forward the information to the merchant via transaction 31 confirmation 817 (which may take a form similar to transaction confirmation 219), who I 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 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-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, ECO ADVANTAGE may receive 823 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 18 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 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 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 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 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 processed. In some implementations the merchant may, if it receives a notification 838 ii indicating a successful transaction, print and/or display a transaction receipt 839 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 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 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 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.
[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 15a-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, 10 an exemplary batch payment request 903 may take a form similar to the following:
11 POST / batch_payment_request.php HTTP/1.1 12 Host: www.ECOADVANTAGEprocess.com 13 Content-Type: Application/XML
14 Content-Length: 788 15 <?XML version = "1.0" encoding = "UTF-8"?>
16 <batchPaymentRequest>
17 <list0fPaymentRequest>
18 <paymentRequest>
19 <id>125414</id>
20 <ecoadvantage>true</merchantId>
21 <balanceOwed>8547.00</balanceOwed>
22 <requestDate>05/13/2013</requestDate>
23 </paymentRequest>
24 <paymentRequest>
25 <id>125415</id>
26 <acquirer>2033</merchantId>
27 <balanceOwed>54871.00</balanceOwed>
28 <requestDate>05/13/2013</requestDate>
29 </paymentRequest>
30 <paymentRequest>
31 <id>125416</id>
32 <merchantId>2034</merchantId>
33 <balanceOwed>125.00</balanceOwed>
34 <requestDate>05/13/2013</requestDate>
1 </paymentRequest>
2 <paymentRequest>
3 <id>125417</id>
4 <merchantId>2035</merchantId>
<balanceOwed>588.00</balanceOwed>
6 <requestDate>05/13/2013</requestDate>
7 </paymentRequest>
8 </list0fPaymentRequest>
9 </batchPaymentRequest>
[0 0 1 45] The acquirer may perform 905 reconciliation with various payment ii entities via sending a payment instruction message 906 to the user's issuing bank 907 12 and an acquirer payment instruction message 908 to an acquiring bank 909.
In some 13 implementations, the issuer bank may send a bill 910 to the user 911, who may view the 14 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 16 the funds for the payment.
17 [00146] The issuer may send a merchant payment message 914 to the merchant's 18 bank 915, which may include the funds requested for the payment being processed. The 19 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 21 may, using the acquirer payment instructions 908 and the acquirer payment 916, 22 calculate a payment value to be sent to ECO ADVANTAGE 918, and may send the ECO
23 ADVANTAGE Payment 917 to ECO ADVANTAGE. In some implementations, ECO
24 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 26 implementations, ECO ADVANTAGE may receive a confirmation once the payment has 27 been processed at the ECO ADVANTAGE bank, which may include a confirmation that 28 the transaction was successfully processed, the transaction ID for each transaction from 29 the acquirer, and/or the like, for each transaction in the batch.
[00147] FIGURE 9b shows a logic flow diagram illustrating merchant 31 reconciliation in example embodiments of the ECO ADVANTAGE. In some 32 implementations, for each acquirer connected to ECO ADVANTAGE 919, ECO
1 ADVANTAGE may check every merchant 920 that uses the acquirer to see if any 2 reconciliation is necessary for the merchant. ECO ADVANTAGE may query 921 the 3 database for transaction data, merchant data, the merchant's eco schedule, the 4 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 6 unreconciled 922, ECO ADVANTAGE may calculate the transaction total for the 7 transaction, and may also calculate what the acquirer's running transaction total at the 8 time, the merchant's running transaction total at the time, and the ECO
ADVANTAGE
9 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 ii maximum amount of total funds that may be processed by the acquirer at the time), 12 ECO ADVANTAGE may determine whether there are other unreconciled transactions 13 928 (e.g. in case another unreconciled transaction may be processable), and may 14 continue to check each unreconciled transaction in the database.
[00148] If the transaction is processable, ECO ADVANTAGE may also check to 16 determine whether the projected totals would be less than the merchant's maximum 17 amount of possible funds to process 925. If not, ECO ADVANTAGE may determine 18 whether there are any other unreconciled transactions to process 928. If the projected 19 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 21 calculated running total of the merchant, acquirer, ECO ADVANTAGE, and/or the like 22 once the transaction is processed. ECO ADVANTAGE may also keep a running total for 23 different payment methods, such as the total amount of funds to be received from 24 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
26 ADVANTAGE database records with the totals calculated at the time, and may update 27 the transaction record to reflect that the transaction has been reconciled.
Once all 28 transactions have been checked, ECO ADVANTAGE may update 929 the running total 29 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 31 for the remaining merchants; if not, ECO ADVANTAGE may prepare 931 a batch 1 payment request to an acquirer using the data obtained from all the processed 2 merchants, and may send 932 the batch payment request to the acquirer for payment 3 processing. If there are other acquirers 933 to process, ECO ADVANTAGE may repeat 4 the process for each other acquirer connected with ECO ADVANTAGE.
[00149] In some implementations, Grails code for processing the batch payment 6 may take a form similar to the following:
7 def totalEcoAdvantage = 0 8 def batchPayment = [];
def list0fAquirer = Acquirer.findAll() 12 foreach(aquirer in list0fAquirer) {
14 def totalAcquirer = 0 16 def list0fMerchant = Merchant.findbyAquirerer(acquirer) 18 foreach(merchant in list0fMerchant) {
def totalMerchandFund = 0 21 def totalMerchant = 0 23 def listOfTransaction =
24 Transaction.findByAcquirerAndMerchant(acquirer, merchant) 26 foreach(transaction in listOfTransaction) {
28 if (NOT transaction.reconciled) {
def totalTransaction = transaction.calculateTotal() 31 totalMerchant = totalMerchant +
32transaction.calculateTotalMerchant() 33 totalAcquirer = totalAcquirer +
34transaction.calculateTotalAcquirer() totalEcoAdvantage = totalEcoAdvantage +
36transaction.calculateTotalEcoAdv() 2 if (totalMerchandFund + totalMerchant <
3 SystemSetting.getMaxFundToMerchant()) {
Reconcilation reconcilation = new Reconcilation() 6 reconcilation.merchant = merchant 7 reconcilation.acquirer = acquirer 8 reconcilation.date = today() 9 reconcilation.totalTransaction = totalTransaction M reconcilation.totalMerchant = transaction.calculateTotalMerchant() 11 reconcilation.totalAcquirer = transaction.calculateTotalAcquirer() 12 reconcilation.totalEcoAdvantage = transaction.calculateTotalEcoAdv() M reconcilation.totalCash = transaction.calculateTotalCash() 14 reconcilation.totalCard = transaction.calculateTotalCard() M reconcilation.totalEco = transaction.calculateTotalEco() M reconcilation.save() M transaction.reconciled = true 19 transaction.save();
20 totalMerchandFund =+ totalMerchant 22 }
23 }
24 }
26 PaymentRequest paymentRequest = new PaymentRequest();
27 paymentRequest.merchant = merchant;
28 paymentRequest.balanceOwed = totalMerchant;
29 paymentRequest.requestDate = new Date();
W paymentRequest.confirmed = false;
31 paymentRequest.save() 32batchPayment.push(payment: paymentRequest) 36 PaymentRequest paymentRequest = new PaymentRequest();
1 paymentRequest.acquirer = acquirer;
2 paymentRequest.balanceOwed = totalAcquirer;
3 paymentRequest.requestDate = new Date();
4 paymentRequest.confirmed = false;
5 paymentRequest.save() 6 batchPayment.push(payment: paymentRequest) 7}
9 PaymentRequest paymentRequest = new PaymentRequest();
M paymentRequest.ecoAdvantage = true;
11 paymentRequest.balanceOwed = totalEcoAdvantage;
12 paymentRequest.requestDate = new Date();
M paymentRequest.confirmed = false;
14 paymentRequest.save() M batchPayment.push(payment: paymentRequest) M
17 render batchPayment as XML;
18 [o 0 15 0 ] FIGURE loa shows a data flow diagram illustrating slow commit, cash and 19 credit transactions in example embodiments of the ECO ADVANTAGE. In some 20 implementations, a user 1001 may send a transaction initiation request 1003 to the 21 merchant 1004 using the merchant's PoS device and/or a user electronic device 1002. In 22 some implementations, sensitive information (e.g. the user PIN and/or the like) may be 23 encrypted. In some implementations, the merchant may send an eco request 1005 to the 24 ECO ADVANTAGE 1006. In some implementations, eco request 1005 may take a form 25 similar to eco request 206. ECO ADVANTAGE may look up the user's and merchant's 26 records using the user ID (UID) and the merchant ID 1007, respectively, and may 27 determine which and how many ecos and bonus blocks the user may apply to his 28 transaction (e.g. based on the merchant's eco schedule, the user's eco and bonus block 29 balances, and/or the like), and may determine the state of a user confirmation setting. If 30 the confirmation setting is set to "true," ECO ADVANTAGE may require the user to 31 confirm his transaction before initiating any portion of it. In some implementations 32 ECO ADVANTAGE may send an eco response 1008 back to the merchant, which may 33 take a form similar to eco response 212.
1 [0 0 15 1] In some implementations, the merchant may display and/or print 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 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 loll to ECO ADVANTAGE
9 indicating that the user has already paid part of the transaction balance in cash, and is 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 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 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 Host: www.ECOADVANTAGEprocess.com 26 Content-Type: Application/XML
27 Content-Length: 788 28 <?XML version = "1.0" encoding = "UTF-8"?>
29 <paymentConfirmation>
<UID>da6c5cdf4e90b2961873f7b2e863415</UID>
31 <transactionId>635467</transactionId>
32 <merchantId>2033</merchantId>
1 <posId>4088</posId>
2 <amounDueInDollars>77.0</amountDueInDollars>
3 <bonusBlockAmount>20</bonusBlockAmount>
4 <debitCreditAmount>27.0</debitCreditAmount>
<cashAmount>50.0</cashAmount>
6 <totalAmount>100</totalAmount>
7 <dateTime>03/07/2013 03:40 PM</dateTime>
8 <approved>true</approved>
9 </paymentConfirmation>
[00153] In some implementations the acquirer may forward the information to the ii merchant via transaction confirmation 1019 (which may take a form similar to 12 transaction confirmation 219), who may forward the information via transaction 13 confirmation 1020 to ECO ADVANTAGE. Once ECO ADVANTAGE has received a 14 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, 16 and may update the user's balance. ECO ADVANTAGE may also update the merchant 17 account record 1023, including updating BI information, transaction data, the 18 merchant's usage schedule, atmospherics, and/or the like. In some implementations, 19 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
21 ADVANTAGE may also monitor the status of various transactions, and may reverse, 22 retry, and/or otherwise handle incomplete transactions if found in the ECO
23 ADVANTAGE database's records, based on predetermined criteria.
24 [o 0154] FIGURES lob-c show logic flow diagrams illustrating slow commit, cash and credit transactions in example embodiments of the ECO ADVANTAGE. In some 26 implementations, a user may initiate 1025 a transaction with an enrolled merchant, via 27 providing transaction input to a merchant. The merchant may receive the user input and 28 transaction information 1026, and may generate and send 1027 a request to ECO
29 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 31 balance, and may retrieve from the ECO ADVANTAGE database 1029 the user's 32 available ecos, bonus blocks, and/or the like to determine which and how many ecos and 1 bonus blocks may be applied to the current transaction, as well as to determine the 2 user's confirmation setting. If the confirmation setting is on 1030, ECO
ADVANTAGE
3 may generate 1031 and send 1032 a response to the merchant indicating the user's eco 4 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 6 displaying and/or printing the transaction information for the user and asking the user 7 to confirm the transaction 1034. The user may authenticate 1035 the transaction and the 8 use of his ecos and/or bonus blocks towards the purchase using his password, user PIN, 9 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
11 ADVANTAGE indicating the user has both confirmed the use of his ecos and/or bonus 12 blocks and wishes to pay for the transaction, and has paid at least a portion of the 13 transaction balance in cash. Once ECO ADVANTAGE receives 1037 the message, it may 14 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 16 amount based on the cash payment.
17 [00155] In some implementations, the merchant may also generate and send a 18 payment request 1039 with the user's payment information, the transaction balance 19 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 21 procurement. In some implementations the acquirer may receive 1040 the user's 22 payment information, transaction data, and/or the like, and may authenticate the 23 sender of the message 1041 and use the information to request the transaction balance 24 from the user's issuing bank.
[00156] If the acquirer can successfully procures the funds 1042, the acquirer may 26 obtain the funds 1043 and may send a confirmation to the merchant (and in some 27 implementations, to ECO ADVANTAGE) indicating that the transaction was successfully 28 processed. In some implementations the merchant may, if it receives a notification 1044 29 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 31 ECO ADVANTAGE indicating that the transaction was successful. ECO ADVANTAGE
1 may, after receiving 1047 the transaction confirmation, save the confirmation within the 2 transaction record in the ECO ADVANTAGE database in order to mark the transaction 3 as completed. ECO ADVANTAGE may also credit 1048 the user's account with a 4 predetermined amount of new ecos based on the user's credit/debit payment, and may update the merchant and transaction records 1049 using the data in 1023 and/or like 6 information in the ECO ADVANTAGE database to indicate that the full transaction 7 amount has been processed and procured.
8 [ o col 5 7] If the acquirer cannot successfully procure the funds 1042, the acquirer 9 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 ii notification of a failed transaction, generate and send 1052 a transaction confirmation to 12 ECO ADVANTAGE indicating the transaction failed, and may also display and/or print 13 1053 a notification of transaction failure for the user and/or may prompt the user to 14 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 16 transaction as incomplete and necessary to retry, and mark related records (e.g. the 17 user's record, the merchant's record and/or the like) as also being incomplete 1055. In 18 some implementations, ECO ADVANTAGE may also monitor the status of various 19 transactions, and may reverse, retry, and/or otherwise handle incomplete transactions if found in the ECO ADVANTAGE database's records, based on predetermined criteria.
21 [o 0158] FIGURE na shows a data flow diagram illustrating fast commit, cash and 22 credit transaction in example embodiments of the ECO ADVANTAGE. In some 23 implementations, a user 1101 may send a transaction initiation request 1103 to the 24 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 26 encrypted. In some implementations the user may also provide a cash payment to the 27 merchant covering at least a part of the remaining transaction balance once the user's 28 ecos and/or bonus blocks are applied. In some implementations, the cash payment may 29 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 31 payment method. In some implementations, the merchant may send an eco request 1 1105 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 1109 the user account with a predetermined amount of ecos based ii 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(transactionId) 14 User user = transaction.getUser() 15 Merchant merchant = transaction.getMerchant() 16 long ecoUsage = transaction.getEcoUsage() 17 long bonusBlockUsage = transaction.getBonusBlockUsage() 18 long amountPaidInCash = transaction.getAmountPaidInCash() 19 Try {
20 beginTransaction() 21 user.debitEco(ecoUsage) 22 user.debitBonusBlock(bonusBlockUsage) 23 user.creditEco(amountPaidInCash, merchant) 24 commitTransaction();
25 I catch (Exception) {
26 rollbackTransaction();
27 return false;
28 }
29 [0 0 159] 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 [0 0160] 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 1 implementations, the merchant may display and/or print 1112 the ecos information for 2 the user via an ecos transaction receipt. The merchant may send a payment request 1113 3 to the merchant's acquirer 1114, which may ask the entity to process the transaction. In 4 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 6 sending a transaction request 1116 to a bank entity 1117 (e.g. the user's issuing bank, 7 another acquirer, and/or the like). The bank may send a transaction response 1118 to the 8 acquirer, which may indicate whether or not the transaction was approved and/or 9 processed, or whether the transaction was declined. The acquirer may forward this information to ECO ADVANTAGE via transaction confirmation 1121, which may take a ii form similar to transaction confirmation 1021, or may forward the information to the 12 merchant via transaction confirmation 1119 (which may take a form similar to 13 transaction confirmation 219), who may forward the information via transaction 14 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 16 similar to ttransaction receipt 1024. In some implementations, ECO
ADVANTAGE may 17 also monitor the status of various transactions, and may reverse, retry, and/or otherwise 18 handle incomplete transactions if found in the ECO ADVANTAGE database's records, 19 based on predetermined criteria.
[o 0 1 6 1 ] FIGURES ilb-c show logic flow diagrams illustrating fast commit, cash 21 and credit transactions in example embodiments of the ECO ADVANTAGE. In some 22 implementations, a user may initiate 1150 a transaction with an enrolled merchant, via 23 providing transaction input to a merchant. The merchant may receive the user input and 24 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, 26 ECO ADVANTAGE may receive 1125 the request for the user's eco and bonus block 27 balance, and may retrieve from the ECO ADVANTAGE database 1126 the user's 28 available ecos, bonus blocks, and/or the like to determine which and how many ecos and 29 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
31 may debit 1128 the ecos and/or bonus blocks used in the transaction from the user's 1 account, and may credit the user's account with a predetermined amount of new ecos, 2 which may be based on the transaction amount (e.g. both the cash payment and the 3 pending credit/debit card payment). ECO ADVANTAGE may also update the merchant 4 account and transaction records 1129 using the information in 1110 and/or like information to add the transaction to the ECO ADVANTAGE database and to update the 6 merchant's records based on the transaction data (e.g. update information described in 7 ino). ECO ADVANTAGE may generate and send 1130 a response to the merchant 8 indicating the user's eco and/or bonus block balances and/or like transaction 9 information. After receiving 1131 the response, the merchant may generate and send a transaction receipt 1132 to the user containing the data from the transaction (e.g.
ii transaction total, amount paid with cash, amount paid with a credit/debit card, amount 12 of ecos and/or bonus blocks used, and/or the like), which may be sent and received 1133 13 by the user.
14 [00162] In some implementations, the merchant may also generate and send a payment request 1134 with the user's payment information, the transaction balance 16 after subtracting the applied ecos and/or bonus blocks and the partial cash payment 17 from the original transaction amount, and/or like information to an acquirer for 18 procurement. In some implementations the acquirer may receive 1135 the user's 19 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 21 from the user's issuing bank.
22 [00163] If the acquirer can successfully procures the funds 1137, the acquirer may 23 obtain the funds 1138 and may send a confirmation to the merchant (and in some 24 implementations, to ECO ADVANTAGE) indicating that the transaction was successfully processed. In some implementations the merchant may, if it receives a notification 1139 26 indicating a successful transaction, print and/or display a transaction receipt 1140 for 27 the user, and may generate 1141 and send 1142 a transaction confirmation message to 28 ECO ADVANTAGE indicating that the transaction was successful. ECO ADVANTAGE
29 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 31 as completed.
1 [o 0 1 64 ] 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 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. the io user's record, the merchant's record and/or the like) as also being incomplete 1149. In ii some implementations, ECO ADVANTAGE may also monitor the status of various 12 transactions, and may reverse, retry, and/or otherwise handle incomplete transactions if 13 found in the ECO ADVANTAGE database's records, based on predetermined criteria.
14 [00165] FIGURE 12a shows a data flow diagram illustrating fast commit, cash only transactions in example embodiments of the ECO ADVANTAGE. In some 16 implementations, a user 1201 may send a transaction initiation request 1203 to the 17 merchant 1204 using the merchant's PoS device and/or a user electronic device 1202. In 18 some implementations, sensitive information (e.g. the user PIN and/or the like) may be 19 encrypted. In some implementations the user may also provide a cash payment to the merchant covering the entirety of the remaining transaction balance once the user's ecos 21 and/or bonus blocks are applied. In some implementations, the cash payment may also 22 be a check, gift coupon, pre-paid gift voucher, community scrip, electronic fund transfer, 23 a money card, money order, bank transfer, bank payment slip, and/or a like payment 24 method. In some implementations, the merchant may send an eco request 1205 to the ECO ADVANTAGE 1206. In some implementations, eco request 1205 may take a form 26 similar to eco request 206. ECO ADVANTAGE may look up the user's and merchant's 27 records using the user ID (UID) and the merchant ID 1207, respectively, and may 28 determine which and how many ecos and bonus blocks the user may apply to his 29 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 31 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 the merchant account record 1209, including updating BI information, transaction data, 6 the merchant's usage schedule, atmospherics, and/or the like.
7 [00166] 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 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 [0016 7] FIGURE 12b shows a logic flow diagram illustrating fast commit, cash only 14 transactions in example embodiments of the ECO ADVANTAGE. In some 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, 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, and may credit the user's account with a predetermined amount of new ecos, which may 26 be based on the cash payment).
27[o 0168] ECO ADVANTAGE may also update the merchant account and transaction 28 records 1219 using the information from 1209 and/or like information to add the 29 transaction to the ECO ADVANTAGE database and to update the merchant's records 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 1 user's eco and/or bonus block balances and/or like transaction information.
After 2 receiving 1221 the response, the merchant may generate and send a transaction receipt 3 to the user containing the data from the transaction (e.g. transaction total, amount paid 4 with cash, amount of ecos and/or bonus blocks used, and/or the like). When the user 5 receives 1222 the transaction receipt, the user may pay cash 1223 to the merchant. The 6 merchant may receive the cash payment 1224 from the user, which may cover the 7 transaction balance after the user's qualifying ecos and bonus blocks have been applied.
8 The merchant may credit 1225 the cash payment to the merchant's bank account via 9 depositing the cash in the merchant's bank account.
10 [co co 16 9 ] In some implementations, ECO ADVANTAGE and/or the merchant may 11 prompt the user to confirm after the transaction has been committed. In such 12 implementations, if the user confirms the transaction, the user may receive transaction 13 receipt 1211 and may pay for the transaction. If the user declines the transaction, ECO
14 ADVANTAGE may reverse the committed transaction information in the ECO
15 ADVANTAGE database.
16 [00170] FIGURE 13a shows a data flow diagram illustrating slow commit, cash 17 only transactions in example embodiments of the ECO ADVANTAGE. In some 18 implementations, a user 1301 may send a transaction initiation request 1303 to the 19 merchant 1304 using the merchant's PoS device and/or a user electronic device 1302. In 20 some implementations, sensitive information (e.g. the user PIN and/or the like) may be 21 encrypted. In some implementations, the merchant may send an eco request 1305 to the 22 ECO ADVANTAGE 1306. In some implementations, eco request 1305 may take a form 23 similar to eco request 206.
24 [00171] ECO ADVANTAGE may look up the user's and merchant's records using 25 the user ID (UID) and the merchant ID 1307, respectively, and may determine which 26 and how many ecos and bonus blocks the user may apply to his transaction (e.g. based 27 on the merchant's eco schedule, the user's eco and bonus block balances, and/or the 28 like), and may determine the state of a user confirmation setting. If the confirmation 29 setting is set to "true," ECO ADVANTAGE may require the user to confirm his 30 transaction before initiating any portion of it. In some implementations ECO
31 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 1309 the ecos information for the user, who may review the information 3 1310 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 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 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 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 to transaction receipt 1211.
21 [00173] FIGURE 1313 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 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 may be applied to the current transaction, as well as to determine the user's 31 confirmation setting. If the confirmation setting is off 1319, 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 1321 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 transaction. The user may confirm 1322 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 [ o co 174] 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 and/or bonus blocks have been applied. The merchant may credit 1324 the cash ii 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 1325 the transaction receipt, and ECO ADVANTAGE may debit the used ecos and/or bonus blocks from the user's balances 1326 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 1327 using the 18 information from 1314 and/or like information and ECO ADVANTAGE's transaction 19 records in order to update the merchant and transaction data stored in the ECO
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 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:
W POST / eco_schedule_request.php HTTP/1.1 31 Host: www.ECOADVANTAGEprocess.com 1 Content-Type: Application/XML
2 Content-Length: 788 3 <?XML version = "1.0" encoding = "UTF-8"?>
4 <ecoScheduleRequest>
<partnerId>154</partnerId>
6 <deviceId>579524552</deviceId>
7 <userId>102557952</userId>
8 <userAuth>da6c5cdf4e90b2961873f7b2e863415</userAuth>
9 <origDocNumber></origDocNumber>
M <nsu>572052</nsu>
11 <mcc>6432</mcc>
12 <transactionAmount>100.0</transactionAmount>
M <minTransactionSize>100</minTransactionSize>
14 <maxTransactionSize>5000</maxTransactionSize>
M <transactionSize>1</transactionSize>
M <productData>
17 <sku>56673858</sku>
M <sku>56673953</sku><description>television</description>
19 <sku>56685901</sku>
20 </productData>
21 <dateTime>03/07/2013 03:39 PM</dateTime>
22</ecoScheduleRequest>
23 [00176] In some implementations, ECO ADVANTAGE may look up the partner in 24 the ECO ADVANTAGE database using the partner's ID 1404, and may retrieve the 25 partner's eco schedule for bulk amounts. In some implementations the eco schedule 26 may be based on transaction and historic data, atmospherics, and/or the like. ECO
27 ADVANTAGE may send an eco schedule response 1405 to the partner containing eco 28 schedules and/or the like. In some implementations the eco schedule response 1405 29 may take a form similar to the following:
W POST /eco_schedule_response.php HTTP/1.1 31 Host: www.ECOADVANTAGEprocess.com 32 Content-Type: Application/XML
33 Content-Length: 788 34<?XML version = "1.0" encoding =
35<ecoScheduleResponse>
1 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
2 <transactionId>635467</transactionId>
3 <partnerId>154</partnerId>
4 <ecoScheduleList>
<ecoUsage>
6 <sku>56673858</sku>
7 <quantity>100</quantity>
8 <percentage>15</percentage>
9 </ecoUsage>
<ecoUsage>
11 <sku>56673953</sku>
12 <description>television</description>
13 <quantity>500</quantity>
14 <percentage>20</percentage>
</ecoUsage>
16 <ecoUsage>
17 <sku>56685901</sku>
18 <quantity>1000</quantity>
19 <percentage>30</percentage>
</ecoUsage>
21 </ecoScheduleList>
22 <startDateTime>03/03/2013 00:00 AM</startDateTime>
23 <endDateTime>04/04/2013 23:59 PM</endDateTime>
24 <dateTime>02/02/2013 03:39 PM</dateTime>
</ecoScheduleResponse>
26 [00177] The partner may use the information in the response to create a 27 product/service bulk amount 1406 based on the promoter's eco schedule and/or other 28 ECO ADVANTAGE parameters.
29 [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 31 to employees and/or the like as part of an incentive program (e.g. as bonuses, rewards, 32 and/or the like). In some implementations partners may open credit lines for 33 employees, wherein the credit line may be equal to an amount of ecos given to 34 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) 1 in products and/or services, with SRP. In some implementations consumers may also be 2 able to pay parts of transactions with partners with ecos.
3 [00179] In other implementations, the partner may also have access to a B2B
4 Marketplace interface (e.g. a website, application, and/or the like) which may allow the 5 partner to launch new products, and/or provide like information.
6 [00180] In some implementations ECO ADVANTAGE may provide a merchant 7 with an allotment of ecos, bonus blocks, and/or the like to be used with participating 8 partners. In some implementations the merchant may receive such allotments once (e.g.
9 after meeting a milestone, e.g. providing a predetermined amount of ecos to its io consumers and/or the like, after enrolling, and/or the like), or more than once over a ii period of time (e.g. weekly, monthly, annually, and/or the like, at some interval if the 12 merchant meets predefined ECO ADVANTAGE criteria, and/or the like). In some 13 implementations, a merchant 1407 may use the allotment of ecos to purchase a product 14 and/or service from the partner, via choosing 1408 a product and/or service available 15 for purchase from the partner. The partner may send an eco request 1409 to ECO
16 ADVANTAGE in order to get the merchant's eco balance, updated partner eco 17 schedules, and/or the like. in some implementations eco request 1409 may take a form 18 similar to the following:
19 POST /eco_request.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<ecoRequest>
25 <partnerId>154</partnerId>
26 <merchantId>2033</merchantId>
27 <transactionAmount>100.0</transactionAmount>
28 <productData>
29 <sku>56673953</sku>
W </productData>
31 <dateTime>03/07/2013 03:39 PM</dateTime>
32</ecoRequest>
1 [00181] ECO ADVANTAGE may look up 1410 the merchant to ensure it has an 2 account in the ECO ADVANTAGE database, and to look up the partner for its available 3 schedules and/or the like. In some implementations Grails code for looking up the 4 merchant and partner may take a form similar to the following:
def partner = Partner.get(params.partnerId);
6 if (!partner) {
7 log.warn("Partner not found with value '${params.partnerId}'");
8 return sendError('exception.partner.not.found');
9 }elseif (!partner.enabled 11 !partner.confirmed) {
log.warn("Partner inactive with value '${params.partnerId}'");
11 return sendError('exception.partner.inactive');
12 1 elseif (partner.accountLocked) {
M log.warn("Partner account locked with value 14 '${params.partnerId}'");
return sendError('exception.partner.locked');
18 def schedule = partner.getSchedules() def merchant = Merchant.get(params.merchantId);
21 if (!merchant) {
22 log.warn("Merchant not found with value '${params.merchant}'");
23 return sendError('exception.merchant.not.found');
24 1 elseif (!merchant.enabled 11 !merchant.confirmed) {
log.warn("Merchant inactive with value '${params.merchant}'");
26 return sendError('exception.merchant.inactive');
27 1 elseif (merchant.accountLocked) {
28 log.warn("Merchant account locked with value 29 '${params.merchant}'");
return sendError('exception.merchant.locked');
33 def productData = merchant.getProductData() def balanceForPartner = getBalanceForPartner(transaction.merchant, 36 transaction.partner) 1 def amountOfEcos = calculateValueToPayWithEco(transaction, schedule, 2 productData, balanceForPartner) 3 [00182] ECO ADVANTAGE may send an eco response 1411 to the partner with the 4 requested information. In some implementations, eco response 1411 may take a form similar to the following:
6 POST /eco_response.php HTTP/1.1 7 Host: www.ECOADVANTAGEprocess.com 8 Content-Type: Application/XML
9 Content-Length: 788 <?XML version = "1.0" encoding = "UTF-8"?>
11 <ecoResponse>
12 <partnerId>154</partnerId>
13 <merchantId>2033</merchantId>
14 <transactionId>635467</transactionId>
<transactionAmount>100.0</transactionAmount>
16 <ecoSaving>20%</ecoSaving>
17 <ecoBalance>1091</ecoBalance>
18 <amountDueInDollars>77.0</amountDueInDollars>
19 <ecoUsage>23</ecoUsage>
<dateTime>03/07/2013 03:39 PM</dateTime>
21 <ecoResponse>
22 [0 0183] The partner may send a transaction confirmation message 1412 to the 23 merchant indicating the transaction balance and/or like transaction information, and 24 prompting the merchant to confirm the transaction. In some implementations, the transaction confirmation message 1412 may take a form similar to the following:
26 POST /transaction_confirmation.php HTTP/1.1 27 Host: www.ECOADVANTAGEprocess.com 28 Content-Type: Application/XML
29 Content-Length: 788 <?XML version = "1.0" encoding =
31 <transactionConfirmation>
32 <partnerId>154</partnerId>
33 <merchantId>2033</merchantId>
34 <transactionId>635467</transactionId>
<status>Approved</status>
1 <dateTime>03/07/2013 03:39 PM</dateTime>
2 </transactionConfirmation>
3 [00184] The merchant may confirm 1413 the transaction and the use of ecos 4 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 6 some implementations, the partner may receive a transaction confirmation from the 7 acquirer indicating whether or not the transaction was successful or not, and may 8 forward this transaction confirmation via a message 1415 to ECO ADVANTAGE.
In some 9 implementations, ECO ADVANTAGE may, upon receiving a confirmation that the transaction was successful, debit the ecos used for the transaction from the merchant's ii account 1416, may credit the merchant's account with a new predetermined amount of 12 ecos (the amount based at least partially on the amount the merchant pays for the 13 transaction), and may update the merchant's balance. IN some implementations, 14 updating the merchant's balance may take a form similar to the following:
Transaction transaction = Transaction.get(transactionId) 16 Merchant merchant = transaction.getMerchant() 17 Partner partner = transaction.getPartner() 18 long ecoUsage = transaction.getEcoUsage() 19 long bonusBlockUsage = transaction.getBonusBlockUsage() long amountDueInDollars = transaction.getAmountDueInDollars() 22 Try {
23 beginTransaction() 24 merchant.debitEco(ecoUsage) user.debitBonusBlock(bonusBlockUsage) 26 merchant.creditEco(amountDueInDollars, partner) 27 commitTransaction();
28 I catch (Exception) {
29 rollbackTransaction();
1 return false;
2}
3 [00185] ECO ADVANTAGE may also update the partner's account record and 4 transaction records, including creating a transaction record, updating the partner's BI
information, transaction data, usage schedules using the transaction's date, time and 6 atmospherics, and/or the like. In some implementations, Grails code for updating 7 partner data may take a form similar to the following:
8 Transaction transaction = Transaction.get(transactionId) 9 Partner partner = transaction.getPartner() M Merchant merchant = transaction.getMerchant() 11 long ecoUsage = transaction.getEcoUsage() 12 long bonusBlockUsage = transaction.getBonusBlockUsage() M
14 def historyTransaction = new HistoryTransaction(transaction, partner, merchant, M ecoUsage, bonusBlockUsage) M historyTransaction.save() 17 [00186] FIGURES 14b-c show logic flow diagrams illustrating merchant and 18 partner transactions in example embodiments of the ECO ADVANTAGE. In some 19 implementations, before a transaction, a partner may generate and send 1418 a request 20 to ECO ADVANTAGE for its eco schedule information. ECO ADVANTAGE may receive 21 1419 the request for the partner's eco schedules, and may look up the partner's record 22 using the partner ID included in the request. ECO ADVANTAGE may retrieve the 23 partner's eco schedules and/or like partner information and use them to calculate the 24 eco schedule to provide per bulk amount of the partner's products and/or services. ECO
25 ADVANTAGE may generate and send 1421 a schedule response to the partner, who may 26 receive the eco schedule response 1422 and may use the eco schedule per bulk amount 27 received to create and/or update product and service bulk amounts.
28 [00187] In some implementations, a merchant may, at some point, initiate a 29 transaction 1423 with a partner via choosing products and/or services to purchase. The 30 partner may obtain 1424 the transaction information from the merchant, and may 31 generate and send an eco request to ECO ADVANTAGE. ECO ADVANTAGE may receive 32 the eco request 1425 from the partner and may look up the partner and the merchant 1 using the partner and merchant IDs, respectively. If a partner record is not found, ECO
2 ADVANTAGE may prompt the partner to enroll in ECO ADVANTAGE. If a partner 3 record is found 1426, ECO ADVANTAGE may determine if a record for the merchant 4 can be found. If the merchant record 1427 is not found, ECO ADVANTAGE may prompt 5 the merchant to enroll in ECO ADVANTAGE (see FIGURES 4a-c for further detail). If 6 the merchant's record can be found, ECO ADVANTAGE may retrieve 1429 the 7 merchant's eco balance, and may use it to determine the number of ecos that can be 8 applied to the transaction amount. ECO ADVANTAGE may also retrieve the partner's 9 eco schedules, bulk amounts, and/or the like, and may send the partner and merchant 10 data to the partner via an eco response 1430 to the merchant. The merchant may receive 11 1431 the eco response from ECO ADVANTAGE and may prompt the merchant to 12 confirm the transaction given the merchant's eco information and the partner's current 13 bulk amounts. Once the merchant has confirmed 1432 the transaction and the use of 14 ecos, the partner may send 1433 the transaction balance (e.g. the transaction amount 15 minus the ecos applied) to an acquirer for procurement.
16 [00188] In some implementations, if the acquirer notifies the partner 1434 that the 17 procurement was a success, ECO ADVANTAGE may receive a notification indicating a 18 successful transaction 1438, and may create and store a record of the transaction in the 19 ECO ADVANTAGE database. ECO ADVANTAGE may debit 1439 the ecos used in the 20 transaction from the merchant's account, and may credit the merchant's account with a 21 predetermined amount of ecos based on the transaction amount and marked as being 22 from the promoter. ECO ADVANTAGE may also update the merchant and partner's 23 account records 1440 using the transaction information and/or like information in 1417, 24 and/or like information.
25 [00189] In some implementations, if the procurement was not successful 1434, the 26 merchant may receive a notification of transaction failure 1435, may be prompted to 27 retry the transaction and/or the like. The partner may also forward the notification to 28 ECO ADVANTAGE, which may receive the notice and store a transaction record for the 29 transaction 1436. In some implementations the record may be marked as incomplete so 30 that ECO ADVANTAGE may retry the transaction at a later time. In some 31 implementations ECO ADVANTAGE may also mark 1437 related records (e.g.
merchant 1 and partner records, and/or the like) as being incomplete as a result of the failed 2 transaction.
3 [00190] FIGURE 15a show a data flow diagram illustrating refunding or cancelling 4 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 6 cancel and/or obtain a refund for a transaction 1502, and may provide transaction 7 information (e.g. transaction and/or order ID, the user's ID, and/or the like) to the 8 merchant. In some implementations, sensitive information (e.g. the user PIN
and/or the 9 like) may be encrypted. The merchant may send a cancellation request 1504 to ECO
ADVANTAGE 1505, including the provided transaction information. In some 11 implementations, the cancellation request 1504 may take a forms similar to the 12 following:
13 POST /cancellation_request.php HTTP/1.1 14 Host: www.ECOADVANTAGEprocess.com Content-Type: Application/XML
16 Content-Length: 788 17 <?XML version = "1.0" encoding = "UTF-8"?>
18 <cancellationRequest>
19 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
<merchantId>2033</merchantId>
21 <posId>4088</posId>
22 <mcc>6432</mcc>
23 <transactionId>635467</transactionId>
24 <transactionDate>03/06/2013</transactionDate>
<transactionProcessingCode></transactionProcessingCode>
26 <transactionDocNumber></transactionDocNumber>
27 <transactionNsu></transactionNsu>
28 <dateTime>03/07/2013 01:39 PM</dateTime>
29 </cancellationRequest>
[00191] In some implementations, ECO ADVANTAGE may use the transaction ID
31 and/or other provided data 1506 in order to locate the transaction record in the ECO
32 ADVANTAGE database. In some implementations Grails code for locating the 33 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 '${params.transactionIc1}'.") return sendErroWexception.transaction.not.found');
6 1 elseif (!transaction.isCancellable()) {
7 log.warn("Transaction '${params.transactionId}' cannot be 8 cancelled.") 9 return sendErroWexception.transaction.not.cancellable');
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 take a form similar to the following:
M def amountDueInDollars = transaction.amountDueInDollars 17 def newEcos = transaction.newEcos M def usedEcos = transacton.usedEcos 19 def usedBonusBlocks = transacton.usedBonusBlocks [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:
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"?>
<cancellationResponse>
31 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
32 <transactionId>635467</transactionId>
33 <AmountToRefundUser4{amountDueInDollars}</AmountToRefundUser>
34 <EcosToRefundUser4{usedEcos}</EcosToRefundUser>
<BonusBlocksToRefundUser4{usedBonusBlocks}</BonusBlocksToRefundUser>
1 </cancellationResponse>
2 [00194] The merchant may print and/or display 1509 the amount of ecos to be 3 refunded, the amount of real currency to be refunded, the amount of ecos to be 4 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 6 cancellation transaction 1510, and the merchant may send a refund request 1511 to its 7 acquirer 1512 and/or a like entity in order to process the transaction. In some 8 implementations, refund request 1511 may take a form similar to the following:
9 POST /refund_request.php HTTP/1.1 M Host: www.ECOADVANTAGEprocess.com 11 Content-Type: Application/XML
12 Content-Length: 788 M<?XML version = "1.0" encoding = "UTF-8"?>
14 <refundRequest>
M <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
M <transactionId>635467</transactionId>
17 <merchantId>2033</merchantId>
M <posId>4065</posId>
19 <amountToBeRefunded>77.0</amountToBeRefunded>
20 <dateTime>03/07/2013 01:39 PM</dateTime>
21 </refundRequest>
22 [00195] The acquirer and/or like entity may authenticate the request 1513 and may 23 cancel the previous transaction and/or perform like tasks in order to process the 24 cancellation of the previous transaction. In some implementations the acquirer may 25 send a refund response 1514 indicating whether or not the refund transaction was 26 successful or not, and/or the like to the merchant, who may forward the refund response 27 to ECO ADVANTAGE 1515. In some implementations refund response 1514, 1515, and 28 1516 may take a form similar to the following:
29 POST /refund_request.php HTTP/1.1 W Host: www.ECOADVANTAGEprocess.com 31 Content-Type: Application/XML
32 Content-Length: 788 33<?XML version = "1.0" encoding =
34<refundResponse>
1 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
2 <transactionId>635467</transactionId>
3 <merchantId>2033</merchantId>
4 <posId>4065</posId>
<AmountToBeRefunded>77.0</AmountToBeRefunded>
6 <dateTime>03/07/2013 01:39 PM</dateTime>
7 <approved>true</approved>
8 </refundResponse>
9 [00196] In some implementations the acquirer may also send a refund response 1516 to ECO ADVANTAGE. In some implementations ECO ADVANTAGE may recredit ii 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 Grails code for updating the user's balances may take a form similar to the following:
16 Transaction transaction = Transaction.get(transactionId) 17 User user = transaction.getUser() 19 Try {
beginTransaction() 21 user.creditEco(transaction.usedEcos) 22 user.creditBonusBlocks(transaction.usedBonusBlocks) 23 user.debitEco(transaction.newEcos) 24 transaction.refunded = true;
transaction.save() 26 commitTransaction();
27 I catch (Exception) {
28 rollbackTransaction();
29 return false;
}
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 1513 shows a logic flow diagram illustrating refunding or 34 cancelling transactions in example embodiments of the ECO ADVANTAGE. In some 1 implementations, a user may indicate to a merchant a desire to cancel and/or refund a 2 transaction 1519. The merchant may obtain the request for a refund 1520 and may 3 generate and send a request for the transaction's information to ECO
ADVANTAGE, 4 using the transaction ID and/or other data provided by the user. ECO
ADVANTAGE
5 may receive 1521 the request for information about the transaction and may use the 6 transaction ID and/or like information 1522 in order to locate the proper transaction 7 record in the ECO ADVANTAGE. ECO ADVANTAGE may determine from the 8 transaction record 1523 the amount charged to the user, the amount of ecos and/or 9 bonus blocks the user spent in the transaction, the amount of ecos the user gained from 10 the transaction, and/or the like. ECO ADVANTAGE may then generate and send a 11 response 1524 to the merchant with the information determined from the transaction 12 record.
13 [o 0199] The merchant, upon receiving the response 1525, may print and/or display 14 the information received for the user to review, and may prompt the user to confirm the 15 refund and/or transaction cancellation. If the user authenticates and/or otherwise 16 confirms 1526 the transaction based on the displayed information, the merchant may 17 send a message 1527 to an acquirer and/or like payment entity in order to have the 18 refund transaction processed. In some implementations, the acquirer may receive 1528 19 the refund request, may authenticate 1529 the request, and may cancel 1530 the original 20 payment transaction.
21 [o 0200] If the cancellation is successful 1531, the acquirer may send a notification 22 1532 to the merchant indicating success in processing the refund. The merchant may 23 receive the notification 1533, may forward the confirmation to ECO
ADVANTAGE, and 24 the user may receive from the merchant a transaction receipt 1534 indicating the refund 25 confirmation and/or further transaction details. In some implementations, ECO
26 ADVANTAGE may receive the transaction message, and may save the confirmation as a 27 transaction record in the ECO ADVANTAGE database 1535 for future reference.
In some 28 implementations, ECO ADVANTAGE may also re-credit the user's account with the ecos 29 and/or bonus blocks used in the cancelled transaction 1526, may rescind any ecos given 30 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 1538 to the merchant, who may receive 1539 the 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 later time. ECO ADVANTAGE may also mark all related records (e.g. transaction ii 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 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 $o, but may require a wait time for 18 appointments 1607 of six or more months, may only allow a physician to earn 1609 $10 19 per visit, and may cost $o to a health insurance provider 1610.
[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.
[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 $8o 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 $80 to a health insurance provider if the user is insured, and provide $130 in earnings 2 (post-tax) to a physician per visit.
3 [0 0 2 05] 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 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 $8o per visit 9 if uninsured (along with 120 ecos), and may pay only $o and 120 ecos per visit if insured, and if the user's insurance will refund up to $8o 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 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 $8o, which 17 would be the same cost if the patient were able to afford private health insurance.
18 [co o 2 co 6] FIGURES 22a-b show block diagrams illustrating checking into ECO
19 ADVANTAGE in some embodiments of an ECO ADVANTAGE. In some 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 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 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 2209 to ECO
1 ADVANTAGE. In some implementations ECO ADVANTAGE may retrieve eco statistics 2 for the merchant 2210, such as the total number of ecos used from and/or at the 3 merchant, the merchant's current eco schedule (and/or the schedule within a specified 4 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 6 send the information to the user via an econometer response 2212. The user may then 7 send a check-in request 2213 to ECO ADVANTAGE, which may include user 8 identification information, the date and time of the check-in, the GPS
coordinates of the 9 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.
ii Facebook, Twitter, and/or the like), and/or may provide the user the opportunity to 12 choose social networking websites to share the check-in data with. ECO
ADVANTAGE
13 may also send a check-in confirmation 2215 to the user to indicate whether or not the 14 check-in was successful or not.
[00207] In some implementations, ECO ADVANTAGE may use a Telemetry 16 component to pull information from current real-time transactions and historic data 17 about users, merchants, transactions, ecos, bonus blocks, donation, eco calculations, 18 and/or the like.
19 [00208] Using the BI and the analytics components in conjunction with the Telemetry component, ECO ADVANTAGE may process these types of data, and may 21 produce individual and aggregated trend and skew per transaction data, user, merchant, 22 eco schedule, usage schedule, region, category, grand-total entities data, and/or the like.
23 ECO ADVANTAGE may also use these components to compare this trend and skew data 24 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 26 to trigger immediate action mechanisms on various components and entities, including 27 the Eco Schedule Calculation Component, Merchant Managers, Economic Promoters, 28 Merchants, Eco and Usage Schedules, and/or the like, in order to keep delivering the 29 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 31 Component. The Merchant Information Aggregation Component, and the Merchant and 1 User Enrollment Components. ECO ADVANTAGE may also use the Telemetry and/or 2 other components for calibration of thresholds.
3 [o 0210] In some implementations, an Econometer Component may allow ECO
4 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 6 entities as needed.
7 [00211] In some implementations ECO ADVANTAGE may use the Econometer 8 Component and/or other components to pull information from current real-time 9 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 ii Econometer Component to distribute this data to all available devices and entities.
12 [00212] For example, in some implementations, ECO ADVANTAGE may use this 13 component to facilitate communications between merchant and user entities via the 14 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 16 components as an Eco Calculator (e.g., for specific merchants, for specific entities as a 17 whole, and/or the like). In some implementations ECO ADVANTAGE may also use the 18 component to calculate current and/or near future merchant eco schedules, in numeric 19 and figurative representations.
[o 0213] In some implementations ECO ADVANTAGE may use this component to 21 facilitate communications from ECO ADVANTAGE to a user via his mobile device, a 22 website, SMS, Push msg, email, PoS, and/or like forms of communication. ECO
23 ADVANTAGE may also use the component to keep track of each user's total transaction 24 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 26 allow ECO ADVANTAGE to generate and/or provide reports of all these types of data.
27 [00214] In some implementations ECO ADVANTAGE may use this component to 28 facilitate communications from ECO ADVANTAGE to a merchant via a merchant's 29 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 1 components to calculate transaction usage, ecos usage, bonus block usage, aggregated 2 and by period, show graphs, %, balances, and/or like values, and may use the 3 component to generate and/or provide reports of all these types of data.
4 [00215] In some implementations ECO ADVANTAGE may also use the component 5 to, via a mobile application, a website, and/or the like, provide the aggregated overall 6 grand-total ecos usage (e.g., the total amount everybody already saved using the ECO
7 ADVANTAGE SYSTEM to date), and/or like statistics to entities on ECO
ADVANTAGE.
8 [ o o 216 ] Figure 22b demonstrates another exemplary implementations of checking 9 into ECO ADVANTAGE and searching for merchants.
10 ECO ADVANTAGE Controller 11 [o o 217] FIGURE 23 shows a block diagram illustrating embodiments of a ECO
12 ADVANTAGE controller. In this embodiment, the ECO ADVANTAGE controller 2301 13 may serve to aggregate, process, store, search, serve, identify, instruct, generate, match, 14 and/or facilitate interactions with a computer through commerce and mutual benefit 15 technologies, and/or other related data.
16 [00218] Typically, users, which may be people and/or other systems, may engage 17 information technology systems (e.g., computers) to facilitate information processing.
18 In turn, computers employ processors to process information; such processors 2303 19 may be referred to as central processing units (CPU). One form of processor is referred 20 to as a microprocessor. CPUs use communicative circuits to pass binary encoded signals 21 acting as instructions to enable various operations. These instructions may be 22 operational and/or data instructions containing and/or referencing other instructions 23 and data in various processor accessible and operable areas of memory 2329 (e.g., 24 registers, cache memory, random access memory, etc.). Such communicative 25 instructions may be stored and/or transmitted in batches (e.g., batches of instructions) 26 as programs and/or data components to facilitate desired operations. These stored 27 instruction codes, e.g., programs, may engage the CPU circuit components and other 28 motherboard and/or system components to perform desired operations. One type of 29 program is a computer operating system, which, may be executed by CPU on a I computer; the operating system enables and facilitates users to access and operate 2 computer information technology and resources. Some resources that may be employed 3 in information technology systems include: input and output mechanisms through 4 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 6 technology systems may be used to collect data for later retrieval, analysis, and 7 manipulation, which may be facilitated through a database program. These information 8 technology systems provide interfaces that allow users to access and operate various 9 system components.
[co co 2 19 ] In one embodiment, the ECO ADVANTAGE controller 2301 may be ii connected to and/or communicate with entities such as, but not limited to:
one or more 12 users from user input devices 2311; peripheral devices 2312; an optional cryptographic 13 processor device 2328; and/or a communications network 2313.
14 [00220] Networks are commonly thought to comprise the interconnection and interoperation of clients, servers, and intermediary nodes in a graph topology. It should 16 be noted that the term "server" as used throughout this application refers generally to a 17 computer, other device, program, or combination thereof that processes and responds to 18 the requests of remote users across a communications network. Servers serve their 19 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 21 processing and making requests and obtaining and processing any responses from 22 servers across a communications network. A computer, other device, program, or 23 combination thereof that facilitates, processes information and requests, and/or 24 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 26 transfer of information from source points to destinations. A node specifically tasked 27 with furthering the passage of information from a source to a destination is commonly 28 called a "router." There are many forms of networks such as Local Area Networks 29 (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 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 read only memory (ROM) 2306, a random access memory (RAM) 2305, etc.), and/or an ii 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, 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 2312 via the interface bus I/O. In turn, the transceivers may be connected to antenna(s) 21 2375, 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.1in, Bluetooth 24 3.0, FM, global positioning system (GPS) (thereby allowing ECO ADVANTAGE
controller to determine its location)); Broadcom BCM4329FKUBG transceiver chip 26 (e.g., providing 802.1in, Bluetooth 2.1 + EDR, FM, etc.); a Broadcom 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 systemization's circuit pathways. The clock is typically coupled to the system bus and 1 various clock multipliers that will increase or decrease the base operating frequency for 2 other components interconnected in the computer systemization. The clock and various 3 components in a computer systemization drive signals embodying information 4 throughout the system. Such transmission and reception of instructions embodying information throughout a computer systemization may be commonly referred to as 6 communications. These communicative instructions may further be transmitted, 7 received, and the cause of return and/or reply communications beyond the instant 8 computer systemization to: communications networks, input devices, other computer 9 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 ii one another, connected to the CPU, and/or organized in numerous variations employed 12 as exemplified by various computer systems.
13 [00223] The CPU comprises at least one high-speed data processor adequate to 14 execute program components for executing user and/or system-generated requests.
Often, the processors themselves will incorporate various specialized processing units, 16 such as, but not limited to: integrated system (bus) controllers, memory management 17 control units, floating point units, and even specialized processing sub-units like 18 graphics processing units, digital signal processing units, and/or the like. Additionally, 19 processors may include internal fast access addressable memory, and be capable of mapping and addressing memory 2329 beyond the processor itself; internal memory 21 may include, but is not limited to: fast registers, various levels of cache memory (e.g., 22 level 1, 2, 3, etc.), RAM, etc. The processor may access this memory through the use of a 23 memory address space that is accessible via instruction address, which the processor 24 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:
26 AMD's Athlon, Duron and/or Opteron; ARM's application, embedded and secure 27 processors; IBM and/or Motorola's DragonBall and PowerPC; IBM's and Sony's Cell 28 processor; Intel's Celeron, Core (2) Duo, Itanium, Pentium, Xeon, and/or XScale;
29 and/or the like processor(s). The CPU interacts with memory through instruction passing through conductive and/or transportive conduits (e.g., (printed) electronic 31 and/or optic circuits) to execute stored instructions (i.e., program code) according to 1 conventional data processing techniques. Such instruction passing facilitates 2 communication within the ECO ADVANTAGE controller and beyond through various 3 interfaces. Should processing requirements dictate a greater amount speed and/or 4 capacity, distributed processors (e.g., Distributed ECO ADVANTAGE), mainframe, multi-core, parallel, and/or super-computer architectures may similarly be employed.
6 Alternatively, should deployment requirements dictate greater portability, smaller 7 Personal Digital Assistants (PDAs) may be employed.
8 [00224] Depending on the particular implementation, features of the ECO
9 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.
ii Also, to implement certain features of the ECO ADVANTAGE, some feature 12 implementations may rely on embedded components, such as: Application-Specific 13 Integrated Circuit ("ASIC"), Digital Signal Processing ("DSP"), Field Programmable 14 Gate Array ("FPGA"), and/or the like embedded technology. For example, any of the ECO ADVANTAGE component collection (distributed or otherwise) and/or features 16 may be implemented via the microprocessor and/or via embedded components;
e.g., via 17 ASIC, coprocessor, DSP, FPGA, and/or the like. Alternately, some implementations of 18 the ECO ADVANTAGE may be implemented with embedded components that are 19 configured and used to achieve a variety of features or signal processing.
[ 00225] Depending on the particular implementation, the embedded components 21 may include software solutions, hardware solutions, and/or some combination of both 22 hardware/software solutions. For example, ECO ADVANTAGE features discussed 23 herein may be achieved through implementing FPGAs, which are a semiconductor 24 devices containing programmable logic components called "logic blocks", and programmable interconnects, such as the high performance FPGA Virtex series and/or 26 the low cost Spartan series manufactured by Xilinx. Logic blocks and interconnects can 27 be programmed by the customer or designer, after the FPGA is manufactured, to 28 implement any of the ECO ADVANTAGE features. A hierarchy of programmable 29 interconnects allow logic blocks to be interconnected as needed by the ECO
ADVANTAGE system designer/administrator, somewhat like a one-chip programmable 31 breadboard. An FPGA's logic blocks can be programmed to perform the operation of 1 basic logic gates such as AND, and XOR, or more complex combinational operators such 2 as decoders or mathematical operations. In most FPGAs, the logic blocks also include 3 memory elements, which may be circuit flip-flops or more complete blocks of memory.
4 In some circumstances, the ECO ADVANTAGE may be developed on regular FPGAs and then migrated into a fixed version that more resembles ASIC implementations.
6 Alternate or coordinating implementations may migrate ECO ADVANTAGE
controller 7 features to a final ASIC instead of or in addition to FPGAs. Depending on the 8 implementation all of the aforementioned embedded components and microprocessors 9 may be considered the "CPU" and/or "processor" for the ECO ADVANTAGE.
Power Source 11 [00226] The power source 2386 may be of any standard form for powering small 12 electronic circuit board devices such as the following power cells:
alkaline, lithium 13 hydride, lithium ion, lithium polymer, nickel cadmium, solar cells, and/or the like.
14 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 16 capture photonic energy. The power cell 2386 is connected to at least one of the 17 interconnected subsequent components of the ECO ADVANTAGE thereby providing an 18 electric current to all subsequent components. In one example, the power source 2386 is 19 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 21 example, a USB and/or IEEE 1394 connection carries both data and power across the 22 connection and is therefore a suitable source of power.
23 Interface Adapters 24 [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 26 adapter cards, such as but not limited to: input output interfaces (I/O) 2308, storage 27 interfaces 2309, network interfaces 2310, and/or the like. Optionally, cryptographic 28 processor interfaces 2327 similarly may be connected to the interface bus.
The interface 29 bus provides for the communications of interface adapters with one another as well as 1 with other components of the computer systemization. Interface adapters are adapted 2 for a compatible interface bus. Interface adapters conventionally connect to the 3 interface bus via a slot architecture. Conventional slot architectures may be employed, 4 such as, but not limited to: Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, 6 Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal 7 Computer Memory Card International Association (PCMCIA), and/or the like.
8 [o co 2 2 8] Storage interfaces 2309 may accept, communicate, and/or connect to a 9 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 ii as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet 12 Interface) ((Ultra) (Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE), 13 Institute of Electrical and Electronics Engineers (IEEE) 1394, fiber channel, Small 14 Computer Systems Interface (SCSI), Universal Serial Bus (USB), and/or the like.
[00229] Network interfaces 2310 may accept, communicate, and/or connect to a 16 communications network 2313. Through a communications network 2313, the ECO
17 ADVANTAGE controller is accessible through remote clients 2333b (e.g., computers 18 with web browsers) by users 2333a. Network interfaces may employ connection 19 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
21 802.na-x, and/or the like. Should processing requirements dictate a greater amount 22 speed and/or capacity, distributed network controllers (e.g., Distributed ECO
23 ADVANTAGE), architectures may similarly be employed to pool, load balance, and/or 24 otherwise increase the communicative bandwidth required by the ECO
ADVANTAGE
controller. A communications network may be any one and/or the combination of the 26 following: a direct interconnection; the Internet; a Local Area Network (LAN); a 27 Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet 28 (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless 29 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 31 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 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 1394a-b, serial, universal serial bus (USB);
infrared; joystick;
9 keyboard; midi; optical; PC AT; PS/2; parallel; radio; video interface:
Apple Desktop Connector (ADC), BNC, coaxial, component, composite, digital, Digital Visual Interface ii (DVI), high-definition multimedia interface (HDMI), RCA, RF antennae, S-Video, VGA, 12 and/or the like; wireless transceivers: 802.11a/b/g/n/x; Bluetooth;
cellular (e.g., code 13 division multiple access (CDMA), high speed packet access (HSPA(+)), high-speed 14 downlink packet access (HSDPA), global system for mobile communications (GSM), long term evolution (LTE), WiMax, etc.); and/or the like. One typical output device may 16 include a video display, which typically comprises a Cathode Ray Tube (CRT) or Liquid 17 Crystal Display (LCD) based monitor with an interface (e.g., DVI circuitry and cable) 18 that accepts signals from a video interface, may be used. The video interface composites 19 information generated by a computer systemization and generates video signals based on the composited information in a video memory frame. Another output device is a 21 television set, which accepts signals from a video interface. Typically, the video interface 22 provides the composited video information through a video connection interface that 23 accepts a video display interface (e.g., an RCA composite video connector accepting an 24 RCA composite video cable; a DVI connector accepting a DVI display cable, etc.).
[00231] User input devices 2311 often are a type of peripheral device 512 (see 26 below) and may include: card readers, dongles, finger print readers, gloves, graphics 27 tablets, joysticks, keyboards, microphones, mouse (mice), remote controls, retina 28 readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors 29 (e.g., accelerometers, ambient light, GPS, gyroscopes, proximity, etc.), styluses, and/or 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 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 (e.g., cellular, GPS, etc.), video devices (e.g., goggles, monitors, etc.), video sources, ii 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, 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, 18 processors 2326, interfaces 2327, and/or devices 2328 may be attached, and/or 19 communicate with the ECO ADVANTAGE controller. A MC68HC16 microcontroller, 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 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 CryptoNetX 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 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 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 io may be configured wherein the operation of on-chip CPU memory (e.g., registers), RAM, ii 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 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 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) 2315 (operating system); information server component(s) 2316 (information server);
26 user interface component(s) 2317 (user interface); Web browser component(s) 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 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 [o co 2 3 7] The operating system component 2315 is an executable program 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
Nan 9; Be 14 OS; Unix and Unix-like system distributions (such as AT&T's UNIX; Berkley Software 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.
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, 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 communication protocols may be used by the ECO ADVANTAGE controller as a 1 subcarrier transport mechanism for interaction, such as, but not limited to:
multicast, 2 TCP/IP, UDP, unicast, and/or the like.
3 Information Server 4 [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 6 information server such as, but not limited to Apache Software Foundation's Apache, 7 Microsoft's Internet Information Server, and/or the like. The information server may 8 allow for the execution of program components through facilities such as Active Server 9 Page (ASP), ActiveX, (ANSI) (Objective-) C (++), C* and/or .NET, Common Gateway Interface (CGI) scripts, dynamic (D) hypertext markup language (HTML), FLASH, Java, ii JavaScript, Practical Extraction Report Language (PERL), Hypertext Pre-Processor 12 (PHP), pipes, Python, wireless application protocol (WAP), WebObjects, and/or the like.
13 The information server may support secure communications protocols such as, but not 14 limited to, File Transfer Protocol (FTP), HyperText Transfer Protocol (HTTP), Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), messaging protocols 16 (e.g., America Online (AOL) Instant Messenger (AIM), Application Exchange (APEX), 17 ICQ, Internet Relay Chat (IRC), Microsoft Network (MSN) Messenger Service, Presence 18 and Instant Messaging Protocol (PRIM), Internet Engineering Task Force's (IETF's) 19 Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE), open XML-based Extensible Messaging and Presence Protocol 21 (XMPP) (i.e., Jabber or Open Mobile Alliance's (OMA's) Instant Messaging and 22 Presence Service (IMPS)), Yahoo! Instant Messenger Service, and/or the like. The 23 information server provides results in the form of Web pages to Web browsers, and 24 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 26 HTTP request is resolved to a particular information server, the information server 27 resolves requests for information at specified locations on the ECO
ADVANTAGE
28 controller based on the remainder of the HTTP request. For example, a request such as 29 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;
1 that information server might in turn further parse the http request for the 2 "/myInformation.html" portion of the request and resolve it to a location in memory 3 containing the information "myInformation.html." Additionally, other information 4 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 6 other components in a component collection, including itself, and/or facilities of the 7 like. Most frequently, the information server communicates with the ECO
ADVANTAGE
8 database 2319, operating systems, other program components, user interfaces, Web 9 browsers, and/or the like.
[co co 2 3 9] Access to the ECO ADVANTAGE database may be achieved through a ii number of database bridge mechanisms such as through scripting languages as 12 enumerated below (e.g., CGI) and through inter-application communication channels as 13 enumerated below (e.g., CORBA, WebObjects, etc.). Any data requests through a Web 14 browser are parsed through the bridge mechanism into appropriate grammars as required by the ECO ADVANTAGE. In one embodiment, the information server would 16 provide a Web form accessible by a Web browser. Entries made into supplied fields in 17 the Web form are tagged as having been entered into the particular fields, and parsed as 18 such. The entered terms are then passed along with the field tags, which act to instruct 19 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 21 string with the proper join/select commands based on the tagged text entries, wherein 22 the resulting command is provided over the bridge mechanism to the ECO
23 ADVANTAGE as a query. Upon generating query results from the query, the results are 24 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 26 provided to the information server, which may supply it to the requesting Web browser.
27 [00240] Also, an information server may contain, communicate, generate, obtain, 28 and/or provide program component, system, user, and/or data communications, 29 requests, and/or responses.
1 User Interface 2 [0 0241] 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, 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 Macintosh Operating System's Aqua, IBM's OS/2, Microsoft's Windows 11 2000/2003/3.1/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, 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 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 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 program component, system, user, and/or data communications, requests, and/or 31 responses.
1 Web Browser 2 [00243] A Web browser component 2318 is a stored program component that is 3 executed by a CPU. The Web browser may be a conventional hypertext viewing 4 application such as Microsoft Internet Explorer or Netscape Navigator.
Secure Web browsing may be supplied with 128bit (or greater) encryption by way of HTTPS, SSL, 6 and/or the like. Web browsers allowing for the execution of program components 7 through facilities such as ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web 8 browser plug-in APIs (e.g., FireFox, Safari Plug-in, and/or the like APIs), and/or the 9 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 ii and/or with other components in a component collection, including itself, and/or 12 facilities of the like. Most frequently, the Web browser communicates with information 13 servers, operating systems, integrated program components (e.g., plug-ins), and/or the 14 like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.
16 Also, in place of a Web browser and information server, a combined application may be 17 developed to perform similar operations of both. The combined application would 18 similarly affect the obtaining and the provision of information to users, user agents, 19 and/or the like from the ECO ADVANTAGE enabled nodes. The combined application may be nugatory on systems employing standard Web browsers.
21 Mail Server 22 [00244] A mail server component 2321 is a stored program component that is 23 executed by a CPU 2303. The mail server may be a conventional Internet mail server 24 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 26 ASP, ActiveX, (ANSI) (Objective-) C (++), C* and/or .NET, CGI scripts, Java, 27 JavaScript, PERL, PHP, pipes, Python, WebObjects, and/or the like. The mail server 28 may support communications protocols such as, but not limited to: Internet message 29 access protocol (IMAP), Messaging Application Programming Interface 1 (MAPI)/Microsoft Exchange, post office protocol (POP3), simple mail transfer protocol 2 (SMTP), and/or the like. The mail server can route, forward, and process incoming and 3 outgoing mail messages that have been sent, relayed and/or otherwise traversing 4 through and/or to the ECO ADVANTAGE.
[00245] Access to the ECO ADVANTAGE mail may be achieved through a number 6 of APIs offered by the individual Web server components and/or the operating system.
7 [00246] Also, a mail server may contain, communicate, generate, obtain, and/or 8 provide program component, system, user, and/or data communications, requests, 9 information, and/or responses.
Mail Client 11[00247] A mail client component 2322 is a stored program component that is 12 executed by a CPU 2303. The mail client may be a conventional mail viewing application 13 such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook 14 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
16 mail client may communicate to and/or with other components in a component 17 collection, including itself, and/or facilities of the like. Most frequently, the mail client 18 communicates with mail servers, operating systems, other mail clients, and/or the like;
19 e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or 21 responses. Generally, the mail client provides a facility to compose and transmit 22 electronic mail messages.
23 Cryptographic Server 24 [00248] A cryptographic server component 2320 is a stored program component that is executed by a CPU 2303, cryptographic processor 2326, cryptographic processor 26 interface 2327, cryptographic processor device 2328, and/or the like.
Cryptographic 27 processor interfaces will allow for expedition of encryption and/or decryption requests 28 by the cryptographic component; however, the cryptographic component, alternatively, I may run on a conventional CPU. The cryptographic component allows for the 2 encryption and/or decryption of provided data. The cryptographic component allows for 3 both symmetric and asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/or 4 decryption. The cryptographic component may employ cryptographic techniques such as, but not limited to: digital certificates (e.g., X.5o9 authentication framework), digital 6 signatures, dual signatures, enveloping, password access protection, public key 7 management, and/or the like. The cryptographic component will facilitate numerous 8 (encryption and/or decryption) security protocols such as, but not limited to: checksum, 9 Data Encryption Standard (DES), Elliptical Curve Encryption (ECC), International Data Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash ii operation), passwords, Rivest Cipher (RC5), Rijndael, RSA (which is an Internet 12 encryption and authentication system that uses an algorithm developed in 1977 by Ron 13 Rivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA), Secure 14 Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and/or the like.
Employing such encryption security protocols, the ECO ADVANTAGE may encrypt all 16 incoming and/or outgoing communications and may serve as node within a virtual 17 private network (VPN) with a wider communications network. The cryptographic 18 component facilitates the process of "security authorization" whereby access to a 19 resource is inhibited by a security protocol wherein the cryptographic component effects authorized access to the secured resource. In addition, the cryptographic component 21 may provide unique identifiers of content, e.g., employing and MD 5 hash to obtain a 22 unique signature for an digital audio file. A cryptographic component may communicate 23 to and/or with other components in a component collection, including itself, and/or 24 facilities of the like. The cryptographic component supports encryption schemes allowing for the secure transmission of information across a communications network 26 to enable the ECO ADVANTAGE component to engage in secure transactions if so 27 desired. The cryptographic component facilitates the secure accessing of resources on 28 the ECO ADVANTAGE and facilitates the access of secured resources on remote 29 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 31 systems, other program components, and/or the like. The cryptographic component I may contain, communicate, generate, obtain, and/or provide program component, 2 system, user, and/or data communications, requests, and/or responses.
3 The ECO ADVANTAGE Database 4 [o o 249] 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 6 executed by the CPU; the stored program component portion configuring the CPU to 7 process the stored data. The database may be a conventional, fault tolerant, relational, 8 scalable, secure database such as Oracle or Sybase. Relational databases are an 9 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 ii the tables by indexing against the key field; i.e., the key fields act as dimensional pivot 12 points for combining information from various tables. Relationships generally identify 13 links maintained between tables by matching primary keys. Primary keys represent 14 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.
16 [oo 2 5 o] Alternatively, the ECO ADVANTAGE database may be implemented using 17 various standard data-structures, such as an array, hash, (linked) list, struct, structured 18 text file (e.g., XML), table, and/or the like. Such data-structures may be stored in 19 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 21 databases can include a number of object collections that are grouped and/or linked 22 together by common attributes; they may be related to other object collections by some 23 common attributes. Object-oriented databases perform similarly to relational databases 24 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 26 implemented as a data-structure, the use of the ECO ADVANTAGE database 2319 may 27 be integrated into another component such as the ECO ADVANTAGE component 2335.
28 Also, the database may be implemented as a mix of data structures, objects, and 29 relational structures. Databases may be consolidated and/or distributed in countless 1 variations through standard data processing techniques. Portions of databases, e.g., 2 tables, may be exported and/or imported and thus decentralized and/or integrated.
3 [00251] In one embodiment, the database component 2319 includes several tables 4 2319a-k, m-n, p-r.
[00252] A users table 2319a includes fields such as, but not limited to: a user ID, 6 user fname, user lname, user ID type, user auth code, user email, user address, 7 user date created, user pay method, user password, user phone, user interests, 8 user devices, user confirmed, user account locked, user enabled, user username, 9 and/or the like. The user table may support and/or track multiple user accounts on a ECO ADVANTAGE. A merchants table 231913 includes fields such as, but not limited to:
11 merchant ID, merchant name, merchant email, merchant date created, 12 merchant username, merchant password, merchant enabled, 13 merchant account locked, merchant confirmed, merchant phone, merchant contact, 14 merchant open time, merchant website, merchant region, merchant min consumpt, merchant max consumpt, merchant bank, 16 merchant bank agency, merchant bank acct, and/or the like. The merchant table 17 may support and/or track multiple merchant accounts on a ECO ADVANTAGE. An 18 Economic Promoter table 2319c includes fields such as, but not limited to:
ep ID, 19 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 21 Promoter accounts on a ECO ADVANTAGE. A Merchant Agents table 2319d includes 22 fields such as, but not limited to: ma ID, ma name, ma merchants, ma region, 23 ma categories, ma parameters, ma agg info, and/or the like. The Merchant Agent 24 table may support and/or track multiple Merchant Agent accounts on a ECO
ADVANTAGE. A partners table 2319e includes fields such as, but not limited to:
26 partner ID, partner name, partner email, partner date created, partner username, 27 partner password, partner enabled, partner account locked, partner confirmed, 28 partner phone, partner contact, partner open time, partner website, 29 partner region, partner min consumpt, partner max consumpt, partner bank, partner bank agency, partner bank acct, and/or the like. The partner table may 31 support and/or track multiple partner accounts on a ECO ADVANTAGE. An ecos table 1 2319f includes fields such as, but not limited to: eco ID, eco user ID, 2 eco merchant ID, eco expiration, eco donated, and/or the like. The ecos table may 3 support and/or track multiple ecos on an ECO ADVANTAGE. A PoS table 2319g 4 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 6 track multiple PoS devices on a ECO ADVANTAGE. A transactions table 2319h includes 7 fields such as, but not limited to: transaction ID, transaction date, 8 transaction amount, transaction user, transaction merchant, transaction ecos paid, 9 transaction ecos received, transaction payment method, transaction atmospherics, and/or the like. The transaction table may support and/or track multiple transactions ii on a ECO ADVANTAGE. A transaction analytics table 2319i includes fields such as, but 12 not limited to: ta ID, ta date, ta results merchants, ta results transactions, 13 ta results ecos, ta results credit, ta results acquirer, ta results users, 14 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 2319j includes 16 fields such as, but not limited to: account firstname, account lastname, account type, 17 account num, account balance list, billingaddress linei, billingaddress line2, 18 billing zipcode, billing state, shipping preferences, shippingaddress linei, 19 shippingaddress line2, shipping zipcode, shipping state, and/or the like.
The acquirer table may support and/or track multiple acquirer accounts on a ECO
21 ADVANTAGE. An issuers table 2319k includes fields such as, but not limited to:
22 issuer id, issuer name, issuer address, ip address, mac address, auth key, 23 port num, security settings list, and/or the like. The issuer table may support and/or 24 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, 26 bb expiration, bb type, and/or the like. The bonus blocks table may support and/or 27 track multiple bonus blocks on a ECO ADVANTAGE. A regions table 2319n includes 28 fields such as, but not limited to: region ID, region name, region geography, 29 region demographics, region demarcations, region merchants, region users, region partners, region epromoters, region mmanagers, region categories, and/or 31 the like. The regions table may support and/or track multiple regions on a ECO
32 ADVANTAGE. A categories table 2319p includes fields such as, but not limited to:
1 category ID, category interests, category merchants, category users, 2 category region, and/or the like. The categories table may support and/or track 3 multiple categories on a ECO ADVANTAGE. A schedules table 2319q includes fields 4 such as, but not limited to: schedule ID, schedule annual, schedule monthly, schedule weekly, schedule daily, schedule special schedules, schedule entity ID
6 and/or the like. The schedules table may support and/or track multiple eco schedules on 7 a ECO ADVANTAGE. A BI information table 2319r includes fields such as, but not 8 limited to: bi id, bi transactions, bi analytics,and/or the like. The BI
information table 9 may support and/or track BI information on a ECO ADVANTAGE.
[0 0 2 5 3] In one embodiment, the ECO ADVANTAGE database may interact with ii other database systems. For example, employing a distributed database system, queries 12 and data access by search ECO ADVANTAGE component may treat the combination of 13 the ECO ADVANTAGE database, an integrated data security layer database as a single 14 database entity.
[00254] In one embodiment, user programs may contain various user interface 16 primitives, which may serve to update the ECO ADVANTAGE. Also, various accounts 17 may require custom database tables depending upon the environments and the types of 18 clients the ECO ADVANTAGE may need to serve. It should be noted that any unique 19 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 21 controllers (i.e., individual database controllers for each of the above tables). Employing 22 standard data processing techniques, one may further distribute the databases over 23 several computer systemizations and/or storage devices. Similarly, configurations of the 24 decentralized database controllers may be varied by consolidating and/or distributing the various database components 2319a-k, m-n, p-r. The ECO ADVANTAGE may be 26 configured to keep track of various settings, inputs, and parameters via database 27 controllers.
28 [00255] The ECO ADVANTAGE database may communicate to and/or with other 29 components in a component collection, including itself, and/or facilities of the like.
Most frequently, the ECO ADVANTAGE database communicates with the ECO
1 ADVANTAGE component, other program components, and/or the like. The database 2 may contain, retain, and provide information regarding other nodes and data.
3 The ECO ADVANTAGEs 4 [0 0256] The ECO ADVANTAGE component 2335 is a stored program component that is executed by a CPU. In one embodiment, the ECO ADVANTAGE component 6 incorporates any and/or all combinations of the aspects of the ECO ADVANTAGE
that 7 was discussed in the previous figures. As such, the ECO ADVANTAGE affects accessing, 8 obtaining and the provision of information, services, transactions, and/or the like across 9 various communications networks. The features and embodiments of the ECO
ADVANTAGE discussed herein increase network efficiency by reducing data transfer ii requirements the use of more efficient data structures and mechanisms for their transfer 12 and storage. As a consequence, more data may be transferred in less time, and latencies 13 with regard to transactions, are also reduced. In many cases, such reduction in storage, 14 transfer time, bandwidth requirements, latencies, etc., will reduce the capacity and structural infrastructure requirements to support the ECO ADVANTAGE's features and 16 facilities, and in many cases reduce the costs, energy consumption/requirements, and 17 extend the life of ECO ADVANTAGE's underlying infrastructure; this has the added 18 benefit of making the ECO ADVANTAGE more reliable. Similarly, many of the features 19 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
21 ADVANTAGE; such ease of use also helps to increase the reliability of the ECO
22 ADVANTAGE. In addition, the feature sets include heightened security as noted via the 23 Cryptographic components 2320, 2326, 2328 and throughout, making access to the 24 features and data more reliable and secure.
[00257] The ECO ADVANTAGE transforms transaction and user, merchant, and 26 payment data inputs via ECO ADVANTAGE Transaction Processing Component 2341, 27 User Enrollment Component 2342, Merchant Enrollment Component 2343, Eco 28 Schedule Calculation Component 2344, Merchant Information Aggregation and 29 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 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 server extensions, web development environments and libraries (e.g., Microsoft's ActiveX;
ii Adobe AIR, FLEX & FLASH; AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI);
12 MooTools; Prototype; script.aculo.us; Simple Object Access Protocol (SOAP);
13 SWFObject; Yahoo! User Interface; and/or the like), WebObjects, and/or the like. In 14 one embodiment, the ECO ADVANTAGE server employs a cryptographic server to encrypt and decrypt communications. The ECO ADVANTAGE component may 16 communicate to and/or with other components in a component collection, including 17 itself, and/or facilities of the like. Most frequently, the ECO ADVANTAGE
component 18 communicates with the ECO ADVANTAGE database, operating systems, other program 19 components, and/or the like. The ECO ADVANTAGE may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data 21 communications, requests, and/or responses.
22 Distributed ECO ADVANTAGEs 23 [o 0259] The structure and/or operation of any of the ECO ADVANTAGE node 24 controller components may be combined, consolidated, and/or distributed in any number of ways to facilitate development and/or deployment. Similarly, the component 26 collection may be combined in any number of ways to facilitate deployment and/or 27 development. To accomplish this, one may integrate the components into a common 28 code base or in a facility that can dynamically load the components on demand in an 29 integrated fashion.
1 [00260] The component collection may be consolidated and/or distributed in 2 countless variations through standard data processing and/or development techniques.
3 Multiple instances of any one of the program components in the program component 4 collection may be instantiated on a single node, and/or across numerous nodes to improve performance through load-balancing and/or data-processing techniques.
6 Furthermore, single instances may also be distributed across multiple controllers 7 and/or storage devices; e.g., databases. All program component instances and 8 controllers working in concert may do so through standard data processing 9 communication techniques.
[ o 0261] The configuration of the ECO ADVANTAGE controller will depend on the ii context of system deployment. Factors such as, but not limited to, the budget, capacity, 12 location, and/or use of the underlying hardware resources may affect deployment 13 requirements and configuration. Regardless of if the configuration results in more 14 consolidated and/or integrated program components, results in a more distributed series of program components, and/or results in some combination between a 16 consolidated and distributed configuration, data may be communicated, obtained, 17 and/or provided. Instances of components consolidated into a common code base from 18 the program component collection may communicate, obtain, and/or provide data. This 19 may be accomplished through intra-application data processing communication techniques such as, but not limited to: data referencing (e.g., pointers), internal 21 messaging, object instance variable communication, shared memory space, variable 22 passing, and/or the like.
23 [o 0 2 6 2 ] If component collection components are discrete, separate, and/or 24 external to one another, then communicating, obtaining, and/or providing data with and/or to other component components may be accomplished through inter-application 26 data processing communication techniques such as, but not limited to:
Application 27 Program Interfaces (API) information passage; (distributed) Component Object Model 28 ((D)COM), (Distributed) Object Linking and Embedding ((D)OLE), and/or the like), 29 Common Object Request Broker Architecture (CORBA), Jini local and remote application program interfaces, JavaScript Object Notation (JSON), Remote Method 31 Invocation (RMI), SOAP, process pipes, shared files, and/or the like.
Messages sent 1 between discrete component components for inter-application communication or within 2 memory spaces of a singular component for intra-application communication may be 3 facilitated through the creation and parsing of a grammar. A grammar may be 4 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 6 of communication messages within and between components.
7 [o 0263] For example, a grammar may be arranged to recognize the tokens of an 8 HTTP post command, e.g.:
9 w3c -post http://... Valuel 11 [oo 264] where Valuei is discerned as being a parameter because "http://"
is part of 12 the grammar syntax, and what follows is considered part of the post value.
Similarly, 13 with such a grammar, a variable "Valuei" may be inserted into an "http://"
post 14 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 16 syntax description text file as processed by lex, yacc, etc.). Also, once the parsing 17 mechanism is generated and/or instantiated, it itself may process and/or parse 18 structured data such as, but not limited to: character (e.g., tab) delineated text, HTML, 19 structured text streams, XML, and/or the like structured data. In another embodiment, inter-application data processing protocols themselves may have integrated and/or 21 readily available parsers (e.g., JSON, SOAP, and/or like parsers) that may be employed 22 to parse (e.g., communications) data. Further, the parsing grammar may be used 23 beyond message parsing, but may also be used to parse: databases, data collections, data 24 stores, structured data, and/or the like. Again, the desired configuration will depend upon the context, environment, and requirements of system deployment.
26 [o 0265] For example, in some implementations, the ECO ADVANTAGE controller 27 may be executing a PHP script implementing a Secure Sockets Layer ("SSL") socket 28 server via the information server, which listens to incoming communications on a server 29 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 31 from the client device, parse the received JSON-encoded text data to extract information 1 from the JSON-encoded text data into PHP script variables, and store the data (e.g., 2 client identifying information, etc.) and/or extracted information in a relational 3 database accessible using the Structured Query Language ("SQL"). An exemplary 4 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 6 variables, and store the data to a database, is provided below:
7 <?PHP
8 header('Content-Type: text/plain');
// set ip address and port to listen to for incoming data 11 $address = '192.168Ø100';
12 $port = 255;
14 // create a server-side SSL socket, listen for/accept incoming communication m $sock = socket_create(AF_INET, SOCK_STREAM, 0);
m socket_bind(Ssock, $address, $port) or die('Could not bind to address');
17 socket_listen(Ssock);
m $client = socket_accept(Ssock);
// read input data from client device in 1024 byte blocks until end of message 21 do{
22 $input =
23 $input = socket_read(Sclient, 1024);
24 $data .= $input;
} while($input 27 // parse data to extract variables 28 $obj = json_decode(Sdata, true);
// store input data in a database 31 mysql_connect("201.408.185.132",SDBserver,Spassword); // access database server 32 mysql_select("CLIENT_DB.SQL"); // select database to append 33 mysql_query("INSERT INTO UserTable (transmission) 34 VALUES ($data)"); // add data to UserTable table in a CLIENT database mysql_close("CLIENT_DB.SQL"); // close connection to database 1 ?>
3 [00266] Also, the following resources may be used to provide example 4 embodiments regarding SOAP parser implementation:
http://www.xav.com/perl/site/lib/SOAP/Parser.html http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm 7 .IBMDI.doc/referenceguide295.htm 9 [oo 2 67] and other parser implementations:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm .IBMDI.doc/referenceguide259.htm 13 [oo 2 68] all of which are hereby expressly incorporated by reference.
14 [0 0 2 6 9 ] In order to address various issues and advance the art, the entirety of this application for ECO ADVANTAGE MEDIATION APPARATUSES, METHODS AND
16 SYSTEMS (including the Cover Page, Title, Headings, Field, Background, Summary, 17 Brief Description of the Drawings, Detailed Description, Claims, Abstract, Figures, 18 Appendices, and otherwise) shows, by way of illustration, various embodiments in 19 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 21 and/or exclusive. They are presented only to assist in understanding and teach the 22 claimed principles. It should be understood that they are not representative of all 23 claimed innovations. As such, certain aspects of the disclosure have not been discussed 24 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 26 for a portion is not to be considered a disclaimer of those alternate embodiments. It will 27 be appreciated that many of those undescribed embodiments incorporate the same 28 principles of the innovations and others are equivalent. Thus, it is to be understood that 29 other embodiments may be utilized and functional, logical, operational, organizational, structural and/or topological modifications may be made without departing from the 31 scope and/or spirit of the disclosure. As such, all examples and/or embodiments are 32 deemed to be non-limiting throughout this disclosure. Also, no inference should be 1 drawn regarding those embodiments discussed herein relative to those not discussed 2 herein other than it is as such for purposes of reducing space and repetition. For 3 instance, it is to be understood that the logical and/or topological structure of any 4 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 6 limited to a fixed operating order and/or arrangement, but rather, any disclosed order is 7 exemplary and all equivalents, regardless of order, are contemplated by the disclosure.
8 Furthermore, it is to be understood that such features are not limited to serial execution, 9 but rather, any number of threads, processes, services, servers, and/or the like that may execute asynchronously, concurrently, in parallel, simultaneously, synchronously, ii and/or the like are contemplated by the disclosure. As such, some of these features may 12 be mutually contradictory, in that they cannot be simultaneously present in a single 13 embodiment. Similarly, some features are applicable to one aspect of the innovations, 14 and inapplicable to others. In addition, the disclosure includes other innovations not presently claimed. Applicant reserves all rights in those presently unclaimed 16 innovations including the right to claim such innovations, file additional applications, 17 continuations, continuations in part, divisions, and/or the like thereof.
As such, it 18 should be understood that advantages, embodiments, examples, functional, features, 19 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 21 or limitations on equivalents to the claims. It is to be understood that, depending on the 22 particular needs and/or characteristics of a ECO ADVANTAGE individual and/or 23 enterprise user, database configuration and/or relational model, data type, data 24 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 26 flexibility and customization. For example, aspects of the ECO ADVANTAGE
may be 27 adapted for health care, travel services, Accessories, Advertising and Marketing, Animal 28 Clinic and Hospital, Arts and Crafts, Auto Body Shop, Auto Dealer, Auto Electric Shop, 29 Auto Parts Store, Bakery, Beauty Clinic, Book Wholesale, Bookstore, Building Supplies, Camera and Photo, Car-Wash, Ceilings/ Partition, Cell Phone Provider, Children's Store, 31 Chocolate Shop, Clothing Repair, Coffee Shop, Computer and Accessories, Convenience 32 Store, Cosmetics, Costume Shop, Courier Service, Dairy Products, Delicatessen, Diner, 1 Do-It-Yourself Store, Durable Medical Equipment, DVD and Movies, Electrical Parts, 2 Electronic and Video Game, Eletro/electronic Repair and Maintenance, Eyeglasses and 3 Sunglasses, Fabric and Upholstery Store, Fast Graphic Service, Furniture Store, Gas 4 Station, Gift Store, Gourmet and Specially Food Store, Grocery Store, Gym, Hardware Store, Heating and Air Conditioning, Home and Gardening, Home and Kitchen Goods, 6 Home Appliance, Home Improvement, Home Phone Provider, Hotels, Ice Cream 7 Parlour, Janitorial / Cleaning Supplies, Jewelry, Kids Party Place, Kids Tutoring, 8 Language School or Learning Center, Laundry and Dry Cleaning, Leisure and Tourism, 9 Light Fixture, Lingerie and Intimate Apparel, Locksmith, Luggage and Suitcase Store, Men's Fashion, Motels, Motorcycle Dealer, Movie Theater, Moving Service, Musical ii Instrument Shop, Natural Food Store, Nautical Store, Nightclub / Disco, Office 12 Supplies, Paint Store, Party Supply Store, Perfumery, Personal Development Course, 13 Pet Shop, Pharmacy, Plastic Surgery, Refrigeration Shop, Restaurant (all kinds), 14 Rotisserie, Rug and Curtain Shop, School, Shoe Repair, Shoe Store, SPA, Specialty Pharmacy, Sporting Goods, Sport Tickets, Supermarket, Surgical Equipment, Swimwear 16 Fashion, Technical Course, Theaters, Tickets (ShowsConcerts), Toy Store, Visual 17 Communication, Winery, Women's Fashion, and/or the like. While various 18 embodiments and discussions of the ECO ADVANTAGE have included commerce 19 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 21 variety of other applications and/or implementations.
22 [0 0 2 7o ] In some implementations, some embodiments may include:
23 [0 0 2 71] 1. A processor-implemented method for mutual benefits, comprising:
24 receiving a request for a user's transaction value modifier (TVM) balance and a merchant's current TVM schedule from a merchant;
26 receiving a TVM transaction confirmation indicating a transaction has been successfully 27 processed, and TVM transaction data;
28 debiting from a user's account an amount of TVMs received from another merchant in a 29 previous transaction for use in the transaction;
1 crediting to the user's account an amount of TVMs based on the TVM
transaction data;
2 and 3 generating via a processor a TVM transaction record and storing the TVM
transaction 4 data in the TVM transaction record.
[00272] 2. The method of embodiment 1, further comprising:
6 updating via the processor the merchant's current TVM schedule in the database using 7 the TVM record.
8 [00273] 3. The method of embodiment 1, wherein a TVM is an eco, a value 9 identifier, or a subsequent value transaction modifier.
[00274] 4. The method of embodiment 1, wherein the user's TVM balance is ii updated after receiving the TVM transaction confirmation.
12 [00275] 5. The method of embodiment 1, wherein the user's TVM balance is 13 updated before receiving the TVM transaction confirmation.
14 [0 0276] 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 16 transaction amount with a payment device.
17 [00277] 7. The method of embodiment 6, wherein the payment device is one of a 18 credit card, debit card, or prepaid card.
19 [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 21 transaction amount with cash.
22 [0 0279] 9. The method of embodiment 1, wherein the TVM transaction comprises 23 paying at least a portion of the transaction amount in TVMs, at least a portion of the 24 transaction amount with cash, and at least a portion of the transaction amount with a payment device.
26 [00280] 10. The method of embodiment 9, wherein the payment device is one of a 27 credit card, debit card, or prepaid card.
1 [o o 2 8 1] 11. The method of embodiment 1, wherein the credited transaction value 2 modifiers can only be used in subsequent transactions.
3 [0 0 2 82] 12. The method of embodiment ii, wherein the credited transaction value 4 modifiers is marked as originating from the merchant; and wherein the transaction value modifiers cannot be used in subsequent transactions at 6 the merchant from which they originated.
7 [00 2 83] 13. The method of embodiment 1, further comprising:
8 sending the user's TVM balance and the merchant's current TVM schedule to the 9 merchant.
[ o 0 2 84] 14. A processor-implemented method for mutual benefits, comprising:
ii sending to the user the user's TVM balance and an indication that at least some TVMs in 12 the user's TVMs balance will expire;
13 receiving a request to donate expiring TVMs to a designated friend;
14 allocating via a processor the user's expiring TVMs to be donated to the designated friend;
16 sending a TVM donation message to the designated friend;
17 receiving from the designated friend an enrollment request;
18 generating via a processor a new user account for the designated friend;
19 transferring the allocated expiring TVMs to the designated friend's new user account;
and 21 sending a confirmation of the transfer to the user and to the designated friend.
22 [o o 2 85] 15. The method of embodiment 14, further comprising:
23 monitoring the spending of the user's donated TVMs by the designated friend; and 24 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.
26 [o o 2 86] 16. The method of embodiment 14, further comprising:
1 receiving a request from a user for user transaction value modifier (TVM) balance 2 information;
3 [0 o 2 8 7] 17. The method of embodiment 15, wherein the mutual benefit enrollment 4 request further comprises an amount of TVM gifted by an economic promoter.
[00288] 18. The method of embodiment 17, wherein the economic promoter 6 obtains a percentage of the amount of TVMs donated to the friend.
7 [00289] 19. The method of embodiment 18, wherein a merchant manager gifts 8 TVMs to the economic promoter and obtains a percentage of the amount of TVMs gifted 9 to the friend.
[ o 02 9 0 ] 20. A processor-implemented method for mutual benefits, comprising:
11 receiving an indication of preliminary interest in a mutual benefit program;
12 providing to the merchant a mutual benefit enrollment request form;
13 receiving a mutual benefit enrollment request from a merchant for the mutual benefit 14 program;
sending a mutual benefit enrollment form to the merchant;
16 receiving from the merchant a completed mutual benefit enrollment form;
17 sending a request to a merchant agent requesting background material on the merchant;
18 receiving background material on the merchant from the merchant agent;
19 analyzing the background material from the merchant agent;enrolling the merchant in the mutual benefit program if the background material meets predetermined criteria;
21 generating a merchant account for the merchant; and 22 sending the merchant a confirmation of enrollment in the mutual benefits program.
23 [ 0 0291] 21. The method of embodiment 20, further comprising:
24 receiving from a merchant a survey of current point-of-sales (PoS) infrastructure and settings configurations;
26 determining a new PoS configuration for the merchant based on mutual benefit 27 program specifications; and 1 sending the new PoS configuration and the training materials to the merchant for 2 implementation.
3 [ 0 0 2 9 2 ] 22. The method of embodiment 21, further comprising:
4 generating training materials for the new PoS configuration.
[o 0 2 9 3 ] 23. A processor-implemented method for mutual benefits, comprising:
6 receiving a request for a user's value point balance and a merchant's current value point 7 schedule from a merchant;
8 receiving a value point transaction confirmation indicating a transaction has been 9 successfully processed and value point transaction data;
debiting from a user's account an amount of value points received from another ii merchant in a previous transaction for use in the transaction;
12 crediting to the user's account an amount of value points based on the value point 13 transaction data; and 14 generating via a processor a value point transaction record and storing the value point transaction data in the value point transaction record.
16 [ 0 0 2 9 4 ] 24. The method of embodiment 23, further comprising:
17 updating via the processor the merchant's current value point schedule in the database 18 using the value point record.
19 [o 0 2 9 5 ] 25. A processor-implemented method for mutual benefits, comprising:
receiving a product bulk amount from a partner;
21 receiving a request for a merchant's transaction value modifier (TVM) balance and a 22 partner's current TVM schedule from a partner;
23 sending the merchant's TVM balance and the partner's current TVM schedule to the 24 partner;
receiving a TVM transaction confirmation indicating a transaction involving purchasing 26 at least one product bulk amount has been successfully processed and TVM
transaction 27 data;
1 debiting from the merchant's account an amount of TVMs used in the transaction;
2 crediting to the merchant's account an amount of TVM based on the TVM
transaction 3 data;
4 generating via a processor a TVM transaction record and storing the TVM
transaction data in the TVM transaction record; and 6 updating via the processor the merchant's current TVM schedule in the database using 7 the TVM transaction record.
8 [ o 0 2 9 6 ] 26. A processor-implemented method for mutual benefits, comprising:
9 receiving aggregated entity data in a mutual benefits program within a defined geo-demographical region;
ii performing performance analytics on the entity data;
12 determining demarcation indicia to divide a region if the region is overpopulated;
13 splitting the region based on the geo-demographical demarcation indicia into sub-14 regions;
receiving updated demographic and industry data on each sub-region; and 16 generating new merchant categories for each sub-region based on the updated 17 demographic and industry data.
18 [ o o 2 9 7] 27. The method of embodiment 26, wherein the entity is at least one of a 19 merchant or demographic data.
[o 0 2 9 8 ] 28. A processor-implemented method for mutual benefits, comprising:
21 receiving aggregated entity data in a mutual benefits program within a defined geo-22 demographical region;
23 performing performance analytics on the entity data;
24 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;
26 sending a mutual benefit enrollment form to a merchant not enrolled in the mutual 27 benefits program;
1 receiving from the merchant not enrolled in the mutual benefits program a completed 2 mutual benefit enrollment form;
3 enrolling the merchant in the mutual benefits program; and 4 updating the region record in a database to include the enrolled merchant.
[00 2 9 9 ] 29. The method of embodiment 28, wherein the entity is at least one of a 6 merchant or demographic data.
7 [00300] 30. The method of embodiment 28, wherein the enrollment criteria may 8 include the category that the at least one merchant in the region which is over-capacity.
9 [00301] 31. A system for mutual benefits, comprising:
means for receiving a request for a user's transaction value modifier (TVM) balance and ii a merchant's current TVM schedule from a merchant;
12 means for receiving a TVM transaction confirmation indicating a transaction has been 13 successfully processed, and TVM transaction data;
14 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;
16 means for crediting to the user's account an amount of TVMs based on the TVM
17 transaction data; and 18 means for generating via a processor a TVM transaction record and storing the TVM
19 transaction data in the TVM transaction record.
[0030 2 ] 32. The system of embodiment 31, further comprising:
21 means for updating via the processor the merchant's current TVM schedule in the 22 database using the TVM record.
23 [00303] 33. The system of embodiment 31, wherein a TVM is an eco, a value 24 identifier, or a subsequent value transaction modifier.
[00304] 34. The system of embodiment 31, wherein the user's TVM balance is 26 updated after receiving the TVM transaction confirmation.
1 [00305] 35. The system of embodiment 31, wherein the user's TVM balance is 2 updated before receiving the TVM transaction confirmation.
3 [00306] 36. The system of embodiment 31, wherein the TVM transaction 4 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.
6 [o 0307] 37. The system of embodiment 36, wherein the payment device is one of a 7 credit card, debit card, or prepaid card.
8 [00308] 38. The system of embodiment 31, wherein the TVM transaction 9 comprises paying at least a portion of the transaction amount in TVMs and at least a portion of the transaction amount with cash.
11 [00309] 39. The system of embodiment 31, wherein the TVM transaction 12 comprises paying at least a portion of the transaction amount in TVMs, at least a portion 13 of the transaction amount with cash, and at least a portion of the transaction amount 14 with a payment device.
[o 0310] 40. The system of embodiment 39, wherein the payment device is one of a 16 credit card, debit card, or prepaid card.
17 [o0311] 41. The system of embodiment 31, wherein the credited transaction value 18 modifiers can only be used in subsequent transactions.
19 [o 0312] 42. The system of embodiment 41, wherein the credited transaction value modifiers is marked as originating from the merchant; and 21 wherein the transaction value modifiers cannot be used in subsequent transactions at 22 the merchant from which they originated.
23 [00313] 43. The system of embodiment 31, further comprising:
24 means for sending the user's TVM balance and the merchant's current TVM
schedule to the merchant.
26 [00314] 44. A system for mutual benefits, comprising:
27 means for sending to the user the user's TVM balance and an indication that at least 28 some TVMs in the user's TVMs balance will expire;
1 means for receiving a request to donate expiring TVMs to a designated friend;
2 means for allocating via a processor the user's expiring TVMs to be donated to the 3 designated friend;
4 means for sending a TVM donation message to the designated friend;
means for receiving from the designated friend an enrollment request;
6 means for generating via a processor a new user account for the designated friend;
7 means for transferring the allocated expiring TVMs to the designated friend's new user 8 account; and 9 means for sending a confirmation of the transfer to the user and to the designated friend.
11 [ o o 3 15 ] 45. The system of embodiment 44, further comprising:
12 means for monitoring the spending of the user's donated TVMs by the designated 13 friend; and 14 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.
16 [00316] 46. The system of embodiment 44, further comprising:
17 means for receiving a request from a user for user transaction value modifier (TVM) 18 balance information;
19 [o 0317] 47. The system of embodiment 45, wherein the mutual benefit enrollment request further comprises an amount of TVM gifted by an economic promoter.
21 [00318] 48. The system of embodiment 47, wherein the economic promoter 22 obtains a percentage of the amount of TVMs donated to the friend.
23 [00319] 49. The system of embodiment 48, wherein a merchant manager gifts 24 TVMs to the economic promoter and obtains a percentage of the amount of TVMs gifted to the friend.
26 [o 03 2 0 ] 50. A system for mutual benefits, comprising:
27 means for receiving an indication of preliminary interest in a mutual benefit program;
1 means for providing to the merchant a mutual benefit enrollment request form;
2 means for receiving a mutual benefit enrollment request from a merchant for the 3 mutual benefit program;
4 means for sending a mutual benefit enrollment form to the merchant;
means for receiving from the merchant a completed mutual benefit enrollment form;
6 means for sending a request to a merchant agent requesting background material on the 7 merchant;
8 means for receiving background material on the merchant from the merchant agent;
9 means for analyzing the background material from the merchant agent;
means for enrolling the merchant in the mutual benefit program if the background ii material meets predetermined criteria;
12 means for generating a merchant account for the merchant; and 13 means for sending the merchant a confirmation of enrollment in the mutual benefits 14 program.
[o o 3 2 1] 51. The system of embodiment 50, further comprising:
16 means for receiving from a merchant a survey of current point-of-sales (PoS) 17 infrastructure and settings configurations;
18 means for determining a new PoS configuration for the user based on mutual benefit 19 program specifications; and means for sending the new PoS configuration and the training materials to the merchant 21 for implementation.
22 [ 0 o 3 2 2 ] 52. The system of embodiment 51, further comprising:
23 means for generating training materials for the new PoS configuration.
24 [o 0 3 2 3 ] 53. A system for mutual benefits, comprising:
means for receiving a request for a user's value point balance and a merchant's current 26 value point schedule from a merchant;
1 means for receiving a value point transaction confirmation indicating a transaction has 2 been successfully processed and value point transaction data;
3 means for debiting from a user's account an amount of value points received from 4 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 6 point transaction data; and 7 means for generating via a processor a value point transaction record and storing the 8 value point transaction data in the value point transaction record.
9 [00324] 54. The system of embodiment 53, further comprising:
means for updating via the processor the merchant's current value point schedule in the ii database using the value point record.
12 [o o 3 2 5 ] 55. A system for mutual benefits, comprising:
13 means for receiving a product bulk amount from a partner;
14 means for receiving a request for a merchant's transaction value modifier (TVM) balance and a partner's current TVM schedule from a partner;
16 means for sending the merchant's TVM balance and the partner's current TVM
schedule 17 to the partner;
18 means for receiving a TVM transaction confirmation indicating a transaction involving 19 purchasing at least one product bulk amount has been successfully processed and TVM
transaction data;
21 means for debiting from the merchant's account an amount of TVMs used in the 22 transaction;
23 means for crediting to the merchant's account an amount of TVM based on the TVM
24 transaction data;
means for generating via a processor a TVM transaction record and storing the TVM
26 transaction data in the TVM transaction record; and 1 means for updating via the processor the merchant's current TVM schedule in the 2 database using the TVM transaction record.
3 [o o 3 2 6 ] 56. A system for mutual benefits, comprising:
4 means for receiving aggregated entity data in a mutual benefits program within a defined geo-demographical region;
6 means for performing performance analytics on the entity data;
7 means for determining demarcation indicia to divide a region if the region is 8 overpopulated;
9 means for splitting the region based on the geo-demographical demarcation indicia into io sub-regions;
ii means for receiving updated demographic and industry data on each sub-region; and 12 means for generating new merchant categories for each sub-region based on the 13 updated demographic and industry data.
14 [00327] 57. The system of embodiment 56, wherein the entity is at least one of a merchant or demographic data.
16 [0 o 3 2 8 ] 58. A system for mutual benefits, comprising:
17 means for receiving aggregated entity data in a mutual benefits program within a 18 defined geo-demographical region;
19 means for performing performance analytics on the entity data;
means for determining enrollment criteria for enrolling at least one merchant in the 21 mutual benefits program if at least one merchant in the region is over-capacity;
22 means for sending a mutual benefit enrollment form to a merchant not enrolled in the 23 mutual benefits program;
24 means for receiving from the merchant not enrolled in the mutual benefits program a completed mutual benefit enrollment form;
26 means for enrolling the merchant in the mutual benefits program; and 27 means for updating the region record in a database to include the enrolled merchant.
1 [00329] 59. The system of embodiment 58, wherein the entity is at least one of a 2 merchant or demographic data.
3 [00330] 60. The system of embodiment 58, wherein the enrollment criteria may 4 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 6 processor-executable instructions, said instructions executable by a processor to:
7 receive a request for a user's transaction value modifier (TVM) balance and a merchant's 8 current TVM schedule from a merchant;
9 receive a TVM transaction confirmation indicating a transaction has been successfully processed, and TVM transaction data;
ii debit from a user's account an amount of TVMs received from another merchant in a 12 previous transaction for use in the transaction;
13 credit to the user's account an amount of TVMs based on the TVM transaction data; and 14 generate via a processor a TVM transaction record and storing the TVM
transaction data in the TVM transaction record.
16 [0o332] 62. The medium of embodiment 61, further comprising instructions to:
17 update via the processor the merchant's current TVM schedule in the database using the 18 TVM record.
19 [00333] 63. The medium of embodiment 61, wherein a TVM is an eco, a value identifier, or a subsequent value transaction modifier.
21 [00334] 64. The medium of embodiment 61, wherein the user's TVM balance is 22 updated after receiving the TVM transaction confirmation.
23 [00335] 65. The medium of embodiment 61, wherein the user's TVM balance is 24 updated before receiving the TVM transaction confirmation.
[00336] 66. The medium of embodiment 61, wherein the TVM transaction 26 comprises paying at least a portion of the transaction amount in TVMs and at least a 27 portion of the transaction amount with a payment device.
1 [0 0 3 3 7] 67. The medium of embodiment 66, wherein the payment device is one of 2 a credit card, debit card, or prepaid card.
3 [00338] 68. The medium of embodiment 61, wherein the TVM transaction 4 comprises paying at least a portion of the transaction amount in TVMs and at least a portion of the transaction amount with cash.
6 [00339] 69. The medium of embodiment 61, wherein the TVM transaction 7 comprises paying at least a portion of the transaction amount in TVMs, at least a portion 8 of the transaction amount with cash, and at least a portion of the transaction amount 9 with a payment device.
[oo 34 o ] 70. The medium of embodiment 69, wherein the payment device is one of ii a credit card, debit card, or prepaid card.
12 [0 0341] 71. The medium of embodiment 61, wherein the credited transaction value 13 modifiers can only be used in subsequent transactions.
14 [0 o 34 2 ] 72. The medium of embodiment 71, wherein the credited transaction value modifiers is marked as originating from the merchant; and 16 wherein the transaction value modifiers cannot be used in subsequent transactions at 17 the merchant from which they originated.
18 [oo 343] 73. The medium of embodiment 61, further comprising instructions to:
19 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 21 processor-executable instructions, said instructions executable by a processor to:
22 send to the user the user's TVM balance and an indication that at least some TVMs in 23 the user's TVMs balance will expire;
24 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;
26 send a TVM donation message to the designated friend;
27 receive from the designated friend an enrollment request;
1 generate via a processor a new user account for the designated friend;
2 transfer the allocated expiring TVMs to the designated friend's new user account; and 3 send a confirmation of the transfer to the user and to the designated friend.
4 [0o345] 75. The medium of embodiment 74, further comprising instructions to:
monitor the spending of the user's donated TVMs by the designated friend; and 6 allocate via a processor an invite bonus block to the user's account when a 7 predetermined number of the user's donated TVMs have been spent.
8 [o 0346] 76. The medium of embodiment 74, further comprising instructions to:
9 receive a request from a user for user transaction value modifier (TVM) balance information.
ii [o 0347] 77. The medium of embodiment 75, wherein the mutual benefit enrollment 12 request further comprises an amount of TVM gifted by an economic promoter.
13 [00348] 78. The medium of embodiment 77, wherein the economic promoter 14 obtains a percentage of the amount of TVMs donated to the friend.
[00349] 79. The medium of embodiment 78, wherein a merchant manager gifts 16 TVMs to the economic promoter and obtains a percentage of the amount of TVMs gifted 17 to the friend.
18 [ o 0350] 80. A mutual benefits non-transitory computer-readable medium storing 19 processor-executable instructions, said instructions executable by a processor to:
receive an indication of preliminary interest in a mutual benefit program;
21 provide to the merchant a mutual benefit enrollment request form;
22 receive a mutual benefit enrollment request from a merchant for the mutual benefit 23 program;
24 send a mutual benefit enrollment form to the merchant;
receive from the merchant a completed mutual benefit enrollment form;
26 send a request to a merchant agent requesting background material on the merchant;
I 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;
generate a merchant account for the merchant; and 6 send the merchant a confirmation of enrollment in the mutual benefits program.
7 [ oo 3 5 1] 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;
determine a new PoS configuration for the user based on mutual benefit program ii specifications; and 12 send the new PoS configuration and the training materials to the merchant for 13 implementation.
14 [o 0352] 82. The medium of embodiment 81, further comprising instructions to:
generate training materials for the new PoS configuration.
16 [o 0353] 83. A non-transitory computer-readable medium storing processor-17 executable instructions, said instructions executable by a processor to:
18 receive a request for a user's value point balance and a merchant's current value point 19 schedule from a merchant;
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 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.
1 [0 0354] 84. The medium of embodiment 83, further comprising instructions to:
2 update via the processor the merchant's current value point schedule in the database 3 using the value point record.
4 [0 co 3 5 5] 85. A mutual benefits non-transitory computer-readable medium storing processor-executable instructions, said instructions executable by a processor to:
6 receive a product bulk amount from a partner;
7 receive a request for a merchant's transaction value modifier (TVM) balance and a 8 partner's current TVM schedule from a partner;
9 send the merchant's TVM balance and the partner's current TVM schedule to the partner;
ii receive a TVM transaction confirmation indicating a transaction involving purchasing at 12 least one product bulk amount has been successfully processed and TVM
transaction 13 data;
14 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;
16 generate via a processor a TVM transaction record and storing the TVM
transaction data 17 in the TVM transaction record; and 18 update via the processor the merchant's current TVM schedule in the database using the 19 TVM transaction record.
[00 3 5 6 ] 86. A mutual benefits non-transitory computer-readable medium storing 21 processor-executable instructions, said instructions executable by a processor to:
22 receive aggregated entity data in a mutual benefits program within a defined geo-23 demographical region;
24 perform performance analytics on the entity data;
determine demarcation indicia to divide a region if the region is overpopulated;
26 split the region based on the geo-demographical demarcation indicia into sub-regions;
27 receive updated demographic and industry data on each sub-region; and 1 generate new merchant categories for each sub-region based on the updated 2 demographic and industry data.
3 [00 3 5 7] 87. The medium of embodiment 86, wherein the entity is at least one of a 4 merchant or demographic data.
[00 3 5 8 ] 88. A mutual benefits non-transitory computer-readable medium storing 6 processor-executable instructions, said instructions executable by a processor to:
7 receive aggregated entity data in a mutual benefits program within a defined geo-8 demographical region;
9 perform performance analytics on the entity data;
determine enrollment criteria for enrolling at least one merchant in the mutual benefits 11 program if at least one merchant in the region is over-capacity;
12 send a mutual benefit enrollment form to a merchant not enrolled in the mutual benefits 13 program;
14 receive from the merchant not enrolled in the mutual benefits program a completed mutual benefit enrollment form;
16 enroll the merchant in the mutual benefits program; and 17 update the region record in a database to include the enrolled merchant.
18 [ o o 3 5 9 ] 89. The medium of embodiment 88, wherein the entity is at least one of a 19 merchant or demographic data.
[0036 o ] 90. The medium of embodiment 88, wherein the enrollment criteria may 21 include the category that the at least one merchant in the region which is over-capacity.
22 [0 o 3 61] 91. An apparatus for mutual benefits, comprising:
23 a processor; and 24 a memory disposed in communication with the processor and storing processor-executable instructions to:
26 receive a request for a user's transaction value modifier (TVM) balance 27 and a merchant's current TVM schedule from a merchant;
I receive a TVM transaction confirmation indicating a transaction has been 2 successfully processed, and TVM transaction data;
3 debit from a user's account an amount of TVMs received from another 4 merchant in a previous transaction for use in the transaction;
credit to the user's account an amount of TVMs based on the TVM
6 transaction data; and 7 generate via a processor a TVM transaction record and storing the TVM
8 transaction data in the TVM transaction record.
9 [0o362] 92. The apparatus of embodiment 91, further comprising instructions to:
io update via the processor the merchant's current TVM schedule in the ii database using the TVM record.
12 [00363] 93. The apparatus of embodiment 91, wherein a TVM is an eco, a value 13 identifier, or a subsequent value transaction modifier.
14 [00364] 94. The apparatus of embodiment 91, wherein the user's TVM balance is updated after receiving the TVM transaction confirmation.
16 [00365] 95. The apparatus of embodiment 91, wherein the user's TVM balance is 17 updated before receiving the TVM transaction confirmation.
18 [ co co 3 6 6 ] 96. The apparatus of embodiment 91, wherein the TVM
transaction 19 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.
21 [00367] 97. The apparatus of embodiment 96, wherein the payment device is one 22 of a credit card, debit card, or prepaid card.
23 [00368] 98. The apparatus of embodiment 91, wherein the TVM transaction 24 comprises paying at least a portion of the transaction amount in TVMs and at least a portion of the transaction amount with cash.
26 [00369] 99. The apparatus of embodiment 91, wherein the TVM transaction 27 comprises paying at least a portion of the transaction amount in TVMs, at least a portion 1 of the transaction amount with cash, and at least a portion of the transaction amount 2 with a payment device.
3 [00370] loo. The apparatus of embodiment 99, wherein the payment device is one 4 of a credit card, debit card, or prepaid card.
[00371] 101. The apparatus of embodiment 91, wherein the credited transaction 6 value modifiers can only be used in subsequent transactions.
7 [00372] 102. The apparatus of embodiment 101, wherein the credited transaction 8 value modifiers is marked as originating from the merchant; and 9 wherein the transaction value modifiers cannot be used in subsequent transactions at the merchant from which they originated.
ii [ o o 3 73 ] 103. The apparatus of embodiment 91, further comprising instructions to:
12 send the user's TVM balance and the merchant's current TVM
schedule to 13 the merchant.
14 [0 o 3 74 ] 104. An apparatus for mutual benefits, comprising:
a processor; and 16 a memory disposed in communication with the processor and storing processor-17 executable instructions to:
18 send to the user the user's TVM balance and an indication that at least 19 some TVMs in the user's TVMs balance will expire;
receive a request to donate expiring TVMs to a designated friend;
21 allocating via a processor the user's expiring TVMs to be donated to the 22 designated friend;
23 send a TVM donation message to the designated friend;
24 receive from the designated friend an enrollment request;
generate via a processor a new user account for the designated friend;
26 transfer the allocated expiring TVMs to the designated friend's new user 27 account; and 1 send a confirmation of the transfer to the user and to the designated 2 friend.
3 [00375] 105. The apparatus of embodiment 104, further comprising instructions 4 to:
monitor the spending of the user's donated TVMs by the designated friend; and 6 allocate via a processor an invite bonus block to the user's account when a 7 predetermined number of the user's donated TVMs have been spent.
8 [o 0376] 106. The apparatus of embodiment 104, further comprising instructions 9 to:
receive a request from a user for user transaction value modifier (TVM) balance ii information;
12 [o 0377] 107. The apparatus of embodiment 105, wherein the mutual benefit 13 enrollment request further comprises an amount of TVM gifted by an economic 14 promoter.
[0 0 3 78 ] 108. The apparatus of embodiment 107, wherein the economic promoter 16 obtains a percentage of the amount of TVMs donated to the friend.
17 [oo 3 79 ] 109. The apparatus of embodiment 108, wherein a merchant manager gifts 18 TVMs to the economic promoter and obtains a percentage of the amount of TVMs gifted 19 to the friend.
[0 0380] 110. An apparatus for mutual benefits, comprising:
21 a processor; and 22 a memory disposed in communication with the processor and storing processor-23 executable instructions to:
24 receive an indication of preliminary interest in a mutual benefit program;
provide to the merchant a mutual benefit enrollment request form;
26 receive a mutual benefit enrollment request from a merchant for the 27 mutual benefit program;
1 send a mutual benefit enrollment form to the merchant;
2 receive from the merchant a completed mutual benefit enrollment form;
3 send a request to a merchant agent requesting background material on the 4 merchant;
receive background material on the merchant from the merchant agent;
6 analyze the background material from the merchant agent;
7 enroll the merchant in the mutual benefit program if the background 8 material meets predetermined criteria;
9 generate a merchant account for the merchant; and send the merchant a confirmation of enrollment in the mutual benefits 11 program.
12 [0 o 3 8 1] 111. The apparatus of embodiment 110, further comprising instructions to:
13 receive from a merchant a survey of current point-of-sales (PoS) infrastructure and 14 settings configurations;
determine a new PoS configuration for the user based on mutual benefit program 16 specifications; and 17 send the new PoS configuration and the training materials to the merchant for 18 implementation.
19 [0 o 3 8 2 ] 112. The apparatus of embodiment in, further comprising instructions to:
generate training materials for the new PoS configuration.
21 [0 0 3 8 3 ] 113. An apparatus for mutual benefits, comprising:
22 a processor; and 23 a memory disposed in communication with the processor and storing processor-24 executable instructions to:
receive a request for a user's value point balance and a merchant's current 26 value point schedule from a merchant;
I receive a value point transaction confirmation indicating a transaction has 2 been successfully processed and value point transaction data;
3 debit from a user's account an amount of value points received from 4 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 6 point transaction data; and 7 generate via a processor a value point transaction record and storing the 8 value point transaction data in the value point transaction record.
9 [0o384] 114. The apparatus of embodiment 113, further comprising instructions to:
io update via the processor the merchant's current value point schedule in the database ii using the value point record.
12 [0o385] 115. An apparatus for mutual benefits, comprising:
13 a processor; and 14 a memory disposed in communication with the processor and storing processor-executable instructions to:
16 receive a product bulk amount from a partner;
17 receive a request for a merchant's transaction value modifier (TVM) 18 balance and a partner's current TVM schedule from a partner;
19 send the merchant's TVM balance and the partner's current TVM
schedule to the partner;
21 receive a TVM transaction confirmation indicating a transaction involving 22 purchasing at least one product bulk amount has been successfully processed and TVM
23 transaction data;
24 debit from the merchant's account an amount of TVMs used in the transaction;
26 credit to the merchant's account an amount of TVM based on the TVM
27 transaction data;
1 generate via a processor a TVM transaction record and storing the TVM
2 transaction data in the TVM transaction record; and 3 update via the processor the merchant's current TVM schedule in the 4 database using the TVM transaction record.
[00 3 8 6 ] 116. An apparatus for mutual benefits, comprising:
6 a processor; and 7 a memory disposed in communication with the processor and storing processor-s executable instructions to:
9 receive aggregated entity data in a mutual benefits program within a defined geo-demographical region;
11 perform performance analytics on the entity data;
12 determine demarcation indicia to divide a region if the region is 13 overpopulated;
14 split the region based on the geo-demographical demarcation indicia into sub-regions;
16 receive updated demographic and industry data on each sub-region; and 17 generate new merchant categories for each sub-region based on the 18 updated demographic and industry data.
19 [0 o 3 8 7] 117. The apparatus of embodiment 116, wherein the entity is at least one of a merchant or demographic data.
21 [00 3 8 8 ] 118. An apparatus for mutual benefits, comprising:
22 a processor; and 23 a memory disposed in communication with the processor and storing processor-24 executable instructions to:
receive aggregated entity data in a mutual benefits program within a 26 defined geo-demographical region;
27 perform performance analytics on the entity data;
1 determine enrollment criteria for enrolling at least one merchant in the 2 mutual benefits program if at least one merchant in the region is over-capacity;
3 send a mutual benefit enrollment form to a merchant not enrolled in the 4 mutual benefits program;
receive from the merchant not enrolled in the mutual benefits program a 6 completed mutual benefit enrollment form;
7 enroll the merchant in the mutual benefits program; and 8 update the region record in a database to include the enrolled merchant.
9 [0 0389] 119. The apparatus of embodiment 118, wherein the entity is at least one of a merchant or demographic data.
11 [00390] 120. The apparatus of embodiment 118, wherein the enrollment criteria 12 may include the category that the at least one merchant in the region which is over-13 capacity.
46 ECO ADVANTAGE may update the merchant profile 510, eco schedule, and/or the like 47 for merchants being analyzed. ECO ADVANTAGE may create and/or update region and 48 category information 511 in the ECO ADVANTAGE database based on the merchant 49 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 18 and 19.
4 [00106] FIGURES 5b-d show logic flow diagrams illustrating creating and 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, merchant transaction history, the merchant location, and/or like data from the ii 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 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 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 525 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 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, 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 1 like), and may, for each merchant 532, aggregate qualitative and quantitative merchant 2 data 533 (see FIGURE 4h for further details), and may add the data 534 to a collective 3 list of merchant prospects for ECO ADVANTAGE. When all merchants have been 4 processed 535, the merchant agent may generate and send the aggregated data 536 of all merchants found to ECO ADVANTAGE, which may, upon receiving 561 the aggregated 6 data, rank 537 the merchants based on pre-specified criteria (e.g. the average and/or 7 total number of customers for the merchant, the merchant's current capacity, the 8 merchant's financial reputation, and/or the like). ECO ADVANTAGE may select 538 the 9 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 ii the requirements, ECO ADVANTAGE may select the next best merchant on the list 540, 12 and may perform the same check on the next best merchant. If a merchant meets ECO
13 ADVANTAGE requirements, ECO ADVANTAGE may generate 541 and send 542 an 14 enrollment invitation to the merchant (see FIGURES 4b-c for more detail).
In some implementations, after the merchant has enrolled, ECO ADVANTAGE may update 543 16 the region and category that the new merchant belongs to, in order to show that a 17 merchant has been added to both.
18 [co co 1 co 7] In some implementations, after performing analytics on enrolled 19 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 21 overpopulated 545, ECO ADVANTAGE may with to divide the region such that each 22 sub-region is not overpopulated. In some implementations this may be done via 23 determining a geographical, demographic, and/or like demarcation category 546 to 24 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 26 implementations, if there is more than one variant of the demarcation category in the 27 region 547 (e.g., if there is more than one area code and/or the like in the region), ECO
28 ADVANTAGE may split the existing region 550 by the one or more variant in the region 29 (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 31 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 548 using a region map and/or region 2 location data points, and may split the region 549 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 552 (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 554 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, for each new region 556, gather new region information 557 (.g. demographics, industries, ii and/or the like), may update 558 the region's categories, records, and/or the like based 12 on the gathered information, and may gather updated information 559 of merchants 13 currently enrolled and in the region (see FIGURES 5a-c for more details).
ECO
14 ADVANTAGE may continue to do this for each new region until it there are not any new regions left to check 56o.
16 [00108] FIGURES 6a-b show data flow diagrams illustrating friend invitations and 17 donations in example embodiments of the ECO ADVANTAGE. In some 18 implementations, a user 601 may indicate at a merchant PoS device, merchant kiosk, via 19 an electronic device 602, and/or using like technology that he would like to donate ecos.
In some implementations the user may be encouraged to donate ecos that are close to 21 expiring after a time period defined by ECO ADVANTAGE, and may be able to donate 22 either to charities, organizations, and/or the like, or to friends in the form of a referral 23 program. In some implementations the user may send a balance request 603 to ECO
24 ADVANTAGE 604, which may ask for the user's current balance, including ecos that will expire soon. In some implementations the balance request 603 may be an XML-encoded 26 message and may take a form similar to the following:
27 POST /balance_request.php HTTP/1.1 28 Host: www.ECOADVANTAGEprocess.com 29 Content-Type: Application/XML
Content-Length: 788 31 <?XML version = "1.0" encoding = "UTF -8"?>
32 <balanceRequest>
1 <userId>102557952</userId>
2 <userIdType>SSN</userIdType >
3 <ecoId>3074</ecoId>
4 <Document>06998524500</Document>
<dateTime>03/07/2013 03:39 PM</dateTime>
6 </balanceRequest>
7 [00109] In some implementations, ECO ADVANTAGE may send a balance 8 response 605 which may contain the user's eco balance, expiration date data for all of 9 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:
11 POST /balance_response.php HTTP/1.1 12 Host: www.ECOADVANTAGEprocess.com 13 Content-Type: Application/XML
14 Content-Length: 788 <?XML version = "1.0" encoding = "UTF-8"?>
16 <balanceResponse>
17 <userId>102557952</userId>
18 <userIdType>SSN</userIdType >
19 <ecoId>3074</ecoId>
<Document>06998524500</Document>
21 <ListOfBalance>
22 <Balance>
23 <Value>77</Value>
24 <ExpirationDate>05/15/2013</ExpirationDate>
</Balance>
26 <Balance>
27 <Value>200</Value>
28 <ExpirationDate>06/15/2013</ExpirationDate>
29 </Balance>
</ListOfBalance>
31 </balanceResponse>
32 [00110] In some implementations, the user may be able to view his ecos balance 33 via an ecos balance user interface similar to that in FIGURE 21b, and may, using an 34 interface similar to that in FIGURES 20a-b, choose a number of ecos to donate to a friend, and may send a gift request 606 to ECO ADVANTAGE. In some implementations 1 the gift request 606 may be an XML-encoded message which may take a form similar to 2 the following:
3 POST /gift_request.php HTTP/1.1 4 Host: www.ECOADVANTAGEprocess.com 5 Content-Type: Application/XML
6 Content-Length: 788 7 <?XML version = "1.0" encoding = "UTF-8"?>
8 <giftRequest>
9 <UID>32134321354321345312</UID>
10 <EcoBlockAmount>400</EcoBlockAmount>
11 <FriendID>02541478744</FriendID>
12 <Email>peter@friend.com</Email>
13 <PhoneNumber>1465448874</PhoneNumber>
14 </giftRequest>
15 [00111] In some implementations, ECO ADVANTAGE may be able to determine 16 whether the friend is already enrolled or not 607, and may allocate 608 the user-17 specified number of ecos in the user's balance as ecos to be donated to the friend. In 18 some implementations, Grails code for checking for friend enrollment and allocating 19 ecos may take a form similar to the following:
20 def userGift 21 User user = User.getByDocument(friendID) 22 if (user) {
23 userGift = user 24 } else {
25 userGift = TemporaryUser.create(friendID) 26 }
27 User user = User.getByDocument(userId) 28 def userBalance = user.getBalance() 30 if (userBalance > ecoBlockAmount) {
31 sendError("insufficient.funds.for.gifting") 32 } else {
33 user.blockForDonation(ecoBlockAmount,UID) 34 }
1 [0 0 1 12 ] In some implementations, ECO ADVANTAGE may send an allocation 2 confirmation request 609 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 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
Content-Length: 788 11 <?XML version = "1.0" encoding = "UTF-8"?>
12 <giftConfirmation>
13 <UID>32134321354321345312qUID>
14 <EcoBlockAmount>500</EcoBlockAmount>
<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 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 26 Are you getting 400 ecos to spend using Eco Advantage 28 Sign up to take advantage GiftID: 32134321354321345312 31 UserID: 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 1 313, 314, or 315. In some implementations, sensitive information (e.g. the user PIN
2 and/or the like) may be encrypted.
3 [00115] In some implementations, ECO ADVANTAGE may instantiate 615 a user 4 account for the friend using the enrollment data provided, via sending a user account insert query 616 to the users 617d table of the ECO ADVANTAGE database 617. In some 6 implementations, ECO ADVANTAGE may transfer 618 the block of ecos from the user 7 to the friend (e.g. by moving the ecos to the friend's new account, designating them as 8 "donation ecos," resetting the expiration date for the ecos donated, and/or like record-9 updating). In some implementations, example Grails code for transferring the ecos may take a form similar to the following:
11 DonationBlock donation = DonationBlock.getbyUID(UID) 12 User userFrom = donation.userFrom 13 User userTo = donation.userTo 14 userFrom.donate(UID, userTo) [00116] In some implementations, ecos designated as being donated may not be 16 donated again by any user, and may only be able to be spent. In some implementations, 17 ECO ADVANTAGE may update records via ecos update 619.
18 [co co 117] In some implementations, ECO ADVANTAGE may send a confirmation to 19 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 21 been successfully transferred to the friend's new account.
22 [00118] Referring to FIGURE 6b, in some implementations, friend 613 may use the 23 donated ecos 622 in a plurality of transactions (see FIGURES 2a-d for more details).
24 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, 26 allocate an invite bonus block to the user's account, via sending an invite bonus block 27 update 625 to the ECO ADVANTAGE database. In some implementations, Grails code 28 for monitoring the spending of donated ecos may take a form similar to the following:
29 def list0fDonation = Donation.findbyBonusBlockId(null) 31 foreach (donation in list0fDonation) {
1 def userFrom = donation.userFrom 2 def userTo = donation.userTo 3 def amount = donaction.amount 4 def date = donation.date 6 def usedAmountSinceDonation =
7 transaction . getByUserAndSinceDate(userTo, date) 9 call eligibleForBonusBlock(donation, usedAmountSinceDonation) }
11 [00119] In some implementations, Grails code for allocating invite bonus blocks 12 may take a form similar to the following:
M function eligibleForBonusBlock( donation, usedAmountSinceDonation) {
14 if ( usedAmountSinceDonation >=
(donation.amount *
M ecoAdvantageConfig.donationFactor)) {
16 def bonusBlockId = donation.userFrom.creditBonusBlock() 17 donation.bonusBlockId = bonusBlockId;
18 donation.save() 19 }
}
21 [00120] In some implementations, the bonus block update query 625 may be a 22 PHP-encoded insert statement.
23 [00121] In some implementations, the user may receive confirmation 626 that the 24 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 26 participate in a qualifying transaction 627, such as a purchase transaction at an enrolled 27 merchant 628 (see FIGURES 2a-d). In some implementations, a qualifying transaction 28 may include a transaction where the combination of using ecos and bonus blocks will 29 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 31 minimum value at which a user can use bonus blocks towards a transaction), a 32 transaction initiated at a particular merchant, in a particular region, in a particular 33 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 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 629 io (which may resemble eco message 206), and receive eco response 630 (which may ii 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 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 [ o 0124] FIGURES 6c-d show logic flow diagrams illustrating friend invitations and 19 donations in example embodiments of the ECO ADVANTAGE. In some 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 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 may receive 639 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
1 may, if the friend is enrolled 641, transfer the specified block of ecos to the friend 642, 2 may update the user's and friend's balances, may mark the transferred ecos as "donated 3 ecos" 643 and reset the expiration dates of the donated ecos, and/or take care of other 4 transfer details. ECO ADVANTAGE may notify the user and the friend 644 that the ecos 5 were successfully transferred from the user to the friend.
6 [00125] If the friend is not enrolled, ECO ADVANTAGE may instead allocate a 7 block of the user's ecos 645 to be donated to the friend, and may prepare and send a 8 template or customized enrollment form 646 to the friend. The friend may receive the 9 enrollment form 647, along with the amount of ecos being donated to them, from whom, 10 and/or the like. If the friend declines to enroll 648, ECO ADVANTAGE may deactivate ii the enrollment invitation 649, and may send a notification to the user that his 12 enrollment invite has been deactivated 65o because the friend did not wish to enroll in 13 ECO ADVANTAGE. If the friend chooses to enroll 648, the friend may do so by 14 completing and submitting the enrollment form 651 to ECO ADVANTAGE, which may 15 create a user account 652 for the friend based on the provided enrollment data in the 16 friend's submitted enrollment form. ECO ADVANTAGE may transfer 653 the allocated 17 block of ecos to be donated from the user account to the friend's new account, and may 18 update the user's and friend's eco balances. ECO ADVANTAGE may mark the 19 transferred ecos as "donation ecos" 654, along with resetting their expiration date 20 and/or the like. The user may be notified of a successful eco donation 655.
21 [00126] In some implementations, the friend may use the donated ecos in one or 22 more subsequent transactions 656 (see FIGURES 2a-d for more details), which may be 23 monitored 657 by ECO ADVANTAGE. If ECO ADVANTAGE finds that the friend has 24 spent some pre-defined number and/or percentage of the donated ecos 658, it may 25 allocate 659 a predetermined invite bonus block value to the user, and may update the 26 user's account 660 with the allocated invite bonus block. ECO ADVANTAGE may 27 generate may generate 661 and send 662 a confirmation message to the user indicating 28 that a predetermined number ecos donated by the user have been spent, that the user is 29 consequently receiving an invite bonus block, the user's current ecos and invite bonus 30 block balances, and/or the like. the user may receive 663 the confirmation and may 31 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 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 [0 0 1 27] FIGURE 7a shows a data flow diagram illustrating slow commit, credit-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 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 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 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 implementations, the merchant may display and/or print 709 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 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 M Host: www.ECOADVANTAGEprocess.com 11 Content-Type: Application/XML
12 Content-Length: 788 M<?XML version = "1.0" encoding = "UTF-8"?>
14 <paymentRequest>
M <posId>4088</posId>
M <merchantId>2033</merchantId>
17 <amountDueInDollars>77.0</amountDueInDollars>
M <dateTime>03/07/2013 03:39 PM</dateTime>
19 <userCard>3214 3578 3568 3542</userCard>
20 </paymentRequest>
21 [00128] In some implementations payment request 711 may only include the 22 transaction balance after ecos and/or bonus blocks have been applied. The acquirer may 23 prepare 712 the transaction and procure payment via sending a transaction request 714 24 to a bank entity 715 (e.g. the user's issuing bank, another acquirer, and/or the like).
25 [00129] The bank may send a transaction response 716 to the acquirer, which may 26 indicate whether or not the transaction was approved and/or processed, or whether the 27 transaction was declined. The acquirer may forward this information to ECO
28 ADVANTAGE via transaction confirmation 717, which may take a form similar to 29 transaction confirmation 219, or may forward the information to the merchant via 30 transaction confirmation 718 (which may take a form similar to transaction 31 confirmation 219), who may forward the information via transaction confirmation 719 32 to ECO ADVANTAGE. In some implementations, the entity the acquirer forwards the 33 confirmation to may depend on the security of the entities, entity resources, and/or the 34 like. In some implementations ECO ADVANTAGE may not receive the confirmation 35 (e.g., via the acquirer or the merchant). In some implementations, transaction 1 confirmation 719 may take a form similar to transaction confirmation 219.
Once ECO
2 ADVANTAGE has received a transaction confirmation, it may debit 720 the used ecos 3 and bonus blocks from the user's balances, may credit to the user with new ecos equal to 4 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 6 take a form similar to the following:
7 Transaction transaction = Transaction.get(transactionId) 8 User user = transaction.getUser() 9 Merchant merchant = transaction.getMerchant() long ecoUsage = transaction.getEcoUsage() 11 long bonusBlockUsage = transaction.getBonusBlockUsage() 12 Try {
13 beginTransaction() 14 user.debitEco(ecoUsage) user.debitBonusBlock(bonusBlockUsage) 16 commitTransaction();
17 I catch (Exception) {
18 rollbackTransaction();
19 return false;
}
21 [00130] ECO ADVANTAGE may also update the merchant account record 721, 22 including updating BI information, transaction data, the merchant's usage schedule, 23 atmospherics, and/or the like. In some implementations, Grails code for updating the 24 user's balances may take a form similar to the following:
Transaction transaction = Transaction.get(transactionId) 26 User user = transaction.getUser() 27 Merchant merchant = transaction.getMerchant() 28 long amountDueInDollars = transaction.getAmountDueInDollars() 29 Try {
beginTransaction() 31 user.creditEco(amountDueInDollars, merchant) 32 commitTransaction();
33 I catch (Exception) {
34 rollbackTransaction();
1 return false;
2}
3 [00131] ECO ADVANTAGE may send an eco credit confirmation 722 to the 4 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 6 take a form similar to the following:
7 POST /eco_credit_confirmation.php HTTP/1.1 8 Host: www.ECOADVANTAGEprocess.com 9 Content-Type: Application/XML
Content-Length: 788 11 <?XML version = "1.0" encoding = "UTF-8"?>
12 <ecoCreditConfirmation>
13 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
14 <newEcos>77</newEcos>
<bonusBlock>0</BonusBlock>
16 <usedEcos>23</usedEcos>
17 <EcoBalance>1091</EcoBalance>
18 <ecoCreditConfirmation>
19 [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 21 contain information similar to the following:
22 DOCUMENT: NNN.NNN.NNN-NN ID EAS: IIIIII
23 USED ECOS: VVV.VVV,VV
24 USED BONUS BLOCKS: VVV.VVV,VV
NEW ECOS: EEE.EEE,EE
27 ECO BALANCE: BBB.BBB,BB
29 [00133] In some implementations, ECO ADVANTAGE may also monitor the status of various transactions, and may reverse, retry, and/or otherwise handle incomplete 31 transactions if found in the ECO ADVANTAGE database's records, based on 32 predetermined criteria.
1 [o 0 1 34 ] 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 1 user's balance, as well as updating merchant and transaction records 745 using the 2 information described in 721 and/or like information.
3 [0 co 13 6 ] If the acquirer cannot successfully procure the funds 736, the acquirer may 4 send a notification of transaction failure 738 to the merchant (and, in some implementations, to ECO ADVANTAGE). The merchant may, after determining the 6 transaction was not successful 739, send a notification to the user 740, along with a 7 prompt to retry the transaction (e.g. with a different payment method and or the like).
8 In some implementations the merchant may also forward the notification to ECO
9 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 11 incomplete until the transaction is successfully processed, until the user cancels the 12 transaction, and/or the like. In some implementations, ECO ADVANTAGE may also 13 monitor the status of various transactions, and may reverse, retry, and/or otherwise 14 handle incomplete transactions if found in the ECO ADVANTAGE database's records, based on predetermined criteria.
16 [00137] FIGURE 8a shows a data flow diagram illustrating fast commit, credit-17 only transactions in example embodiments of the ECO ADVANTAGE. In some 18 implementations, a user 801 may send a transaction initiation request 803 to the 19 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 21 encrypted. In some implementations, the transaction initiation request may take a form 22 similar transaction initiation 205, or may take a form similar to the following:
23 POST /transaction_intitation_request.php HTTP/1.1 24 Host: www.ECOADVANTAGEprocess.com Content-Type: Application/XML
26 Content-Length: 788 27<?XML version = "1.0" encoding = "UTF-8"?>
28<InitiateTransactionRequest>
29 <UID>32134321354321345312qUID>
<ProductData>haircut</ProductData>
31 <TransactionAmount>100</TransactionAmount>
32 <UserPIN>3214 3558 1587 9877</UserPIN>
1 </InitiateTransactionRequest>
2 [o 0138] In some implementations, sensitive information (e.g. the user PIN
and/or 3 the like) may be encrypted. In some implementations, the merchant may send an eco 4 request 805 to the ECO ADVANTAGE 806. In some implementations, eco request may take a form similar to eco request 206. ECO ADVANTAGE may look up the user's 6 and merchant's records using the user ID (UID) and the merchant ID 807, respectively, 7 and may determine which and how many ecos and bonus blocks the user may apply to 8 his transaction (e.g. based on the merchant's eco schedule, the user's eco and bonus 9 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 ii the user to confirm his transaction before initiating any portion of it. In some 12 implementations ECO ADVANTAGE may debit 808 the used ecos and bonus blocks 13 from the user's balances, may credit to the user with new ecos equal to a predetermined 14 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
16 information, transaction data, the merchant's usage schedule, atmospherics, and/or the 17 like.
18 [00139] ECO ADVANTAGE may send an eco response 810 back to the merchant, 19 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 21 transaction. In some implementations, payment request 811 may take a form similar to 22 payment request 215. The acquirer may prepare 812 the transaction and procure 23 payment via sending a transaction request 814 to a bank entity 815 (e.g.
the user's 24 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 26 may send a transaction response 816 to the acquirer, which may indicate whether or not 27 the transaction was approved and/or processed, or whether the transaction was 28 declined. The acquirer may forward this information to ECO ADVANTAGE via 29 transaction confirmation 819, which may take a form similar to transaction confirmation 219, or may forward the information to the merchant via transaction 31 confirmation 817 (which may take a form similar to transaction confirmation 219), who I 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 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-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, ECO ADVANTAGE may receive 823 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 18 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 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 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 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 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 processed. In some implementations the merchant may, if it receives a notification 838 ii indicating a successful transaction, print and/or display a transaction receipt 839 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 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 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 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.
[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 15a-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, 10 an exemplary batch payment request 903 may take a form similar to the following:
11 POST / batch_payment_request.php HTTP/1.1 12 Host: www.ECOADVANTAGEprocess.com 13 Content-Type: Application/XML
14 Content-Length: 788 15 <?XML version = "1.0" encoding = "UTF-8"?>
16 <batchPaymentRequest>
17 <list0fPaymentRequest>
18 <paymentRequest>
19 <id>125414</id>
20 <ecoadvantage>true</merchantId>
21 <balanceOwed>8547.00</balanceOwed>
22 <requestDate>05/13/2013</requestDate>
23 </paymentRequest>
24 <paymentRequest>
25 <id>125415</id>
26 <acquirer>2033</merchantId>
27 <balanceOwed>54871.00</balanceOwed>
28 <requestDate>05/13/2013</requestDate>
29 </paymentRequest>
30 <paymentRequest>
31 <id>125416</id>
32 <merchantId>2034</merchantId>
33 <balanceOwed>125.00</balanceOwed>
34 <requestDate>05/13/2013</requestDate>
1 </paymentRequest>
2 <paymentRequest>
3 <id>125417</id>
4 <merchantId>2035</merchantId>
<balanceOwed>588.00</balanceOwed>
6 <requestDate>05/13/2013</requestDate>
7 </paymentRequest>
8 </list0fPaymentRequest>
9 </batchPaymentRequest>
[0 0 1 45] The acquirer may perform 905 reconciliation with various payment ii entities via sending a payment instruction message 906 to the user's issuing bank 907 12 and an acquirer payment instruction message 908 to an acquiring bank 909.
In some 13 implementations, the issuer bank may send a bill 910 to the user 911, who may view the 14 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 16 the funds for the payment.
17 [00146] The issuer may send a merchant payment message 914 to the merchant's 18 bank 915, which may include the funds requested for the payment being processed. The 19 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 21 may, using the acquirer payment instructions 908 and the acquirer payment 916, 22 calculate a payment value to be sent to ECO ADVANTAGE 918, and may send the ECO
23 ADVANTAGE Payment 917 to ECO ADVANTAGE. In some implementations, ECO
24 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 26 implementations, ECO ADVANTAGE may receive a confirmation once the payment has 27 been processed at the ECO ADVANTAGE bank, which may include a confirmation that 28 the transaction was successfully processed, the transaction ID for each transaction from 29 the acquirer, and/or the like, for each transaction in the batch.
[00147] FIGURE 9b shows a logic flow diagram illustrating merchant 31 reconciliation in example embodiments of the ECO ADVANTAGE. In some 32 implementations, for each acquirer connected to ECO ADVANTAGE 919, ECO
1 ADVANTAGE may check every merchant 920 that uses the acquirer to see if any 2 reconciliation is necessary for the merchant. ECO ADVANTAGE may query 921 the 3 database for transaction data, merchant data, the merchant's eco schedule, the 4 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 6 unreconciled 922, ECO ADVANTAGE may calculate the transaction total for the 7 transaction, and may also calculate what the acquirer's running transaction total at the 8 time, the merchant's running transaction total at the time, and the ECO
ADVANTAGE
9 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 ii maximum amount of total funds that may be processed by the acquirer at the time), 12 ECO ADVANTAGE may determine whether there are other unreconciled transactions 13 928 (e.g. in case another unreconciled transaction may be processable), and may 14 continue to check each unreconciled transaction in the database.
[00148] If the transaction is processable, ECO ADVANTAGE may also check to 16 determine whether the projected totals would be less than the merchant's maximum 17 amount of possible funds to process 925. If not, ECO ADVANTAGE may determine 18 whether there are any other unreconciled transactions to process 928. If the projected 19 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 21 calculated running total of the merchant, acquirer, ECO ADVANTAGE, and/or the like 22 once the transaction is processed. ECO ADVANTAGE may also keep a running total for 23 different payment methods, such as the total amount of funds to be received from 24 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
26 ADVANTAGE database records with the totals calculated at the time, and may update 27 the transaction record to reflect that the transaction has been reconciled.
Once all 28 transactions have been checked, ECO ADVANTAGE may update 929 the running total 29 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 31 for the remaining merchants; if not, ECO ADVANTAGE may prepare 931 a batch 1 payment request to an acquirer using the data obtained from all the processed 2 merchants, and may send 932 the batch payment request to the acquirer for payment 3 processing. If there are other acquirers 933 to process, ECO ADVANTAGE may repeat 4 the process for each other acquirer connected with ECO ADVANTAGE.
[00149] In some implementations, Grails code for processing the batch payment 6 may take a form similar to the following:
7 def totalEcoAdvantage = 0 8 def batchPayment = [];
def list0fAquirer = Acquirer.findAll() 12 foreach(aquirer in list0fAquirer) {
14 def totalAcquirer = 0 16 def list0fMerchant = Merchant.findbyAquirerer(acquirer) 18 foreach(merchant in list0fMerchant) {
def totalMerchandFund = 0 21 def totalMerchant = 0 23 def listOfTransaction =
24 Transaction.findByAcquirerAndMerchant(acquirer, merchant) 26 foreach(transaction in listOfTransaction) {
28 if (NOT transaction.reconciled) {
def totalTransaction = transaction.calculateTotal() 31 totalMerchant = totalMerchant +
32transaction.calculateTotalMerchant() 33 totalAcquirer = totalAcquirer +
34transaction.calculateTotalAcquirer() totalEcoAdvantage = totalEcoAdvantage +
36transaction.calculateTotalEcoAdv() 2 if (totalMerchandFund + totalMerchant <
3 SystemSetting.getMaxFundToMerchant()) {
Reconcilation reconcilation = new Reconcilation() 6 reconcilation.merchant = merchant 7 reconcilation.acquirer = acquirer 8 reconcilation.date = today() 9 reconcilation.totalTransaction = totalTransaction M reconcilation.totalMerchant = transaction.calculateTotalMerchant() 11 reconcilation.totalAcquirer = transaction.calculateTotalAcquirer() 12 reconcilation.totalEcoAdvantage = transaction.calculateTotalEcoAdv() M reconcilation.totalCash = transaction.calculateTotalCash() 14 reconcilation.totalCard = transaction.calculateTotalCard() M reconcilation.totalEco = transaction.calculateTotalEco() M reconcilation.save() M transaction.reconciled = true 19 transaction.save();
20 totalMerchandFund =+ totalMerchant 22 }
23 }
24 }
26 PaymentRequest paymentRequest = new PaymentRequest();
27 paymentRequest.merchant = merchant;
28 paymentRequest.balanceOwed = totalMerchant;
29 paymentRequest.requestDate = new Date();
W paymentRequest.confirmed = false;
31 paymentRequest.save() 32batchPayment.push(payment: paymentRequest) 36 PaymentRequest paymentRequest = new PaymentRequest();
1 paymentRequest.acquirer = acquirer;
2 paymentRequest.balanceOwed = totalAcquirer;
3 paymentRequest.requestDate = new Date();
4 paymentRequest.confirmed = false;
5 paymentRequest.save() 6 batchPayment.push(payment: paymentRequest) 7}
9 PaymentRequest paymentRequest = new PaymentRequest();
M paymentRequest.ecoAdvantage = true;
11 paymentRequest.balanceOwed = totalEcoAdvantage;
12 paymentRequest.requestDate = new Date();
M paymentRequest.confirmed = false;
14 paymentRequest.save() M batchPayment.push(payment: paymentRequest) M
17 render batchPayment as XML;
18 [o 0 15 0 ] FIGURE loa shows a data flow diagram illustrating slow commit, cash and 19 credit transactions in example embodiments of the ECO ADVANTAGE. In some 20 implementations, a user 1001 may send a transaction initiation request 1003 to the 21 merchant 1004 using the merchant's PoS device and/or a user electronic device 1002. In 22 some implementations, sensitive information (e.g. the user PIN and/or the like) may be 23 encrypted. In some implementations, the merchant may send an eco request 1005 to the 24 ECO ADVANTAGE 1006. In some implementations, eco request 1005 may take a form 25 similar to eco request 206. ECO ADVANTAGE may look up the user's and merchant's 26 records using the user ID (UID) and the merchant ID 1007, respectively, and may 27 determine which and how many ecos and bonus blocks the user may apply to his 28 transaction (e.g. based on the merchant's eco schedule, the user's eco and bonus block 29 balances, and/or the like), and may determine the state of a user confirmation setting. If 30 the confirmation setting is set to "true," ECO ADVANTAGE may require the user to 31 confirm his transaction before initiating any portion of it. In some implementations 32 ECO ADVANTAGE may send an eco response 1008 back to the merchant, which may 33 take a form similar to eco response 212.
1 [0 0 15 1] In some implementations, the merchant may display and/or print 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 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 loll to ECO ADVANTAGE
9 indicating that the user has already paid part of the transaction balance in cash, and is 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 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 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 Host: www.ECOADVANTAGEprocess.com 26 Content-Type: Application/XML
27 Content-Length: 788 28 <?XML version = "1.0" encoding = "UTF-8"?>
29 <paymentConfirmation>
<UID>da6c5cdf4e90b2961873f7b2e863415</UID>
31 <transactionId>635467</transactionId>
32 <merchantId>2033</merchantId>
1 <posId>4088</posId>
2 <amounDueInDollars>77.0</amountDueInDollars>
3 <bonusBlockAmount>20</bonusBlockAmount>
4 <debitCreditAmount>27.0</debitCreditAmount>
<cashAmount>50.0</cashAmount>
6 <totalAmount>100</totalAmount>
7 <dateTime>03/07/2013 03:40 PM</dateTime>
8 <approved>true</approved>
9 </paymentConfirmation>
[00153] In some implementations the acquirer may forward the information to the ii merchant via transaction confirmation 1019 (which may take a form similar to 12 transaction confirmation 219), who may forward the information via transaction 13 confirmation 1020 to ECO ADVANTAGE. Once ECO ADVANTAGE has received a 14 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, 16 and may update the user's balance. ECO ADVANTAGE may also update the merchant 17 account record 1023, including updating BI information, transaction data, the 18 merchant's usage schedule, atmospherics, and/or the like. In some implementations, 19 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
21 ADVANTAGE may also monitor the status of various transactions, and may reverse, 22 retry, and/or otherwise handle incomplete transactions if found in the ECO
23 ADVANTAGE database's records, based on predetermined criteria.
24 [o 0154] FIGURES lob-c show logic flow diagrams illustrating slow commit, cash and credit transactions in example embodiments of the ECO ADVANTAGE. In some 26 implementations, a user may initiate 1025 a transaction with an enrolled merchant, via 27 providing transaction input to a merchant. The merchant may receive the user input and 28 transaction information 1026, and may generate and send 1027 a request to ECO
29 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 31 balance, and may retrieve from the ECO ADVANTAGE database 1029 the user's 32 available ecos, bonus blocks, and/or the like to determine which and how many ecos and 1 bonus blocks may be applied to the current transaction, as well as to determine the 2 user's confirmation setting. If the confirmation setting is on 1030, ECO
ADVANTAGE
3 may generate 1031 and send 1032 a response to the merchant indicating the user's eco 4 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 6 displaying and/or printing the transaction information for the user and asking the user 7 to confirm the transaction 1034. The user may authenticate 1035 the transaction and the 8 use of his ecos and/or bonus blocks towards the purchase using his password, user PIN, 9 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
11 ADVANTAGE indicating the user has both confirmed the use of his ecos and/or bonus 12 blocks and wishes to pay for the transaction, and has paid at least a portion of the 13 transaction balance in cash. Once ECO ADVANTAGE receives 1037 the message, it may 14 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 16 amount based on the cash payment.
17 [00155] In some implementations, the merchant may also generate and send a 18 payment request 1039 with the user's payment information, the transaction balance 19 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 21 procurement. In some implementations the acquirer may receive 1040 the user's 22 payment information, transaction data, and/or the like, and may authenticate the 23 sender of the message 1041 and use the information to request the transaction balance 24 from the user's issuing bank.
[00156] If the acquirer can successfully procures the funds 1042, the acquirer may 26 obtain the funds 1043 and may send a confirmation to the merchant (and in some 27 implementations, to ECO ADVANTAGE) indicating that the transaction was successfully 28 processed. In some implementations the merchant may, if it receives a notification 1044 29 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 31 ECO ADVANTAGE indicating that the transaction was successful. ECO ADVANTAGE
1 may, after receiving 1047 the transaction confirmation, save the confirmation within the 2 transaction record in the ECO ADVANTAGE database in order to mark the transaction 3 as completed. ECO ADVANTAGE may also credit 1048 the user's account with a 4 predetermined amount of new ecos based on the user's credit/debit payment, and may update the merchant and transaction records 1049 using the data in 1023 and/or like 6 information in the ECO ADVANTAGE database to indicate that the full transaction 7 amount has been processed and procured.
8 [ o col 5 7] If the acquirer cannot successfully procure the funds 1042, the acquirer 9 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 ii notification of a failed transaction, generate and send 1052 a transaction confirmation to 12 ECO ADVANTAGE indicating the transaction failed, and may also display and/or print 13 1053 a notification of transaction failure for the user and/or may prompt the user to 14 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 16 transaction as incomplete and necessary to retry, and mark related records (e.g. the 17 user's record, the merchant's record and/or the like) as also being incomplete 1055. In 18 some implementations, ECO ADVANTAGE may also monitor the status of various 19 transactions, and may reverse, retry, and/or otherwise handle incomplete transactions if found in the ECO ADVANTAGE database's records, based on predetermined criteria.
21 [o 0158] FIGURE na shows a data flow diagram illustrating fast commit, cash and 22 credit transaction in example embodiments of the ECO ADVANTAGE. In some 23 implementations, a user 1101 may send a transaction initiation request 1103 to the 24 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 26 encrypted. In some implementations the user may also provide a cash payment to the 27 merchant covering at least a part of the remaining transaction balance once the user's 28 ecos and/or bonus blocks are applied. In some implementations, the cash payment may 29 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 31 payment method. In some implementations, the merchant may send an eco request 1 1105 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 1109 the user account with a predetermined amount of ecos based ii 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(transactionId) 14 User user = transaction.getUser() 15 Merchant merchant = transaction.getMerchant() 16 long ecoUsage = transaction.getEcoUsage() 17 long bonusBlockUsage = transaction.getBonusBlockUsage() 18 long amountPaidInCash = transaction.getAmountPaidInCash() 19 Try {
20 beginTransaction() 21 user.debitEco(ecoUsage) 22 user.debitBonusBlock(bonusBlockUsage) 23 user.creditEco(amountPaidInCash, merchant) 24 commitTransaction();
25 I catch (Exception) {
26 rollbackTransaction();
27 return false;
28 }
29 [0 0 159] 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 [0 0160] 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 1 implementations, the merchant may display and/or print 1112 the ecos information for 2 the user via an ecos transaction receipt. The merchant may send a payment request 1113 3 to the merchant's acquirer 1114, which may ask the entity to process the transaction. In 4 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 6 sending a transaction request 1116 to a bank entity 1117 (e.g. the user's issuing bank, 7 another acquirer, and/or the like). The bank may send a transaction response 1118 to the 8 acquirer, which may indicate whether or not the transaction was approved and/or 9 processed, or whether the transaction was declined. The acquirer may forward this information to ECO ADVANTAGE via transaction confirmation 1121, which may take a ii form similar to transaction confirmation 1021, or may forward the information to the 12 merchant via transaction confirmation 1119 (which may take a form similar to 13 transaction confirmation 219), who may forward the information via transaction 14 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 16 similar to ttransaction receipt 1024. In some implementations, ECO
ADVANTAGE may 17 also monitor the status of various transactions, and may reverse, retry, and/or otherwise 18 handle incomplete transactions if found in the ECO ADVANTAGE database's records, 19 based on predetermined criteria.
[o 0 1 6 1 ] FIGURES ilb-c show logic flow diagrams illustrating fast commit, cash 21 and credit transactions in example embodiments of the ECO ADVANTAGE. In some 22 implementations, a user may initiate 1150 a transaction with an enrolled merchant, via 23 providing transaction input to a merchant. The merchant may receive the user input and 24 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, 26 ECO ADVANTAGE may receive 1125 the request for the user's eco and bonus block 27 balance, and may retrieve from the ECO ADVANTAGE database 1126 the user's 28 available ecos, bonus blocks, and/or the like to determine which and how many ecos and 29 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
31 may debit 1128 the ecos and/or bonus blocks used in the transaction from the user's 1 account, and may credit the user's account with a predetermined amount of new ecos, 2 which may be based on the transaction amount (e.g. both the cash payment and the 3 pending credit/debit card payment). ECO ADVANTAGE may also update the merchant 4 account and transaction records 1129 using the information in 1110 and/or like information to add the transaction to the ECO ADVANTAGE database and to update the 6 merchant's records based on the transaction data (e.g. update information described in 7 ino). ECO ADVANTAGE may generate and send 1130 a response to the merchant 8 indicating the user's eco and/or bonus block balances and/or like transaction 9 information. After receiving 1131 the response, the merchant may generate and send a transaction receipt 1132 to the user containing the data from the transaction (e.g.
ii transaction total, amount paid with cash, amount paid with a credit/debit card, amount 12 of ecos and/or bonus blocks used, and/or the like), which may be sent and received 1133 13 by the user.
14 [00162] In some implementations, the merchant may also generate and send a payment request 1134 with the user's payment information, the transaction balance 16 after subtracting the applied ecos and/or bonus blocks and the partial cash payment 17 from the original transaction amount, and/or like information to an acquirer for 18 procurement. In some implementations the acquirer may receive 1135 the user's 19 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 21 from the user's issuing bank.
22 [00163] If the acquirer can successfully procures the funds 1137, the acquirer may 23 obtain the funds 1138 and may send a confirmation to the merchant (and in some 24 implementations, to ECO ADVANTAGE) indicating that the transaction was successfully processed. In some implementations the merchant may, if it receives a notification 1139 26 indicating a successful transaction, print and/or display a transaction receipt 1140 for 27 the user, and may generate 1141 and send 1142 a transaction confirmation message to 28 ECO ADVANTAGE indicating that the transaction was successful. ECO ADVANTAGE
29 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 31 as completed.
1 [o 0 1 64 ] 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 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. the io user's record, the merchant's record and/or the like) as also being incomplete 1149. In ii some implementations, ECO ADVANTAGE may also monitor the status of various 12 transactions, and may reverse, retry, and/or otherwise handle incomplete transactions if 13 found in the ECO ADVANTAGE database's records, based on predetermined criteria.
14 [00165] FIGURE 12a shows a data flow diagram illustrating fast commit, cash only transactions in example embodiments of the ECO ADVANTAGE. In some 16 implementations, a user 1201 may send a transaction initiation request 1203 to the 17 merchant 1204 using the merchant's PoS device and/or a user electronic device 1202. In 18 some implementations, sensitive information (e.g. the user PIN and/or the like) may be 19 encrypted. In some implementations the user may also provide a cash payment to the merchant covering the entirety of the remaining transaction balance once the user's ecos 21 and/or bonus blocks are applied. In some implementations, the cash payment may also 22 be a check, gift coupon, pre-paid gift voucher, community scrip, electronic fund transfer, 23 a money card, money order, bank transfer, bank payment slip, and/or a like payment 24 method. In some implementations, the merchant may send an eco request 1205 to the ECO ADVANTAGE 1206. In some implementations, eco request 1205 may take a form 26 similar to eco request 206. ECO ADVANTAGE may look up the user's and merchant's 27 records using the user ID (UID) and the merchant ID 1207, respectively, and may 28 determine which and how many ecos and bonus blocks the user may apply to his 29 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 31 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 the merchant account record 1209, including updating BI information, transaction data, 6 the merchant's usage schedule, atmospherics, and/or the like.
7 [00166] 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 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 [0016 7] FIGURE 12b shows a logic flow diagram illustrating fast commit, cash only 14 transactions in example embodiments of the ECO ADVANTAGE. In some 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, 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, and may credit the user's account with a predetermined amount of new ecos, which may 26 be based on the cash payment).
27[o 0168] ECO ADVANTAGE may also update the merchant account and transaction 28 records 1219 using the information from 1209 and/or like information to add the 29 transaction to the ECO ADVANTAGE database and to update the merchant's records 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 1 user's eco and/or bonus block balances and/or like transaction information.
After 2 receiving 1221 the response, the merchant may generate and send a transaction receipt 3 to the user containing the data from the transaction (e.g. transaction total, amount paid 4 with cash, amount of ecos and/or bonus blocks used, and/or the like). When the user 5 receives 1222 the transaction receipt, the user may pay cash 1223 to the merchant. The 6 merchant may receive the cash payment 1224 from the user, which may cover the 7 transaction balance after the user's qualifying ecos and bonus blocks have been applied.
8 The merchant may credit 1225 the cash payment to the merchant's bank account via 9 depositing the cash in the merchant's bank account.
10 [co co 16 9 ] In some implementations, ECO ADVANTAGE and/or the merchant may 11 prompt the user to confirm after the transaction has been committed. In such 12 implementations, if the user confirms the transaction, the user may receive transaction 13 receipt 1211 and may pay for the transaction. If the user declines the transaction, ECO
14 ADVANTAGE may reverse the committed transaction information in the ECO
15 ADVANTAGE database.
16 [00170] FIGURE 13a shows a data flow diagram illustrating slow commit, cash 17 only transactions in example embodiments of the ECO ADVANTAGE. In some 18 implementations, a user 1301 may send a transaction initiation request 1303 to the 19 merchant 1304 using the merchant's PoS device and/or a user electronic device 1302. In 20 some implementations, sensitive information (e.g. the user PIN and/or the like) may be 21 encrypted. In some implementations, the merchant may send an eco request 1305 to the 22 ECO ADVANTAGE 1306. In some implementations, eco request 1305 may take a form 23 similar to eco request 206.
24 [00171] ECO ADVANTAGE may look up the user's and merchant's records using 25 the user ID (UID) and the merchant ID 1307, respectively, and may determine which 26 and how many ecos and bonus blocks the user may apply to his transaction (e.g. based 27 on the merchant's eco schedule, the user's eco and bonus block balances, and/or the 28 like), and may determine the state of a user confirmation setting. If the confirmation 29 setting is set to "true," ECO ADVANTAGE may require the user to confirm his 30 transaction before initiating any portion of it. In some implementations ECO
31 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 1309 the ecos information for the user, who may review the information 3 1310 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 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 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 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 to transaction receipt 1211.
21 [00173] FIGURE 1313 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 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 may be applied to the current transaction, as well as to determine the user's 31 confirmation setting. If the confirmation setting is off 1319, 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 1321 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 transaction. The user may confirm 1322 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 [ o co 174] 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 and/or bonus blocks have been applied. The merchant may credit 1324 the cash ii 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 1325 the transaction receipt, and ECO ADVANTAGE may debit the used ecos and/or bonus blocks from the user's balances 1326 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 1327 using the 18 information from 1314 and/or like information and ECO ADVANTAGE's transaction 19 records in order to update the merchant and transaction data stored in the ECO
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 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:
W POST / eco_schedule_request.php HTTP/1.1 31 Host: www.ECOADVANTAGEprocess.com 1 Content-Type: Application/XML
2 Content-Length: 788 3 <?XML version = "1.0" encoding = "UTF-8"?>
4 <ecoScheduleRequest>
<partnerId>154</partnerId>
6 <deviceId>579524552</deviceId>
7 <userId>102557952</userId>
8 <userAuth>da6c5cdf4e90b2961873f7b2e863415</userAuth>
9 <origDocNumber></origDocNumber>
M <nsu>572052</nsu>
11 <mcc>6432</mcc>
12 <transactionAmount>100.0</transactionAmount>
M <minTransactionSize>100</minTransactionSize>
14 <maxTransactionSize>5000</maxTransactionSize>
M <transactionSize>1</transactionSize>
M <productData>
17 <sku>56673858</sku>
M <sku>56673953</sku><description>television</description>
19 <sku>56685901</sku>
20 </productData>
21 <dateTime>03/07/2013 03:39 PM</dateTime>
22</ecoScheduleRequest>
23 [00176] In some implementations, ECO ADVANTAGE may look up the partner in 24 the ECO ADVANTAGE database using the partner's ID 1404, and may retrieve the 25 partner's eco schedule for bulk amounts. In some implementations the eco schedule 26 may be based on transaction and historic data, atmospherics, and/or the like. ECO
27 ADVANTAGE may send an eco schedule response 1405 to the partner containing eco 28 schedules and/or the like. In some implementations the eco schedule response 1405 29 may take a form similar to the following:
W POST /eco_schedule_response.php HTTP/1.1 31 Host: www.ECOADVANTAGEprocess.com 32 Content-Type: Application/XML
33 Content-Length: 788 34<?XML version = "1.0" encoding =
35<ecoScheduleResponse>
1 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
2 <transactionId>635467</transactionId>
3 <partnerId>154</partnerId>
4 <ecoScheduleList>
<ecoUsage>
6 <sku>56673858</sku>
7 <quantity>100</quantity>
8 <percentage>15</percentage>
9 </ecoUsage>
<ecoUsage>
11 <sku>56673953</sku>
12 <description>television</description>
13 <quantity>500</quantity>
14 <percentage>20</percentage>
</ecoUsage>
16 <ecoUsage>
17 <sku>56685901</sku>
18 <quantity>1000</quantity>
19 <percentage>30</percentage>
</ecoUsage>
21 </ecoScheduleList>
22 <startDateTime>03/03/2013 00:00 AM</startDateTime>
23 <endDateTime>04/04/2013 23:59 PM</endDateTime>
24 <dateTime>02/02/2013 03:39 PM</dateTime>
</ecoScheduleResponse>
26 [00177] The partner may use the information in the response to create a 27 product/service bulk amount 1406 based on the promoter's eco schedule and/or other 28 ECO ADVANTAGE parameters.
29 [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 31 to employees and/or the like as part of an incentive program (e.g. as bonuses, rewards, 32 and/or the like). In some implementations partners may open credit lines for 33 employees, wherein the credit line may be equal to an amount of ecos given to 34 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) 1 in products and/or services, with SRP. In some implementations consumers may also be 2 able to pay parts of transactions with partners with ecos.
3 [00179] In other implementations, the partner may also have access to a B2B
4 Marketplace interface (e.g. a website, application, and/or the like) which may allow the 5 partner to launch new products, and/or provide like information.
6 [00180] In some implementations ECO ADVANTAGE may provide a merchant 7 with an allotment of ecos, bonus blocks, and/or the like to be used with participating 8 partners. In some implementations the merchant may receive such allotments once (e.g.
9 after meeting a milestone, e.g. providing a predetermined amount of ecos to its io consumers and/or the like, after enrolling, and/or the like), or more than once over a ii period of time (e.g. weekly, monthly, annually, and/or the like, at some interval if the 12 merchant meets predefined ECO ADVANTAGE criteria, and/or the like). In some 13 implementations, a merchant 1407 may use the allotment of ecos to purchase a product 14 and/or service from the partner, via choosing 1408 a product and/or service available 15 for purchase from the partner. The partner may send an eco request 1409 to ECO
16 ADVANTAGE in order to get the merchant's eco balance, updated partner eco 17 schedules, and/or the like. in some implementations eco request 1409 may take a form 18 similar to the following:
19 POST /eco_request.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<ecoRequest>
25 <partnerId>154</partnerId>
26 <merchantId>2033</merchantId>
27 <transactionAmount>100.0</transactionAmount>
28 <productData>
29 <sku>56673953</sku>
W </productData>
31 <dateTime>03/07/2013 03:39 PM</dateTime>
32</ecoRequest>
1 [00181] ECO ADVANTAGE may look up 1410 the merchant to ensure it has an 2 account in the ECO ADVANTAGE database, and to look up the partner for its available 3 schedules and/or the like. In some implementations Grails code for looking up the 4 merchant and partner may take a form similar to the following:
def partner = Partner.get(params.partnerId);
6 if (!partner) {
7 log.warn("Partner not found with value '${params.partnerId}'");
8 return sendError('exception.partner.not.found');
9 }elseif (!partner.enabled 11 !partner.confirmed) {
log.warn("Partner inactive with value '${params.partnerId}'");
11 return sendError('exception.partner.inactive');
12 1 elseif (partner.accountLocked) {
M log.warn("Partner account locked with value 14 '${params.partnerId}'");
return sendError('exception.partner.locked');
18 def schedule = partner.getSchedules() def merchant = Merchant.get(params.merchantId);
21 if (!merchant) {
22 log.warn("Merchant not found with value '${params.merchant}'");
23 return sendError('exception.merchant.not.found');
24 1 elseif (!merchant.enabled 11 !merchant.confirmed) {
log.warn("Merchant inactive with value '${params.merchant}'");
26 return sendError('exception.merchant.inactive');
27 1 elseif (merchant.accountLocked) {
28 log.warn("Merchant account locked with value 29 '${params.merchant}'");
return sendError('exception.merchant.locked');
33 def productData = merchant.getProductData() def balanceForPartner = getBalanceForPartner(transaction.merchant, 36 transaction.partner) 1 def amountOfEcos = calculateValueToPayWithEco(transaction, schedule, 2 productData, balanceForPartner) 3 [00182] ECO ADVANTAGE may send an eco response 1411 to the partner with the 4 requested information. In some implementations, eco response 1411 may take a form similar to the following:
6 POST /eco_response.php HTTP/1.1 7 Host: www.ECOADVANTAGEprocess.com 8 Content-Type: Application/XML
9 Content-Length: 788 <?XML version = "1.0" encoding = "UTF-8"?>
11 <ecoResponse>
12 <partnerId>154</partnerId>
13 <merchantId>2033</merchantId>
14 <transactionId>635467</transactionId>
<transactionAmount>100.0</transactionAmount>
16 <ecoSaving>20%</ecoSaving>
17 <ecoBalance>1091</ecoBalance>
18 <amountDueInDollars>77.0</amountDueInDollars>
19 <ecoUsage>23</ecoUsage>
<dateTime>03/07/2013 03:39 PM</dateTime>
21 <ecoResponse>
22 [0 0183] The partner may send a transaction confirmation message 1412 to the 23 merchant indicating the transaction balance and/or like transaction information, and 24 prompting the merchant to confirm the transaction. In some implementations, the transaction confirmation message 1412 may take a form similar to the following:
26 POST /transaction_confirmation.php HTTP/1.1 27 Host: www.ECOADVANTAGEprocess.com 28 Content-Type: Application/XML
29 Content-Length: 788 <?XML version = "1.0" encoding =
31 <transactionConfirmation>
32 <partnerId>154</partnerId>
33 <merchantId>2033</merchantId>
34 <transactionId>635467</transactionId>
<status>Approved</status>
1 <dateTime>03/07/2013 03:39 PM</dateTime>
2 </transactionConfirmation>
3 [00184] The merchant may confirm 1413 the transaction and the use of ecos 4 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 6 some implementations, the partner may receive a transaction confirmation from the 7 acquirer indicating whether or not the transaction was successful or not, and may 8 forward this transaction confirmation via a message 1415 to ECO ADVANTAGE.
In some 9 implementations, ECO ADVANTAGE may, upon receiving a confirmation that the transaction was successful, debit the ecos used for the transaction from the merchant's ii account 1416, may credit the merchant's account with a new predetermined amount of 12 ecos (the amount based at least partially on the amount the merchant pays for the 13 transaction), and may update the merchant's balance. IN some implementations, 14 updating the merchant's balance may take a form similar to the following:
Transaction transaction = Transaction.get(transactionId) 16 Merchant merchant = transaction.getMerchant() 17 Partner partner = transaction.getPartner() 18 long ecoUsage = transaction.getEcoUsage() 19 long bonusBlockUsage = transaction.getBonusBlockUsage() long amountDueInDollars = transaction.getAmountDueInDollars() 22 Try {
23 beginTransaction() 24 merchant.debitEco(ecoUsage) user.debitBonusBlock(bonusBlockUsage) 26 merchant.creditEco(amountDueInDollars, partner) 27 commitTransaction();
28 I catch (Exception) {
29 rollbackTransaction();
1 return false;
2}
3 [00185] ECO ADVANTAGE may also update the partner's account record and 4 transaction records, including creating a transaction record, updating the partner's BI
information, transaction data, usage schedules using the transaction's date, time and 6 atmospherics, and/or the like. In some implementations, Grails code for updating 7 partner data may take a form similar to the following:
8 Transaction transaction = Transaction.get(transactionId) 9 Partner partner = transaction.getPartner() M Merchant merchant = transaction.getMerchant() 11 long ecoUsage = transaction.getEcoUsage() 12 long bonusBlockUsage = transaction.getBonusBlockUsage() M
14 def historyTransaction = new HistoryTransaction(transaction, partner, merchant, M ecoUsage, bonusBlockUsage) M historyTransaction.save() 17 [00186] FIGURES 14b-c show logic flow diagrams illustrating merchant and 18 partner transactions in example embodiments of the ECO ADVANTAGE. In some 19 implementations, before a transaction, a partner may generate and send 1418 a request 20 to ECO ADVANTAGE for its eco schedule information. ECO ADVANTAGE may receive 21 1419 the request for the partner's eco schedules, and may look up the partner's record 22 using the partner ID included in the request. ECO ADVANTAGE may retrieve the 23 partner's eco schedules and/or like partner information and use them to calculate the 24 eco schedule to provide per bulk amount of the partner's products and/or services. ECO
25 ADVANTAGE may generate and send 1421 a schedule response to the partner, who may 26 receive the eco schedule response 1422 and may use the eco schedule per bulk amount 27 received to create and/or update product and service bulk amounts.
28 [00187] In some implementations, a merchant may, at some point, initiate a 29 transaction 1423 with a partner via choosing products and/or services to purchase. The 30 partner may obtain 1424 the transaction information from the merchant, and may 31 generate and send an eco request to ECO ADVANTAGE. ECO ADVANTAGE may receive 32 the eco request 1425 from the partner and may look up the partner and the merchant 1 using the partner and merchant IDs, respectively. If a partner record is not found, ECO
2 ADVANTAGE may prompt the partner to enroll in ECO ADVANTAGE. If a partner 3 record is found 1426, ECO ADVANTAGE may determine if a record for the merchant 4 can be found. If the merchant record 1427 is not found, ECO ADVANTAGE may prompt 5 the merchant to enroll in ECO ADVANTAGE (see FIGURES 4a-c for further detail). If 6 the merchant's record can be found, ECO ADVANTAGE may retrieve 1429 the 7 merchant's eco balance, and may use it to determine the number of ecos that can be 8 applied to the transaction amount. ECO ADVANTAGE may also retrieve the partner's 9 eco schedules, bulk amounts, and/or the like, and may send the partner and merchant 10 data to the partner via an eco response 1430 to the merchant. The merchant may receive 11 1431 the eco response from ECO ADVANTAGE and may prompt the merchant to 12 confirm the transaction given the merchant's eco information and the partner's current 13 bulk amounts. Once the merchant has confirmed 1432 the transaction and the use of 14 ecos, the partner may send 1433 the transaction balance (e.g. the transaction amount 15 minus the ecos applied) to an acquirer for procurement.
16 [00188] In some implementations, if the acquirer notifies the partner 1434 that the 17 procurement was a success, ECO ADVANTAGE may receive a notification indicating a 18 successful transaction 1438, and may create and store a record of the transaction in the 19 ECO ADVANTAGE database. ECO ADVANTAGE may debit 1439 the ecos used in the 20 transaction from the merchant's account, and may credit the merchant's account with a 21 predetermined amount of ecos based on the transaction amount and marked as being 22 from the promoter. ECO ADVANTAGE may also update the merchant and partner's 23 account records 1440 using the transaction information and/or like information in 1417, 24 and/or like information.
25 [00189] In some implementations, if the procurement was not successful 1434, the 26 merchant may receive a notification of transaction failure 1435, may be prompted to 27 retry the transaction and/or the like. The partner may also forward the notification to 28 ECO ADVANTAGE, which may receive the notice and store a transaction record for the 29 transaction 1436. In some implementations the record may be marked as incomplete so 30 that ECO ADVANTAGE may retry the transaction at a later time. In some 31 implementations ECO ADVANTAGE may also mark 1437 related records (e.g.
merchant 1 and partner records, and/or the like) as being incomplete as a result of the failed 2 transaction.
3 [00190] FIGURE 15a show a data flow diagram illustrating refunding or cancelling 4 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 6 cancel and/or obtain a refund for a transaction 1502, and may provide transaction 7 information (e.g. transaction and/or order ID, the user's ID, and/or the like) to the 8 merchant. In some implementations, sensitive information (e.g. the user PIN
and/or the 9 like) may be encrypted. The merchant may send a cancellation request 1504 to ECO
ADVANTAGE 1505, including the provided transaction information. In some 11 implementations, the cancellation request 1504 may take a forms similar to the 12 following:
13 POST /cancellation_request.php HTTP/1.1 14 Host: www.ECOADVANTAGEprocess.com Content-Type: Application/XML
16 Content-Length: 788 17 <?XML version = "1.0" encoding = "UTF-8"?>
18 <cancellationRequest>
19 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
<merchantId>2033</merchantId>
21 <posId>4088</posId>
22 <mcc>6432</mcc>
23 <transactionId>635467</transactionId>
24 <transactionDate>03/06/2013</transactionDate>
<transactionProcessingCode></transactionProcessingCode>
26 <transactionDocNumber></transactionDocNumber>
27 <transactionNsu></transactionNsu>
28 <dateTime>03/07/2013 01:39 PM</dateTime>
29 </cancellationRequest>
[00191] In some implementations, ECO ADVANTAGE may use the transaction ID
31 and/or other provided data 1506 in order to locate the transaction record in the ECO
32 ADVANTAGE database. In some implementations Grails code for locating the 33 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 '${params.transactionIc1}'.") return sendErroWexception.transaction.not.found');
6 1 elseif (!transaction.isCancellable()) {
7 log.warn("Transaction '${params.transactionId}' cannot be 8 cancelled.") 9 return sendErroWexception.transaction.not.cancellable');
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 take a form similar to the following:
M def amountDueInDollars = transaction.amountDueInDollars 17 def newEcos = transaction.newEcos M def usedEcos = transacton.usedEcos 19 def usedBonusBlocks = transacton.usedBonusBlocks [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:
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"?>
<cancellationResponse>
31 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
32 <transactionId>635467</transactionId>
33 <AmountToRefundUser4{amountDueInDollars}</AmountToRefundUser>
34 <EcosToRefundUser4{usedEcos}</EcosToRefundUser>
<BonusBlocksToRefundUser4{usedBonusBlocks}</BonusBlocksToRefundUser>
1 </cancellationResponse>
2 [00194] The merchant may print and/or display 1509 the amount of ecos to be 3 refunded, the amount of real currency to be refunded, the amount of ecos to be 4 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 6 cancellation transaction 1510, and the merchant may send a refund request 1511 to its 7 acquirer 1512 and/or a like entity in order to process the transaction. In some 8 implementations, refund request 1511 may take a form similar to the following:
9 POST /refund_request.php HTTP/1.1 M Host: www.ECOADVANTAGEprocess.com 11 Content-Type: Application/XML
12 Content-Length: 788 M<?XML version = "1.0" encoding = "UTF-8"?>
14 <refundRequest>
M <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
M <transactionId>635467</transactionId>
17 <merchantId>2033</merchantId>
M <posId>4065</posId>
19 <amountToBeRefunded>77.0</amountToBeRefunded>
20 <dateTime>03/07/2013 01:39 PM</dateTime>
21 </refundRequest>
22 [00195] The acquirer and/or like entity may authenticate the request 1513 and may 23 cancel the previous transaction and/or perform like tasks in order to process the 24 cancellation of the previous transaction. In some implementations the acquirer may 25 send a refund response 1514 indicating whether or not the refund transaction was 26 successful or not, and/or the like to the merchant, who may forward the refund response 27 to ECO ADVANTAGE 1515. In some implementations refund response 1514, 1515, and 28 1516 may take a form similar to the following:
29 POST /refund_request.php HTTP/1.1 W Host: www.ECOADVANTAGEprocess.com 31 Content-Type: Application/XML
32 Content-Length: 788 33<?XML version = "1.0" encoding =
34<refundResponse>
1 <UID>da6c5cdf4e90b2961873f7b2e863415</UID>
2 <transactionId>635467</transactionId>
3 <merchantId>2033</merchantId>
4 <posId>4065</posId>
<AmountToBeRefunded>77.0</AmountToBeRefunded>
6 <dateTime>03/07/2013 01:39 PM</dateTime>
7 <approved>true</approved>
8 </refundResponse>
9 [00196] In some implementations the acquirer may also send a refund response 1516 to ECO ADVANTAGE. In some implementations ECO ADVANTAGE may recredit ii 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 Grails code for updating the user's balances may take a form similar to the following:
16 Transaction transaction = Transaction.get(transactionId) 17 User user = transaction.getUser() 19 Try {
beginTransaction() 21 user.creditEco(transaction.usedEcos) 22 user.creditBonusBlocks(transaction.usedBonusBlocks) 23 user.debitEco(transaction.newEcos) 24 transaction.refunded = true;
transaction.save() 26 commitTransaction();
27 I catch (Exception) {
28 rollbackTransaction();
29 return false;
}
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 1513 shows a logic flow diagram illustrating refunding or 34 cancelling transactions in example embodiments of the ECO ADVANTAGE. In some 1 implementations, a user may indicate to a merchant a desire to cancel and/or refund a 2 transaction 1519. The merchant may obtain the request for a refund 1520 and may 3 generate and send a request for the transaction's information to ECO
ADVANTAGE, 4 using the transaction ID and/or other data provided by the user. ECO
ADVANTAGE
5 may receive 1521 the request for information about the transaction and may use the 6 transaction ID and/or like information 1522 in order to locate the proper transaction 7 record in the ECO ADVANTAGE. ECO ADVANTAGE may determine from the 8 transaction record 1523 the amount charged to the user, the amount of ecos and/or 9 bonus blocks the user spent in the transaction, the amount of ecos the user gained from 10 the transaction, and/or the like. ECO ADVANTAGE may then generate and send a 11 response 1524 to the merchant with the information determined from the transaction 12 record.
13 [o 0199] The merchant, upon receiving the response 1525, may print and/or display 14 the information received for the user to review, and may prompt the user to confirm the 15 refund and/or transaction cancellation. If the user authenticates and/or otherwise 16 confirms 1526 the transaction based on the displayed information, the merchant may 17 send a message 1527 to an acquirer and/or like payment entity in order to have the 18 refund transaction processed. In some implementations, the acquirer may receive 1528 19 the refund request, may authenticate 1529 the request, and may cancel 1530 the original 20 payment transaction.
21 [o 0200] If the cancellation is successful 1531, the acquirer may send a notification 22 1532 to the merchant indicating success in processing the refund. The merchant may 23 receive the notification 1533, may forward the confirmation to ECO
ADVANTAGE, and 24 the user may receive from the merchant a transaction receipt 1534 indicating the refund 25 confirmation and/or further transaction details. In some implementations, ECO
26 ADVANTAGE may receive the transaction message, and may save the confirmation as a 27 transaction record in the ECO ADVANTAGE database 1535 for future reference.
In some 28 implementations, ECO ADVANTAGE may also re-credit the user's account with the ecos 29 and/or bonus blocks used in the cancelled transaction 1526, may rescind any ecos given 30 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 1538 to the merchant, who may receive 1539 the 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 later time. ECO ADVANTAGE may also mark all related records (e.g. transaction ii 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 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 $o, but may require a wait time for 18 appointments 1607 of six or more months, may only allow a physician to earn 1609 $10 19 per visit, and may cost $o to a health insurance provider 1610.
[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.
[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 $8o 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 $80 to a health insurance provider if the user is insured, and provide $130 in earnings 2 (post-tax) to a physician per visit.
3 [0 0 2 05] 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 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 $8o per visit 9 if uninsured (along with 120 ecos), and may pay only $o and 120 ecos per visit if insured, and if the user's insurance will refund up to $8o 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 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 $8o, which 17 would be the same cost if the patient were able to afford private health insurance.
18 [co o 2 co 6] FIGURES 22a-b show block diagrams illustrating checking into ECO
19 ADVANTAGE in some embodiments of an ECO ADVANTAGE. In some 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 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 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 2209 to ECO
1 ADVANTAGE. In some implementations ECO ADVANTAGE may retrieve eco statistics 2 for the merchant 2210, such as the total number of ecos used from and/or at the 3 merchant, the merchant's current eco schedule (and/or the schedule within a specified 4 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 6 send the information to the user via an econometer response 2212. The user may then 7 send a check-in request 2213 to ECO ADVANTAGE, which may include user 8 identification information, the date and time of the check-in, the GPS
coordinates of the 9 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.
ii Facebook, Twitter, and/or the like), and/or may provide the user the opportunity to 12 choose social networking websites to share the check-in data with. ECO
ADVANTAGE
13 may also send a check-in confirmation 2215 to the user to indicate whether or not the 14 check-in was successful or not.
[00207] In some implementations, ECO ADVANTAGE may use a Telemetry 16 component to pull information from current real-time transactions and historic data 17 about users, merchants, transactions, ecos, bonus blocks, donation, eco calculations, 18 and/or the like.
19 [00208] Using the BI and the analytics components in conjunction with the Telemetry component, ECO ADVANTAGE may process these types of data, and may 21 produce individual and aggregated trend and skew per transaction data, user, merchant, 22 eco schedule, usage schedule, region, category, grand-total entities data, and/or the like.
23 ECO ADVANTAGE may also use these components to compare this trend and skew data 24 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 26 to trigger immediate action mechanisms on various components and entities, including 27 the Eco Schedule Calculation Component, Merchant Managers, Economic Promoters, 28 Merchants, Eco and Usage Schedules, and/or the like, in order to keep delivering the 29 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 31 Component. The Merchant Information Aggregation Component, and the Merchant and 1 User Enrollment Components. ECO ADVANTAGE may also use the Telemetry and/or 2 other components for calibration of thresholds.
3 [o 0210] In some implementations, an Econometer Component may allow ECO
4 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 6 entities as needed.
7 [00211] In some implementations ECO ADVANTAGE may use the Econometer 8 Component and/or other components to pull information from current real-time 9 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 ii Econometer Component to distribute this data to all available devices and entities.
12 [00212] For example, in some implementations, ECO ADVANTAGE may use this 13 component to facilitate communications between merchant and user entities via the 14 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 16 components as an Eco Calculator (e.g., for specific merchants, for specific entities as a 17 whole, and/or the like). In some implementations ECO ADVANTAGE may also use the 18 component to calculate current and/or near future merchant eco schedules, in numeric 19 and figurative representations.
[o 0213] In some implementations ECO ADVANTAGE may use this component to 21 facilitate communications from ECO ADVANTAGE to a user via his mobile device, a 22 website, SMS, Push msg, email, PoS, and/or like forms of communication. ECO
23 ADVANTAGE may also use the component to keep track of each user's total transaction 24 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 26 allow ECO ADVANTAGE to generate and/or provide reports of all these types of data.
27 [00214] In some implementations ECO ADVANTAGE may use this component to 28 facilitate communications from ECO ADVANTAGE to a merchant via a merchant's 29 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 1 components to calculate transaction usage, ecos usage, bonus block usage, aggregated 2 and by period, show graphs, %, balances, and/or like values, and may use the 3 component to generate and/or provide reports of all these types of data.
4 [00215] In some implementations ECO ADVANTAGE may also use the component 5 to, via a mobile application, a website, and/or the like, provide the aggregated overall 6 grand-total ecos usage (e.g., the total amount everybody already saved using the ECO
7 ADVANTAGE SYSTEM to date), and/or like statistics to entities on ECO
ADVANTAGE.
8 [ o o 216 ] Figure 22b demonstrates another exemplary implementations of checking 9 into ECO ADVANTAGE and searching for merchants.
10 ECO ADVANTAGE Controller 11 [o o 217] FIGURE 23 shows a block diagram illustrating embodiments of a ECO
12 ADVANTAGE controller. In this embodiment, the ECO ADVANTAGE controller 2301 13 may serve to aggregate, process, store, search, serve, identify, instruct, generate, match, 14 and/or facilitate interactions with a computer through commerce and mutual benefit 15 technologies, and/or other related data.
16 [00218] Typically, users, which may be people and/or other systems, may engage 17 information technology systems (e.g., computers) to facilitate information processing.
18 In turn, computers employ processors to process information; such processors 2303 19 may be referred to as central processing units (CPU). One form of processor is referred 20 to as a microprocessor. CPUs use communicative circuits to pass binary encoded signals 21 acting as instructions to enable various operations. These instructions may be 22 operational and/or data instructions containing and/or referencing other instructions 23 and data in various processor accessible and operable areas of memory 2329 (e.g., 24 registers, cache memory, random access memory, etc.). Such communicative 25 instructions may be stored and/or transmitted in batches (e.g., batches of instructions) 26 as programs and/or data components to facilitate desired operations. These stored 27 instruction codes, e.g., programs, may engage the CPU circuit components and other 28 motherboard and/or system components to perform desired operations. One type of 29 program is a computer operating system, which, may be executed by CPU on a I computer; the operating system enables and facilitates users to access and operate 2 computer information technology and resources. Some resources that may be employed 3 in information technology systems include: input and output mechanisms through 4 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 6 technology systems may be used to collect data for later retrieval, analysis, and 7 manipulation, which may be facilitated through a database program. These information 8 technology systems provide interfaces that allow users to access and operate various 9 system components.
[co co 2 19 ] In one embodiment, the ECO ADVANTAGE controller 2301 may be ii connected to and/or communicate with entities such as, but not limited to:
one or more 12 users from user input devices 2311; peripheral devices 2312; an optional cryptographic 13 processor device 2328; and/or a communications network 2313.
14 [00220] Networks are commonly thought to comprise the interconnection and interoperation of clients, servers, and intermediary nodes in a graph topology. It should 16 be noted that the term "server" as used throughout this application refers generally to a 17 computer, other device, program, or combination thereof that processes and responds to 18 the requests of remote users across a communications network. Servers serve their 19 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 21 processing and making requests and obtaining and processing any responses from 22 servers across a communications network. A computer, other device, program, or 23 combination thereof that facilitates, processes information and requests, and/or 24 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 26 transfer of information from source points to destinations. A node specifically tasked 27 with furthering the passage of information from a source to a destination is commonly 28 called a "router." There are many forms of networks such as Local Area Networks 29 (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 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 read only memory (ROM) 2306, a random access memory (RAM) 2305, etc.), and/or an ii 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, 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 2312 via the interface bus I/O. In turn, the transceivers may be connected to antenna(s) 21 2375, 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.1in, Bluetooth 24 3.0, FM, global positioning system (GPS) (thereby allowing ECO ADVANTAGE
controller to determine its location)); Broadcom BCM4329FKUBG transceiver chip 26 (e.g., providing 802.1in, Bluetooth 2.1 + EDR, FM, etc.); a Broadcom 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 systemization's circuit pathways. The clock is typically coupled to the system bus and 1 various clock multipliers that will increase or decrease the base operating frequency for 2 other components interconnected in the computer systemization. The clock and various 3 components in a computer systemization drive signals embodying information 4 throughout the system. Such transmission and reception of instructions embodying information throughout a computer systemization may be commonly referred to as 6 communications. These communicative instructions may further be transmitted, 7 received, and the cause of return and/or reply communications beyond the instant 8 computer systemization to: communications networks, input devices, other computer 9 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 ii one another, connected to the CPU, and/or organized in numerous variations employed 12 as exemplified by various computer systems.
13 [00223] The CPU comprises at least one high-speed data processor adequate to 14 execute program components for executing user and/or system-generated requests.
Often, the processors themselves will incorporate various specialized processing units, 16 such as, but not limited to: integrated system (bus) controllers, memory management 17 control units, floating point units, and even specialized processing sub-units like 18 graphics processing units, digital signal processing units, and/or the like. Additionally, 19 processors may include internal fast access addressable memory, and be capable of mapping and addressing memory 2329 beyond the processor itself; internal memory 21 may include, but is not limited to: fast registers, various levels of cache memory (e.g., 22 level 1, 2, 3, etc.), RAM, etc. The processor may access this memory through the use of a 23 memory address space that is accessible via instruction address, which the processor 24 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:
26 AMD's Athlon, Duron and/or Opteron; ARM's application, embedded and secure 27 processors; IBM and/or Motorola's DragonBall and PowerPC; IBM's and Sony's Cell 28 processor; Intel's Celeron, Core (2) Duo, Itanium, Pentium, Xeon, and/or XScale;
29 and/or the like processor(s). The CPU interacts with memory through instruction passing through conductive and/or transportive conduits (e.g., (printed) electronic 31 and/or optic circuits) to execute stored instructions (i.e., program code) according to 1 conventional data processing techniques. Such instruction passing facilitates 2 communication within the ECO ADVANTAGE controller and beyond through various 3 interfaces. Should processing requirements dictate a greater amount speed and/or 4 capacity, distributed processors (e.g., Distributed ECO ADVANTAGE), mainframe, multi-core, parallel, and/or super-computer architectures may similarly be employed.
6 Alternatively, should deployment requirements dictate greater portability, smaller 7 Personal Digital Assistants (PDAs) may be employed.
8 [00224] Depending on the particular implementation, features of the ECO
9 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.
ii Also, to implement certain features of the ECO ADVANTAGE, some feature 12 implementations may rely on embedded components, such as: Application-Specific 13 Integrated Circuit ("ASIC"), Digital Signal Processing ("DSP"), Field Programmable 14 Gate Array ("FPGA"), and/or the like embedded technology. For example, any of the ECO ADVANTAGE component collection (distributed or otherwise) and/or features 16 may be implemented via the microprocessor and/or via embedded components;
e.g., via 17 ASIC, coprocessor, DSP, FPGA, and/or the like. Alternately, some implementations of 18 the ECO ADVANTAGE may be implemented with embedded components that are 19 configured and used to achieve a variety of features or signal processing.
[ 00225] Depending on the particular implementation, the embedded components 21 may include software solutions, hardware solutions, and/or some combination of both 22 hardware/software solutions. For example, ECO ADVANTAGE features discussed 23 herein may be achieved through implementing FPGAs, which are a semiconductor 24 devices containing programmable logic components called "logic blocks", and programmable interconnects, such as the high performance FPGA Virtex series and/or 26 the low cost Spartan series manufactured by Xilinx. Logic blocks and interconnects can 27 be programmed by the customer or designer, after the FPGA is manufactured, to 28 implement any of the ECO ADVANTAGE features. A hierarchy of programmable 29 interconnects allow logic blocks to be interconnected as needed by the ECO
ADVANTAGE system designer/administrator, somewhat like a one-chip programmable 31 breadboard. An FPGA's logic blocks can be programmed to perform the operation of 1 basic logic gates such as AND, and XOR, or more complex combinational operators such 2 as decoders or mathematical operations. In most FPGAs, the logic blocks also include 3 memory elements, which may be circuit flip-flops or more complete blocks of memory.
4 In some circumstances, the ECO ADVANTAGE may be developed on regular FPGAs and then migrated into a fixed version that more resembles ASIC implementations.
6 Alternate or coordinating implementations may migrate ECO ADVANTAGE
controller 7 features to a final ASIC instead of or in addition to FPGAs. Depending on the 8 implementation all of the aforementioned embedded components and microprocessors 9 may be considered the "CPU" and/or "processor" for the ECO ADVANTAGE.
Power Source 11 [00226] The power source 2386 may be of any standard form for powering small 12 electronic circuit board devices such as the following power cells:
alkaline, lithium 13 hydride, lithium ion, lithium polymer, nickel cadmium, solar cells, and/or the like.
14 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 16 capture photonic energy. The power cell 2386 is connected to at least one of the 17 interconnected subsequent components of the ECO ADVANTAGE thereby providing an 18 electric current to all subsequent components. In one example, the power source 2386 is 19 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 21 example, a USB and/or IEEE 1394 connection carries both data and power across the 22 connection and is therefore a suitable source of power.
23 Interface Adapters 24 [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 26 adapter cards, such as but not limited to: input output interfaces (I/O) 2308, storage 27 interfaces 2309, network interfaces 2310, and/or the like. Optionally, cryptographic 28 processor interfaces 2327 similarly may be connected to the interface bus.
The interface 29 bus provides for the communications of interface adapters with one another as well as 1 with other components of the computer systemization. Interface adapters are adapted 2 for a compatible interface bus. Interface adapters conventionally connect to the 3 interface bus via a slot architecture. Conventional slot architectures may be employed, 4 such as, but not limited to: Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, 6 Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal 7 Computer Memory Card International Association (PCMCIA), and/or the like.
8 [o co 2 2 8] Storage interfaces 2309 may accept, communicate, and/or connect to a 9 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 ii as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet 12 Interface) ((Ultra) (Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE), 13 Institute of Electrical and Electronics Engineers (IEEE) 1394, fiber channel, Small 14 Computer Systems Interface (SCSI), Universal Serial Bus (USB), and/or the like.
[00229] Network interfaces 2310 may accept, communicate, and/or connect to a 16 communications network 2313. Through a communications network 2313, the ECO
17 ADVANTAGE controller is accessible through remote clients 2333b (e.g., computers 18 with web browsers) by users 2333a. Network interfaces may employ connection 19 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
21 802.na-x, and/or the like. Should processing requirements dictate a greater amount 22 speed and/or capacity, distributed network controllers (e.g., Distributed ECO
23 ADVANTAGE), architectures may similarly be employed to pool, load balance, and/or 24 otherwise increase the communicative bandwidth required by the ECO
ADVANTAGE
controller. A communications network may be any one and/or the combination of the 26 following: a direct interconnection; the Internet; a Local Area Network (LAN); a 27 Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet 28 (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless 29 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 31 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 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 1394a-b, serial, universal serial bus (USB);
infrared; joystick;
9 keyboard; midi; optical; PC AT; PS/2; parallel; radio; video interface:
Apple Desktop Connector (ADC), BNC, coaxial, component, composite, digital, Digital Visual Interface ii (DVI), high-definition multimedia interface (HDMI), RCA, RF antennae, S-Video, VGA, 12 and/or the like; wireless transceivers: 802.11a/b/g/n/x; Bluetooth;
cellular (e.g., code 13 division multiple access (CDMA), high speed packet access (HSPA(+)), high-speed 14 downlink packet access (HSDPA), global system for mobile communications (GSM), long term evolution (LTE), WiMax, etc.); and/or the like. One typical output device may 16 include a video display, which typically comprises a Cathode Ray Tube (CRT) or Liquid 17 Crystal Display (LCD) based monitor with an interface (e.g., DVI circuitry and cable) 18 that accepts signals from a video interface, may be used. The video interface composites 19 information generated by a computer systemization and generates video signals based on the composited information in a video memory frame. Another output device is a 21 television set, which accepts signals from a video interface. Typically, the video interface 22 provides the composited video information through a video connection interface that 23 accepts a video display interface (e.g., an RCA composite video connector accepting an 24 RCA composite video cable; a DVI connector accepting a DVI display cable, etc.).
[00231] User input devices 2311 often are a type of peripheral device 512 (see 26 below) and may include: card readers, dongles, finger print readers, gloves, graphics 27 tablets, joysticks, keyboards, microphones, mouse (mice), remote controls, retina 28 readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors 29 (e.g., accelerometers, ambient light, GPS, gyroscopes, proximity, etc.), styluses, and/or 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 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 (e.g., cellular, GPS, etc.), video devices (e.g., goggles, monitors, etc.), video sources, ii 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, 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, 18 processors 2326, interfaces 2327, and/or devices 2328 may be attached, and/or 19 communicate with the ECO ADVANTAGE controller. A MC68HC16 microcontroller, 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 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 CryptoNetX 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 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 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 io may be configured wherein the operation of on-chip CPU memory (e.g., registers), RAM, ii 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 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 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) 2315 (operating system); information server component(s) 2316 (information server);
26 user interface component(s) 2317 (user interface); Web browser component(s) 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 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 [o co 2 3 7] The operating system component 2315 is an executable program 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
Nan 9; Be 14 OS; Unix and Unix-like system distributions (such as AT&T's UNIX; Berkley Software 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.
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, 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 communication protocols may be used by the ECO ADVANTAGE controller as a 1 subcarrier transport mechanism for interaction, such as, but not limited to:
multicast, 2 TCP/IP, UDP, unicast, and/or the like.
3 Information Server 4 [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 6 information server such as, but not limited to Apache Software Foundation's Apache, 7 Microsoft's Internet Information Server, and/or the like. The information server may 8 allow for the execution of program components through facilities such as Active Server 9 Page (ASP), ActiveX, (ANSI) (Objective-) C (++), C* and/or .NET, Common Gateway Interface (CGI) scripts, dynamic (D) hypertext markup language (HTML), FLASH, Java, ii JavaScript, Practical Extraction Report Language (PERL), Hypertext Pre-Processor 12 (PHP), pipes, Python, wireless application protocol (WAP), WebObjects, and/or the like.
13 The information server may support secure communications protocols such as, but not 14 limited to, File Transfer Protocol (FTP), HyperText Transfer Protocol (HTTP), Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), messaging protocols 16 (e.g., America Online (AOL) Instant Messenger (AIM), Application Exchange (APEX), 17 ICQ, Internet Relay Chat (IRC), Microsoft Network (MSN) Messenger Service, Presence 18 and Instant Messaging Protocol (PRIM), Internet Engineering Task Force's (IETF's) 19 Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE), open XML-based Extensible Messaging and Presence Protocol 21 (XMPP) (i.e., Jabber or Open Mobile Alliance's (OMA's) Instant Messaging and 22 Presence Service (IMPS)), Yahoo! Instant Messenger Service, and/or the like. The 23 information server provides results in the form of Web pages to Web browsers, and 24 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 26 HTTP request is resolved to a particular information server, the information server 27 resolves requests for information at specified locations on the ECO
ADVANTAGE
28 controller based on the remainder of the HTTP request. For example, a request such as 29 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;
1 that information server might in turn further parse the http request for the 2 "/myInformation.html" portion of the request and resolve it to a location in memory 3 containing the information "myInformation.html." Additionally, other information 4 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 6 other components in a component collection, including itself, and/or facilities of the 7 like. Most frequently, the information server communicates with the ECO
ADVANTAGE
8 database 2319, operating systems, other program components, user interfaces, Web 9 browsers, and/or the like.
[co co 2 3 9] Access to the ECO ADVANTAGE database may be achieved through a ii number of database bridge mechanisms such as through scripting languages as 12 enumerated below (e.g., CGI) and through inter-application communication channels as 13 enumerated below (e.g., CORBA, WebObjects, etc.). Any data requests through a Web 14 browser are parsed through the bridge mechanism into appropriate grammars as required by the ECO ADVANTAGE. In one embodiment, the information server would 16 provide a Web form accessible by a Web browser. Entries made into supplied fields in 17 the Web form are tagged as having been entered into the particular fields, and parsed as 18 such. The entered terms are then passed along with the field tags, which act to instruct 19 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 21 string with the proper join/select commands based on the tagged text entries, wherein 22 the resulting command is provided over the bridge mechanism to the ECO
23 ADVANTAGE as a query. Upon generating query results from the query, the results are 24 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 26 provided to the information server, which may supply it to the requesting Web browser.
27 [00240] Also, an information server may contain, communicate, generate, obtain, 28 and/or provide program component, system, user, and/or data communications, 29 requests, and/or responses.
1 User Interface 2 [0 0241] 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, 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 Macintosh Operating System's Aqua, IBM's OS/2, Microsoft's Windows 11 2000/2003/3.1/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, 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 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 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 program component, system, user, and/or data communications, requests, and/or 31 responses.
1 Web Browser 2 [00243] A Web browser component 2318 is a stored program component that is 3 executed by a CPU. The Web browser may be a conventional hypertext viewing 4 application such as Microsoft Internet Explorer or Netscape Navigator.
Secure Web browsing may be supplied with 128bit (or greater) encryption by way of HTTPS, SSL, 6 and/or the like. Web browsers allowing for the execution of program components 7 through facilities such as ActiveX, AJAX, (D)HTML, FLASH, Java, JavaScript, web 8 browser plug-in APIs (e.g., FireFox, Safari Plug-in, and/or the like APIs), and/or the 9 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 ii and/or with other components in a component collection, including itself, and/or 12 facilities of the like. Most frequently, the Web browser communicates with information 13 servers, operating systems, integrated program components (e.g., plug-ins), and/or the 14 like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.
16 Also, in place of a Web browser and information server, a combined application may be 17 developed to perform similar operations of both. The combined application would 18 similarly affect the obtaining and the provision of information to users, user agents, 19 and/or the like from the ECO ADVANTAGE enabled nodes. The combined application may be nugatory on systems employing standard Web browsers.
21 Mail Server 22 [00244] A mail server component 2321 is a stored program component that is 23 executed by a CPU 2303. The mail server may be a conventional Internet mail server 24 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 26 ASP, ActiveX, (ANSI) (Objective-) C (++), C* and/or .NET, CGI scripts, Java, 27 JavaScript, PERL, PHP, pipes, Python, WebObjects, and/or the like. The mail server 28 may support communications protocols such as, but not limited to: Internet message 29 access protocol (IMAP), Messaging Application Programming Interface 1 (MAPI)/Microsoft Exchange, post office protocol (POP3), simple mail transfer protocol 2 (SMTP), and/or the like. The mail server can route, forward, and process incoming and 3 outgoing mail messages that have been sent, relayed and/or otherwise traversing 4 through and/or to the ECO ADVANTAGE.
[00245] Access to the ECO ADVANTAGE mail may be achieved through a number 6 of APIs offered by the individual Web server components and/or the operating system.
7 [00246] Also, a mail server may contain, communicate, generate, obtain, and/or 8 provide program component, system, user, and/or data communications, requests, 9 information, and/or responses.
Mail Client 11[00247] A mail client component 2322 is a stored program component that is 12 executed by a CPU 2303. The mail client may be a conventional mail viewing application 13 such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook 14 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
16 mail client may communicate to and/or with other components in a component 17 collection, including itself, and/or facilities of the like. Most frequently, the mail client 18 communicates with mail servers, operating systems, other mail clients, and/or the like;
19 e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or 21 responses. Generally, the mail client provides a facility to compose and transmit 22 electronic mail messages.
23 Cryptographic Server 24 [00248] A cryptographic server component 2320 is a stored program component that is executed by a CPU 2303, cryptographic processor 2326, cryptographic processor 26 interface 2327, cryptographic processor device 2328, and/or the like.
Cryptographic 27 processor interfaces will allow for expedition of encryption and/or decryption requests 28 by the cryptographic component; however, the cryptographic component, alternatively, I may run on a conventional CPU. The cryptographic component allows for the 2 encryption and/or decryption of provided data. The cryptographic component allows for 3 both symmetric and asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/or 4 decryption. The cryptographic component may employ cryptographic techniques such as, but not limited to: digital certificates (e.g., X.5o9 authentication framework), digital 6 signatures, dual signatures, enveloping, password access protection, public key 7 management, and/or the like. The cryptographic component will facilitate numerous 8 (encryption and/or decryption) security protocols such as, but not limited to: checksum, 9 Data Encryption Standard (DES), Elliptical Curve Encryption (ECC), International Data Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash ii operation), passwords, Rivest Cipher (RC5), Rijndael, RSA (which is an Internet 12 encryption and authentication system that uses an algorithm developed in 1977 by Ron 13 Rivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA), Secure 14 Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and/or the like.
Employing such encryption security protocols, the ECO ADVANTAGE may encrypt all 16 incoming and/or outgoing communications and may serve as node within a virtual 17 private network (VPN) with a wider communications network. The cryptographic 18 component facilitates the process of "security authorization" whereby access to a 19 resource is inhibited by a security protocol wherein the cryptographic component effects authorized access to the secured resource. In addition, the cryptographic component 21 may provide unique identifiers of content, e.g., employing and MD 5 hash to obtain a 22 unique signature for an digital audio file. A cryptographic component may communicate 23 to and/or with other components in a component collection, including itself, and/or 24 facilities of the like. The cryptographic component supports encryption schemes allowing for the secure transmission of information across a communications network 26 to enable the ECO ADVANTAGE component to engage in secure transactions if so 27 desired. The cryptographic component facilitates the secure accessing of resources on 28 the ECO ADVANTAGE and facilitates the access of secured resources on remote 29 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 31 systems, other program components, and/or the like. The cryptographic component I may contain, communicate, generate, obtain, and/or provide program component, 2 system, user, and/or data communications, requests, and/or responses.
3 The ECO ADVANTAGE Database 4 [o o 249] 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 6 executed by the CPU; the stored program component portion configuring the CPU to 7 process the stored data. The database may be a conventional, fault tolerant, relational, 8 scalable, secure database such as Oracle or Sybase. Relational databases are an 9 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 ii the tables by indexing against the key field; i.e., the key fields act as dimensional pivot 12 points for combining information from various tables. Relationships generally identify 13 links maintained between tables by matching primary keys. Primary keys represent 14 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.
16 [oo 2 5 o] Alternatively, the ECO ADVANTAGE database may be implemented using 17 various standard data-structures, such as an array, hash, (linked) list, struct, structured 18 text file (e.g., XML), table, and/or the like. Such data-structures may be stored in 19 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 21 databases can include a number of object collections that are grouped and/or linked 22 together by common attributes; they may be related to other object collections by some 23 common attributes. Object-oriented databases perform similarly to relational databases 24 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 26 implemented as a data-structure, the use of the ECO ADVANTAGE database 2319 may 27 be integrated into another component such as the ECO ADVANTAGE component 2335.
28 Also, the database may be implemented as a mix of data structures, objects, and 29 relational structures. Databases may be consolidated and/or distributed in countless 1 variations through standard data processing techniques. Portions of databases, e.g., 2 tables, may be exported and/or imported and thus decentralized and/or integrated.
3 [00251] In one embodiment, the database component 2319 includes several tables 4 2319a-k, m-n, p-r.
[00252] A users table 2319a includes fields such as, but not limited to: a user ID, 6 user fname, user lname, user ID type, user auth code, user email, user address, 7 user date created, user pay method, user password, user phone, user interests, 8 user devices, user confirmed, user account locked, user enabled, user username, 9 and/or the like. The user table may support and/or track multiple user accounts on a ECO ADVANTAGE. A merchants table 231913 includes fields such as, but not limited to:
11 merchant ID, merchant name, merchant email, merchant date created, 12 merchant username, merchant password, merchant enabled, 13 merchant account locked, merchant confirmed, merchant phone, merchant contact, 14 merchant open time, merchant website, merchant region, merchant min consumpt, merchant max consumpt, merchant bank, 16 merchant bank agency, merchant bank acct, and/or the like. The merchant table 17 may support and/or track multiple merchant accounts on a ECO ADVANTAGE. An 18 Economic Promoter table 2319c includes fields such as, but not limited to:
ep ID, 19 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 21 Promoter accounts on a ECO ADVANTAGE. A Merchant Agents table 2319d includes 22 fields such as, but not limited to: ma ID, ma name, ma merchants, ma region, 23 ma categories, ma parameters, ma agg info, and/or the like. The Merchant Agent 24 table may support and/or track multiple Merchant Agent accounts on a ECO
ADVANTAGE. A partners table 2319e includes fields such as, but not limited to:
26 partner ID, partner name, partner email, partner date created, partner username, 27 partner password, partner enabled, partner account locked, partner confirmed, 28 partner phone, partner contact, partner open time, partner website, 29 partner region, partner min consumpt, partner max consumpt, partner bank, partner bank agency, partner bank acct, and/or the like. The partner table may 31 support and/or track multiple partner accounts on a ECO ADVANTAGE. An ecos table 1 2319f includes fields such as, but not limited to: eco ID, eco user ID, 2 eco merchant ID, eco expiration, eco donated, and/or the like. The ecos table may 3 support and/or track multiple ecos on an ECO ADVANTAGE. A PoS table 2319g 4 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 6 track multiple PoS devices on a ECO ADVANTAGE. A transactions table 2319h includes 7 fields such as, but not limited to: transaction ID, transaction date, 8 transaction amount, transaction user, transaction merchant, transaction ecos paid, 9 transaction ecos received, transaction payment method, transaction atmospherics, and/or the like. The transaction table may support and/or track multiple transactions ii on a ECO ADVANTAGE. A transaction analytics table 2319i includes fields such as, but 12 not limited to: ta ID, ta date, ta results merchants, ta results transactions, 13 ta results ecos, ta results credit, ta results acquirer, ta results users, 14 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 2319j includes 16 fields such as, but not limited to: account firstname, account lastname, account type, 17 account num, account balance list, billingaddress linei, billingaddress line2, 18 billing zipcode, billing state, shipping preferences, shippingaddress linei, 19 shippingaddress line2, shipping zipcode, shipping state, and/or the like.
The acquirer table may support and/or track multiple acquirer accounts on a ECO
21 ADVANTAGE. An issuers table 2319k includes fields such as, but not limited to:
22 issuer id, issuer name, issuer address, ip address, mac address, auth key, 23 port num, security settings list, and/or the like. The issuer table may support and/or 24 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, 26 bb expiration, bb type, and/or the like. The bonus blocks table may support and/or 27 track multiple bonus blocks on a ECO ADVANTAGE. A regions table 2319n includes 28 fields such as, but not limited to: region ID, region name, region geography, 29 region demographics, region demarcations, region merchants, region users, region partners, region epromoters, region mmanagers, region categories, and/or 31 the like. The regions table may support and/or track multiple regions on a ECO
32 ADVANTAGE. A categories table 2319p includes fields such as, but not limited to:
1 category ID, category interests, category merchants, category users, 2 category region, and/or the like. The categories table may support and/or track 3 multiple categories on a ECO ADVANTAGE. A schedules table 2319q includes fields 4 such as, but not limited to: schedule ID, schedule annual, schedule monthly, schedule weekly, schedule daily, schedule special schedules, schedule entity ID
6 and/or the like. The schedules table may support and/or track multiple eco schedules on 7 a ECO ADVANTAGE. A BI information table 2319r includes fields such as, but not 8 limited to: bi id, bi transactions, bi analytics,and/or the like. The BI
information table 9 may support and/or track BI information on a ECO ADVANTAGE.
[0 0 2 5 3] In one embodiment, the ECO ADVANTAGE database may interact with ii other database systems. For example, employing a distributed database system, queries 12 and data access by search ECO ADVANTAGE component may treat the combination of 13 the ECO ADVANTAGE database, an integrated data security layer database as a single 14 database entity.
[00254] In one embodiment, user programs may contain various user interface 16 primitives, which may serve to update the ECO ADVANTAGE. Also, various accounts 17 may require custom database tables depending upon the environments and the types of 18 clients the ECO ADVANTAGE may need to serve. It should be noted that any unique 19 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 21 controllers (i.e., individual database controllers for each of the above tables). Employing 22 standard data processing techniques, one may further distribute the databases over 23 several computer systemizations and/or storage devices. Similarly, configurations of the 24 decentralized database controllers may be varied by consolidating and/or distributing the various database components 2319a-k, m-n, p-r. The ECO ADVANTAGE may be 26 configured to keep track of various settings, inputs, and parameters via database 27 controllers.
28 [00255] The ECO ADVANTAGE database may communicate to and/or with other 29 components in a component collection, including itself, and/or facilities of the like.
Most frequently, the ECO ADVANTAGE database communicates with the ECO
1 ADVANTAGE component, other program components, and/or the like. The database 2 may contain, retain, and provide information regarding other nodes and data.
3 The ECO ADVANTAGEs 4 [0 0256] The ECO ADVANTAGE component 2335 is a stored program component that is executed by a CPU. In one embodiment, the ECO ADVANTAGE component 6 incorporates any and/or all combinations of the aspects of the ECO ADVANTAGE
that 7 was discussed in the previous figures. As such, the ECO ADVANTAGE affects accessing, 8 obtaining and the provision of information, services, transactions, and/or the like across 9 various communications networks. The features and embodiments of the ECO
ADVANTAGE discussed herein increase network efficiency by reducing data transfer ii requirements the use of more efficient data structures and mechanisms for their transfer 12 and storage. As a consequence, more data may be transferred in less time, and latencies 13 with regard to transactions, are also reduced. In many cases, such reduction in storage, 14 transfer time, bandwidth requirements, latencies, etc., will reduce the capacity and structural infrastructure requirements to support the ECO ADVANTAGE's features and 16 facilities, and in many cases reduce the costs, energy consumption/requirements, and 17 extend the life of ECO ADVANTAGE's underlying infrastructure; this has the added 18 benefit of making the ECO ADVANTAGE more reliable. Similarly, many of the features 19 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
21 ADVANTAGE; such ease of use also helps to increase the reliability of the ECO
22 ADVANTAGE. In addition, the feature sets include heightened security as noted via the 23 Cryptographic components 2320, 2326, 2328 and throughout, making access to the 24 features and data more reliable and secure.
[00257] The ECO ADVANTAGE transforms transaction and user, merchant, and 26 payment data inputs via ECO ADVANTAGE Transaction Processing Component 2341, 27 User Enrollment Component 2342, Merchant Enrollment Component 2343, Eco 28 Schedule Calculation Component 2344, Merchant Information Aggregation and 29 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 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 server extensions, web development environments and libraries (e.g., Microsoft's ActiveX;
ii Adobe AIR, FLEX & FLASH; AJAX; (D)HTML; Dojo, Java; JavaScript; jQuery(UI);
12 MooTools; Prototype; script.aculo.us; Simple Object Access Protocol (SOAP);
13 SWFObject; Yahoo! User Interface; and/or the like), WebObjects, and/or the like. In 14 one embodiment, the ECO ADVANTAGE server employs a cryptographic server to encrypt and decrypt communications. The ECO ADVANTAGE component may 16 communicate to and/or with other components in a component collection, including 17 itself, and/or facilities of the like. Most frequently, the ECO ADVANTAGE
component 18 communicates with the ECO ADVANTAGE database, operating systems, other program 19 components, and/or the like. The ECO ADVANTAGE may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data 21 communications, requests, and/or responses.
22 Distributed ECO ADVANTAGEs 23 [o 0259] The structure and/or operation of any of the ECO ADVANTAGE node 24 controller components may be combined, consolidated, and/or distributed in any number of ways to facilitate development and/or deployment. Similarly, the component 26 collection may be combined in any number of ways to facilitate deployment and/or 27 development. To accomplish this, one may integrate the components into a common 28 code base or in a facility that can dynamically load the components on demand in an 29 integrated fashion.
1 [00260] The component collection may be consolidated and/or distributed in 2 countless variations through standard data processing and/or development techniques.
3 Multiple instances of any one of the program components in the program component 4 collection may be instantiated on a single node, and/or across numerous nodes to improve performance through load-balancing and/or data-processing techniques.
6 Furthermore, single instances may also be distributed across multiple controllers 7 and/or storage devices; e.g., databases. All program component instances and 8 controllers working in concert may do so through standard data processing 9 communication techniques.
[ o 0261] The configuration of the ECO ADVANTAGE controller will depend on the ii context of system deployment. Factors such as, but not limited to, the budget, capacity, 12 location, and/or use of the underlying hardware resources may affect deployment 13 requirements and configuration. Regardless of if the configuration results in more 14 consolidated and/or integrated program components, results in a more distributed series of program components, and/or results in some combination between a 16 consolidated and distributed configuration, data may be communicated, obtained, 17 and/or provided. Instances of components consolidated into a common code base from 18 the program component collection may communicate, obtain, and/or provide data. This 19 may be accomplished through intra-application data processing communication techniques such as, but not limited to: data referencing (e.g., pointers), internal 21 messaging, object instance variable communication, shared memory space, variable 22 passing, and/or the like.
23 [o 0 2 6 2 ] If component collection components are discrete, separate, and/or 24 external to one another, then communicating, obtaining, and/or providing data with and/or to other component components may be accomplished through inter-application 26 data processing communication techniques such as, but not limited to:
Application 27 Program Interfaces (API) information passage; (distributed) Component Object Model 28 ((D)COM), (Distributed) Object Linking and Embedding ((D)OLE), and/or the like), 29 Common Object Request Broker Architecture (CORBA), Jini local and remote application program interfaces, JavaScript Object Notation (JSON), Remote Method 31 Invocation (RMI), SOAP, process pipes, shared files, and/or the like.
Messages sent 1 between discrete component components for inter-application communication or within 2 memory spaces of a singular component for intra-application communication may be 3 facilitated through the creation and parsing of a grammar. A grammar may be 4 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 6 of communication messages within and between components.
7 [o 0263] For example, a grammar may be arranged to recognize the tokens of an 8 HTTP post command, e.g.:
9 w3c -post http://... Valuel 11 [oo 264] where Valuei is discerned as being a parameter because "http://"
is part of 12 the grammar syntax, and what follows is considered part of the post value.
Similarly, 13 with such a grammar, a variable "Valuei" may be inserted into an "http://"
post 14 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 16 syntax description text file as processed by lex, yacc, etc.). Also, once the parsing 17 mechanism is generated and/or instantiated, it itself may process and/or parse 18 structured data such as, but not limited to: character (e.g., tab) delineated text, HTML, 19 structured text streams, XML, and/or the like structured data. In another embodiment, inter-application data processing protocols themselves may have integrated and/or 21 readily available parsers (e.g., JSON, SOAP, and/or like parsers) that may be employed 22 to parse (e.g., communications) data. Further, the parsing grammar may be used 23 beyond message parsing, but may also be used to parse: databases, data collections, data 24 stores, structured data, and/or the like. Again, the desired configuration will depend upon the context, environment, and requirements of system deployment.
26 [o 0265] For example, in some implementations, the ECO ADVANTAGE controller 27 may be executing a PHP script implementing a Secure Sockets Layer ("SSL") socket 28 server via the information server, which listens to incoming communications on a server 29 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 31 from the client device, parse the received JSON-encoded text data to extract information 1 from the JSON-encoded text data into PHP script variables, and store the data (e.g., 2 client identifying information, etc.) and/or extracted information in a relational 3 database accessible using the Structured Query Language ("SQL"). An exemplary 4 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 6 variables, and store the data to a database, is provided below:
7 <?PHP
8 header('Content-Type: text/plain');
// set ip address and port to listen to for incoming data 11 $address = '192.168Ø100';
12 $port = 255;
14 // create a server-side SSL socket, listen for/accept incoming communication m $sock = socket_create(AF_INET, SOCK_STREAM, 0);
m socket_bind(Ssock, $address, $port) or die('Could not bind to address');
17 socket_listen(Ssock);
m $client = socket_accept(Ssock);
// read input data from client device in 1024 byte blocks until end of message 21 do{
22 $input =
23 $input = socket_read(Sclient, 1024);
24 $data .= $input;
} while($input 27 // parse data to extract variables 28 $obj = json_decode(Sdata, true);
// store input data in a database 31 mysql_connect("201.408.185.132",SDBserver,Spassword); // access database server 32 mysql_select("CLIENT_DB.SQL"); // select database to append 33 mysql_query("INSERT INTO UserTable (transmission) 34 VALUES ($data)"); // add data to UserTable table in a CLIENT database mysql_close("CLIENT_DB.SQL"); // close connection to database 1 ?>
3 [00266] Also, the following resources may be used to provide example 4 embodiments regarding SOAP parser implementation:
http://www.xav.com/perl/site/lib/SOAP/Parser.html http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm 7 .IBMDI.doc/referenceguide295.htm 9 [oo 2 67] and other parser implementations:
http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=/com.ibm .IBMDI.doc/referenceguide259.htm 13 [oo 2 68] all of which are hereby expressly incorporated by reference.
14 [0 0 2 6 9 ] In order to address various issues and advance the art, the entirety of this application for ECO ADVANTAGE MEDIATION APPARATUSES, METHODS AND
16 SYSTEMS (including the Cover Page, Title, Headings, Field, Background, Summary, 17 Brief Description of the Drawings, Detailed Description, Claims, Abstract, Figures, 18 Appendices, and otherwise) shows, by way of illustration, various embodiments in 19 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 21 and/or exclusive. They are presented only to assist in understanding and teach the 22 claimed principles. It should be understood that they are not representative of all 23 claimed innovations. As such, certain aspects of the disclosure have not been discussed 24 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 26 for a portion is not to be considered a disclaimer of those alternate embodiments. It will 27 be appreciated that many of those undescribed embodiments incorporate the same 28 principles of the innovations and others are equivalent. Thus, it is to be understood that 29 other embodiments may be utilized and functional, logical, operational, organizational, structural and/or topological modifications may be made without departing from the 31 scope and/or spirit of the disclosure. As such, all examples and/or embodiments are 32 deemed to be non-limiting throughout this disclosure. Also, no inference should be 1 drawn regarding those embodiments discussed herein relative to those not discussed 2 herein other than it is as such for purposes of reducing space and repetition. For 3 instance, it is to be understood that the logical and/or topological structure of any 4 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 6 limited to a fixed operating order and/or arrangement, but rather, any disclosed order is 7 exemplary and all equivalents, regardless of order, are contemplated by the disclosure.
8 Furthermore, it is to be understood that such features are not limited to serial execution, 9 but rather, any number of threads, processes, services, servers, and/or the like that may execute asynchronously, concurrently, in parallel, simultaneously, synchronously, ii and/or the like are contemplated by the disclosure. As such, some of these features may 12 be mutually contradictory, in that they cannot be simultaneously present in a single 13 embodiment. Similarly, some features are applicable to one aspect of the innovations, 14 and inapplicable to others. In addition, the disclosure includes other innovations not presently claimed. Applicant reserves all rights in those presently unclaimed 16 innovations including the right to claim such innovations, file additional applications, 17 continuations, continuations in part, divisions, and/or the like thereof.
As such, it 18 should be understood that advantages, embodiments, examples, functional, features, 19 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 21 or limitations on equivalents to the claims. It is to be understood that, depending on the 22 particular needs and/or characteristics of a ECO ADVANTAGE individual and/or 23 enterprise user, database configuration and/or relational model, data type, data 24 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 26 flexibility and customization. For example, aspects of the ECO ADVANTAGE
may be 27 adapted for health care, travel services, Accessories, Advertising and Marketing, Animal 28 Clinic and Hospital, Arts and Crafts, Auto Body Shop, Auto Dealer, Auto Electric Shop, 29 Auto Parts Store, Bakery, Beauty Clinic, Book Wholesale, Bookstore, Building Supplies, Camera and Photo, Car-Wash, Ceilings/ Partition, Cell Phone Provider, Children's Store, 31 Chocolate Shop, Clothing Repair, Coffee Shop, Computer and Accessories, Convenience 32 Store, Cosmetics, Costume Shop, Courier Service, Dairy Products, Delicatessen, Diner, 1 Do-It-Yourself Store, Durable Medical Equipment, DVD and Movies, Electrical Parts, 2 Electronic and Video Game, Eletro/electronic Repair and Maintenance, Eyeglasses and 3 Sunglasses, Fabric and Upholstery Store, Fast Graphic Service, Furniture Store, Gas 4 Station, Gift Store, Gourmet and Specially Food Store, Grocery Store, Gym, Hardware Store, Heating and Air Conditioning, Home and Gardening, Home and Kitchen Goods, 6 Home Appliance, Home Improvement, Home Phone Provider, Hotels, Ice Cream 7 Parlour, Janitorial / Cleaning Supplies, Jewelry, Kids Party Place, Kids Tutoring, 8 Language School or Learning Center, Laundry and Dry Cleaning, Leisure and Tourism, 9 Light Fixture, Lingerie and Intimate Apparel, Locksmith, Luggage and Suitcase Store, Men's Fashion, Motels, Motorcycle Dealer, Movie Theater, Moving Service, Musical ii Instrument Shop, Natural Food Store, Nautical Store, Nightclub / Disco, Office 12 Supplies, Paint Store, Party Supply Store, Perfumery, Personal Development Course, 13 Pet Shop, Pharmacy, Plastic Surgery, Refrigeration Shop, Restaurant (all kinds), 14 Rotisserie, Rug and Curtain Shop, School, Shoe Repair, Shoe Store, SPA, Specialty Pharmacy, Sporting Goods, Sport Tickets, Supermarket, Surgical Equipment, Swimwear 16 Fashion, Technical Course, Theaters, Tickets (ShowsConcerts), Toy Store, Visual 17 Communication, Winery, Women's Fashion, and/or the like. While various 18 embodiments and discussions of the ECO ADVANTAGE have included commerce 19 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 21 variety of other applications and/or implementations.
22 [0 0 2 7o ] In some implementations, some embodiments may include:
23 [0 0 2 71] 1. A processor-implemented method for mutual benefits, comprising:
24 receiving a request for a user's transaction value modifier (TVM) balance and a merchant's current TVM schedule from a merchant;
26 receiving a TVM transaction confirmation indicating a transaction has been successfully 27 processed, and TVM transaction data;
28 debiting from a user's account an amount of TVMs received from another merchant in a 29 previous transaction for use in the transaction;
1 crediting to the user's account an amount of TVMs based on the TVM
transaction data;
2 and 3 generating via a processor a TVM transaction record and storing the TVM
transaction 4 data in the TVM transaction record.
[00272] 2. The method of embodiment 1, further comprising:
6 updating via the processor the merchant's current TVM schedule in the database using 7 the TVM record.
8 [00273] 3. The method of embodiment 1, wherein a TVM is an eco, a value 9 identifier, or a subsequent value transaction modifier.
[00274] 4. The method of embodiment 1, wherein the user's TVM balance is ii updated after receiving the TVM transaction confirmation.
12 [00275] 5. The method of embodiment 1, wherein the user's TVM balance is 13 updated before receiving the TVM transaction confirmation.
14 [0 0276] 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 16 transaction amount with a payment device.
17 [00277] 7. The method of embodiment 6, wherein the payment device is one of a 18 credit card, debit card, or prepaid card.
19 [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 21 transaction amount with cash.
22 [0 0279] 9. The method of embodiment 1, wherein the TVM transaction comprises 23 paying at least a portion of the transaction amount in TVMs, at least a portion of the 24 transaction amount with cash, and at least a portion of the transaction amount with a payment device.
26 [00280] 10. The method of embodiment 9, wherein the payment device is one of a 27 credit card, debit card, or prepaid card.
1 [o o 2 8 1] 11. The method of embodiment 1, wherein the credited transaction value 2 modifiers can only be used in subsequent transactions.
3 [0 0 2 82] 12. The method of embodiment ii, wherein the credited transaction value 4 modifiers is marked as originating from the merchant; and wherein the transaction value modifiers cannot be used in subsequent transactions at 6 the merchant from which they originated.
7 [00 2 83] 13. The method of embodiment 1, further comprising:
8 sending the user's TVM balance and the merchant's current TVM schedule to the 9 merchant.
[ o 0 2 84] 14. A processor-implemented method for mutual benefits, comprising:
ii sending to the user the user's TVM balance and an indication that at least some TVMs in 12 the user's TVMs balance will expire;
13 receiving a request to donate expiring TVMs to a designated friend;
14 allocating via a processor the user's expiring TVMs to be donated to the designated friend;
16 sending a TVM donation message to the designated friend;
17 receiving from the designated friend an enrollment request;
18 generating via a processor a new user account for the designated friend;
19 transferring the allocated expiring TVMs to the designated friend's new user account;
and 21 sending a confirmation of the transfer to the user and to the designated friend.
22 [o o 2 85] 15. The method of embodiment 14, further comprising:
23 monitoring the spending of the user's donated TVMs by the designated friend; and 24 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.
26 [o o 2 86] 16. The method of embodiment 14, further comprising:
1 receiving a request from a user for user transaction value modifier (TVM) balance 2 information;
3 [0 o 2 8 7] 17. The method of embodiment 15, wherein the mutual benefit enrollment 4 request further comprises an amount of TVM gifted by an economic promoter.
[00288] 18. The method of embodiment 17, wherein the economic promoter 6 obtains a percentage of the amount of TVMs donated to the friend.
7 [00289] 19. The method of embodiment 18, wherein a merchant manager gifts 8 TVMs to the economic promoter and obtains a percentage of the amount of TVMs gifted 9 to the friend.
[ o 02 9 0 ] 20. A processor-implemented method for mutual benefits, comprising:
11 receiving an indication of preliminary interest in a mutual benefit program;
12 providing to the merchant a mutual benefit enrollment request form;
13 receiving a mutual benefit enrollment request from a merchant for the mutual benefit 14 program;
sending a mutual benefit enrollment form to the merchant;
16 receiving from the merchant a completed mutual benefit enrollment form;
17 sending a request to a merchant agent requesting background material on the merchant;
18 receiving background material on the merchant from the merchant agent;
19 analyzing the background material from the merchant agent;enrolling the merchant in the mutual benefit program if the background material meets predetermined criteria;
21 generating a merchant account for the merchant; and 22 sending the merchant a confirmation of enrollment in the mutual benefits program.
23 [ 0 0291] 21. The method of embodiment 20, further comprising:
24 receiving from a merchant a survey of current point-of-sales (PoS) infrastructure and settings configurations;
26 determining a new PoS configuration for the merchant based on mutual benefit 27 program specifications; and 1 sending the new PoS configuration and the training materials to the merchant for 2 implementation.
3 [ 0 0 2 9 2 ] 22. The method of embodiment 21, further comprising:
4 generating training materials for the new PoS configuration.
[o 0 2 9 3 ] 23. A processor-implemented method for mutual benefits, comprising:
6 receiving a request for a user's value point balance and a merchant's current value point 7 schedule from a merchant;
8 receiving a value point transaction confirmation indicating a transaction has been 9 successfully processed and value point transaction data;
debiting from a user's account an amount of value points received from another ii merchant in a previous transaction for use in the transaction;
12 crediting to the user's account an amount of value points based on the value point 13 transaction data; and 14 generating via a processor a value point transaction record and storing the value point transaction data in the value point transaction record.
16 [ 0 0 2 9 4 ] 24. The method of embodiment 23, further comprising:
17 updating via the processor the merchant's current value point schedule in the database 18 using the value point record.
19 [o 0 2 9 5 ] 25. A processor-implemented method for mutual benefits, comprising:
receiving a product bulk amount from a partner;
21 receiving a request for a merchant's transaction value modifier (TVM) balance and a 22 partner's current TVM schedule from a partner;
23 sending the merchant's TVM balance and the partner's current TVM schedule to the 24 partner;
receiving a TVM transaction confirmation indicating a transaction involving purchasing 26 at least one product bulk amount has been successfully processed and TVM
transaction 27 data;
1 debiting from the merchant's account an amount of TVMs used in the transaction;
2 crediting to the merchant's account an amount of TVM based on the TVM
transaction 3 data;
4 generating via a processor a TVM transaction record and storing the TVM
transaction data in the TVM transaction record; and 6 updating via the processor the merchant's current TVM schedule in the database using 7 the TVM transaction record.
8 [ o 0 2 9 6 ] 26. A processor-implemented method for mutual benefits, comprising:
9 receiving aggregated entity data in a mutual benefits program within a defined geo-demographical region;
ii performing performance analytics on the entity data;
12 determining demarcation indicia to divide a region if the region is overpopulated;
13 splitting the region based on the geo-demographical demarcation indicia into sub-14 regions;
receiving updated demographic and industry data on each sub-region; and 16 generating new merchant categories for each sub-region based on the updated 17 demographic and industry data.
18 [ o o 2 9 7] 27. The method of embodiment 26, wherein the entity is at least one of a 19 merchant or demographic data.
[o 0 2 9 8 ] 28. A processor-implemented method for mutual benefits, comprising:
21 receiving aggregated entity data in a mutual benefits program within a defined geo-22 demographical region;
23 performing performance analytics on the entity data;
24 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;
26 sending a mutual benefit enrollment form to a merchant not enrolled in the mutual 27 benefits program;
1 receiving from the merchant not enrolled in the mutual benefits program a completed 2 mutual benefit enrollment form;
3 enrolling the merchant in the mutual benefits program; and 4 updating the region record in a database to include the enrolled merchant.
[00 2 9 9 ] 29. The method of embodiment 28, wherein the entity is at least one of a 6 merchant or demographic data.
7 [00300] 30. The method of embodiment 28, wherein the enrollment criteria may 8 include the category that the at least one merchant in the region which is over-capacity.
9 [00301] 31. A system for mutual benefits, comprising:
means for receiving a request for a user's transaction value modifier (TVM) balance and ii a merchant's current TVM schedule from a merchant;
12 means for receiving a TVM transaction confirmation indicating a transaction has been 13 successfully processed, and TVM transaction data;
14 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;
16 means for crediting to the user's account an amount of TVMs based on the TVM
17 transaction data; and 18 means for generating via a processor a TVM transaction record and storing the TVM
19 transaction data in the TVM transaction record.
[0030 2 ] 32. The system of embodiment 31, further comprising:
21 means for updating via the processor the merchant's current TVM schedule in the 22 database using the TVM record.
23 [00303] 33. The system of embodiment 31, wherein a TVM is an eco, a value 24 identifier, or a subsequent value transaction modifier.
[00304] 34. The system of embodiment 31, wherein the user's TVM balance is 26 updated after receiving the TVM transaction confirmation.
1 [00305] 35. The system of embodiment 31, wherein the user's TVM balance is 2 updated before receiving the TVM transaction confirmation.
3 [00306] 36. The system of embodiment 31, wherein the TVM transaction 4 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.
6 [o 0307] 37. The system of embodiment 36, wherein the payment device is one of a 7 credit card, debit card, or prepaid card.
8 [00308] 38. The system of embodiment 31, wherein the TVM transaction 9 comprises paying at least a portion of the transaction amount in TVMs and at least a portion of the transaction amount with cash.
11 [00309] 39. The system of embodiment 31, wherein the TVM transaction 12 comprises paying at least a portion of the transaction amount in TVMs, at least a portion 13 of the transaction amount with cash, and at least a portion of the transaction amount 14 with a payment device.
[o 0310] 40. The system of embodiment 39, wherein the payment device is one of a 16 credit card, debit card, or prepaid card.
17 [o0311] 41. The system of embodiment 31, wherein the credited transaction value 18 modifiers can only be used in subsequent transactions.
19 [o 0312] 42. The system of embodiment 41, wherein the credited transaction value modifiers is marked as originating from the merchant; and 21 wherein the transaction value modifiers cannot be used in subsequent transactions at 22 the merchant from which they originated.
23 [00313] 43. The system of embodiment 31, further comprising:
24 means for sending the user's TVM balance and the merchant's current TVM
schedule to the merchant.
26 [00314] 44. A system for mutual benefits, comprising:
27 means for sending to the user the user's TVM balance and an indication that at least 28 some TVMs in the user's TVMs balance will expire;
1 means for receiving a request to donate expiring TVMs to a designated friend;
2 means for allocating via a processor the user's expiring TVMs to be donated to the 3 designated friend;
4 means for sending a TVM donation message to the designated friend;
means for receiving from the designated friend an enrollment request;
6 means for generating via a processor a new user account for the designated friend;
7 means for transferring the allocated expiring TVMs to the designated friend's new user 8 account; and 9 means for sending a confirmation of the transfer to the user and to the designated friend.
11 [ o o 3 15 ] 45. The system of embodiment 44, further comprising:
12 means for monitoring the spending of the user's donated TVMs by the designated 13 friend; and 14 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.
16 [00316] 46. The system of embodiment 44, further comprising:
17 means for receiving a request from a user for user transaction value modifier (TVM) 18 balance information;
19 [o 0317] 47. The system of embodiment 45, wherein the mutual benefit enrollment request further comprises an amount of TVM gifted by an economic promoter.
21 [00318] 48. The system of embodiment 47, wherein the economic promoter 22 obtains a percentage of the amount of TVMs donated to the friend.
23 [00319] 49. The system of embodiment 48, wherein a merchant manager gifts 24 TVMs to the economic promoter and obtains a percentage of the amount of TVMs gifted to the friend.
26 [o 03 2 0 ] 50. A system for mutual benefits, comprising:
27 means for receiving an indication of preliminary interest in a mutual benefit program;
1 means for providing to the merchant a mutual benefit enrollment request form;
2 means for receiving a mutual benefit enrollment request from a merchant for the 3 mutual benefit program;
4 means for sending a mutual benefit enrollment form to the merchant;
means for receiving from the merchant a completed mutual benefit enrollment form;
6 means for sending a request to a merchant agent requesting background material on the 7 merchant;
8 means for receiving background material on the merchant from the merchant agent;
9 means for analyzing the background material from the merchant agent;
means for enrolling the merchant in the mutual benefit program if the background ii material meets predetermined criteria;
12 means for generating a merchant account for the merchant; and 13 means for sending the merchant a confirmation of enrollment in the mutual benefits 14 program.
[o o 3 2 1] 51. The system of embodiment 50, further comprising:
16 means for receiving from a merchant a survey of current point-of-sales (PoS) 17 infrastructure and settings configurations;
18 means for determining a new PoS configuration for the user based on mutual benefit 19 program specifications; and means for sending the new PoS configuration and the training materials to the merchant 21 for implementation.
22 [ 0 o 3 2 2 ] 52. The system of embodiment 51, further comprising:
23 means for generating training materials for the new PoS configuration.
24 [o 0 3 2 3 ] 53. A system for mutual benefits, comprising:
means for receiving a request for a user's value point balance and a merchant's current 26 value point schedule from a merchant;
1 means for receiving a value point transaction confirmation indicating a transaction has 2 been successfully processed and value point transaction data;
3 means for debiting from a user's account an amount of value points received from 4 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 6 point transaction data; and 7 means for generating via a processor a value point transaction record and storing the 8 value point transaction data in the value point transaction record.
9 [00324] 54. The system of embodiment 53, further comprising:
means for updating via the processor the merchant's current value point schedule in the ii database using the value point record.
12 [o o 3 2 5 ] 55. A system for mutual benefits, comprising:
13 means for receiving a product bulk amount from a partner;
14 means for receiving a request for a merchant's transaction value modifier (TVM) balance and a partner's current TVM schedule from a partner;
16 means for sending the merchant's TVM balance and the partner's current TVM
schedule 17 to the partner;
18 means for receiving a TVM transaction confirmation indicating a transaction involving 19 purchasing at least one product bulk amount has been successfully processed and TVM
transaction data;
21 means for debiting from the merchant's account an amount of TVMs used in the 22 transaction;
23 means for crediting to the merchant's account an amount of TVM based on the TVM
24 transaction data;
means for generating via a processor a TVM transaction record and storing the TVM
26 transaction data in the TVM transaction record; and 1 means for updating via the processor the merchant's current TVM schedule in the 2 database using the TVM transaction record.
3 [o o 3 2 6 ] 56. A system for mutual benefits, comprising:
4 means for receiving aggregated entity data in a mutual benefits program within a defined geo-demographical region;
6 means for performing performance analytics on the entity data;
7 means for determining demarcation indicia to divide a region if the region is 8 overpopulated;
9 means for splitting the region based on the geo-demographical demarcation indicia into io sub-regions;
ii means for receiving updated demographic and industry data on each sub-region; and 12 means for generating new merchant categories for each sub-region based on the 13 updated demographic and industry data.
14 [00327] 57. The system of embodiment 56, wherein the entity is at least one of a merchant or demographic data.
16 [0 o 3 2 8 ] 58. A system for mutual benefits, comprising:
17 means for receiving aggregated entity data in a mutual benefits program within a 18 defined geo-demographical region;
19 means for performing performance analytics on the entity data;
means for determining enrollment criteria for enrolling at least one merchant in the 21 mutual benefits program if at least one merchant in the region is over-capacity;
22 means for sending a mutual benefit enrollment form to a merchant not enrolled in the 23 mutual benefits program;
24 means for receiving from the merchant not enrolled in the mutual benefits program a completed mutual benefit enrollment form;
26 means for enrolling the merchant in the mutual benefits program; and 27 means for updating the region record in a database to include the enrolled merchant.
1 [00329] 59. The system of embodiment 58, wherein the entity is at least one of a 2 merchant or demographic data.
3 [00330] 60. The system of embodiment 58, wherein the enrollment criteria may 4 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 6 processor-executable instructions, said instructions executable by a processor to:
7 receive a request for a user's transaction value modifier (TVM) balance and a merchant's 8 current TVM schedule from a merchant;
9 receive a TVM transaction confirmation indicating a transaction has been successfully processed, and TVM transaction data;
ii debit from a user's account an amount of TVMs received from another merchant in a 12 previous transaction for use in the transaction;
13 credit to the user's account an amount of TVMs based on the TVM transaction data; and 14 generate via a processor a TVM transaction record and storing the TVM
transaction data in the TVM transaction record.
16 [0o332] 62. The medium of embodiment 61, further comprising instructions to:
17 update via the processor the merchant's current TVM schedule in the database using the 18 TVM record.
19 [00333] 63. The medium of embodiment 61, wherein a TVM is an eco, a value identifier, or a subsequent value transaction modifier.
21 [00334] 64. The medium of embodiment 61, wherein the user's TVM balance is 22 updated after receiving the TVM transaction confirmation.
23 [00335] 65. The medium of embodiment 61, wherein the user's TVM balance is 24 updated before receiving the TVM transaction confirmation.
[00336] 66. The medium of embodiment 61, wherein the TVM transaction 26 comprises paying at least a portion of the transaction amount in TVMs and at least a 27 portion of the transaction amount with a payment device.
1 [0 0 3 3 7] 67. The medium of embodiment 66, wherein the payment device is one of 2 a credit card, debit card, or prepaid card.
3 [00338] 68. The medium of embodiment 61, wherein the TVM transaction 4 comprises paying at least a portion of the transaction amount in TVMs and at least a portion of the transaction amount with cash.
6 [00339] 69. The medium of embodiment 61, wherein the TVM transaction 7 comprises paying at least a portion of the transaction amount in TVMs, at least a portion 8 of the transaction amount with cash, and at least a portion of the transaction amount 9 with a payment device.
[oo 34 o ] 70. The medium of embodiment 69, wherein the payment device is one of ii a credit card, debit card, or prepaid card.
12 [0 0341] 71. The medium of embodiment 61, wherein the credited transaction value 13 modifiers can only be used in subsequent transactions.
14 [0 o 34 2 ] 72. The medium of embodiment 71, wherein the credited transaction value modifiers is marked as originating from the merchant; and 16 wherein the transaction value modifiers cannot be used in subsequent transactions at 17 the merchant from which they originated.
18 [oo 343] 73. The medium of embodiment 61, further comprising instructions to:
19 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 21 processor-executable instructions, said instructions executable by a processor to:
22 send to the user the user's TVM balance and an indication that at least some TVMs in 23 the user's TVMs balance will expire;
24 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;
26 send a TVM donation message to the designated friend;
27 receive from the designated friend an enrollment request;
1 generate via a processor a new user account for the designated friend;
2 transfer the allocated expiring TVMs to the designated friend's new user account; and 3 send a confirmation of the transfer to the user and to the designated friend.
4 [0o345] 75. The medium of embodiment 74, further comprising instructions to:
monitor the spending of the user's donated TVMs by the designated friend; and 6 allocate via a processor an invite bonus block to the user's account when a 7 predetermined number of the user's donated TVMs have been spent.
8 [o 0346] 76. The medium of embodiment 74, further comprising instructions to:
9 receive a request from a user for user transaction value modifier (TVM) balance information.
ii [o 0347] 77. The medium of embodiment 75, wherein the mutual benefit enrollment 12 request further comprises an amount of TVM gifted by an economic promoter.
13 [00348] 78. The medium of embodiment 77, wherein the economic promoter 14 obtains a percentage of the amount of TVMs donated to the friend.
[00349] 79. The medium of embodiment 78, wherein a merchant manager gifts 16 TVMs to the economic promoter and obtains a percentage of the amount of TVMs gifted 17 to the friend.
18 [ o 0350] 80. A mutual benefits non-transitory computer-readable medium storing 19 processor-executable instructions, said instructions executable by a processor to:
receive an indication of preliminary interest in a mutual benefit program;
21 provide to the merchant a mutual benefit enrollment request form;
22 receive a mutual benefit enrollment request from a merchant for the mutual benefit 23 program;
24 send a mutual benefit enrollment form to the merchant;
receive from the merchant a completed mutual benefit enrollment form;
26 send a request to a merchant agent requesting background material on the merchant;
I 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;
generate a merchant account for the merchant; and 6 send the merchant a confirmation of enrollment in the mutual benefits program.
7 [ oo 3 5 1] 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;
determine a new PoS configuration for the user based on mutual benefit program ii specifications; and 12 send the new PoS configuration and the training materials to the merchant for 13 implementation.
14 [o 0352] 82. The medium of embodiment 81, further comprising instructions to:
generate training materials for the new PoS configuration.
16 [o 0353] 83. A non-transitory computer-readable medium storing processor-17 executable instructions, said instructions executable by a processor to:
18 receive a request for a user's value point balance and a merchant's current value point 19 schedule from a merchant;
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 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.
1 [0 0354] 84. The medium of embodiment 83, further comprising instructions to:
2 update via the processor the merchant's current value point schedule in the database 3 using the value point record.
4 [0 co 3 5 5] 85. A mutual benefits non-transitory computer-readable medium storing processor-executable instructions, said instructions executable by a processor to:
6 receive a product bulk amount from a partner;
7 receive a request for a merchant's transaction value modifier (TVM) balance and a 8 partner's current TVM schedule from a partner;
9 send the merchant's TVM balance and the partner's current TVM schedule to the partner;
ii receive a TVM transaction confirmation indicating a transaction involving purchasing at 12 least one product bulk amount has been successfully processed and TVM
transaction 13 data;
14 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;
16 generate via a processor a TVM transaction record and storing the TVM
transaction data 17 in the TVM transaction record; and 18 update via the processor the merchant's current TVM schedule in the database using the 19 TVM transaction record.
[00 3 5 6 ] 86. A mutual benefits non-transitory computer-readable medium storing 21 processor-executable instructions, said instructions executable by a processor to:
22 receive aggregated entity data in a mutual benefits program within a defined geo-23 demographical region;
24 perform performance analytics on the entity data;
determine demarcation indicia to divide a region if the region is overpopulated;
26 split the region based on the geo-demographical demarcation indicia into sub-regions;
27 receive updated demographic and industry data on each sub-region; and 1 generate new merchant categories for each sub-region based on the updated 2 demographic and industry data.
3 [00 3 5 7] 87. The medium of embodiment 86, wherein the entity is at least one of a 4 merchant or demographic data.
[00 3 5 8 ] 88. A mutual benefits non-transitory computer-readable medium storing 6 processor-executable instructions, said instructions executable by a processor to:
7 receive aggregated entity data in a mutual benefits program within a defined geo-8 demographical region;
9 perform performance analytics on the entity data;
determine enrollment criteria for enrolling at least one merchant in the mutual benefits 11 program if at least one merchant in the region is over-capacity;
12 send a mutual benefit enrollment form to a merchant not enrolled in the mutual benefits 13 program;
14 receive from the merchant not enrolled in the mutual benefits program a completed mutual benefit enrollment form;
16 enroll the merchant in the mutual benefits program; and 17 update the region record in a database to include the enrolled merchant.
18 [ o o 3 5 9 ] 89. The medium of embodiment 88, wherein the entity is at least one of a 19 merchant or demographic data.
[0036 o ] 90. The medium of embodiment 88, wherein the enrollment criteria may 21 include the category that the at least one merchant in the region which is over-capacity.
22 [0 o 3 61] 91. An apparatus for mutual benefits, comprising:
23 a processor; and 24 a memory disposed in communication with the processor and storing processor-executable instructions to:
26 receive a request for a user's transaction value modifier (TVM) balance 27 and a merchant's current TVM schedule from a merchant;
I receive a TVM transaction confirmation indicating a transaction has been 2 successfully processed, and TVM transaction data;
3 debit from a user's account an amount of TVMs received from another 4 merchant in a previous transaction for use in the transaction;
credit to the user's account an amount of TVMs based on the TVM
6 transaction data; and 7 generate via a processor a TVM transaction record and storing the TVM
8 transaction data in the TVM transaction record.
9 [0o362] 92. The apparatus of embodiment 91, further comprising instructions to:
io update via the processor the merchant's current TVM schedule in the ii database using the TVM record.
12 [00363] 93. The apparatus of embodiment 91, wherein a TVM is an eco, a value 13 identifier, or a subsequent value transaction modifier.
14 [00364] 94. The apparatus of embodiment 91, wherein the user's TVM balance is updated after receiving the TVM transaction confirmation.
16 [00365] 95. The apparatus of embodiment 91, wherein the user's TVM balance is 17 updated before receiving the TVM transaction confirmation.
18 [ co co 3 6 6 ] 96. The apparatus of embodiment 91, wherein the TVM
transaction 19 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.
21 [00367] 97. The apparatus of embodiment 96, wherein the payment device is one 22 of a credit card, debit card, or prepaid card.
23 [00368] 98. The apparatus of embodiment 91, wherein the TVM transaction 24 comprises paying at least a portion of the transaction amount in TVMs and at least a portion of the transaction amount with cash.
26 [00369] 99. The apparatus of embodiment 91, wherein the TVM transaction 27 comprises paying at least a portion of the transaction amount in TVMs, at least a portion 1 of the transaction amount with cash, and at least a portion of the transaction amount 2 with a payment device.
3 [00370] loo. The apparatus of embodiment 99, wherein the payment device is one 4 of a credit card, debit card, or prepaid card.
[00371] 101. The apparatus of embodiment 91, wherein the credited transaction 6 value modifiers can only be used in subsequent transactions.
7 [00372] 102. The apparatus of embodiment 101, wherein the credited transaction 8 value modifiers is marked as originating from the merchant; and 9 wherein the transaction value modifiers cannot be used in subsequent transactions at the merchant from which they originated.
ii [ o o 3 73 ] 103. The apparatus of embodiment 91, further comprising instructions to:
12 send the user's TVM balance and the merchant's current TVM
schedule to 13 the merchant.
14 [0 o 3 74 ] 104. An apparatus for mutual benefits, comprising:
a processor; and 16 a memory disposed in communication with the processor and storing processor-17 executable instructions to:
18 send to the user the user's TVM balance and an indication that at least 19 some TVMs in the user's TVMs balance will expire;
receive a request to donate expiring TVMs to a designated friend;
21 allocating via a processor the user's expiring TVMs to be donated to the 22 designated friend;
23 send a TVM donation message to the designated friend;
24 receive from the designated friend an enrollment request;
generate via a processor a new user account for the designated friend;
26 transfer the allocated expiring TVMs to the designated friend's new user 27 account; and 1 send a confirmation of the transfer to the user and to the designated 2 friend.
3 [00375] 105. The apparatus of embodiment 104, further comprising instructions 4 to:
monitor the spending of the user's donated TVMs by the designated friend; and 6 allocate via a processor an invite bonus block to the user's account when a 7 predetermined number of the user's donated TVMs have been spent.
8 [o 0376] 106. The apparatus of embodiment 104, further comprising instructions 9 to:
receive a request from a user for user transaction value modifier (TVM) balance ii information;
12 [o 0377] 107. The apparatus of embodiment 105, wherein the mutual benefit 13 enrollment request further comprises an amount of TVM gifted by an economic 14 promoter.
[0 0 3 78 ] 108. The apparatus of embodiment 107, wherein the economic promoter 16 obtains a percentage of the amount of TVMs donated to the friend.
17 [oo 3 79 ] 109. The apparatus of embodiment 108, wherein a merchant manager gifts 18 TVMs to the economic promoter and obtains a percentage of the amount of TVMs gifted 19 to the friend.
[0 0380] 110. An apparatus for mutual benefits, comprising:
21 a processor; and 22 a memory disposed in communication with the processor and storing processor-23 executable instructions to:
24 receive an indication of preliminary interest in a mutual benefit program;
provide to the merchant a mutual benefit enrollment request form;
26 receive a mutual benefit enrollment request from a merchant for the 27 mutual benefit program;
1 send a mutual benefit enrollment form to the merchant;
2 receive from the merchant a completed mutual benefit enrollment form;
3 send a request to a merchant agent requesting background material on the 4 merchant;
receive background material on the merchant from the merchant agent;
6 analyze the background material from the merchant agent;
7 enroll the merchant in the mutual benefit program if the background 8 material meets predetermined criteria;
9 generate a merchant account for the merchant; and send the merchant a confirmation of enrollment in the mutual benefits 11 program.
12 [0 o 3 8 1] 111. The apparatus of embodiment 110, further comprising instructions to:
13 receive from a merchant a survey of current point-of-sales (PoS) infrastructure and 14 settings configurations;
determine a new PoS configuration for the user based on mutual benefit program 16 specifications; and 17 send the new PoS configuration and the training materials to the merchant for 18 implementation.
19 [0 o 3 8 2 ] 112. The apparatus of embodiment in, further comprising instructions to:
generate training materials for the new PoS configuration.
21 [0 0 3 8 3 ] 113. An apparatus for mutual benefits, comprising:
22 a processor; and 23 a memory disposed in communication with the processor and storing processor-24 executable instructions to:
receive a request for a user's value point balance and a merchant's current 26 value point schedule from a merchant;
I receive a value point transaction confirmation indicating a transaction has 2 been successfully processed and value point transaction data;
3 debit from a user's account an amount of value points received from 4 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 6 point transaction data; and 7 generate via a processor a value point transaction record and storing the 8 value point transaction data in the value point transaction record.
9 [0o384] 114. The apparatus of embodiment 113, further comprising instructions to:
io update via the processor the merchant's current value point schedule in the database ii using the value point record.
12 [0o385] 115. An apparatus for mutual benefits, comprising:
13 a processor; and 14 a memory disposed in communication with the processor and storing processor-executable instructions to:
16 receive a product bulk amount from a partner;
17 receive a request for a merchant's transaction value modifier (TVM) 18 balance and a partner's current TVM schedule from a partner;
19 send the merchant's TVM balance and the partner's current TVM
schedule to the partner;
21 receive a TVM transaction confirmation indicating a transaction involving 22 purchasing at least one product bulk amount has been successfully processed and TVM
23 transaction data;
24 debit from the merchant's account an amount of TVMs used in the transaction;
26 credit to the merchant's account an amount of TVM based on the TVM
27 transaction data;
1 generate via a processor a TVM transaction record and storing the TVM
2 transaction data in the TVM transaction record; and 3 update via the processor the merchant's current TVM schedule in the 4 database using the TVM transaction record.
[00 3 8 6 ] 116. An apparatus for mutual benefits, comprising:
6 a processor; and 7 a memory disposed in communication with the processor and storing processor-s executable instructions to:
9 receive aggregated entity data in a mutual benefits program within a defined geo-demographical region;
11 perform performance analytics on the entity data;
12 determine demarcation indicia to divide a region if the region is 13 overpopulated;
14 split the region based on the geo-demographical demarcation indicia into sub-regions;
16 receive updated demographic and industry data on each sub-region; and 17 generate new merchant categories for each sub-region based on the 18 updated demographic and industry data.
19 [0 o 3 8 7] 117. The apparatus of embodiment 116, wherein the entity is at least one of a merchant or demographic data.
21 [00 3 8 8 ] 118. An apparatus for mutual benefits, comprising:
22 a processor; and 23 a memory disposed in communication with the processor and storing processor-24 executable instructions to:
receive aggregated entity data in a mutual benefits program within a 26 defined geo-demographical region;
27 perform performance analytics on the entity data;
1 determine enrollment criteria for enrolling at least one merchant in the 2 mutual benefits program if at least one merchant in the region is over-capacity;
3 send a mutual benefit enrollment form to a merchant not enrolled in the 4 mutual benefits program;
receive from the merchant not enrolled in the mutual benefits program a 6 completed mutual benefit enrollment form;
7 enroll the merchant in the mutual benefits program; and 8 update the region record in a database to include the enrolled merchant.
9 [0 0389] 119. The apparatus of embodiment 118, wherein the entity is at least one of a merchant or demographic data.
11 [00390] 120. The apparatus of embodiment 118, wherein the enrollment criteria 12 may include the category that the at least one merchant in the region which is over-13 capacity.
Claims (125)
1. 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.
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 1, further comprising:
updating via the processor the account holder's current eco schedule in the database using the eco record.
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.
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.
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.
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;
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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;
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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;
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.
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.
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.
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 holder114. 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.
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 holder114. 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.
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.
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.
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.
100. 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.
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.
101. The program of claim 1, further comprising:
updating via the processor the account holder's current eco schedule in the database using the eco record.
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.
106. The program of claim 10 cl, further comprising:
sending the user's ecos balance and the account holder's current ecos schedule to the account holder.
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.
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.
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;
receiving a request from a user for user eco balance information;
110. The program of claim 108, wherein the mutual benefit enrollment request further comprises an amount of eco gifted by a promoter.
111. 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 111, 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.
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.
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.
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.
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.
updating via the processor the account holder's current value point schedule in the database using the value point record.
118. 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.
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.
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.
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 exchange 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 exchange with a health insurance provider and a health care provider.
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| BRPCT/BR2012/000148 | 2012-05-21 | ||
| PCT/BR2012/000148 WO2013173891A2 (en) | 2012-05-21 | 2012-05-21 | Win-win intermediary system and method |
| US201313842593A | 2013-03-15 | 2013-03-15 | |
| US13/842,593 | 2013-03-15 | ||
| PCT/IB2013/001865 WO2013175320A2 (en) | 2012-05-21 | 2013-05-21 | Eco advantage mediation apparatuses, methods and systems |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2874072A1 true CA2874072A1 (en) | 2013-11-28 |
Family
ID=49624441
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2874072A Abandoned CA2874072A1 (en) | 2012-05-21 | 2013-05-21 | Eco advantage mediation apparatuses, methods and systems |
Country Status (7)
| Country | Link |
|---|---|
| EP (1) | EP2852929A4 (en) |
| KR (1) | KR20150016971A (en) |
| AU (1) | AU2013264948A1 (en) |
| BR (1) | BR112014029153A2 (en) |
| CA (1) | CA2874072A1 (en) |
| MX (1) | MX2014014137A (en) |
| WO (1) | WO2013175320A2 (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| SG10201907709WA (en) * | 2019-08-21 | 2021-03-30 | Mastercard International Inc | Methods and systems for tracking eco-friendly financial activities |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6151586A (en) * | 1996-12-23 | 2000-11-21 | Health Hero Network, Inc. | Computerized reward system for encouraging participation in a health management program |
| US7398225B2 (en) * | 2001-03-29 | 2008-07-08 | American Express Travel Related Services Company, Inc. | System and method for networked loyalty program |
| US8005714B2 (en) * | 2004-02-02 | 2011-08-23 | David Shaw | System and method for providing a discount |
| US20070192195A1 (en) * | 2006-01-25 | 2007-08-16 | Asmar Alejandro G | System and method of economic incentives to foster behavioral changes that improve health |
| US8965784B2 (en) * | 2009-01-14 | 2015-02-24 | Signature Systems Llc | Reward exchange method and system implementing data collection and analysis |
-
2013
- 2013-05-21 CA CA2874072A patent/CA2874072A1/en not_active Abandoned
- 2013-05-21 MX MX2014014137A patent/MX2014014137A/en unknown
- 2013-05-21 WO PCT/IB2013/001865 patent/WO2013175320A2/en active Application Filing
- 2013-05-21 EP EP13793144.0A patent/EP2852929A4/en not_active Withdrawn
- 2013-05-21 KR KR1020147035854A patent/KR20150016971A/en not_active Application Discontinuation
- 2013-05-21 BR BR112014029153A patent/BR112014029153A2/en not_active IP Right Cessation
- 2013-05-21 AU AU2013264948A patent/AU2013264948A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| EP2852929A2 (en) | 2015-04-01 |
| KR20150016971A (en) | 2015-02-13 |
| AU2013264948A1 (en) | 2015-01-22 |
| EP2852929A4 (en) | 2015-11-04 |
| WO2013175320A3 (en) | 2014-05-08 |
| WO2013175320A2 (en) | 2013-11-28 |
| AU2013264948A8 (en) | 2015-03-12 |
| MX2014014137A (en) | 2015-06-17 |
| BR112014029153A2 (en) | 2017-06-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11093919B2 (en) | Merchant-consumer bridging platform apparatuses, methods and systems | |
| US11354723B2 (en) | Smart shopping cart with E-wallet store injection search | |
| US10438176B2 (en) | Multiple merchant payment processor platform apparatuses, methods and systems | |
| US20200094133A1 (en) | Dynamic payment optimization apparatuses, methods and systems | |
| US20200034753A1 (en) | Secure Anonymous Transaction Apparatuses, Methods And Systems | |
| US10223710B2 (en) | Wearable intelligent vision device apparatuses, methods and systems | |
| US20190108509A1 (en) | Cloud-based virtual wallet nfc apparatuses, methods and systems | |
| CN103765453B (en) | Snap mobile payment device, method and system | |
| KR102050909B1 (en) | In-person one-tap purchasing apparatuses, methods and systems | |
| US9846880B2 (en) | Product recall platform apparatuses, methods and systems | |
| AU2019200041A1 (en) | Multi-channel remote payment apparatuses, methods and systems | |
| US20140279474A1 (en) | Multi-purse one card transaction apparatuses, methods and systems | |
| US20120101881A1 (en) | Loyalty promotion apparatuses, methods and systems | |
| US20150248664A1 (en) | Snap Mobile Payment Apparatuses, Methods and Systems | |
| US20130290234A1 (en) | Intelligent Consumer Service Terminal Apparatuses, Methods and Systems | |
| US20120239417A1 (en) | Healthcare wallet payment processing apparatuses, methods and systems | |
| US20180276702A1 (en) | Eco Advantage Mediation Apparatuses, Methods and Systems | |
| WO2013009660A1 (en) | Bidirectional bandwidth reducing notifications and targeted incentive platform apparatuses, methods and systems | |
| US20150170186A1 (en) | Eco Advantage Mediation Apparatuses, Methods and Systems | |
| CA2874072A1 (en) | Eco advantage mediation apparatuses, methods and systems | |
| JP2015524953A (en) | Eco Advantage Mediation Device, Method, and System |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Dead |
Effective date: 20180523 |