WITH MULTIPLE POINT LEVELS AND JURISDICTIONS

TECHNICAL FIELD

[0001] This application relates to customer loyalty systems in general, and to customer acquisition and loyalty by personal localized promotional messaging with multiple point levels and jurisdictions, in particular.

BACKGROUND

[0002] It is well known that merchants know the value of the loyalty of their customers. A loyalty card (often called a store card or a reward card), is a marketing tool allowing to reward loyal customers. In material form, loyalty cards allow merchants to identify the most loyal of customers and attribute to them advantages such as services, gifts, or rebates.

[0003] More recently, dematerialized loyalty cards have become available in electronic form on mobile devices and smart phones. Many mobile applications have been created to that end. These electronic wallets for loyalty cards raise issues about the ownership of information, and in some cases, may prevent the merchants from compiling statistics, and may limit the ability of the merchant to manage the confidentiality of their customers.

[0004] There are also hybrid systems including a loyalty card, a mobile application, and a point of sale (POS) terminal, and tools to manage the loyalty system from a simple web browser.

SUMMARY

[0005] According to one aspect of the present application, there is provided a method of providing a loyalty system for use by a network of partners for both rewarding the loyalty of an existing customer of a first partner towards the first partner and for the acquisition of the existing customer as a new customer by at least one other partner in the network. The method includes: (a) providing an exclusive point based component to keep track of the balance of exclusive points of the existing customer that are redeemable exclusively with the first partner in the network; (b) providing a network point based component to keep track of the balance of network points of the existing customer that are redeemable with one of the first partner and the at least one other partner in the network; and (c) providing an acquisition component to enable the at least one other partner to acquire the existing customer of the first partner as a new customer of the at least one other partner. [0006] In some embodiments, the exclusive point based component further keeps track of the balance of exclusive points of the exiting customer that are redeemable exclusively with the at least one other partner in the network. In some embodiments the method further comprises adding an amount to a balance of points that are redeemable with the at least one other partner in the network. In some embodiments, the amount added is caused by an entry of a promo code by the existing customer. In some embodiments, the promo code is one of a random promo code and a keyword promo code. In some embodiments, the promo code is advertised using a coupon. In some embodiments, the promo code is advertised using a promotional message. In some embodiments, the amount added is caused by a purchase of points by a purchaser of points. In some embodiments, the purchase of points is accomplished using a prepaid card having a value corresponding to the purchased points. In some embodiments, the recipient of the points is notified of the purchase of points so as to be able to claim the purchased points. In some embodiments, the notification is by email. In some embodiments, the at least one other partner acquires the existing customer as a new customer when the existing customer redeems points with the at least one other partner. In some embodiments, the method further includes sending a promotional message. In some embodiments, the promotional message is an on-site promotion. In some embodiments, the on-site promotion is triggered by a beacon. In some embodiments, the promotional message is personalized based on a profile of the existing customer fitting within a target group so as to preserve the confidentiality of the profile of the existing customer. In some embodiments, the acquisition component enables a user to accomplish at least one of the acts of buying points and claiming points. In some embodiments, the act of buying points includes the steps of: (a) providing a web interface for purchase of points that can be reached by a user; (b) presenting a form to the user to be filled which contains a cart of points and all the necessary information for the purchase and the routing of the points to a recipient; (c) validating the form by the user; (d) presenting an invoice to be paid by the user; (e) receiving an agreement to pay by the user pressing on the button to pay; (f) redirecting the user to a payment gateway in order to pay the invoice; (g) receiving a payment information entered by the user and validating a payment; (h) returning the user from the payment gateway to the web interface; and (i)displaying a message confirming the purchase and sending at least one confirmation email. In some embodiments, the act of claiming points includes the steps of: (a) providing a user with a link in an email in order to reach a page for a claiming of points; (b) displaying a form for the claiming of points; (c) filling in the form and validating the form by the user; and (d) validating the form and displaying a message of success. In some embodiments, the acquisition component authenticates the user to identify the user as a member for consulting a purchase history. In some embodiments, the act of consulting a purchase history includes the steps of: (a) providing a purchase history interface through a reports menu of a navigation bar of a website; and (b) listing the purchases carried out by the member. In some embodiments, the acquisition component enables a partner to authenticate for consulting at least one of a transaction history, a money balance, and a statistic. In some embodiments, the act of consulting a transaction history includes the steps of: (a) providing a transactions interface through a reports menu of a navigation bar of a website; and (b) listing a list of transaction carried out that involves the partner. In some embodiments, the act of consulting a transaction history includes the steps of: (a) providing an instrument panel interface dedicated to the partner; and (b) displaying a money balance available. In some embodiments, the act of consulting a statistic includes the steps of: (a) providing a statistics interface through a reports menu of the navigation bar of a website; and (b) displaying at least one statistic available. In some embodiments, the acquisition component enables an administrator to authenticate to at least one of consulting a statistic, correcting an email address for a purchase, and consulting a point history. In some embodiments, the act of consulting a statistic includes the steps of: (a) providing a statistics interface through a reports menu of the navigation bar of a website; and (b) displaying at least one statistic available. In some embodiments, the act of correcting an email address includes the steps of: (a) providing a sale of points interface through a management menu of a navigation bar of a website; (b) listing a list of sales of points carried out through the system; (c) receiving a press on a resend email button; (d) displaying a form to be filled; (e) filling in the form and validating it; and (f) updating at least one email address and resending at least one email. In some embodiments, the method comprises the step of converting points to currency using an exchange rate. In some embodiments, the exchange rate is dependant on jurisdiction.

[0007] Other aspects and features of the present application will become apparent to those ordinarily skilled in the art upon review of the following description of specific embodiments of a customer acquisition and loyalty by personal localized promotional messaging with multiple point levels and jurisdictions, in conjunction with the accompanying drawing figures.

BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Embodiments of the present application will now be described, by way of example only, with reference to the accompanying drawing figures, wherein:

FIG. 1 illustrates a market focused only on the loyalty of a merchants own clients;

FIG. 2 illustrates a market focused on both loyalty of own clients and on client acquisition with promo codes; FIG. 3 illustrates one embodiment of a combined loyalty and consumer acquisition system;

FIG. 4 illustrates communications between the various components of an embodiment of the system;

FIG. 5 illustrates an exemplary transaction procedure; FIG. 6 illustrates exemplary communications involving partners, members, and promo codes in the process of acquiring clients;

FIG. 7 illustrates an exemplary process for the creation of promo codes;

FIG. 8 illustrates an exemplary coupon used by partners to provide promo codes to members;

FIG. 9 illustrates an exemplary multi-level and multi-point wallet interface;

FIG. 10 illustrates different communication channels that merchants use to try and reach consumers;

FIG. 11 illustrates an exemplary system enabling targeted promotions from partner merchants to reach member consumers;

FIG. 12 illustrates communications between the various components of an embodiment of the system;

FIG. 13 illustrates different communication channels that merchants use to try and reach consumers;

FIG. 14 illustrates an exemplary system enabling targeted promotions from partner merchants to reach member consumers;

FIG. 15 illustrates communications between the various components of an embodiment of the system;

FIG. 16 illustrates an exemplary use of the system;

FIG. 17 is a block diagram illustrating exemplary component modules of the system;

FIG. 18 is a flowchart illustrating exemplary multi-jurisdiction functionality;

FIG. 19 is a block diagram illustrating an exemplary embodiment for the creation of promo codes;

FIG. 20 is a block diagram illustrating an exemplary embodiment for the acquisition of promo codes;

FIG. 21 is a block diagram of an exemplary device including exemplary components of a computer that can be used with embodiments of the application;

FIG. 22 illustrates the traditional loyalty program paradox whereby merchants have to choose either a coalition program or a home program;

FIG. 23 illustrates one effect of embodiments of the present application, the hybrid loyalty program solution to the loyalty program paradox;

FIG. 24 illustrates an exemplary coupon used by partners to provide prepaid cards to members;

FIG. 25 illustrates a flowchart for the purchase of points by a user;

FIG. 26 illustrates a flowchart for the transfer of points to a gift card;

FIG. 27 illustrates a flowchart for the purchase of prepaid points;

FIG. 28 illustrates the architecture of a sub-system for purchase and management of prepaid loyalty points; FIG. 29 illustrates a use case diagram for the sub-system of FIG. 28;

FIG. 30 illustrates a deployment diagram for the subs-system of FIG. 28;

FIG. 31 illustrates a class diagram for an "Information" package;

FIG. 32 illustrates a class diagram for an "Invoice" package;

FIG. 33 illustrates a class diagram for a "Payment GW" package;

FIG. 34 illustrates a class diagram for a "Service" package;

FIG. 35 illustrates a class diagram for a "Transactions" package;

FIG. 36 illustrates a class diagram for a "Facade" package;

FIG. 37 illustrates a user interface for the purchase of points and the various options offered to clients;

FIG. 38 illustrates a simplified version of the user interface of FIG. 37 when the user is authenticated;

FIG. 39 illustrates a user interface to provide members the possibility of consulting a report of transactions carried out with their points;

FIG. 40 illustrates a user interface to provide members the possibility of consulting the point purchase history; FIG. 41 illustrates a user interface for a "My Wallet" homepage of a member of the Network program;

FIG. 42 illustrates a message sent to the recipient;

FIG. 43 illustrates a user interface which enables a recipient to claim points;

FIG. 44 illustrates an example of a prepaid card which a user can print and to present at a merchant;

FIG. 45 illustrates a transaction report user interface; and

FIG. 46 illustrates a dashboard user interface.

[0009] Like reference numerals are used in different figures to denote similar elements.

DETAILED DESCRIPTION OF THE DRAWINGS

[0010] The rise of the strategy of development of consumer loyalty is increasingly prominent today, being one of the top priorities for merchants. It is a determinant, in particular in quickly saturated markets, where competition is hard for businesses in the same sector. This promising approach proved reliable during these last decades, but the numbers in terms of development of consumer loyalty vary depending on sector, and depending on which elaborate study you consider. According to one study, recruiting a customer is three times more expensive than the cost of retaining the customer. The development of consumer loyalty thus seems like an intelligent marketing strategy and economically interesting for businesses. It is all the more important as it is a source for generating additional incomes. Indeed, the numbers collected by the same author reveal that a 5% increase in customer retention increase the profits of the company from 25 to 55%.

[0011] The "classical" notion of consumer loyalty can be detached from the initial concept of rewarding the loyalty of a customer with regards to a specific partner, to extend to the generic concept of a "coalition loyalty program". This consists in the fact that several merchants use the same system for consumer loyalty in order to share their data and their customers. This new form of consumer loyalty gives the opportunity to commercial partners to communicate their offers and promotions with a broader group of customers/members of the loyalty program to obtain improvements in the effectiveness of their loyalty program . So beyond a classical development of consumer loyalty where one's own customers are rewarded, the merchant profits from the advantage of attracting a new population of customers. In addition, given an existing base of members, the addition of a new partner to a loyalty program gives rather fast effects, at reduced cost. With regard to the members, joining such a loyalty program allows, on one side to multiply their chances of gains, and on the other side, to benefit from a choice of more diversified opportunities.

[0012] Often, the development of coalition loyalty of consumers is based on a centralized platform, designed to manage the various modes of gratifications of the partners on line. The existing programs offer practically the same options: rebates, gift certificates, accumulation of fidelity points etc, in relation to a specific partner. The possibilities offered to the customers are sometimes restricted. Indeed, a customer who acquires a gift certificate must choose the merchant where the certificate must be spent by the receiver of the gift. With regard to the merchants, to join such a program of consumer loyalty is limited to the distribution of points or rebates to the faithful customers by ensuring the follow-up of the expenditure of these forms of gratification. The customers available to a partner starting from the network of partners of the program are either loyal, therefore identified a priori, or else unknown, therefore not particularly targeted by the offers of the partner.

[0013] Although the members and the partners adhere to a coalition loyalty program, they remain constrained by rules of acquisition and expenditure of the held points, and by restricted access to the shared data that is potentially interesting for a better performance of the loyalty program. Currently, different systems, though similar in the options suggested, using distinct strategies and offering to the customers mainly services such as the development of consumer loyalty, the possibility of purchasing prepaid cards and gift cards require organization and duplicated work for the businesses and merchant partners, requiring more attention, time and heavy as a whole, complicating membership for the client who is then scattered in the midst of various options. [0014] In the absence of an effective management system gathering at the same time all the services quoted above, the urgent need to develop a means facilitating the tasks for the business, the commercial partners, and the customers is felt. The evolution of the existing systems is possible by the development of innovating features meeting various business needs of the business and its partners. The system developed within the framework of the internship will make it possible to better capture customers by the offer of a better service. It will support the prosperity local and even national economy, by founding and widening an effective exchange network while allowing a better management of time and means.

[0015] In this specification and in the appended claims, depending on the context, we use the following terms to designate either the data structures identifying actors involved in our system, or the actors themselves: partner means a business which participates in the Network consumer loyalty program; a site or a merchant refers to one of the retail outlets associated with a partner; company indicates the company operating the Network program; a member is a customer of a partner who has a Network consumer loyalty program card and who has subscribed to the Web site of the company.

[0016] The Network program makes it possible to accumulate and spend points according to a rule where a point is equal to a penny (although the member sees only balances in dollars on the mobile Web site or in the application). There are two principal categories of the items in the Network program: "Exclusive Points" and the "Network Points". The "Exclusive Points" are the exclusive points with a specific partner and that can only be spent at the specific partner, whereas the "Network Points" are the points which are valid at any partner.

[0017] The principle of consumer loyalty is that the customers receive loyalty points which are proportional to the amount spent at the partner; these points can be used in order to carry out purchases or to gain discounts. Thanks to the Network program, a partner could give a customer, a percentage of the sum spent at his place in the form of points. For example, for the sum of 100$ spent, and with a rate of return of 1%, the customer will receive the equivalent of 1$ in points (100 points). While re-spending these 100 points, the customer will not receive loyalty points. On the other hand, if the customer spends the points of a gift card to carry out a purchase, they will receive loyalty points since the points on the gift card were bought and are not loyalty points. We can thus see that there is a second classification of points which separates points in two groups; received points and bought points.

[0018] On one hand, a Network loyalty program that does not have a platform for the purchase of points on line can still benefit from buying points is in the form of gift cards at the level of shops specific to each partner. However, on the other hand, there may be no possibility of buying gift cards with "Network Points" redeemable at any partner. The fact that certain partners have payment systems which do not accept the gift cards method of payment constitutes a barrier for use of the card in order to charge with the "Network Points" at those partners. To facilitate the use of the platform it is proposed to allow any member registered with the program to be able to directly buy points on its account, without resorting to a card other than that the membership card with the Network. Furthermore, any person, registered or not, can buy points and be able to send them like gifts, without loading them onto a card in their possession. This allows for the sale of "Network Points" by guaranteeing their functionality at all the partners. An adequate payment gateway is one that minimizes the costs of transfer of money in order to present a suitable price to the clients.

[0019] In addition, the databases of the Network program of the members registered with the program form a very valuable asset while maintaining the anonymity and the confidentiality of its clients. In the absence of an analysis of the customers, a partner with the loyalty program does not have means allowing him to direct his sales policies and decisions.

[0020] There are provided tools of exploitation the database of the program so as to develop the capital of information available to the profit of the company and of its partners. Disclosed herein is a platform for purchasing points for the Network program via on line sales and to centralize the purchase of its "Network Points" and "Exclusive Points". This platform allows, on one side, an unregistered customer or a registered member to buy points on line thanks to its banking or credit card, and on another side, the partners to recover their profits in a very fluid and easy way. The customer is enabled to select points and to fill a cart with points, to then send them by email to himself or to another person, or to transfer them directly on his member account. If the points are sent by email, the recipient should claim them before a 30 days deadline; if not the points will be turned over to the purchaser. The recipient can claim the points directly on his member account or by email. If the points were claimed by email, they will be charged on one or more prepaid cards. Thus, these points could be spent at all the partners. With respect to the systems of retail outlets, the prepaid card is regarded as a member card and not as a gift card. All the transfers of money and the payment operations will be performed via a payment gateway which is integrated with this purchase and management platform.

[0021] Finally, in order to benefit from the wealth of the databases of the company, it is herein proposed to integrate into the platform a module for the calculation of statistics in the form of charts illustrating the data in real time on the use of the Network program. This can be used mainly to effectuate a set of data analysis on the clients and the partners to allow the company to evaluate its clientele and to follow their evolution in the market. The partners will be able to visualize part of these results in order to know the state of their sales, the clients and the transactions for better knowing and targeting their clientele. Let us note the data analysis is operated in the system so as to protect the confidentiality of the personal data of the customers.

[0022] Referring to the drawings, FIG. 1 illustrates a market focused only on the loyalty of a merchants own clients. The Market in FIG. 1 includes Merchants 100 that employ models 140 focused only on loyalty of own clients in order to reward the loyalty of consumers 110 using exclusive point based programs 120 and network point based programs 130. As illustrated, these models 140 prevent 150 that exclusive points 120 be combined with, or be combinable with, network points 130. Merchants 100 can take the form of retailers or offices where consumers 110 transact for goods and services in person, as well as through electronic commerce where merchants 100 sell and consumers 110 buy using electronic means, such as web sites and mobile applications.

[0023] FIG. 2 illustrates a market focused on both loyalty of own clients and on client acquisition with promo codes. The Market in FIG. 2 includes Merchants 100 that employ models 170 focused on both loyalty of own clients and on client acquisition with promo codes in order to offer consumers 110 a combination 125 of exclusive points 120 redeemable only at one merchant and network points 130 redeemable at any merchant that is a partner in a network of merchants, and this in order to enable consumer loyalty while at the same time offering a certain degree of freedom to consumers 110. Furthermore, the models 170 offers the possibility for merchants to generate promo codes 160 in order to provide exclusive points 167, or network points 165, or even a combination of both 168, to consumers 110 that are not necessarily their clients in order to favour the acquisition of new clients.

[0024] FIG. 3 illustrates one embodiment of a combined loyalty and consumer acquisition system. The combination of consumer loyalty 140 modules and consumer acquisition 170 modules enables advantages. The combined system includes partners 112, e.g. merchants who have entered into agreements in order to be a part of the network to do business with members 111, e.g. consumers who have joined the network. In order to accept exclusive points 120, network points 130, or both 125, the partners 112 process their transactions 300 normally by using their point of sale system (POS) within which has been integrated a loyalty module, e.g. an API, or using a virtual register 300 provided on a web page which is accessible via a secured connection. The partners 112 have access to management modules 350 enabling, inter-alia, the generation of promo codes, such as random promo code 162 (e.g. RT445TY) and keyword promo code 164 (e.g. GATINEAU) in order to provide exclusive points 167 and/or network points 165, or a combination of both, to members 111. These codes 160 are made available to partners 112 by electronic means, such as for example in a spreadsheet file, and the partners 112 can then distribute them using the communication channel of their choice to members 111, be those members already clients or not, so that the members 111 must make purchases with the partners 112 in order to benefit from the provided points.

[0025] FIG. 4 illustrates communications between the various components of an embodiment of the system. The database 410 includes transactions that are hosted on a server 420 using network services, such as cloud based services. The application server 420 communicates with the database 410, and network clients 111 communicate with the database 410 via an API 300 or a web server 430 connected to a communications network 450, such as the Internet.

[0026] FIG. 5 illustrates an exemplary transaction procedure. The transaction procedure may vary according to the services used by the partners 112. As illustrated, in the case of partners 112 using a POS terminal 462, the protocol is the same: via the intermediary POS server 500, a transaction request 501, 502 is virtually sent to the database 410 via the API 300. A response 3 is then sent to the POS server 500 to authorize or refuse the transaction. In the case of a connection to the virtual cash register via a web page 466, the connection is directly with the database 410 without having to go through the POS server 4500. For transactions made on-line with the electronic commerce E-COM 486, the request 501 and the response 504, in alternative embodiments, is requested 504 or responded 505 via the POS server 500 or through requests 506, 508 and responses 507, 509 via the API 330.

[0027] FIG. 6 illustrates exemplary communications involving partners, members, and promo codes in the process of acquiring clients. Partner 2 103 and partner 1 102 have together generated a promo code which they have made available to member 1 112 and member 2 113. The members 112 and 113, and member 113 has entered the promo code 160 into their member account after having connected to the web site or by using a mobile application. Their request is then sent towards the database 410, which is responsible for authorizing or refusing the addition of points to the account of each member. After authorization, member 1 112 has obtained points at both partner 1 102 and partner 2 103. Member 1 112 chooses to make a loyalty transaction 600 to use the points it has with partner 1 102 (with the E-COM 468 platform, applications and mobile services 460, POS (server, terminal or client) 462, a middleware with the server of the partner 464, or a web page 466). If the member had never made a purchase with the partner before, then client acquisition 610 is enabled.

[0028] FIG. 7 illustrates an exemplary process for the creation of promo codes. In order to create promo codes 160, partners 112 can connect to their partner account using an email and a password and thus have access to tools 770. The partner selects the promo code tool 774, after which the promo code creation interface 700 is provided. The promo code generation module 400 allows them to create random based promo codes 162(varying codes generated by the system) or keyword based promo codes 164. The partner determines the total number of codes that they want to make available 705, a member limit 710, and a daily limit 715, as well as the validity dates of the codes 720 in order to create a determined number of exclusive points 167 or network points 165 or a combination of these 168.

[0029] FIG. 8 illustrates an exemplary coupon used by partners to provide promo codes to members. The promo codes 160 can be provided to members using a communication medium of their choice, such as for example, the printing of coupons 800a or signs (not shown) containing the promo code 805, instructions 815, the total value of the points 810 made available with the promo code, as well as a list of partners 112, such as for example as illustrated on the back side 800b of the coupon.

[0030] FIG. 9 illustrates an exemplary multi-level and multi-point wallet interface. The members 11 can connect to their account via a web site 900 or mobile applications (e.g. iOS, Android, Windows, BlackBerry) 910 and use their email or member number and their password to add the promo codes. The amount in partner exclusive points for each participating partner is then added automatically into their wallet 950 balance for each partner, as well as adding the amount of network points automatically to their network points balance.

[0031] FIG. 10 illustrates different communication channels that merchants use to try and reach consumers. Merchants 100 try to find ways to reach and to send pertinent information to consumers 110. The tools allowing them to know and profile their clientele and their purchasing habits are limited. It therefore becomes difficult to send messages and promotions 105 addressed directly to each type of consumer using traditional tools available to the merchants such as channels 150 like flyers, web sites, publicity in traditional media or on social networks, regardless if trying to reach consumers by mobile applications 120 or email 130. Consumers are also reticent (<?>) to provide their personal information to just any merchant.

[0032] FIG. 11 illustrates an exemplary system enabling targeted promotions from partner merchants to reach member consumers. By combining the information collected on member consumers 110 when they join on one hand and their buying habits on the other hand into a database 200, the system enables partner merchants 100 to better know their clientele of member consumers 110 and to send them messages and personalized promotions 251, 252, 253 that target specific groups of them 211, 212, 213. This is accomplished by providing partner merchants 100 access to management tools including a promotion management module 250. Thanks to these technological improvements, partner merchants 100 can therefore display messages by email or on mobile applications to member consumers 110 that present themselves on-site (e.g. on-site promotions) or event at a distance (e.g. push notifications) as a function of what concerns them according to their profile (211, 212, 213). For example, a partner merchant 100 could say "Hello <FIRST NAME>! I have a sensational offer for you!" to young men between 18 and 34 years of age and "Hello Mrs. <SURNAME>! We are doubling points for you today only!" to women between 35 and 54 years of age. These messages are transmitted on-site via mobile applications and/or email. Since the targeted consumers are members and have given their consent to partner merchants to have ace's to their information to personalize their offers the technology further enables consumers to receive fewer messages that are not pertinent to them.

[0033] FIG. 12 illustrates communications between the various components of an embodiment of the system. Partner 1 100 accesses the database 200 with the aid of one of the management modules 250 made available to him as a partner of the network. Depending on the kind of promotion used, the promotion will be sent to server 300 towards members matching the profile targeted (211, 212, 213), either in their mobile application when arriving on-site (on-site promotion) or via a push notification that is also sent to their email address. A validation is necessary between the database and the server before a message is sent in order to ensure the right message is sent to the members matching the right profile.

[0034] FIG. 13 illustrates different communication channels that merchants use to try and reach consumers. The challenge is to reach consumers 110 by giving them targeted information and targeted promotions as a function of their profile and/or their buying habits. The merchants 100 try to find ways to reach consumers 110 and to send them pertinent information (messages and promotions 105) via traditional channels 150 such as flyers, web, publicity in the media and social networks, for example. The tools available to allow merchants to know the buying habits of their clientele are limited. To try and overcome these difficulties, merchants 100 develop their own mobile applications 175, but consumers are somewhat reticent to add many mobile applications on their mobile phones and to give personal information to any merchant.

[0035] FIG. 14 illustrates an exemplary system enabling targeted promotions from partner merchants to reach member consumers. The partner merchants 100 have access to consumer profiles including information collected on member consumers 110 when they joined as well as their buying habits, stored in database 200, by use of promotion management module 250 that allows partner merchants 100 to create promotions stored in promotion records in database 200 that will be used to send personalized messages and personalized on-site promotions 226. 227 and 228 via on-site locations 265, such as for example iBeacons, while taking into account the information in the consumer profiles of member consumers 110. The use of this technology enables merchants 100 to display different messages on the same mobile network application 175 of member consumers 110 that present themselves on-site as a function of their profiles 211,212, 213 in order to send them the right message/promotion 226,227, 228 when the member consumers are in proximity to an on-site beacon 275, 286, 295. For example, one could send promotion 1 226 to young men between 18 and 34 years of age that are in proximity to beacon 1 275, promotion 2 227 to women between 35 and 54 years of age in proximity to beacon 2 285 and promotion 3 228 to everyone who is in proximity to beacon 3 295. Since these consumers 110 are members, they have consented to give merchants 100 ace's to their information to personalize their offers and thus receive fewer non-pertinent messages.

[0036] FIG. 15 illustrates communications between the various components of an embodiment of the system. Partner 1 100 access the database 200 using one of the tools such as promotions management module 225 made available to them as a partner in the network. The promotion will be sent from server 300 towards a beacon and/or on- site location 265 to be routed towards members belonging to the targeted profile 211,212 213 on their mobile application 175 when arriving in proximity to on-site location 265. A validation is necessary between the database 200 and the server 300 before the message is sent in order to ensure that the message is sent to the right profile. For example, promotion 1 will be sent towards on-site location (Beacon) 1 275 towards members belonging to profile 1 211.

[0037] FIG. 16 illustrates an exemplary use of the system. Partner merchants 100 can access promotion management module 250 to generate messages/promotions 226, 227, 228 and 229 to be sent to different profiles 211,212 and 213 by attributing them to different on-site locations or beacon 1 275, beacon 2 285, beacon 3 295 and 310, and beacon 4 305. These messages are sent to member consumers 110 as a function of their profile and proximity to the beacons via mobile application 175. Thus as member consumer 110 passes the beacons by taking path 301, only messages and promotions that are pertinent to the member consumer 110 are sent to network app 175.

[0038] FIG. 17 is a block diagram illustrating exemplary component modules of the system. In some embodiments, different techniques have been put in place in order to proceed to effect transactions of points between the Partners and the Members. In some embodiments, a cash register interface is provided as a web version (Web User 1066, Web Site 1030, Web 1033) that the Partners can access with their passwords. The web site 1030 obtains the information needed for the transaction from the database (database interface 1010, database 1020). In some embodiments, the Partners use a Point of Sale (POS) system (POS User 1062, POS 1063, POS API 1031) into which the modules are integrated such that transactions proceed automatically since the POS 1063 communicates (Communications 1050) the information to the database 1020 via an API 1031. In some embodiments, when a Member (Mobile User 1070) uses a mobile application (Network App on Platform 1,2,3 1071, 1072, 1073), the account of the Member is also linked to the database 1020 via the API (Mobile API 1032) that accomplishes the requests for the mobile versions of the transactional application.

[0039] FIG. 18 is a flowchart illustrating exemplary multi-jurisdiction functionality. In some embodiments, in order to proceed to a transaction between a Partner and a Member, several steps take place. First at step 1100, validation that the consumer is a Member of the Network (if their Member card is activated) takes place. If the consumer is not validated as a Member, then the Points can only be accumulated against the Membership / Card number that does not officially have an « owner ». Conversely, if the consumer is validated as a Member, the Member has the choice at step 1110 to apply the accumulated Points at step 1130 on their account as a mode of payment on the transaction. In the eventuality that the Member is in a jurisdiction 1180 that uses a different currency at steps 1170 than the default currency for the Member as determined at step 1120, the wallet of the Member will only display amounts available to that effect at steps 1150. The Member accumulates also Points at step 1140 on the balance of the transaction paid at Sale step 1160 in cash before applicable taxes as a function of the percentage reward currently offered by the Partner. All of this information is collected by communications from these systems to the database 1020.

[0040] FIG. 19 is a block diagram illustrating an exemplary embodiment for the creation of promo codes. As shown, the Architecture includes three layers: a Presentation Layer 1210, a Business Layer 1220 and a Data Layer 1230. At the Presentation Layer, an MVC architecture is used.. MVC stands for Model 1212, View 1215, Controller 1217. This is a programming technique used in, for example, the development of web applications. The MVC architecture separates the user interface and the back-end. By using an MVC architecture at the Presentation Layer 1210, developers can update the user interface and the back-end without having to modify other components. The use of MVC increases also the flexibility of the application by allowing models 1212 and views 1215 to be reused. The Model 1212 processes raw data and the interaction with the database 1020, and will include such functionality such as inserting records into a database, or selecting records in a specific database. The View 1215 processes the display of data and controls that the user 1200 can use to manipulate the data. The Controller 1217 acts as a mediator by interacting with the Model 1212 and the View 1217, acting as a single point of control from where to manage the View 1215 and Model 1212. At the mid-layer of the architecture, Business Layer 1220, Business Entities 1222 and Business Service 1225 are provided. At the Data Layer 1230, Data Entities 1232 and Entity Framework 1235 are provided. Operationally, a User 1200 issues a request for a Promo Code via the Presentation Layer 1210, for example by interacting with the View 1215 and ultimately the Controller 1217 and the Model 1212. The Controller 1217 sends PromoCodeOrderlnfo to the Business Layer 1220, such as for example by asking the BusinessService 1225 to AddPromoCodeOrder as a function of the PromoCodeOrderlnfo. The Business Layer 1220 then asks the Data Layer 1230 to process a PromoCodeOrder, such as by asking the Entity Framework 1235 to AddPromoCodeOrder as a function of the PromoCodeOrder. The Data Layer 1230 ultimately saves the changes by calling SaveChanges at the Database DB 1020. The Presentation Layer 1210 then concludes the process by sending a response to the User 1200 who originally requested the creation of the Promo Code, via the View 1215. Operationally, the schema of FIG. 19 represents the software architecture which includes three layers for the code (presentation 1210, business 1220, data 1230), a database 1020 (DB), and a user 1200. The User 1200 can order promo codes by using the web site of the program manager. The User 1200 must be a representative of the points program or a user having the required permissions to order the promo codes such as a partner in the points program, identified by his email, and authenticated by his password, and enter the codes in a interface specific for the creation of the promo codes, and confirm the action.

[0041] FIG. 20 is a block diagram illustrating an exemplary embodiment for the acquisition of promo codes. As illustrated, in addition to the elements shown in FIG. 19, a Web API 1219 is shown at the Presentation Layer 1210 for processing promo code acquisition requests and responses from devices, such as from a mobile device 1205. The Web API 1219 is a technique that facilitates the construction of http services that can reach a large swath of clients, including web browsers and mobile devices. Operationally, the client (in mobile device 1205) issues a request for the acquisition of a promo code to the Presentation Layer via the Web API 1219 . The Web API 1219 then processes the request by calling the Busines Layer 1220, which in turn calls the Data Layer 1230, and ultimately the Dabase DB 1020. The Presentation layer 1210 then concludes the process by sending a response to the client who originally requested the acquisition of the Pomo Code via the Web API 129. Operationally, the schema of FIG. 20 represents the software architecture which includes three layers for the code (presentation 1210, business 1220, data 1230), a database 1020 (DB), and a user 1200 or mobile device 1205. The user 1200 can acquire a promo code by using the web site of the program manager. The user 1200 can also acquire a promo code using a mobile application (iOS, Android, for example) such as one branded by the point system using the mobile device 1205. In both cases, the user 1200 must be a member of the program, identified by his email or card number, and authenticated by his password, and enter the code in a interface specific for the acquisition of the promo code, and confirm the action.

[0042] Reference is now made to FIG. 21. FIG. 21 is a block diagram of an exemplary application specific machine environment that can be used with embodiments of the present application. Application Specific Machine 2100 is preferably a two-way wireless or wired communication machine having at least data communication capabilities, as well as other capabilities, such as for example audio, and video capabilities. Application Specific Machine 2100 preferably has the capability to communicate with other computer systems over a Communications Medium 2180. Depending on the exact functionality provided, the machine may be referred to as a smart phone, a data communication machine, client, or server, as examples. [0043] Where Application Specific Machine 2100 is enabled for two-way communication, it will incorporate communication subsystem 2140, including both a receiver 2146 and a transmitter 2144, as well as associated components such as one or more, preferably embedded or internal, antenna elements(not shown) if wireless communications are desired, and a processing module such as a digital signal processor (DSP) 2142. As will be apparent to those skilled in the field of communications, the particular design of the communication subsystem 2140 will be dependent upon the communications medium 2180 in which the machine is intended to operate. For example, Application Specific Machine 2100 may include communication subsystems 2140 designed to operate within the 802.11 network, Bluetooth™ or LTE network, both those networks being examples of communications medium 2180 including location services, such as GPS. Communications subsystems 2140 not only ensures communications over communications medium 2180, but also application specific communications 2147. An application specific processor 2117 may be provided, for example to process application specific data, instructions, and signals, such as for example for GPS, near field, or other application specific functions. Depending on the application, the application specific processor 2117 may be provided by the DSP 2142, by the communications subsystems 2140, or by the processor 2110, instead of by a separate unit.

[0044] Network access requirements will also vary depending upon the type of communications medium 2180. For example, in some networks, Application Specific Machine 2100 is registered on the network using a unique identification number associated with each machine. In other networks, however, network access is associated with a subscriber or user of Application Specific Machine 2100. Some specific Application Specific Machine 2100 therefore require other subsystems 2127 in order to support communications subsystem 2140, and some application specific Application Specific Machine 2100 further require application specific subsystems 2127. Local or non-network communication functions, as well as some functions (if any) such as configuration, may be available, but Application Specific Machine 2100 will be unable to carry out any other functions involving communications over the communications medium 21180 unless it is provisioned. In the case of LTE, a SIM interface is normally provided and is similar to a card-slot into which a SIM card can be inserted and ejected like a persistent memory card, like an SD card. More generally, persistent Memory 2120 can hold many key application specific persistent memory data or instructions 2127, and other instructions 2122 and data structures 2125 such as identification, and subscriber related information. Although not expressly shown in the drawing, such instructions 2122 and data structures 2125 may be arranged in a class hierarchy so as to benefit from re-use whereby some instructions and data are at the class level of the hierarchy, and some instructions and data are at an object instance level of the hierarchy, as would be known to a person of ordinary skill in the art of object oriented programming and design.

[0045] When required network registration or activation procedures have been completed, Application Specific Machine 2100 may send and receive communication signals over the communications medium 2180. Signals received by receiver 2146 through communications medium 2180 may be subject to such common receiver functions as signal amplification, frequency down conversion, filtering, channel selection and the like, analog to digital (A/D) conversion. A D conversion of a received signal allows more complex communication functions such as demodulation and decoding to be performed in the DSP 2142. In a similar manner, signals to be transmitted are processed, including modulation and encoding for example, by DSP 2142 and input to transmitter 2144 for digital to analog conversion, frequency up conversion, filtering, amplification and transmission over the communication medium 2180. DSP 2142 not only processes communication signals, but also provides for receiver and transmitter control. For example, the gains applied to communication signals in receiver 2146 and transmitter 2144 may be adaptively controlled through automatic gain control algorithms implemented in DSP 2144. In the example system shown in FIG. 21, application specifc communications 2147 are also provided. These include communication of information located in either persistent memory 2120 or volatile memory 2130, and in particular application specific PM Data or instructions 2127 and application specific PM Data or instructions 2137.

[0046] Communications medium 2180 may further serve to communicate with multiple systems, including an other machine 2190 and an application specific other machine 2197, such as a server (not shown), GPS satellite (not shown) and other elements (not shown). For example, communications medium 2180 may communicate with both cloud based systems and a web client based systems in order to accommodate various communications with various service levels. Other machine 2190 and Application Specific Other machine 2197 can be provided by another embodiment of Application Specific Machine 2100, wherein the application specific portions are either configured to be specific to the application at the other machine 2190 or the application specific other machine 2197, as would be apparent by a person having ordinary skill in the art to which the other machine 2190 and application specific other machine 2197 pertains.

[0047] Application Specific Machine 2100 preferably includes a processor 2110 which controls the overall operation of the machine. Communication functions, including at least data communications, and where present, application specific communications 2147, are performed through communication subsystem 2140. Processor 2110 also interacts with further machine subsystems such as the machine-human interface 2160 including for example display 2162, digitizer/buttons 2164 (e.g. keyboard that can be provided with display 2162 as a touch screen), speaker 2165, microphone 2166 and Application specific HMI 2167. Processor 2110 also interacts with the machine-machine interface 21150 including for example auxiliary I/O 2152, serial port 2155 (such as a USB port, not shown), and application specific MHI 2157. Processor 2110 also interacts with persistent memory 2120 (such as flash memory), volatile memory (such as random access memory (RAM)) 2130. A short-range communications subsystem (not shown), and any other machine subsystems generally designated as Other subsystems 2170, may be provided, including an application specific subsystem 2127. In some embodiments, an application specific processor 2117 is provided in order to process application specific data or instructions 2127, 2137, to communicate application specific communications 2147, or to make use of application specific subsystems 2127.

[0048] Some of the subsystems shown in FIG. 21 perform communication-related functions, whereas other subsystems may provide application specific or on-machine functions. Notably, some subsystems, such as digitizer/buttons 2164 and display 2162, for example, may be used for both communication-related functions, such as entering a text message for transmission over a communication network, and machine-resident functions such as application specific functions.

[0049] Operating system software used by the processor 2110 is preferably stored in a persistent store such as persistent memory 2120 (for example flash memory), which may instead be a read-only memory (ROM) or similar storage element (not shown). Those skilled in the art will appreciate that the operating system instructions 2132 and data 2135, application specific data or instructions 2137, or parts thereof, may be temporarily loaded into a volatile 2130 memory (such as RAM). Received or transmitted communication signals may also be stored in volatile memory 2130 or persistent memory 2120. Further, one or more unique identifiers (not shown) are also preferably stored in read-only memory, such as persistent memory 2120.

[0050] As shown, persistent memory 2120 can be segregated into different areas for both computer instructions 2122 and application specific PM instructions 2127 as well as program data storage 2125 and application specific PM data 2127. These different storage types indicate that each program can allocate a portion of persistent memory 2120 for their own data storage requirements. Processor 2110 and when present application specific processor 2117, in addition to its operating system functions, preferably enables execution of software applications on the Application Specific Machine 2100. A predetermined set of applications that control basic operations, including at least data communication applications for example, will normally be installed on Application Specific Machine 2100 during manufacturing. A preferred software application may be a specific application embodying aspects of the present application. Naturally, one or more memory stores would be available on the Application Specific Machine 2100 to facilitate storage of application specific data items. Such specific application would preferably have the ability to send and receive data items, via the communications medium 2180. In a preferred embodiment, the application specific data items are seamlessly integrated, synchronized and updated, via the communications medium 2180, with the machine 2110 user's corresponding data items stored or associated with an other machine 2190 or an application specific other machine 2197. Further applications may also be loaded onto the Application Specific Machine 2100 through the communications subsystems 2140, the machine-machine interface 2150, or any other suitable subsystem 2170, and installed by a user in the volatile memory 2130 or preferably in the persistent memory 2120 for execution by the processor 2110. Such flexibility in application installation increases the functionality of the machine and may provide enhanced on-machine functions, communication-related functions, or both. For example, secure communication applications may enable electronic commerce functions and other such financial transactions to be performed using the Application Specific Machine 2100.

[0051] In a data communication mode, a received signal such as a text message or web page download will be processed by the communication subsystem 2140 and input to the processor 2110, which preferably further processes the received signal for output to the machine-human interface 2160, or alternatively to a machine -machine interface 2150. A user of Application Specific Machine 2100 may also compose data items such as messages for example, using the machine-human interface 21160, which preferably includes a digitizer/buttons 2164 that may be provided as on a touch screen, in conjunction with the display 2162 and possibly a machine-machine interface 2150. Such composed data items may then be transmitted over a communication network through the communication subsystem 2110. Although not expressly show, a camera can be used as both a machine-machine interface 2150 by capturing coded images such as QR codes and barcodes, or reading and recognizing images by machine vision, as well as a human-machine interface 2160 for capturing a picture of a scene or a user.

[0052] For audio/video communications, overall operation of Application Specific Machine 2100 is similar, except that received signals would preferably be output to a speaker 2134 and display 2162, and signals for transmission would be generated by a microphone 2136 and camera (not shown). Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, may also be implemented on Application Specific Machine 2100. Although voice or audio signal output is preferably accomplished primarily through the speaker 2165, display 2162 and applications specific MHI 2167 may also be used to provide other related information.

[0053] Serial port 2155 in FIG. 21 would normally be implemented in a smart phone-type machine as a USB port for which communication or charging functionality with a user's desktop computer, car, or charger (not shown), may be desirable. Such a port 2155 would enable a user to set preferences through an external machine or software application and would extend the capabilities of Application Specific Machine 2100 by providing for information or software downloads to Application Specific Machine 2100 other than through a communications medium 2180. The alternate path may for example be used to load an encryption key onto the machine through a direct and thus reliable and trusted connection to thereby enable secure machine communication.

[0054] Communications subsystems 2140, may include a short-range communications subsystem (not shown), as a further optional component which may provide for communication between Application Specific Machine 2100 and different systems or machines, which need not necessarily be similar machines. For example, the other subsystems 2170 may include a low energy, near field, or other short-range associated circuits and components or a Bluetooth™ communication module to provide for communication with similarly enabled systems and machines.

[0055] The exemplary machine of FIG. 21 is meant to be illustrative and other machines with more or fewer features than the above could equally be used for the present application. For example, one or all of the components of FIG. 21 can be implemented using virtualization whereby a virtual Application Specific Machine 2100, Communications medium 2180, Other machine 2190 or Application Specific Other Machine 2197 is provided by a virtual machine. Software executed on these virtual machines is separated from the underlying hardware resources. The host machine is the actual machine on which the virtualization takes place, and the guest machine is the virtual machine. The terms host and guest differentiate between software that runs on the physical machine versus the virtual machine, respectively. The virtualization can be full virtualization wherein the instructions of the guest or virtual machine execute unmodified on the host or physical machine, partial virtualization wherein the virtual machine operates on shared hardware resources in an isolated manner, to hardware -assisted virtualization whereby hardware resources on the host machine are provided to optimize the performance of the virtual machine. Although not expressly shown in the drawing, a hypervisor program can be used to provide firmware for the guest or virtual machine on the host or physical machine. It will be thus apparent to a person having ordinary skill in the art that components of FIG. 21 can be implemented in either hardware or software, depending on the specific application. For example, while testing and developing the Application Specific Machine 2100 may be provided entirely using an emulator for the machine, for example a smartphone emulator running Android™ or iOS™. When deployed, real smartphones would be used.

[0056] Each component in FIG. 21 can be implemented using any one of a number of cloud computing providers such as Microsoft's Azure™, Amazon's Web Service™, Google's Cloud Computing, or an OpenStack based provider, by way of example only. Thus, as will be apparent to a person having ordinary skill in the relevant field of art, depending on whether the environment in which operate the components of FIG. 21, the Communications medium 2180 can be the Internet, an IP based medium such as a virtual, wired, or wireless network, an interconnect back plane on a host machine serving as a back bone between virtual machines and/or other real machines, or a combination thereof. For example, in the case of the communications subsystems 2140, the Transmitter 2144, Receiver 2146 and DSP 2142 may be unnecessary if the application specific machine is provided as a virtual machine. Likewise, when the application is a server provided as a virtual machine, the machine-human interface 2160 and machine-machine interface 2150 may be provided by re-use of the resources of the corresponding host machine, if needed at all.

[0057] Having described the environment in which the specific techniques of the present application can operate, application specific aspects will be further described by way of example only.

[0058] The embodiments described herein are examples of structures, systems or methods having elements corresponding to elements of the techniques of this application. This written description may enable those skilled in the art to make and use embodiments having alternative elements that likewise correspond to the elements of the techniques of this application. The intended scope of the techniques of this application thus includes other structures, systems or methods that do not differ from the techniques of this application as described herein, and further includes other structures, systems or methods with insubstantial differences from the techniques of this application as described herein.

[0059] It is envisaged that components illustrated in FIGs. 1-20 may be embodied in one or more of the Application Specific Machine, Other Machine, Application Specific Other Machine and Communications Medium of FIG. 21. Furthermore, it is envisaged that all application specific processing of FIGs. 1-20 may be implemented using one or more of the Application Specific Communications, Application Specific Subsystems, Application Specific PM Data or Instructions, Application Specific Processor, Application Specific MMI, Application Specific MHI and Application Specific VM Data or Instructions illustrated in FIG. 21.

[0060] FIG. 22 illustrates the traditional loyalty program paradox whereby merchants have to choose either a coalition program or a home program. On one hand, coalition programs, such as AirMiles® and Aeroplan®, allow many merchants to come together under a common platform. The inconvenience is that the points/rewards can be spent 100% at another merchant than the one that provided the points/rewards. On the other hand, home programs (e.g. white label for a merchant or a brand such as Optimim™, Metro™, or SAQ™) do not allow a network, so 100% of the points/rewards (under the home program) return to the merchant that emitted the points/rewards. This results in the loyalty program paradox 1300. [0061] FIG. 23 illustrates one effect of embodiments of the present application, the hybrid loyalty program solution to the loyalty program paradox. The paradox 1300 is resolved by the embodiments of the present application which provide a hybrid program 1400 which allows each merchant to get the advantageous access to the network of the coalition program with the advantage of repeat business of the home program.

[0062] FIG. 24 illustrates an exemplary coupon used by partners to provide prepaid cards to members. It is envisaged that embodiments of the present application can be used to purchase points and to reload a gift card. The points can be exclusive points, which are exclusive to a specific partner, or simply network points that are valid at all partners in the network. These points can be added directly to the account of a network member or be sent as a gift to anyone that has a valid email address. This card or coupon 1500 contains a barcode 1510 generated by the system. Illustrated in FIG. 24 is an example of a prepaid card. Clear instructions 1520 are provided on the coupon to the cashier (see illustration). The coupon 1500 may be used to affix a plastic card 1530 over next to the barcode, in some embodiments.

[0063] FIG. 25 illustrates a flowchart for the purchase of points by a user. The user access the network platform, regardless if they are a member or not, and goes to the network point purchase page at step 1610. The user then selects an amount for a partner of their choice at step 1620. It is possible to order points up to a maximum number of partners at one time on the same order, for example 5 partners, as illustrated at step 1630, and pays for the points at step 1640. The user then decides at step 1650 if the points are for themselves (sent by email at step 1655 or added directly to their account at step 1657) or to send by email to another person at step 1650. In an alternative embodiment, instead of step 1640, the user then proceeds to payment (via a payment service from a payment provider) after step 1650 and not before step 1650. Automated emails are sent to confirm the order and to advise the recipient that they have received points at steps 1660 and 1665. Management fees, for example 1,50$ + 0,50$ by card ordered (Patner) are applicable on each transaction. The recipient must follow a link to respond to a secret question selected by the purchaser in order to claim their points at step 1680. The recipient can then add the points to their member account at step 1670 or receive them by email in the form of a prepaid card. If the points are not claimed within a deadline at step 1680, such as for example 30 days, they will be returned to the purchaser in the form of network points that are valid in all partners of the network at step 1690. The purchaser will also have to follow the above noted procedure in order to claim the returned points. A predetermined number of reminder emails, such as for example three reminder emails, will be sent during the procedure to remind the purchaser and the recipient that the points are unclaimed, if applicable. It is also possible to reload a gift card (plastic) directly on the platform if this card had already contained a balance, thus had been activated at a partner. [0064] FIG. 26 illustrates a flowchart for the transfer of points to a gift card. At step 1710 a user enters the gift card number. At step 1720, it is determined if multiple cards are available, and if so determined step 1730 ensues followed by step 1740, or else step 1740 ensues . At step 1730, the correct gift card is chosen. At step 1740 a from is filled in. At step 1750, the order is paid for. At step 1760, the points are transferred to the gift card.

[0065] FIG. 27 illustrates a flowchart for the purchase of prepaid points. At step 1810, a form is filled in. At step 1820, the order is paid for. At step 1830 it is determined if this is a gift, and if so determined step 1840 ensues followed by step 1850 and step 1860, or else step 1860 ensues. At step 1840, the points are delivered. At step 1850, the points are claimed. At step 1860 it is determined of the claimant has an existing account and if so determined, step 1870 ensues or else steps 1880 and 1890 ensue. At step 1870, the points are transferred to the account. At step 1880 prepaid cards are generated. At step 190 prepaid cards are delivered.

[0066] FIG. 28 illustrates the architecture of a sub-system for purchase and management of prepaid loyalty points. This architecture makes it possible to separate the various components from a computer system in three layers: the presentation layer 1910; the business layer 1920; and the data (access) layer 1930. The presentation layer 1910 is the visible and interactive part for the users. It can be in a graphical form or textual, and can be exploited by a web browser, a mobile application and several other types of terminals. This layer is made up of the browser who allows the users to reach the Web application. The business layer 1920 constitutes the processing necessary on information in order to make them exploitable by each user of the system. It is the functional part of the solution which describes the operations on the data according to the requests of the users starting from the presentation layer. In our case, this layer is hosted on the cloud application platform, and contains the following components: the web services of the payment gateway which processes the transfers of money from the payment cards towards the bank; and a web application which constitutes a management system for the consumer loyalty program "Network". The data (access) layer 1930 is where the application data is preserved. It makes it possible to store a significant amount of data in a structured way. For this part, one can use file systems, systems of databases, etc the common point between all these systems is the possibility of sharing of the data which they contain via a network. In our case, this layer is made up of the database SQL Server which contains all the data necessary to operate the system.

[0067] FIG. 29 illustrates a use case diagram for the sub-system of FIG. 28. The development of use case diagrams represents the first stage of analysis suggested by UML (Unified Modeling Language). This stage makes it possible to collect, analyze, organize the needs, and to count the major features of a system, which satisfy the user expectations. A use case diagram captures the behavior of a system, such as an external user sees it. It divides the functionality of the system into coherent units, the use cases having a direction for the actors. It is based on the concept of actors (external entities which interact with the system, e.g. a person) and use cases (they describe the interactions between the actor and the application, making it possible for the actor to achieve a goal by using the system).

[0068] We now identify the actors intervening in the platform then we work out the use case diagram of our system.

[0069] The following table is a description of the use case for the acf'To buy points":

Description of the sequences

Nominal scenario

1. The user reaches the web interface for purchase of points.

2. The platform presents a form to him to be filled which contains a cart of points and all the necessary information for the purchase and the routing of the points to its recipient.

3. The user validates the form.

4. The system presents an invoice to be paid.

5. The user agrees to pay while pressing on the button to pay.

6. The system redirects the user to the payment gateway in order to pay the invoice.

7. The user enters his payment information and validates the payment.

8. The gateway returns the user to the website.

9. The system displays a message confirming the purchase and sends confirmation emails.

[0070] The following table is a description of the use case for the act "To claim points":

Description of the sequences

Nominal scenario

1. The user follows the link which is in the email in order to reach the page for claiming of points.

2. The system displays a form for the claiming of points.

3. The user fills the form and validates it.

4. The system validates the form and displays a message of success. [0071] The following table is a description of the use case "To consult the history of purchase":

[0072] The following table is a description of the use case "To consult the history of the transactions":

[0073] The following table is a description of the use case "To consult the money balance":

Description of the sequences

Nominal scenario

1. The partner reaches the interface "Instrument panel" dedicated to the partner.

2. The system displays the money balance available.

[0074] The following table is a description of the use case "To consult the statistics":

Description of the sequences

Nominal scenario

1. The administrator or the partner reaches the interface "Statistics" through small "the Reports" of the navigation bar of the website.

2. The system displays the statistics available.

[0075] The following table is a description of the use case "To consult the purchase of points"

[0077] FIG. 30 illustrates a deployment diagram for the subs-system of FIG. 28. A deployment diagram is a UML diagram which provides a high level chart of the organization of the application, and helps to identify the relationships of generalization and dependence between packages. While basing itself on the architecture of the solution, we disclose the deployment diagram illustrated by FIG. 30. This deployment diagram highlights the use of the model of design "Facade" which consists in facilitating the access to several features by encapsulating them. [0078] FIG. 31 illustrates a class diagram for an "Information" package. As shown, the class diagrams of a packages which illustrate the "Information" package of the sub-system. In a concern for clarity and legibility, the methods called "getters" and "setters" of the various attributes of the classes were omitted from class diagrams. Package "Information" contains the classes which represent the entities of the database as well as other entities necessary to the good performance of the system, used mainly by the services to turn over results to the presentation layer. FIG. 31 illustrates well the relations between the entities of the database.

[0079] FIG. 32 illustrates a class diagram for an "Invoice" package. Package "Invoice" is a sub-package of "Information" and contains the classes which are specific to the invoicing. We can identify these various classes in FIG. 32 and notice that the system deals with the taxes and the commissions on the dealers of the products of the company.

[0080] FIG. 33 illustrates a class diagram for a "Payment GW" package. Package "Payment GW" contains the classes specific to the payment gateway, as shown in the figure.

[0081] FIG. 34 illustrates a class diagram for a "Service" package. Package "Service" contains the classes which allow the business layer to reach the data layer. FIG. 34 shows the various classes and the principal functions used by the sub-system.

[0082] FIG. 35 illustrates a class diagram for a "Transactions" package. Package "Transactions", which is a sub- package of "Service", contains the classes specific to the executions of the transactions and their insertion and modification in the database. We can see in FIG. 35 various types of transactions which interest us in our sub-system with their various operations.

[0083] FIG. 36 illustrates a class diagram for a "Facade" package. Package "Facade" contains the classes which facilitate the access to the classes of package "Service". For example, upon the addition of a purchase of points, one must access information of the members, create a temporary invoice, which requires an access to several services. All that is summarized with only one function by using the model of design "Facade". For our sub-system, FIG. 36 illustrates the classes of package "Facade" used.

[0084] FIG. 37 illustrates a user interface for the purchase of points and the various options offered to clients. We can see that the interface is very simple and navigation between several pages does not require to finalize the purchase. A small explanation is displayed on the screen in order to clarify the procedure and to indicate the expenses. We can also see the cart of points and the button "To add" which makes it possible to add a balance of points. [0085] FIG. 38 illustrates a simplified version of the user interface of FIG. 37 when the user is authenticated. The user interface of FIG. 37 can be simpler if a member is authenticated, as we can see in FIG. 38. The connected member chooses to buy points for himself and to transfer them directly on his member account.

[0086] FIG. 39 illustrates a user interface to provide members the possibility of consulting a report of transactions carried out with their points.

[0087] FIG. 40 illustrates a user interface to provide members the possibility of consulting the point purchase history.

[0088] FIG. 41 illustrates a user interface for a "My Wallet" homepage of a member of the Network program. Thanks to this interface, a member can consult his various balances in hand. In the case of a purchase of points, the member can check that its balance was indeed credited with the bought amount.

[0089] FIG. 42 illustrates a message sent to the recipient of points to let them claim their points. We can see that the message contains the link which leads us to the interface of the platform which makes it possible for the recipient to claim his due.

[0090] FIG. 43 illustrates a user interface which enables a recipient to claim points. This interface which one can see on FIG. 43 also lists the choices which are available to user. We can also notice that the user must answer a secret question, which confirms the identity of the recipient and protects his points. Our sub-system proposes to the user two methods to claim the points. The first method consists in transferring the money towards a member account and the second is to receive a prepaid card by email.

[0091] FIG. 44 illustrates an example of a prepaid card which a user can print and to present at a merchant.

[0092] FIG. 45 illustrates a transaction report user interface. The sub-system realized makes it possible for a partner to consult his transactions on prepaid cards and points transferred towards the accounts from members through the interface "transaction report". FIG. 45 shows us this interface which facilitates the search and consultation of the transactions thanks to several search filters.

[0093] FIG. 46 illustrates a dashboard user interface. A partner can also know the sum of money which it sold and that thanks to the dashboard interface for partners.

[0094] The above-described embodiments of the present application are intended to be examples only. Those of skill in the art may effect alterations, modifications and variations to the particular embodiments without departing from the scope of the invention, which is set forth in the claims.