EP2074569A2 - Procédé et systèmes de paiement - Google Patents

Procédé et systèmes de paiement

Info

Publication number
EP2074569A2
EP2074569A2 EP07848326A EP07848326A EP2074569A2 EP 2074569 A2 EP2074569 A2 EP 2074569A2 EP 07848326 A EP07848326 A EP 07848326A EP 07848326 A EP07848326 A EP 07848326A EP 2074569 A2 EP2074569 A2 EP 2074569A2
Authority
EP
European Patent Office
Prior art keywords
payment
imputation
financing
data
purchase
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.)
Ceased
Application number
EP07848326A
Other languages
German (de)
English (en)
Inventor
Jean-Yves Rossi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Individual
Original Assignee
Individual
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Individual filed Critical Individual
Publication of EP2074569A2 publication Critical patent/EP2074569A2/fr
Ceased legal-status Critical Current

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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • 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
    • G06Q30/0215—Including financial accounts

Definitions

  • the New Payment Process applies to the field of payments, the settlement and clearing system, electronic banking, management of loyalty points, ...
  • the invention relates to the actual process of payment
  • the New Payment Process (NP2) is a radical change in the approach to payment processes.
  • the invention makes it possible to proceed line by line, or article by article, or even share of price by share of price, controls, imputations, payments and compensations, to simultaneously produce a basic report of complete operation object of treatment as such, which constitutes a new process, original compared to the state of the art in that it bases a different and complete system of monetics, composed of a set of tools of implementation, supports equipment, distribution schemes, functional processes and "NP2" services, subject of this deposit, allowing the provision of new payment services.
  • NP2 New Payment Process
  • the New Payment Process can be implemented through a system, including servers, local payment and purchase terminals, payment media (cards, telephones, online sales systems,. ..), implementing the NP2 processes and programs, themselves organized within processing chains intended to carry out purchase and payment transactions, ensuring controls, imputations and distribution among various. sources of financing and production of account release data, article by article, within the same payment transaction.
  • NP2 payment supports have the particularity of being able to support several sources of financing or payment and to integrate data defining a set of rules of imputations and controls, adapted according to the particular needs of the domain, the carriers, the financers or merchants.
  • the NP2 processing chains are designed to convey operation reports, by elementary operation, integrating data relating to the payment but also to the object or service paid and data relating to the controls and imputation mechanisms. These reports are in themselves object of treatments which constitute a specific element of the invention.
  • This NP2 finds an immediate and powerful utility in that it aims at creating processing chains capable of processing a set of data not limited to a price and that it opens the new possibility to exploit a set of features new, made available by current and emerging technologies, capable of instant and powerful treatments on increasingly varied, safe and light media but still lack practical applications in the field of payment in fact not, in fact, the existing regulation or technology, but because of the design of payment systems and processes, all of which go through the obligatory step of totaling the amount subject to cashing.
  • the final process remains invariable: the deed of payment is reduced to the final balance of a total established in "the addition”, “the bill”, the bill, ... final step where the case is made, the case the global controls and then the imputation of the total flow into a single account.
  • Card issuers offer "accounts" with which several cards are associated, issued either on behalf of different holders, or marked as “additional” for the same cardholder to enable him, by the choice of the card used at the time of payment of distinguish between types of expenses and budgets. Still other cards are used to support the expenses that will be debited on an associated consumer credit account.
  • the checks generally concern the reliability of the payment medium before the payment requested is accepted in full.
  • the controls will generally relate to
  • Certain items or services can not be paid for by the card and therefore can not be integrated into the "bill" (eg some gas cards may or may not allow the purchase of treats or car accessories). gas station); the controls put in place prevent payment with this card.
  • certain cards for example cards issued by major retailers
  • offer the credit union the choice between direct payment or charging to a consumer credit company for retail, in general, their subsidiary consumer credit.
  • the customer can with some banks distribute by a banking management the clearance or the spreading of its monthly debt by call of facilities of cash or by an associated account of consumer credit.
  • a debit or credit card is also provided.
  • the function is always determined by the choice of the terminal used (ATM or ATM, payment terminal, Monéo or Navigo terminal, etc.); the payment medium is passive in this choice; it carries juxtaposed programs relating to different operations.
  • the regulation sometimes imposes constraints which make natural this dissociation between means of payment (e.g. the regulation specific to the consumer credit makes natural its management by "factories" dedicated in the banking world).
  • the Single European Payment Area should cause a significant evolution of the domain over the period 2007 to 2012. It must open with new technical rules a window of intervention for new providers.
  • the retail industry is also very interested in offering its customers more comprehensive payment services than the only credit card issued by their consumer credit subsidiary.
  • Various initiatives in this area have been taken in recent years, both by consumer goods distribution companies (mail order companies, supermarkets and hypermarkets, etc.) and by distribution companies in specialized consumer goods and services (fuel payment cards, car park).
  • the European Central Bank (ECB) is at the origin of the creation of a status of issuers and broadcasters of electronic money, homogeneous in the countries of the euro zone and, with the help of a Community directive, in the country of the European Union. It also works to create common objectives and security standards for e-money systems.
  • the NP2 changes the payment from a global transaction concentrating controls and associated information to a point that is the payment of a balance (thus confusing by preventing their exploitation the information associated with each item purchased) to a complex and controlled process organized by elementary imputation operation for each item taken separately.
  • NP2 organizes payments by processing related information
  • the invention relates to a method of payment by a carrier to a merchant through a means of payment, characterized in that it is proceeded by successive charges, for each product, good or service presented for purchase, an imputation operating between several sources of financing, and consisting of a debit on one of the sources of financing or a transfer from one of these sources of financing; and in that each imputation is read data stored in the payment means and / or databases of a payment server, these data being accessible by connection to a central system or on a local replication, said data being used by the payment server to select and compare imputation and control rules, defined for each source of financing, by the holder of the means of payment or by the financier to data depending on the characteristics: of the property , the product or service presented for purchase, the conditions of the purchase, including for example the date, the physical checks carried out at the time of purchase, the options chosen by the buyer, as well as data from a database of merchants and categories of products, goods or services.
  • the imputation can be made on a
  • a report is issued associating with the imputation concerned the recording of the information elements required for the control of this imputation.
  • the application of the control and imputation rules serves to check the regularity and the lawfulness of each imputation with regard to the rules chosen by the bearer and / or the merchant and / or the financier.
  • the management of the data by elementary payment imputation leads for each double production charge, on the one hand, to a compensation report issued for the payment of this charge and, on the other hand, to the production. and then the management of a basic settlement transaction report, incorporating the information elements resulting from the payment and the checks carried out during the imputation, in particular with a view to its subsequent exploitation for purposes of control, analysis or statistical exploitation
  • the management of the operation reports is organized in such a way that each of the recipients can receive information from these reports only in the proportion of rights known to each recipient.
  • loyalty points are managed on a dedicated source of financing among those integrated with the payment method, the loyalty points being accumulated as and when payments are made, in accordance with the attribution and control rules that are characteristic of the customer. acquisition of these loyalty points, followed by reports on the evolution of this source of funding.
  • the loyalty points accumulated on the dedicated funding source can be used directly by drawing on this source of financing, in accordance with the rules of imputation and control which govern their use.
  • an imputation is carried out according to data representing a choice made by the holder, in particular the choice of the financing source to be imputed, these data being either previously stored or entered at the time of payment.
  • an imputation is carried out according to data representing checks carried out by the merchant, these data being either previously stored or entered at the time of payment.
  • the invention also relates to a system for payment of goods, products or services, by a holder, to a merchant making it possible to proceed to the payment by successive charges, for each product, good or service presented for purchase, an imputation operating between a plurality of sources of financing, and consisting of a debit on one of the sources of financing or a transfer from one of these sources of financing, the system comprising: a payment medium, specific to the bearer; a payment terminal, able to read and authenticate the payment medium and to transmit the data it contains to a payment server; a purchasing terminal, able to identify the goods, products and services purchased, and to transmit these data to a payment server a payment server, connected to the purchase terminal and the payment terminal to receive data, realizing the successive imputation operations during the payment according to the data stored in databases, these bases being accessible by connection to a central system or on a local replication, said data being used by the payment server to select and then compare imputation and control rules, defined, for each source of financing, by the bearer of the payment medium
  • the payment server comprises means for operating each charge on a fraction of the price of the product, good or service presented at the time of purchase, each fraction of price being chargeable to a different source of financing.
  • the payment server comprises means for issuing, for each imputation, a report associating with the imputation concerned the recording of the information elements required for the control of this imputation.
  • the application of the control and imputation rules serves to check the regularity and the lawfulness of each imputation with regard to the rules chosen by the bearer and / or the funder and / or the merchant.
  • the management of the elementary payment charge data enables the payment server to produce, for each charge, a clearing report issued for the payment of this charge and a report.
  • this report incorporating the information elements resulting from the payment and the checks carried out during the allocation, in particular with a view to its subsequent exploitation for purposes of control, analysis or statistical exploitation
  • the payment server comprises means for managing the operation reports, these means being such that each of the recipients can receive information from these reports only in the proportion of rights to be known that are specific to each recipient. .
  • loyalty points are managed on a dedicated source of financing among those integrated in the payment medium, the loyalty points being accumulated as and when payments, in accordance with the rules of imputation and control characteristics of the acquisition of these loyalty points, followed by reports on the evolution of this source of funding.
  • the loyalty points accumulated on the dedicated financing source can be used directly by drawing on this source of financing, in accordance with the rules of imputation and control which govern their use.
  • an imputation is carried out according to data representing a choice made by the holder, in particular the choice of the financing source to be imputed, these data being either previously stored or entered at the time of payment, on the payment medium. or the payment terminal.
  • an imputation is carried out according to data representing checks carried out by the merchant, these data being either previously stored or entered during the payment on the purchase terminal.
  • the system comprises a management interface dedicated to the bearer, comprising means enabling the bearer to create and / or modify the applicable settlement and control rules and / or funding sources.
  • the system includes a merchant management interface, comprising means for the merchant to create and / or modify the applicable imputation and control rules and / or categories of goods, products or services.
  • the system comprises a financing management interface, comprising means enabling the financier of one of the funding sources to create and / or modify the applicable imputation and control rules.
  • the invention also relates to a remote payment system, by a carrier, goods, products or services to a merchant and to proceed to the payment by successive charges, for each product, good or service presented to purchase, an imputation operating between several sources of financing, and consisting of a debit on one of the sources of financing or a transfer from one of these sources of financing, the system comprising: a means of payment, specific to the holder, which can combine several sources of financing; a purchasing server, able to identify the goods, products and services presented for purchase by the bearer, a payment server, in connection with the purchasing server, performing the successive imputation operations during the payment, in data provided by the purchase server and data stored in databases, these databases being accessible by connection to a central system or on a local replication, said data being used by the payment server to select and then compare allocation and control rules, defined for each source of financing, by the holder of the means of payment or by the financier, of data according to the characteristics: of the good, the product or the service presented at the purchase of the conditions of the purchase, including for
  • the payment server comprises means for operating each charge on a fraction of the price of the product, good or service presented at the time of purchase, each fraction of price being chargeable to a different source of financing.
  • the payment server comprises means for issuing, for each imputation, a report associating with the imputation concerned the recording of the information elements required for the control of the imputation.
  • the application of the control and imputation rules serves to check the regularity and the lawfulness of each imputation with regard to the rules chosen by the bearer and / or the merchant and / or the financier.
  • the management of the data by payment charges enables the payment server to produce, for each account assignment, a compensation report issued for the payment of this charge, and a report of the payment.
  • 'elementary settlement transaction means the report incorporating the information elements arising from the payment and the checks carried out during the allocation, in particular with a view to its subsequent exploitation for purposes of control, analysis or statistical exploitation.
  • the payment server comprises means for managing the operation reports, these means being such that each of the recipients can receive information from these reports only in the proportion of rights to be known that are specific to each recipient. .
  • loyalty points are managed on a dedicated source of financing among those integrated in the payment method, the loyalty points being accumulated as and when payments are made, in accordance with the attribution and control rules that are characteristic of the customer. acquisition of these loyalty points, followed by reports on the evolution of this source of funding.
  • the loyalty points accumulated on the dedicated financing source can be used directly by drawing on this source of financing, in accordance with the rules of imputation and control which govern their use.
  • an imputation is performed according to data representing a choice made by the wearer, in particular the choice of the. source, funding to be charged, these data being either previously stored in the purchase server, entered at the time of payment and transmitted to the purchase server.
  • an imputation is carried out according to data representing checks carried out by the merchant, these data being previously stored in the purchasing server.
  • the system comprises a management interface dedicated to the bearer, comprising means enabling the bearer to create and / or modify the applicable imputation and control rules.
  • the system includes a merchant management interface, comprising means for the merchant to create and / or modify the applicable imputation and control rules.
  • the system includes a financing management interface, comprising means enabling the financier of one of the financing sources to create and / or modify the applicable imputation and control rules.
  • FIG. 1 is a diagram of the system according to the invention comprising a purchase terminal
  • Figure 2 is a diagram of the system according to the invention comprising a purchase server
  • Figures 3 to 6 describe the different stages of payment during a purchase
  • Figure 7 describes the different stages of clearing and restoring accounts following a payment.
  • the set of hardware and logical elements of implementation of the invention has the common feature of organizing all processing elementary payment imputation operation (OIPE), to perform for each of these operations controls based on the purchaser, the mode of financing, the object or the service purchased and then produce a report of specific operations for each OIPE.
  • OIPE processing elementary payment imputation operation
  • the OIPE results from the processing of multiple data concerning the bearer and the sources of financing available to him, the characteristics of the purchase and the rules of imputation and control.
  • the NP2 system By initially designing data on various sources of funding, purchased objects or services, and imputation and control rules, the NP2 system typically includes specific and specific software tools and processing chains.
  • the invention includes the various specific management tools necessary for the administration of the NP2 system and intended to fully exploit the new possibilities provided by this method.
  • This support will most often be a smart card, or a processor included in a mobile phone, a PDA, or even an ad hoc support, ...
  • NP2 can be carried out on any existing or future payment medium, whose processing software capabilities integrate with the construction or will have been completed by the implementation of NP2 programs and software packages. It uses state-of-the-art schemes and circuits for network and network tools.
  • the purchase corresponds to an "article of an addition", it can be related to a property, a service, an operation fee. It may concern only a single share of the price of the same object or service charged to a single source of financing. Its description can be reduced to the strict minimum: a quantity and a unit price; it can be enriched, according to the needs of the field of application, of various descriptive levels.
  • the payment may be charged article by article or even by share of the price of an item on different sources of payment.
  • NP2 allows differentiated item-by-article imputation as well as control of imputation or load balancing between sources of funding or those called “financers" in the rest of this document: it is first the individuals themselves who in this process can impute their different purchases either to their main account normally debited on their current account, or on prepaid budgets (by themselves or relatives, friends, companies, works, donors), or on drawing rights open to them personally or professionally (individuals, credit institutions, public administrations, etc.); secondly, banks and credit institutions, whether general or specialized, may be able to finance certain expenses; Finally, there are companies or organizations wishing to open and control drawing rights to shooters, beneficiaries or principals.
  • the last scheme allows to create a payment service delivery offer, on the initiative of companies issuing means of payment media (mobile phones, brand or co-branded cards, RFID media, or any new payment vector ), who put themselves in a firing position in the NP2 process, with a counterparty: for example a prepaid account holder position, an electronic money issuer status and / or a direct debit.
  • payment media mobile phones, brand or co-branded cards, RFID media, or any new payment vector
  • the allocation to a source of financing may consist of a debit on an account, from bearer or a financier or a transfer (or transfer) from an account or that of a financier.
  • the NP2 device provides for the implementation of checks to the degree of finesse necessary, able to meet the expectations of consumers, traders and distributors, producers and those referred to here as "financiers” (individuals, credit institutions, public administrations, etc.). These controls can be relative.
  • NP2 results in the production of transaction reports, by OIPE, OPE and by settlement, and allows to produce any other desired report by selection and aggregation of the data contained in the OIPE reports.
  • transaction reports describing the global purchase (settlement report, description of the settlement transaction) or the purchase of an item (OPE report) or the item allocation (report OIPE), normally include the report of control operations performed and their results.
  • the NP2 system that is the subject of this repository will be described from the implementation tools, hardware and software, and processing chains of the associated information system.
  • the material tools for implementing the NP2 mechanism are:
  • NP2 Account Reporting and Reporting Server The NP2 processing chains operate:
  • the software developed for this purpose will be kept in compliance with the rules imposed on electronic money (security, transparency and confidentiality, anti-money laundering, etc.) as they result in particular from the rules and criteria laid down by the banks.
  • central banks first and foremost the European Central Bank
  • international settlement systems In particular, they will be developed with reference to the security models and objectives resulting from the COMMON CRITERIA METHODOLOGY set up in May 2003 by the European Central Bank (ECB).
  • the NP2 is equally applicable to any payment medium since it, borrowed from the existing art, will, by construction or implementation, integrated NP2 process elements.
  • the support can be constituted by a magnetic or smart card, a mobile phone, an RFID support or any other existing or future support used for payment applications, as long as it is resistant to copying or falsification, and that it constitutes with the reading terminal a set of suitable and secure identification and authentication systems and an archiving capacity (for the maintenance of the settlement account and the memorization of the transaction reports) and calculation (for checks and imputations) sufficient.
  • the payment terminal NP2 is used for reading, authentication, validation of the payment medium NP2; in connection with this medium and with the purchase terminal or the purchase server NP2, and with the payment server NP2, it constitutes the whole realizing the payment according to the payment payment elementary process.
  • the NP2 is equally applicable to any payment terminal since it, borrowed from the existing art, will have integrated, by construction or implementation, the elements of the NP2 process.
  • some NP2 payment terminals may be installed an interactive screen (touch screen type) which can be substituted for the use of the interface of a smart mobile support (PDA, Smartphone); this interface will allow, for certain domains and according to the options programmed for the implementation of the imputation rules, the interrogation of the carrier who will then be able to direct his various purchases to different sources of funding.
  • touch screen type touch screen type
  • PDA smart mobile support
  • the payment terminal NP2 borrowed from the existing art must be able to cooperate with all NP2 payment media usable in the field of application.
  • the functional assembly formed once the NP2 support connected to the payment terminal NP2 must meet all the security requirements applicable to the digital domain.
  • Payment terminal and NP2 support must constitute a set with suitable and secure identification and authentication systems and an archiving capacity (for the maintenance of settlement accounts and the memorization of transaction reports) and calculation (for sufficient checks and imputations).
  • the NP2 purchase terminal (see Figure 1) is used to read and identify the object of purchase and, after transmission of these data to the NP2 payment terminal, to the carrying out of the controls and to the application of the posting rules by the payment server NP2.
  • the NP2 purchase terminal is a sales terminal as it exists at the outlet of the sales area (typically the cash register of a supermarket or a shop or a service station, etc.) with a mechanism for automatic or manual entry of the object or service purchased (barcode reader, RFID reader 5 automatic cash registers dedicated to a range of products, with preprogrammed buttons or touch screen, etc.) completed, by construction or by implementation of NP2 functions serving:
  • the purchasing terminal may include, depending on the field of application, a vendor interface allowing it to specify different specific parameters article by article, which may depend on the rules of imputations or support, ...
  • this interface can also be used to interrogate the carrier, in particular on his imputation choices, either directly or via the interface of the payment medium NP2 or the payment terminal NP2.
  • the NP2 is equally applicable to any purchasing terminal since it, borrowed from the existing art, will have integrated, by construction or implementation, the elements of the NP2 process.
  • the NP2 purchase terminal borrowed from the existing art will have to be able to cooperate with all the NP2 tools used in the field of application.
  • the functional unit formed by the purchase terminal once connected to the payment terminal NP2 and, via this terminal with the payment support NP2, must satisfy all the security requirements applicable to the electronic payment domain.
  • Purchase terminal, payment terminal and NP2 support must constitute a set of safe and appropriate identification and authentication systems and capacity archiving (for the maintenance of the settlement account and the memorization of the transaction reports) and calculation (for checks and imputations) sufficient.
  • the NP2 purchase server (see Figure 2) is the NP2 process application tool for online purchasing operations.
  • An NP2 purchase server is any online sales server that, by design or implementation, includes the NP2 settlement functionality, i.e. primarily the transmission to the payment server NP2 of the object data. purchase, in particular those necessary to carry out the checks and to apply the rules of
  • the NP2 purchase server can operate as a user of an external NP2 payment server to which it will be connected for the purposes of the operation or even include an NP2 payment server; in this second scheme, the purchase server NP2 will, via a secure connection, dialogue with the payment server NP2 or directly the payment medium NP2 in order to be able to make the payment server NP2 perform the operations of elementary payment imputation and the registration of transaction reports, namely:
  • the purchasing server may include, depending on the field of application, a buyer interface allowing it to enter online or a vendor interface allowing an operator to specify different specific parameters article by article, which may depend on the rules of imputations or of support, ...
  • the NP2 is equally applicable to any purchasing server since it, borrowed from the existing art, will have integrated, by construction or implementation, the elements of the NP2 process.
  • the purchasing server NP2 borrowed from the existing art will have to be able to cooperate as needed with all NP2 tools used in the field of application.
  • Purchasing server, payment server and NP2 support must be a set of suitable and secure identification and authentication systems and archiving capacity (for the maintenance of settlement accounts and memorization of transaction reports ) and calculation (for checks and imputations) sufficient.
  • the payment server NP2 is the logical tool that performs the settlement NP2, based on the received data relating to the object of the purchase, in particular those necessary for carrying out the checks and the application of the rules of payment. imputations.
  • the payment server NP2 Connected to the NP2 purchase terminal or the NP2 purchase server, and to the NP2 payment terminal, the payment server NP2 performs the elementary payment imputation operations and the registration of the transaction reports. to know :
  • the NP2 purchasing server should be able to cooperate with all the NP2 tools used in the application domain.
  • the functional unit formed by the purchase server once connected to the payment server NP2 and via it with the payment medium NP2, must meet all the security requirements applicable to the electronic money market.
  • Purchasing server, payment server and NP2 support must be a set of suitable and secure identification and authentication systems and archiving capacity (for the maintenance of settlement accounts and memorization of transaction reports ) and calculation (for checks and imputations) sufficient.
  • the NP2 carrier management program is used to initialize, organize and manage the payment medium.
  • NP2 payment media write read interface It functions as an NP2 payment media write read interface, available online by connection to an NP2 bearer management server or a read terminal or to the fleet management server of the bearer of the bearer. NP2 payment.
  • the NP2 payment medium includes a principal account in respect of which the holder or an agent or servicer of the holder (bank, company issuing payment media, telecom operator, etc.) is liable for payment of claims resulting from payments and payments by this support. This guarantee of payment can be put stake in particular by direct debit.
  • the NP2 payment carrier can offer a range of other sources of financing that are typically other references for debit, payment, prepaid, and so on.
  • the management program enables
  • the NP2 bearer program is normally accessible via the bearer relationship management server.
  • the NP2 merchant management program is used to manage the Merchant / Material (MA) database
  • the merchant management program may be accessible on a dedicated server, in connection with a fleet management server or with the server of an NP2 operator. It will connect to the server of this operator for the transmission of new RIC rules related to its promotional operations, so that they are propagated in the implementation architectures via the management server parks.
  • the NP2 Imputation and Control Rules Management Program is used to define the imputation and control rules, to administer them in the Rules and Controls Database (RIC), and then to disseminate them in the implementation architecture. implemented by reading NP2 tools and servers, NP2 payment media and reading terminals.
  • RIC Rules and Controls Database
  • the NP2 transaction report management program receives the Payment Element Settlement Transaction (ROIPE) reports from payment servers, stores them and then processes them for distribution, according to the implementation architecture, to On the one hand the clearing and settlement servers and on the other hand, the NP2 account restoration server.
  • ROIPE Payment Element Settlement Transaction
  • payment reports can be done for various purposes depending on the area of application: accounting management, control, production of management reports and budget execution reports, adaptation of management rules and of control, e-commerce targeting, business studies, targeted promotions, etc.
  • the process aims in particular to create value by reducing administration costs and facilitating controls by developing the management of the metadata associated with each purchase, the useful level of granularity of information.
  • the process allows, because of its design, to schedule a return of operations reports integrating all the applicable constraints in terms of confidentiality, secrecy of operations, transparency and anti-money laundering
  • the data are transmitted to the different users (payer, financier, seller %), via the NP2 account restoration server, after fabrication and formatting by the NP2 transaction report management program and in accordance with the laws and confidentiality rules. applicable depending on the domain and the application.
  • treatment chains during settlement, during clearing operations, for the management of the system
  • the managed data integrated in a payment process must therefore comply with the rules imposed by the regulators.
  • the Merchant / Article characteristics are previously non-existent or rudimentary data in existing electronic payment processes and processes.
  • This descriptive data will be either taken from pre-existing nomenclatures in the application domain or defined ad hoc for the NP2 payment application set up on a domain, during the pre-deployment analysis phase.
  • the material data management will borrow from the Supply Chain Management (Supply Chain) supply side of the supply chain and apply them in the NP2 process and monetics applications.
  • the process calls for the creation of rule tables used for elementary checks and imputations, depending on the object or service purchased (item), the bearer, the source of financing, and the data entered at the time of purchase. related to the conditions of it.
  • This data includes in a simple way the rules already used in the monetary domain (limits, validity periods, control of card lists or stolen payment media, ...) but are extended to all the rules specific to the NP2 process, necessary to its operation, in particular the rules for charging all or part of the price of the article between different sources of financing managed and presented by the payment medium.
  • the operation reports are, according to the NP2 process,
  • step 1 the payer identifies himself (see figure 3) The payer connects his NP2 payment support to the NP2 payment terminal (which operates in connection with a central server or asynchronous operation). It performs an authentication according to one of the methods of the existing art.
  • the operations are then carried out on the basis of the information contained in the payment medium, supplemented if necessary by the information available on central site.
  • the payment terminal connects with the NP2 purchase terminal or the NP2 purchase server.
  • Step 2 Items are presented for payment (see Figure 4)
  • the items, presented to the payment by the holder at the time of purchase, are read by the NP2 purchase terminal according to one of the many existing methods (laser barcode reading, RFID, manual identification by the seller or cashier, etc.). ).
  • the information related to the item retrieved varies; they are limited or not to the information read by the purchase terminal, supplemented as much as necessary by the data available on the article or on a purchase server, and by the information entered at the cashier by the cashier.
  • the information is then sent to the payment server NP2, whether it is central or implemented in the payment terminal NP2 (or the purchase terminal), so that the payment server NP2 performs the OIPE.
  • Step 3 The OPE is insured and checked article by article
  • the NP2 payment server then has two of the three sets of data necessary for the NP2 process:
  • the NP2 process realizes, at the OPE, the allocation of the expense related to the article to one of the available sources of financing, according to the imputation rules thus collected.
  • Step 4 Imputation will only be carried out after the planned checks have been carried out at Step 4, whether relating to the article, the method of financing, the rules combining these data or the rules laid down by the data relating to the controls and settlement rules, included in the payment medium, in the cash register reader or the NP2 processor itself.
  • Step 4 Settlement is imputed to various sources of funding (see Figure 5)
  • the payment server NP2 then has all the elements to perform the OIPE (s) relating to a given article.
  • imputation is carried out only after the planned checks have been carried out, whether relating to the article, the method of financing, the rules combining these data or the rules laid down by the relevant data. controls and settlement rules, included in the payment media, in the cash register or the NP2 processor itself. If the conditions are not met, either the account is charged to the main account, ie the account on which the bearer of the payment medium is required to honor its elementary debt (prepaid account within the limit the credited amount or direct debit rate granted by the holder to the operator), ie the sale is refused and the item withdrawn (purchase not authorized).
  • the allocation of the expenditure relating to the share of the price of the item to one of the available sources of financing is carried out according to the imputation rules thus collected and applied.
  • Step 5 OIPE transaction reports are stored or transmitted (see Figure 6)
  • the transaction report - derived from the OIPE includes for each element the data relating to the payer, the payment, the imputed financing and associated amount as well as the descriptive data of the article and the applied rules, useful for the application.
  • This report is stored either in the payment method or in the central server.
  • the data is transmitted by the NP2 account retrieval server to the different users (bearer, payer, fnancancer, seller %) according to the needs of the application and in accordance with the applicable laws and confidentiality rules.
  • the offset of the payments and payments is done in real time or asynchronously.
  • the centralized mode corresponds to a typical client server schema. It allows the realization of all the controls in real time. It supports advantages and disadvantages of central architectures (cost and constraints of availability, security guarantees, ).
  • the asynchronous mode uses the possibilities acquired by the most efficient electronic payment architectures (management of the suspends, fault tolerances, distribution and replication of information between the servers, ).
  • This mode of implementation is not an element of the present invention, it is only a variable mode depending on the choice of implementation media, whose method is only a simple user.
  • Step 1 The OIPE Report reaches the Operations Report Management Program
  • the payment server that carries out the OIPEs, whether it is installed on the payment terminal, the purchase terminal or the purchasing server, transmits, in real time or in asynchronous mode, the reports of OIPE to the server of payment. restitution of the accounts and ROIPE where is implanted the program of management of the reports of operations NP2. Step 2: The NP2 Transaction Report Program Generates a Compensation Transaction Report from the OIPE Reports
  • the NP2 operation report management program Upon receipt of this report, after storage and archiving operations for legal and back-up purposes, the NP2 operation report management program proceeds in the first place with the clearing operation. To do this, it calls the distribution lists of reports to generate downstream of the operation. This program first generates, from the report and according to these rules, an elementary offsetting transaction report, corresponding to the elementary settlement amount, referencing the issuer and the beneficiary, for transmission to a clearing network. accepting. Step 3: The Operations Reporting Program Sends a Clearing Operation Report to the Clearing Server
  • Step 4 The OIPE reports stored by the program are used by the NP2 Report Restitution Server to generate the other transaction reports
  • the NP2 transaction report management program After transmission of the compensation report, the NP2 transaction report management program prepares the other transaction reports.
  • the process allows, because of its design, to schedule a return of operations reports integrating all the applicable constraints in terms of confidentiality, secrecy of operations, transparency and anti-money laundering
  • the data are transmitted to the different users (payer, financier, seller %), via the NP2 account restoration server, after fabrication and formatting by the NP2 transaction report management program and in accordance with the laws and confidentiality rules. applicable depending on the domain and the application.
  • the modes of implementation are, in the process, adaptable according to the domain, tools and media used, available connections and the number of parties involved.
  • the physical payment operation NP2 differs little from a conventional payment, card or any other material or online support.
  • the difference which lies in the nature of the information processed and operations performed, remains globally transparent to the user.
  • the determination of the implementation network architecture on a given application domain depends on the particularities of this application domain and the technologies available.
  • the specific elements related to the choice of an NP2 process concern the volumes of data used and the need to operate control operations and operations on the fly. attributable to the different sources of financing, as proposed by the NP2 payment medium.
  • the process can be implemented both in topologies organized around centralized servers and in asynchronous usage patterns.
  • Implementation topologies can be two, three, four or more.
  • the logic of the NP2 process is to determine the architecture of a new payment service on a given domain only after analysis of the functional needs of the application and definition of the networks, terminals and hardware supports implemented for the construction of the processing chain.
  • This topology leads to the establishment of an operating architecture that distributes between the stakeholders in the system the hosting and management roles of the different servers and the administration roles of the different applications and databases.
  • freedom is the greatest in the determination of this architecture, but in practice it is subject to two types of constraints: those derived from the tools and systems available from different partners and their performance; and those from the many regulatory constraints applicable to the subject.
  • the primary role of the NP2 service provider will naturally be to provide know-how in the design and deployment phases of the treatment chains.
  • This provider may also naturally be responsible for the implementation of these servers and responsible for the management of some NP2 programs, depending on the roles that the stakeholders in the chain of treatment wish to entrust.
  • an administration scheme For the establishment of a payment system in a given application domain, an administration scheme must be defined.
  • the NP2 provider management tool is presented as an interface for managing and parameterizing NP2 elements, processes and data for which the NP2 provider is the operator.
  • Payment servers can either be located at the NP2 provider or housed in the purchase terminals or purchase servers.
  • the NP2 park management server is an interface for managing and configuring NP2 elements, processes and data in a single architecture under the control of the same party.
  • Provider and merchant are normally each user of a park management server.
  • the NP2 carrier relationship management server The NP2 carrier relationship management server
  • the carrier relationship management server NP2 is located in one of the parties to the device set up. As a general rule, this may be the issuer of the payment medium.
  • the bearer or persons in relationship with the bearer can, by using a dedicated interface for linking to the NP2 carrier management program, available on the NP2 fleet management server, credit one or more of the envelopes created by the carrier and made visible by him, after authentication, on the management interface of his NP2 payment medium or NP2 park management server. These same persons may also grant debit fees to which imputation control rules will be associated.
  • credits or debit fees are normally assigned to a general envelope of credit or to envelopes or budgets dedicated to specific expenses (for example for certain categories of purchase: food, health, certain goods, products or services; for certain periods corresponding for example to a holiday budget; ).
  • the person having credited the NP2 account of the holder or having granted him a direct debit right may be made the recipient of all or part of the transaction reports relating to payments charged to his account or prepaid amounts credited to his account.
  • the bearer can, by means of its management tool, create envelopes or budgets dedicated to particular expenses within its NP2 payment support or on the fleet management server NP2 (for example for certain categories of purchase: food , health, certain goods, products or services, for certain periods corresponding for example to a holiday budget; ).
  • Each of these envelopes can be assigned to a particular source of financing: debit on a given current account, allocation to a consumer credit account, posting to an account on which the holder has a debit right, ... implementation of the imputation rule being accompanied by the definition of control rules that may prohibit the allocation, set by the holder or inherited from the financier or the drawee.
  • the parties concerned will be able to define within the NP2 payment media or on the NP2 payment and fleet management servers, any control rules or imputations relating to the field of application.
  • management rules are normally defined with reference to a typology of objects or services that can be purchased and with reference to various sources of financing. They can be easily asked and defined in relation to the envelopes or budgets dedicated to particular expenses (for example for certain categories of purchase: food, health, certain goods, products or services, for certain periods corresponding for example to a budget holidays; ). Each of these envelopes may be assigned allocation rules and control rules reserving the allocation to a particular source of financing where a set of necessary conditions is met.
  • Failure to comply with these conditions may be penalized either by the impossibility to purchase or by automatic posting to the main account of the payment medium.
  • the NP2 process organizing a systematic control of the imputation and allowing the distribution of the components of the price between different funders as soon as possible will be particularly adapted to the introduction in monetary applications of debit rights granted by third party financers, public or private. professionals or individuals, voluntary or obligated donors as well as any companies or credit institutions.
  • the process makes it easier for a whole range of economic actors to access controlled financing. Symmetrically for these financiers, the process will facilitate the management, because of the possibility brought by the process to all the parties concerned to manage, in a given field of application, rules and controls, the application of which will be systematic above all payment and that will result in the production of reports of operations that can be used in the form of structured data files, for the return of the accounts and for the controls.
  • the market relation management server NP2 The market relation management server NP2
  • This server allows access to the NP2 merchant management programs described above among the implementation tools.
  • This server can be implanted with different parts according to the chosen architecture. It is normally administered by the merchant or the NP2 provider. In this second hypothesis, the user merchant connects to this server hosted by the provider NP2.
  • This server is described above among the implementation tools.
  • This server can be implanted in different hardware supports and with different parts according to the chosen architecture.
  • this purchasing server can be implemented on these materials.
  • the purchasing server is normally administered by the merchant or by the NP2 provider or by any other part of the processing chain.
  • the merchant user connects to this server hosted by the party providing the payment service NP2.
  • This server hosts the NP2 Operations Reporting Program and performs the above described operations as part of the clearing steps.
  • This server can be implanted in different hardware supports and with different parts according to the chosen architecture. Given the confidentiality requirements, this server will naturally find a place in the NP2 provider.
  • This server hosts the NP2 operations report management program and performs the operations described above under the steps of the return of the accounts.
  • This server can be implanted in different hardware supports and with different parts according to the chosen architecture.
  • the NP2 channel design phase normally performed by an NP2 payment service provider, comprises:
  • the industrial phase of deployment of the NP2 treatment chains to a given domain normally comprises:
  • the exploitation phase comprises the functions, to be divided between the parts:
  • the new features concern in particular the customer, the financier (s) and the merchant.
  • the holder of the payment medium can himself define envelopes allocated to certain expenses.
  • the holder may indeed be interested in managing specific budgets for certain expenses, for example certain types of purchases or expenses made under certain circumstances.
  • the modern payment support NP2 will allow him to return to quite traditional habits of domestic management (budget holidays, budget health, clothing budget, budget recreation, food budget, back to school budget, child budget, ...) .
  • This new faculty opens up for distributors a range of promotional activities targeted at the "pocket money" that will be given to young people by their parents and allies. For these, the use of this device allows a secure management of sums given and thus facilitates the decision to pay more significant amounts in the form of pocket money.
  • This field of promotion will be all the more promising as the market management tools that are part of the NP2 system offer a range of easy-to-use possibilities. It will be very easy to disseminate these offers via the management tool, and proceed to the issuing of targeted offers for certain types of articles, for certain types of financing, for certain periods; to use the same example: a special discount or a purchase voucher for expenses made on prepaid envelopes during the back-to-school period for books of study or school supplies.
  • the NP2 transaction reporting mechanism also offers powerful opportunities to analyze the commercial effectiveness of these offers, allowing efficient targeting of these promotional transactions.
  • a child or a beneficiary of a senior citizen may grant him a drawing right or pre-paid budgets for living expenses by specifying, if he wishes, that these amounts can not be used to purchases of alcohol or, for example, gambling expenses or expenses in excess of EUR X.
  • NP2 payment systems are also of particular interest.
  • the NP2 system makes it possible to revive in a satisfactory way the experiences so far without much success of "service cards” distributed by town halls or public authorities.
  • the system allows the issuance of NP2 payment media for payment to the public service delivery unit, for example: access to catering services, free access to formal and leisure services, etc.
  • NP2 payment tools used for the distribution of public aid allocated to the public and / or specific expenses, will also have the effect of opportunities for fraud as well as allowing control operations and tracking of much easier abuses.
  • the processing chains have this capacity and the operations report management programs can be parameterized to fit immediately and completely in the information systems internal to the system. whether purchasing and supply systems or the accounting management system (ERP).
  • ERP accounting management system
  • PFi and RIC may be carried out in conjunction with the company's human resources management system (HRM).
  • HRM human resources management system
  • NP2 payment media For smaller companies, especially PE, the use of NP2 payment media will bring even greater benefit by facilitating management and reducing material and administrative tasks, even though case the level of finesse in the processing of reports and the degree of control remains elementary.
  • NP2 payment supports are thus particularly suitable for developing the use of its solutions, whether electronic or online, within companies; they will bring ease, security and cost savings.
  • Another example can be given by the establishment of a card system for the management of meals of employees of a company in one or more of the surrounding restaurants, or even within a network of restaurants (union, network of franchisees, catering branches, ).
  • Cards with a carrier identification system, a collaborator of a company can thus allow this employee to take his meals in the restaurant or restaurants with which the company has signed a contract guaranteeing, within limits and conditions defined in the form of rules of imputation and control, the support by direct debit of his meal.
  • the complement of the assumption of responsibility can be either paid immediately to the restorer by the collaborator, or debited on his account.
  • NP2-type solutions For a bank or a credit company, the deployment of NP2-type solutions makes it possible to renovate the offer of services to the three previous audiences: individuals, businesses, public authorities.
  • the NP2 system provides by design simple solutions to offer and manage new services that banks have, so far, tried to offer to their customers and which have regularly failed because of the complexity of use for customers and the cost of management for the bank.
  • NP2 solutions also open up new opportunities for distributors, producers, merchants and merchants in their marketing offerings and capabilities.
  • NP2 payment solutions are initially designed for deployments of new electronic payment solutions.
  • NP2 solutions In the field of large-scale retailing or specialized distribution towards consumers, the choice of NP2 solutions allows to innovate by offering tailored to the needs of specific target customers.
  • the NP2 process normally leads to accelerating the evolution of the means of payment. It must facilitate the development of applications on new media and the entry of new industrial players or operators and service providers.
  • the NP2 architecture offers a truly new perspective to the deployment of payment solutions on physical media from the world of telecommunications.
  • this technology provides, to a very large extent, pre-existing solutions to the specific needs of media processing chains, linking, processing and preserving encrypted data.
  • the value creation provided by the NP2 must allow the conditions of profitability justifying the investment of modernization to be made, to satisfy the requirements of such applications.
  • the diffusion of innovations related to the means of payment should be accelerated: development of "contactless”, use of payment solutions from the PDA or “smartphones” which will make use of its computing power and the communication skills of these personal assistants, whether or not they use GSM or UMTS or 3G networks, or any new “contactless” technologies.
  • the power of the NP2 can even imagine two applications dematerialized technology to achieve virtual payment media or point.
  • the NP2 device can also be implemented in virtual form, "wallet", adding a payment tool on objects for another purpose other than payment.
  • a typical example is provided by the cards now serving as a hotel room key.
  • the integration on this card of an NP2 payment support makes it possible to greatly simplify the reception and departure operations of the hotel.
  • the hotel chains generally record the references of a means of payment in guarantee, sometimes a deposit, sometimes still a price paid most often corresponding to a set of services (room for x nights, breakfast included or no, meal with or without drinks, ).
  • a set of services room for x nights, breakfast included or no, meal with or without drinks, .
  • the various consumptions made by the customer are summarized, the prepaid benefits are removed, a global invoice is published and the balance is paid by the customer, often by means of a credit card.
  • the NP2 process on the card used as room key, it will be possible at the customer's arrival to load the payment support with a prepaid envelope summarizing the services provided in the package already paid (equivalent to the voucher ), as well as the characteristics of the credit card presented as a guarantee at the reception upon arrival.
  • the customer uses his key by identifying and method of payment of the various services consumed. Those included in the prepaid package are charged, those that are not included are accumulated to be debited at the time of departure on the card presented upon arrival.
  • the payment is immediate: the returned card allows the edition of an invoice summarizing all the services, specifying their allocation on the prepaid package and billing the surplus on the credit card number chosen by the customer to the customer. 'arrival.
  • the method allows the manufacture of a "purchase token" which can be very simply put in place on an NP2 payment medium, such as the opening of a financing service, corresponding to a purchase credit, in a determined limit, under certain conditions of exercise (period of validity, place), for certain products or in certain stores, for the purchase of certain articles or even of a particular article.
  • a "purchase token” which can be very simply put in place on an NP2 payment medium, such as the opening of a financing service, corresponding to a purchase credit, in a determined limit, under certain conditions of exercise (period of validity, place), for certain products or in certain stores, for the purchase of certain articles or even of a particular article.
  • the payment medium becomes the equivalent of a purchase order, a payment receipt or a withdrawal slip, which can be read on an NP2 payment terminal, also benefiting from the security of the mode. authentication of the carrier and the carrier.
  • This credit can be loaded on the NP2 payment medium in various ways: during a visit to the store at the time of connection of the payment medium on the payment terminal, connected to the purchasing server which then issues the credit; by connection to the carrier management server before going to the store.
  • the credit could have been created by the buyer on its bearer management interface or at the end of an online purchase, by deciding to pay by one of the sources of financing and to be issued in this form and on its support NP2 the practical equivalent of a receipt for withdrawal of the purchase; in the latter case, however, the passage of the support on the payment terminal NP2 for the withdrawal of the purchase will be worth "good end” and finalize the payment, which for the consumer has an obvious advantage.
  • C.2.3 In e-commerce
  • NP2 shopping servers will bring new tools for e-commerce, marketing, market analysis and prospecting new customers, ...
  • the NP2 process brings the prospect of new services and reduced downstream management costs.
  • the voucher can be replaced by the granting of a prepaid credit valid in a specific way for certain items, a certain period, in some stores, ...
  • the transaction reporting mechanism allows for accurate tracking of the use of these vouchers and facilitates the analysis of their commercial effectiveness.
  • NP2 payment supports are specifically designed to provide this type of guarantee as well as to facilitate the implementation of a direct debit fee or the periodic recharging of prepaid envelopes.
  • the process By facilitating payment for customers in a weak position, the process will contribute to the solvency of their consumption needs and to attract consumption needs for others ", corresponding to the wishes of their children, relatives or friends to allow them, at a distance, an easy but controlled consumption and limited to certain types of expenses.
  • Such payment media are also suitable for the distribution of certain social assistance by public administrations assisting these populations for their means of subsistence or for certain types of special expenses.
  • Young clients are also particularly suited to significant commercial initiatives organized around the dissemination of "young cards”.
  • distribution companies are also opening a commercial field of action to capture the "pocket money" given to young people by their parents and grandparents, by guaranteeing a framework by nature of goods and services purchased from the community. expenditure that will be made on the prepaid amount.
  • NP2 payment media are specifically designed to provide this type of guarantee as well as to facilitate the implementation of a direct debit fee or the periodic recharging of prepaid envelopes by third parties for the benefit of the holder.
  • Such payment media are also suitable for the distribution of certain social assistance by public administrations granting assistance to young people or certain categories of young people (students, unemployed, etc.) and for certain types of special expenses.
  • the NP2 solutions are particularly adapted to the management of public aids. Depending on the degree of detail and complexity of the rules and controls, this system is even suitable for managing subordinated grants under various conditions.
  • the loading of periodically prepaid accounts or the allocation of drawing rights with associated limitation may be two methods of dispensing these aids via an NP2 support.
  • This support can be dedicated exclusively to the management of the policies of a given community (service card of a community or local authority), or to gather the help of the various communities intended for the same public (students, unemployed, old people, disabled, ).
  • the bearer of these aids may be dedicated to this type of financing source or may be supplemented by an additional source of financing debited from the holder's current account or prepaid by him.
  • the expenditure made beyond the amounts of aid allocated or outside the conditions required may however be paid by the same regulation, offset on several sources of funding. This modality is of more discreet use by the beneficiaries.
  • the social security fund carries a reimbursement portion, which varies according to the drug and whether it has been prescribed by a doctor or not,
  • the NP2 thus allows the differentiated imputation article by article as well as, simultaneously, the control of the imputation or the distribution of the load between sources of financing.

Abstract

L'invention est relative à un procédé de paiement par un porteur à un marchand grâce à un moyen de paiement, caractérisé en ce qu'il est procédé par imputations successives, pour chaque produit, bien ou service présenté à l'achat, une imputation s'opérant entre plusieurs sources de financement, et consistant en un débit sur l'une des sources de financement ou un transfert depuis l'une de ces sources de financement; et en ce que, à chaque imputation, sont lues des données stockées dans le moyen de paiement et/ou dans des bases de données d'un serveur de paiement, ces données étant accessibles par liaison à un système central ou sur une réplication locale, lesdites données étant utilisées par le serveur de paiement pour sélectionner puis confronter des règles d'imputation et de contrôle, définies, pour chaque source de financement, par le porteur du moyen de paiement ou par le financeur à des données fonction des caractéristiques : du bien, du produit ou du service présenté à l'achat des conditions de l'achat, comprenant par exemple la date, des vérifications matérielles opérées au moment de l'achat, des options choisies par l'acheteur ainsi qu'à des données issues d'une base de données relatives aux marchands et à des catégories de produits, biens ou services.

Description

Procédé et systèmes de paiement
Préambule A.1 Domaine concerné A.1.1 Le domaine concerné recouvre tous les systèmes de paiement
Le Nouveau Processus de Paiement (NP2) s'applique au domaine des paiements, au système de règlement et de compensation, à la monétique, à la gestion de points de fidélité, ...
Il ouvre de nouvelles perspectives dans le domaine de la monnaie électronique.
A.1.2 L'invention concerne le processus même du paiement
Le Nouveau Processus de Paiement (NP2) procède d'une modification radicale de l'approche des procédés de paiement.
L'invention permet de procéder ligne par ligne, ou article par article, voire quote-part de prix par quote-part de prix, aux contrôles, imputations, paiements et compensations, de produire simultanément un rapport élémentaire d'opération complet objet de traitement en tant que tel, ce qui constitue un processus nouveau, original par rapport à l'état de l'art en ce qu'il fonde un système monétique différent et complet, composé d'un ensemble d'outils de mise en œuvre, supports matériels, schémas de distribution, procédés fonctionnels et services "NP2", objets de ce dépôt, permettant l'offre de nouveaux services de paiements.
Cet ensemble d'outils NP2, conformément à l'invention, permet la réalisation de chaînes de traitement NP2 ouvrant de nouvelles applications dans un grand nombre de domaines. Le Nouveau Processus de Paiement (NP2) peut être mis en œuvre au moyen d'un système, comprenant des serveurs, des terminaux locaux de paiement et d'achat, des supports de paiement (cartes, téléphones, systèmes de vente en ligne,...), implémentant les procédés et programmes NP2, eux-mêmes organisés au sein de chaînes de traitement destinées à réaliser des opérations d'achat et de paiement, en assurant contrôles, imputations et répartition entre diverses . sources de financement et production de données de restitution de compte, article par article, au sein d'une même opération de paiement.
Les supports de paiement NP2 ont pour particularité de pouvoir supporter plusieurs sources de financement ou de paiement et d'intégrer des données définissant un ensemble de règles d'imputations et de contrôles, adaptées en fonction des besoins particuliers du domaine, des porteurs, des financeurs ou des marchands.
Les chaînes de traitement NP2 sont conçues pour véhiculer des rapports d'opération, par opération élémentaire, intégrant des données relatives au paiement mais aussi à l'objet ou au service payé et des données relatives aux contrôles et mécanismes d'imputation. Ces rapports sont en eux-mêmes objets de traitements qui constituent un élément spécifique de l'invention.
A.1.3 L'invention et son système de mise en œuvre ouvrent des fonctionnalités jusqu'alors inédites, profitant des possibilités technologiques existantes mais sous employées dans les schémas actuels
Ce NP2 trouve en effet une utilité immédiate et puissante en ce qu'il vise à créer des chaînes de traitement capable de traiter un ensemble de données non limitées à un prix et qu'il ouvre ainsi la possibilité nouvelle d'exploiter un ensemble de fonctionnalités nouvelles, rendues disponibles par les technologies actuelles et émergentes, capables de traitements instantanés et puissants sur des supports de plus en plus variés, sûrs et légers mais encore dépourvues d'applications pratiques dans le domaine du paiement du fait non, en réalité, de la réglementation ou de la technologie existantes mais du fait de la conception présente des systèmes et procédés de paiement qui, tous, passent par l'étape obligée de la totalisation de la somme soumise à encaissement.
Cette limite, analysée infra dans la description de l'état de l'art, est en effet l'une des causes profondes de la difficulté à développer des services de paiements réellement novateurs. .2 État de l'art antérieur
A.2.1 En dépit de nombreuses innovations concernant les outils, supports et algorithmes de paiement, les systèmes de paiement et procédés monétiques demeurent exclusivement dédiés au paiement d'un solde, total unique.
L'acte de paiement a été l'objet d'une grande inventivité depuis plusieurs décennies: évolution des mécanismes juridiques et bancaires, développement du débit direct, incidence de l'Internet, développement des cartes de crédit et de la carte à puce, exploration des possibilités apportées par l'évolution technologique...
Cependant, le process final demeure invariable: l'acte de paiement est ramené au solde final d'un total établi dans "l'addition», " the bill", la facture, ... étape finale où s'effectuent, le cas échéant, les contrôles globaux puis l'imputation du débit total sur un compte unique.
Ce processus actuellement général sera appelé dans la suite du document Processus Classique de Paiement par Solde PCPS A.2.2 Divers aménagements ont été imaginés pour pallier les inconvénients de cette façon de procéder qui, d'évidence, limite les fonctionnalités possibles.
A.2.2.1 S 'agissant de l'imputation
Des émetteurs de cartes offrent des "comptes" auxquels sont associées plusieurs cartes, émises soit au nom de différents porteurs, soit marquées comme "additionnelles" pour un même porteur afin de lui permettre, par le choix de la carte utilisée au moment du paiement de distinguer entre types de dépenses et budgets. D'autres cartes encore servent à supporter les dépenses qui seront débitées sur un compte de crédit consommation associé.
C'est le choix de l'une des cartes du porteur qui permet de distinguer une imputation. Cela a pour inconvénient de conduire à une inflation des cartes portées par une même personne.
A.2.2.2 S 'agissant des contrôles
Les contrôles portent en général sur la fiabilité du support de paiement avant acceptation globale du paiement demandé.
Les contrôles vont en général porter sur
• le total à payer ou le total d'un cumul glissant sur période donnée
• sur l'identité du porteur et sa vérification au moyen de la signature, du PESf du porteur du moyen de paiement, ... avant acceptation globale du paiement demandé.
• sur l'intégrité du support de paiement, vérification qu'il ne figure pas sur des listes noires de cartes volées, de "points de compromission" particuliers, ...
Certaines cartes limitent les catégories de dépense possibles
Certains articles ou certains services ne peuvent être payés par la carte et donc ne sont pas intégrables dans "l'addition" (p.ex. certaines cartes de paiement d'essence autorisent ou non l'achat de friandises ou d'accessoires automobile en station service); les contrôles mis en place en empêchent le paiement avec cette carte.
A.2.2.3 s'agissant des sources de financement
Quelques cartes permettent de choisir entre deux modes de financement
Au moment du paiement, certaines cartes (par exemple des cartes émises par des enseignes de grande distribution) offrent, à la caisse, le choix entre paiement direct ou imputation sur une société de crédit consommation (pour la grande distribution, en général, leur filiale de crédit consommation).
A posteriori, le client peut avec certaines banques répartir par une gestion bancaire l'apurement ou l'étalement de sa dette mensuelle par appel de facilités de trésorerie ou par un compte associé de crédit consommation.
Les cartes commencent à avoir plusieurs fonctions selon le terminal de paiement utilisé
Une carte de débit ou de crédit est également
• carte de retrait dans un DAB/GAB
• parfois porte monnaie électronique
• parfois carte de paiement dans des cabines téléphoniques mais dans ces utilisations, la fonction est toujours déterminée par le choix du terminal utilisé (DAB ou ATM, terminal de paiement, terminal Monéo ou Navigo,...); le support de paiement est passif dans ce choix ; il porte des programmes juxtaposés relatifs aux différents fonctionnements.
Les "portefeuilles électroniques" créés ces dernières années portent plusieurs références de cartes
Depuis quelques années, plusieurs sociétés de l'Internet, parfois associées à des banques, ont créé des « portefeuilles électroniques », systèmes de stockage en ligne qui rassemblent les références des cartes de paiement de crédit du porteur. Ces nouveaux outils peuvent également être reproduits sous une forme cryptée sur des cartes ou des téléphones mobiles. Ils sont parfois complétés par une fonction de porte-monnaie électronique correspondant à une réserve prépayée chargée par des versements.
Le développement de ces outils est subordonné, outre l'évolution des comportements des consommateurs, à la constitution d'un nombre suffisant d'accords d'acceptation avec les réseaux bancaires et les systèmes de paiement.
Cependant ces systèmes ne font que reconstituer de manière virtuelle le mode de fonctionnement et l'économie des cartes de paiement physiques. Ils apportent une souplesse de choix et parfois des avantages de sécurité mais ne modifient pas autrement que par la dématérialisation le mode de fonctionnement des cartes de crédit.
A.2.3 Mais toutes ces variantes pallient aux inconvénients du PCPS sans le remettre en cause.
La réglementation pose parfois des contraintes qui rendent naturelle cette dissociation entre moyens de paiement (e.g. la réglementation spécifique au crédit consommation rend naturelle sa gestion par des "usines "dédiées dans le monde bancaire).
Pour autant, force est de constater que ces contraintes, outre d'expliquer, ont eu pour effet d'intégrer le PCPS comme l'invariant du paiement et que, quels que soient les évolutions techniques ou aménagements introduits, les systèmes de paiement inventés jusqu'alors ne l'ont pas remis en cause.
A3 Problème posé: proposer un système complet capable de fournir des prestations de services de paiement d'un type nouveau
A.3.1 Les acteurs économiques expriment le besoin d'une accélération des évolutions de l'offre de services en matière de paiements à court et moyen termes.
A.3.1.1 Les offres existantes ne satisfont plus les acteurs économiques qui sont conscients du retard de ce secteur de services par rapport aux outils modernes
Les acteurs économiques souhaitent disposer d'outils nouveaux qui leur apportent, à la fois,
• des facilités de gestion
• des évolutions de performance
• des baisses de coût des systèmes de paiement, • et l'apparition de nouveaux acteurs industriels, prestataires de services de paiement, capables d'offrir aux consommateurs, entreprises et administrations de nouveaux outils plus riches, plus adaptés à la diversité de leurs besoins et plus sûrs.
Le Single European Paiement Area doit provoquer une évolution significative du domaine sur la période 2007 à 2012. Il doit ouvrir par de nouvelles règles techniques une fenêtre d'intervention pour de nouveaux prestataires.
A.3.1.2 De nouveaux acteurs se présentent
Les opérateurs de télécoms sont régulièrement présentés comme ayant prochainement vocation à intervenir sur ce marché des paiements, la technologie se prêtant désormais à la réalisation de virements par des téléphones mobiles. Plusieurs pays, en Europe et en dehors, commencent à expérimenter ces techniques.
L'industrie de la grande distribution se montre également très intéressée à la perspective d'offrir à ses clients des services de paiement plus complets que la seule carte de crédit émise par leur filiale de crédit consommation. Diverses initiatives en ce domaine ont été prises ces dernières années, aussi bien par les entreprises de distribution de grande consommation (VPC, GMS...) que par des acteurs de distribution en biens et services de consommation spécialisée (cartes de paiement de carburant, parking...).
A.3.1.3 la Commission Européenne s'est engagée à faciliter les opérations de paiement et à abaisser le coût des paiements en Europe (espace communautaire et zone Euro).
Les commissaires européens en charge de la Concurrence et du Marché Intérieur ont régulièrement dénoncé les insuffisances et obstacles au développement communautaire résultant de l'organisation présente du marché des paiements.
Des études économiques ont en effet montré que l'enjeu sur la croissance de la performance des systèmes de paiement représente près de 1 % du produit intérieur brut.
A.3.1.4 la Banque Centrale Européenne (BCE) appuie et renforce ces initiatives
La Banque Centrale Européenne (BCE) est à l'origine de la création d'un statut d'émetteurs et de diffuseurs de monnaie électronique, homogènes dans les pays de la zone euro et, par le concours d'une directive communautaire, dans les pays de l'union européenne. Elle travaille également à la création d'objectifs et de standards de sécurité communs pour les systèmes de monnaie électronique.
A.3.2 Cette évolution ne viendra pas de l'évolution des systèmes monétiques existants car, tous organisés autour du PCPS, ils sont conçus et dimensîonnés pour n'échanger qu'un nombre limité d'informations.
A.3.3 Le concept inventif NP2 associé à ses outils NP2 de mise en œuvre vise à constituer l'une de ces offres nouvelles
A.3.3.1 Énoncé de manière synthétique, le NP2 fait passer le paiement d'une opération globale concentrant contrôles et informations associées en un point qu'est l'acquittement d'un solde (confondant ainsi en empêchant leur exploitation les informations associées à chacun des éléments achetés ) à un processus complexe et contrôlé, organisé par opération élémentaire d'imputation pour chaque article pris séparément.
Le NP2 organise les paiements en traitant des informations relatives
• au porteur et aux sources de financement (identifiants, statut, conditions de validité, compte ou budget d'imputation, ...)
• à l'article ou service (nature, description par nomenclature(s), référence dans des nomenclatures d'achat, paramètres fiscaux, ...)
• aux contrôles et règles d'imputation (fonction de la nature de l'article, et de paramètres commerciaux, sociaux ou réglementaires associés, nature des contrôles opérés et résultat obtenu...).
Les opérations élémentaires sont rapportées, dans ce procédé, dans un rapport à trois dimensions (ou plus) conservant autant que nécessaire, ligne par ligne, article par article, objet de transaction par objet de transaction et par montant imputé, les informations associées (date, lieu, ...)
A.3.3.2 Le procédé associé aux éléments matériels NP2 et aux schémas d'organisation et chaînes de traitement NP2, dont l'invention est revendiquée par le présent dépôt, constitue un système complet de service de paiement.
Il permet de réaliser la quasi totalité des applications de paiement existantes, en les unifiant dans un même cadre.
Il se déploie par implémentation des procédés NP2 dans les divers outils fournis par l'état de l'art existant ou à venir, au moyen de logiciels NP2 puis mise en oeuvre d'une architecture de service NP2.
Il s'adapte à un domaine donné par analyse des flux particuliers de données nécessaires et par paramétrage des outils NP2 et chaînes de traitement NP2, pour définir, au delà des fonctions de base natives au paiement, les fonctionnalités nouvelles spécifiques au domaine, tirant partie de la puissance du procédé et créatrices de valeur novatrice.
Ce NP2 sera décliné, dans les domaines d'application les plus divers. Des exemples d'application sont présentés en fin du présent document, dans les domaines du BtoC, du BtoB et le domaine des services publics.
Ainsi, l'invention concerne un procédé de paiement par un porteur à un marchand grâce à un moyen de paiement, caractérisé en ce qu'il est procédé par imputations successives, pour chaque produit, bien ou service présenté à l'achat, une imputation s'opérant entre plusieurs sources de financement, et consistant en un débit sur l'une des sources de financement ou un transfert depuis l'une de ces sources de financement ; et en ce que, à chaque imputation, sont lues des données stockées dans le moyen de paiement et/ou dans des bases de données d'un serveur de paiement, ces données étant accessibles par liaison à un système central ou sur une réplication locale, lesdites données étant utilisées par le serveur de paiement pour sélectionner puis confronter des règles d'imputation et de contrôle, définies, pour chaque source de financement, par le porteur du moyen de paiement ou par le financeur à des données fonction des caractéristiques : du bien, du produit ou du service présenté à l'achat, des conditions de l'achat, comprenant par exemple la date, des vérifications matérielles opérées au moment de l'achat, des options choisies par l'acheteur, ainsi qu'à des données issues d'une base de données relatives aux marchands et à des catégories de produits, biens ou services. Dans une réalisation, l'imputation peut être opérée sur une traction du prix du produit, bien ou service présenté à l'achat, chaque fraction de prix pouvant être imputée sur une source de financement différente.
Dans une réalisation, pour chaque imputation est émis un rapport associant à l'imputation concernée l'enregistrement des éléments d'information requis pour le contrôle de cette imputation.
Dans une réalisation, l'application des règles de contrôle et d'imputation sert à contrôler la régularité et la licéité de chaque imputation au regard des règles choisies par le porteur et/ou le marchand et/ou le financeur.
Dans une réalisation, la gestion des données par imputations élémentaires de paiement aboutit pour chaque imputation à la double production, d'une part, d'un rapport de compensation émis pour le paiement de cette imputation et, d'autre part, à la production puis la gestion d'un rapport d'opération d'imputation élémentaire, intégrant les éléments d'information découlant du paiement et des contrôles effectués lors de l'imputation, notamment en vue de son exploitation ultérieure à des fins de contrôle, d'analyse ou d'exploitation statistique
Dans une réalisation, la gestion des rapports d'opération est organisée de telle sorte que chacun des destinataires ne peut recevoir d'informations issues de ces rapports que dans la proportion de droits à en connaître propres à chaque destinataire.
Dans une réalisation, des points de fidélité sont gérés sur une source de financement dédiée parmi celles intégrées au moyen de paiement, les points de fidélités étant accumulés au fur et à mesure des paiements, conformément aux règles d'imputation et de contrôle caractéristiques de l'acquisition de ces points de fidélité, suivis à l'aide des rapports relatifs à l'évolution de cette source de financement.
Dans une réalisation, les points de fidélité accumulés sur la source de financement dédiée peuvent être utilisés directement par tirage sur cette source de financement, conformément au règles d'imputation et de contrôle qui en régissent l'utilisation.
Dans une réalisation, une imputation est réalisée en fonction de données représentant un choix effectué par le porteur, notamment le choix de la source de financement à imputer, ces données étant soit préalablement stockées soit saisies lors du paiement.
Dans une réalisation, une imputation est réalisée en fonction de données représentant des contrôles effectués par le marchand, ces données étant soit préalablement stockées soit saisies lors du paiement.
L'invention concerne également un système de paiement de biens, produits ou services, par un porteur, à un marchand permettant de procéder au paiement par imputations successives, pour chaque produit, bien ou service présenté à l'achat, une imputation s'opérant entre plusieurs sources de financement, et consistant en un débit sur l'une des sources de financement ou un transfert depuis l'une de ces sources de financement, le système comprenant : un support de paiement, propre au porteur ; un terminal de paiement, apte à lire et authentifier le support de paiement et à transmettre les données qu'il contient à un serveur de paiement ; un terminal d'achat, apte à identifier les biens, produits et services achetés, et à transmettre ces données à un serveur de paiement un serveur de paiement, connecté au terminal d'achat et au terminal de paiement pour en recevoir des données, réalisant les opérations d'imputations successives lors du paiement en fonction des données stockées dans des bases de données, ces bases étant accessibles par liaison à un système central ou sur une réplication locale, lesdites données étant utilisées par le serveur de paiement pour sélectionner puis confronter des règles d'imputation et de contrôle, définies, pouf chaque source de financement, par le porteur du support de paiement ou par le financeur, à des données fonction des caractéristiques : du bien, du produit ou du service présenté à l'achat des conditions de l'achat, comprenant par exemple la date, des vérifications matérielles opérées au moment de l'achat, des options choisies par l'acheteur ainsi qu'à des données issues d'une base de données relatives aux marchands et à des catégories de produits, biens ou services.
Dans une réalisation, le serveur de paiement comprend des moyens pour opérer chaque imputation sur une fraction du prix du produit, bien ou service présenté à l'achat, chaque fraction de prix pouvant être imputée sur une source de financement différente.
Dans une réalisation, le serveur de paiement comprend des moyens pour émettre, pour chaque imputation, un rapport associant à l'imputation concernée l'enregistrement des éléments d'information requis pour le contrôle de cette imputation.
Dans une réalisation, l'application des règles de contrôle et d'imputation sert à contrôler la régularité et la licéité de chaque imputation au regard des règles choisies par le porteur et/ou le fînanceur et/ou le marchand.
Dans une réalisation, la gestion des données par imputations élémentaires de paiement permet au serveur de paiement de produire, pour chaque imputation, d'une part, un rapport de compensation émis pour le paiement de cette imputation et, d'autre part, un rapport d'opération d'imputation élémentaire, ce rapport intégrant les éléments d'information découlant du paiement et des contrôles effectués lors de l'imputation, notamment en vue de son exploitation ultérieure à des fins de contrôle, d'analyse ou d'exploitation statistique
Dans une réalisation, le serveur de paiement comprend des moyens de gestion des rapports d'opération, ces moyens étant tels que chacun des destinataires ne peut recevoir d'informations issues de ces rapports que dans la proportion de droits à en connaître propres à chaque destinataire.
Dans une réalisation, des points de fidélité sont gérés sur une source de financement dédiée parmi celles intégrées au support de paiement, les points de fidélité étant accumulés au fur et à mesure des paiements, conformément aux règles d'imputation et de contrôle caractéristiques de l'acquisition de ces points de fidélité, suivis à l'aide des rapports relatifs à l'évolution de cette source de financement.
Dans une réalisation, les points de fidélité accumulés sur la source de financement dédiée peuvent être utilisés directement par tirage sur cette source de financement, conformément aux règles d'imputation et de contrôle qui en régissent l'utilisation.
Dans une réalisation, une imputation est réalisée en fonction de données représentant un choix effectué par le porteur, notamment le choix de la source de financement à imputer, ces données étant, soit préalablement stockées, soit saisies lors du paiement, sur le support de paiement ou le terminal de paiement.
Dans une réalisation, une imputation est réalisée en fonction de données représentant des contrôles effectués par le marchand, ces données étant, soit préalablement stockées, soit saisies lors du paiement sur le terminal d'achat.
Dans une réalisation, le système comprend une interface de gestion dédiée au porteur, comprenant des moyens permettant au porteur de créer et/ou de modifier les règles d'imputation et de contrôle applicables et/ou des sources de financement.
Dans une réalisation, le système comprend une interface de gestion marchand, comprenant des moyens permettant au marchand de créer et/ou de modifier les règles d'imputation et de contrôle applicables et/ou des catégories de biens, produits ou services.
Dans une réalisation, le système comprend une interface de gestion financeur, comprenant des moyens permettant au financeur d'une des sources de financement de créer et/ou de modifier les règles d'imputation et de contrôle applicables.
L'invention concerne également un système de paiement à distance, par un porteur, de biens, produits ou services à un marchand et permettant de procéder au paiement par imputations successives, pour chaque produit, bien ou service présenté à l'achat, une imputation s'opérant entre plusieurs sources de financement, et consistant en un débit sur l'une des sources de financement ou un transfert depuis l'une de ces sources de financement, le système comprenant : un moyen de paiement, propre au porteur, pouvant réunir plusieurs sources de financement ; un serveur d'achat, apte à identifier les biens, produits et services présentés à l'achat par le porteur, un serveur de paiement, en liaison avec le serveur d'achat, réalisant les opérations d'imputations successives lors du paiement, en fonction de données fournies par le serveur d'achat et de données stockées dans des bases de données, ces bases étant accessibles par liaison à un système central ou sur une réplication locale, lesdites données étant utilisées par le serveur de paiement pour sélectionner puis confronter des règles d'imputation et de contrôle, définies, pour chaque source de financement, par le porteur du moyen de paiement ou par le financeur, à des données fonction des caractéristiques : du bien, du produit ou du service présenté à l'achat des conditions de l'achat, comprenant par exemple la date, des vérifications opérées au moment de l'achat, des options choisies par l'acheteur ainsi qu'à des données issues d'une base de données relatives aux marchands et à des catégories de produits, biens ou services.
Dans une réalisation, le serveur de paiement comprend des moyens pour opérer chaque imputation sur une fraction du prix du produit, bien ou service présenté à l'achat, chaque fraction de prix pouvant être imputée sur une source de financement différente.
Dans une réalisation, le serveur de paiement comprend des moyens pour émettre, pour chaque imputation, un rapport associant à l'imputation concernée l'enregistrement des éléments d'information requis pour le contrôle de l'imputation.
Dans une réalisation, l'application des règles de contrôle et d'imputation sert à contrôler la régularité et la licéité de chaque imputation au regard des règles choisies par le porteur et/ou le marchand et/ou le financeur.
Dans une réalisation, la gestion des données par imputations de paiement permet au serveur de paiement de produire, pour chaque imputation, d'une part, un rapport de compensation émis pour le paiement de cette imputation et, d'autre part, un rapport d'opération d'imputation élémentaire, ce rapport intégrant les éléments d'information découlant du paiement et des contrôles effectués lors de l'imputation, notamment en vue de son exploitation ultérieure à des fins de contrôle, d'analyse ou d'exploitation statistique.
Dans une réalisation, le serveur de paiement comprend des moyens de gestion des rapports d'opération, ces moyens étant tels que chacun des destinataires ne peut recevoir d'informations issues de ces rapports que dans la proportion de droits à en connaître propres à chaque destinataire.
Dans une réalisation, des points de fidélité sont gérés sur une source de financement dédiée parmi celles intégrées au moyen de paiement, les points de fidélité étant accumulés au fur et à mesure des paiements, conformément aux règles d'imputation et de contrôle caractéristiques de l'acquisition de ces points de fidélité, suivis à l'aide des rapports relatifs à l'évolution de cette source de financement.
Dans une réalisation, les points de fidélité accumulés sur la source de financement dédiée peuvent être utilisés directement par tirage sur cette source de financement, conformément aux règles d'imputation et de contrôle qui en régissent l'utilisation.
Dans une réalisation, une imputation est réalisée en fonction de données représentant un choix effectué par le porteur, notamment le choix de la. source, de financement à imputer, ces données étant, soit préalablement stockées dans le serveur d'achat, saisies lors du paiement et transmises au serveur d'achat.
Dans une réalisation, une imputation est réalisée en fonction de données représentant des contrôles effectués par le marchand, ces données étant préalablement stockées dans le serveur d'achat. Dans une réalisation, le système comprend une interface de gestion dédiée au porteur, comprenant des moyens permettant au porteur de créer et/ou de modifier les règles d'imputation et de contrôle applicables.
Dans une réalisation, le système comprend une interface de gestion marchand, comprenant des moyens permettant au marchand de créer et/ou de modifier les règles d'imputation et de contrôle applicables.
Dans une réalisation, le système comprend une interface de gestion financeur, comprenant des moyens permettant au financeur d'une des sources de financement de créer et/ou de modifier les règles d'imputation et de contrôle applicables
L'invention sera mieux comprise grâce à la description détaillée ci-dessous, faite en référence aux figures 1 à 7, parmi lesquelles : la figure 1 est un schéma du système selon l'invention comprenant un terminal d'achat ; la figure 2 est un schéma du système selon l'invention comprenant un serveur d'achat ; les figures 3 à 6 décrivent les différentes étapes du règlement lors d'un achat ; la figure 7 décrit les différentes étapes de la compensation et de la restitution des comptes consécutives à un paiement.
B Un dispositif nouveau complet B.1 Les éléments du NP2 B.1.1 Une nouvelle approche
L'ensemble des éléments matériels et logiques de mise en œuvre de l'invention a pour caractéristique commune d'organiser tous les traitements par opération d'imputation de paiement élémentaire (OIPE), de réaliser pour chacune de ces opérations des contrôles fonction de l'acheteur, du mode de financement, de l'objet ou du service acheté puis de produire un rapport d'opérations spécifiques pour chaque OIPE.
L'OIPE résulte du traitement de données multiples concernant le porteur et les sources de financement dont il dispose, les caractéristiques de l'achat et les règles d'imputation et de contrôle.
Gérant, par conception initiale, des données relatives à diverses sources de financements, aux objets ou services achetés et aux règles d'imputation et de contrôle, le système NP2 inclut de manière caractéristique des outils logiciels et des chaînes de traitement particuliers et spécifiques.
La création d'un tel système de paiement numérique passe par la définition d'un ensemble d'outils de mise en œuvre, matériels et logiciels dédiés au procédé, et d'architectures permettant de relier ces outils par des chaînes de traitement spécifiques.
L'invention inclut les différents outils de gestion spécifiques, nécessaires à l'administration du système NP2 et destinés à pleinement exploiter les possibilités nouvelles apportées par ce procédé.
B.1.2 Définitions
Dans la suite du document seront utilisées les définitions suivantes
B.l.2.1 Les supports de règlement
II s'agit de l'objet matériel ou virtuel support de son moyen de paiement NP2, identifiant le porteur et les informations qui lui sont associées (date de validité, mode d'authentification, sources de financement,...). Ce support sera le plus souvent une carte à puce, ou un processeur inclus dans un téléphone portable, un PDA, ou bien encore un support ad hoc, ...
La mise en œuvre du NP2 peut s'effectuer sur tout support de paiement existant ou à venir, dont les capacités logicielles de traitement intègrent à la construction ou auront été complétées par l'implémentation des programmes et progiciels NP2. Elle recourt aux schémas et circuits conformes à l'état de l'art en matière de réseaux et d'outils réseaux.
B.l.2.2 l'opération d'imputation de paiement élémentaire OIPE
Elle correspond à l'opération d'imputation élémentaire du paiement de tout ou partie du prix d'un même seul article (objet ou prestation de service, typiquement un article au sein d'une addition) au sein d'un même règlement (une série réglée par un même support de paiement NP2 au même moment,).
Elle est constituée par un ensemble de données collationnées dans un fichier ou N- uplet, décrites infra, relatives à l'article acheté, à l'imputation du paiement, aux contrôles effectués et à l'acte d'achat (auteur, lieu, date et heure, ...). Ces données sont adaptables selon l'application implémentée. Elles peuvent de même être codées et compressées.
B.1.2.3 Les caractéristiques du règlement
Elles décrivent le moyen de paiement, l'auteur, le terminal de paiement, la date, le lieu et l'heure, et toutes autres informations requises dans un service monétique et dans le cas particulier d'une implémentation spécifique.
B.l.2.4 L'achat et ses caractéristiques
L'achat correspond à un "article d'une addition", il peut être relatif à un bien, un service, des frais d'opération. Il peut ne concerner qu'une simple quote-part du prix d'un même objet ou service imputé sur une source de financement unique. Sa description peut être ramenée au strict minimum: une quantité et un prix unitaire ; elle peut s'enrichir, selon les besoins du domaine d'application, de divers niveaux descriptifs.
En règle générale, ces caractéristiques sont répertoriées en référence à une nomenclature, celle- ci peut être d'usage général (Electronic Commerce Modeling Language ECML, codification en usage dans un secteur, ...), spécifique au distributeur, spécifique au tiré, convenue entre le prestataire de service de paiement et son client, dans le cadre d'une application particulière (carte de paiement de marque, affînitaire, pour public particulier, etc.)
B.l.2.5 Le débit et ses caractéristiques
Dans le process de paiement objet du présent dépôt, le règlement peut être imputé article par article voire par quote-part du prix d'un article sur des sources de règlement différentes.
Cette multiplicité d'imputation est aujourd'hui courante en pratique même si la monétique ne sait pas gérer de manière simple ce type de situations. Le monde de la santé en France en fournit un exemple caractéristique: tiers payant, ticket modérateur, caisse de sécurité sociale, mutuelle, assurance complémentaire, dépassement d'honoraires... toutes ces créances se règlent soit par un "jeu de cartes" au paiement, soit par la gestion de règles complexes de remboursement au niveau de systèmes centraux de compensation et de règlement, soit encore par un surcoût élevé de gestion manuelle. Mais pas encore directement par le consommateur qui, pour peu qu'on lui en donne la possibilité de manière techniquement aisée, est pourtant celui qui a la meilleure vision de ses diverses ressources (ou mécanismes de couverture sociale) et doit aussi redevenir clairement responsable de ses choix et arbitrages.
Le NP2 permet l'imputation différentiée article par article ainsi que, simultanément, le contrôle de l'imputation ou la répartition de la charge entre sources de financement ou ceux appelés les "financeurs" dans la suite de ce document: ce sont d'abord les particuliers eux-mêmes qui dans ce procédé peuvent imputer leurs différents achats soit sur leur compte principal normalement débité sur leur compte courant, soit sur des budgets prépayés (par eux même ou des parents, amis, entreprises, œuvres, donateurs), soit sur des droits de tirage qui leur sont ouverts à titre personnel ou professionnel (particuliers, établissements de crédit, administrations publiques, etc.); ce sont ensuite les banques et organismes de crédit, généralistes ou spécialisés, susceptibles à ce titre de financer certaines dépenses ; ce sont enfin des entreprises ou organismes, désireuses d'ouvrir et de contrôler des droits de tirage à des tireurs, bénéficiaires ou commettants,
Le dernier schéma permet de créer une offre de prestation de service de paiement, à l'initiative d'entreprises émettrices de supports de moyens de paiement (téléphones portables, cartes de marque ou co-brandées, supports RFID, ou tout nouveau vecteur de paiement), qui se mettent en position de tiré dans le processus NP2, en disposant d'une contrepartie : par exemple d'une position de teneur de comptes prépayés, d'un statut d'émetteur de monnaie électronique et/ou d'un droit de débit direct.
Par référence à la terminologie issue du projet de directive de la Comission européenne sur "les services de paiement dans le marché intérieur", adopté le 27 mars 2007, l'imputation sur une source de financement peut consister en un Débit sur un compte, du porteur ou d'un financeur ou bien en un virement (ou transfert) depuis un compte ou un celui d'un financeur.
B.l.2.6 Les contrôles par OIPE
Le dispositif NP2 prévoit la mise en œuvre de contrôles au degré de finesse nécessaire, aptes à répondre aux attentes des consommateurs, des commerçants et distributeurs, des producteurs et de ceux appelés ici les "financeurs" (particuliers, établissements de crédit, administrations publiques, etc.). Ces contrôles peuvent être relatifs.
• à l'authentification du porteur (bien sûr) mais de manière plus fine qu'avec un contrôle du moyen de paiement (PIN ou autre), y compris notamment en référence à des propriétés du porteur dans un fichier central ou un système interne à une entreprise de gestion des ressources humaines (HRM)
• à l'achat, à ses conditions comme à la nature de l'objet ou du service acheté
• au paiement, avec
• contrôle de caisse : la provision prépayée est- elle suffisante ? l'article acheté est-il bien imputable sur cette source de financement ? le plafond n'est-il pas dépassé pour cet article, ce financement ?
• contrôle de paveur, l'auteur du paiement a-t- il le droit, compte tenu de ses caractéristiques, de régler ce type d'article sur ce type de financement ? dans quel cas ? avec quel reporting associé ?
B.l.2.7 Les rapports d'opération et leurs usages
Le NP2 a pour conséquence d'aboutir à la production de rapports d'opération, par OIPE, par OPE et par acte de règlement, et de permettre de produire tout autre rapport souhaité par sélection et agrégation des données contenues dans les rapports OIPE.
La nature et les modalités de production de ces rapports constituent eux-mêmes un élément significatif de l'invention.
Ces rapports d'opération, descriptifs de l'achat global (rapport de règlement, descriptif de l'acte de règlement) ou de l'achat d'un article (rapport OPE) ou de l'imputation par article (rapport OIPE), incluent normalement le compte-rendu d'opérations de contrôle effectuées et leur résultat.
Ils constituent eux-mêmes des objets utilisables à des fins d'opérations comptables, de contrôle (de supervision ou par sondage), de gestion d'enveloppes budgétaires, de statistiques.... et tous autres traitements conformes aux réglementations applicables, selon les cas, au consommateur, au pays du marchand, de l'achat ou de l'acheteur, aux règles d'ordre public, nationales, communautaires ou internationales et toutes autres contraintes découlant de l'application particulière mise en œuvre.
Selon le domaine d'application, les rapports sont définis, limités ou étendus et gérés en fonction des droits et besoins de leurs destinataires. Cette finesse de gestion constitue un des éléments caractéristiques de l'invention.
C'est en particulier dans la définition, la conception, le développement et la mise au point de ces systèmes de gestion, d'imputation et de contrôle ainsi que dans l'exploitation des rapports de paiement que pourra se développer une offre de prestation de services de paiements, nouvelle et créatrice de valeur pour les clients.
B.1.3 Un système NP2 complet
Le système NP2 objet du présent dépôt sera décrit à partir des outils de mise en œuvre, matériels et logiciels, et des chaînes de traitement du système d'information associé.
Les outils matériels de mise en œuvre du mécanisme NP2, décrits ci-après en B2.1.1 à 4, sont :
• le support de paiement NP2
• le terminal de paiement NP2
• le terminal d'achat NP2
• le serveur d'achat NP2
Les outils logiques spécifiques de mise en œuvre du mécanisme NP2, décrits ci- après en B2.1.5 à 9, sont :
• le serveur de paiement NP2
• le programme de gestion porteur NP2
• le programme de gestion marchand NP2
• le programme de gestion des règles d'imputation et contrôles NP2
• le programme de gestion des rapports d'opérations NP2, intégrant les
1. serveur de compensation NP2
2. serveur de restitution de comptes et de Rapports d'opération NP2 Les chaînes de traitement NP2 opèrent:
• la gestion des données NP2 (PFi, MA, RIC ; cf. partie B2.2.1.)
• la gestion des parcs
• la gestion de la relation porteur
• la gestion de la relation marchande
• les opérations d'achat paiement
• les opérations de compensation et de restitution de comptes NP2 B.1.4 Des opérateurs NP2
Avant de s'engager dans la description détaillée du mécanisme NP2, il n'est pas inutile de préciser de quelle manière procéderont les opérateurs de ces systèmes pour les adapter et les déployer dans différents domaines d'application.
Compte-tenu de l'ampleur de l'évolution apportée par ce nouveau procédé, le déploiement supposera de disposer de terminaux, de réseaux, de processeurs et de systèmes de conservation et de gestion des données très différents de ceux actuellement employés dans le domaine monétique mais existant ou émergeant dans un ensemble d'autres domaines (télécommunications, GSM, 3G, UMTS, RFID, Internet, ...). Une première tâche des opérateurs NP2 consistera donc à implémenter ces procédés dans différents outils, choisis par l'émetteur, s'intégrant ensuite dans une même chaîne de traitement.
Les logiciels développés à cette fin seront tenus en conformité avec les règles imposées en matière de monnaie électronique (sécurité, transparence et confidentialité, lutte anti-blanchiment,...) telles qu'elles résultent en particulier des règles et critères édictés par les banques centrales (au premier rang desquels la Banque centrale européenne) et les systèmes de règlements internationaux. Ils seront en particulier développés en référence aux modèles et objectifs de sécurité découlant de la COMMON CRITERIA METHODOLOGY mise en place en mai 2003 par la Banque centrale européenne (BCE).
La pleine exploitation des possibilités nouvelles ainsi ouvertes exigera, pour chaque nouveau domaine d'application, un travail spécifique d'analyse des objets, mécanismes, règles,... pour définir et mettre en place les chaînes de traitement et les outils de gestion adaptés au domaine. Cette phase préliminaire de déploiement constituera une condition nécessaire de la réussite et une des composantes du métier de l'opérateur NP2. .2 le mécanisme du NP2 B.2.1 Les outils de mise en œuvre B.2.1.1 Le support de paiement NP2
Le NP2 est applicable indifféremment à tout support de paiement dès lors que celui-ci, emprunté à l'art existant, aura, par construction ou implémentation, intégré les éléments du procédé NP2.
Le support peut être constitué par une carte magnétique ou à puce, un téléphone portable, un support RFID ou tout autre support existant ou à venir utilisé pour des applications de paiement, dès lors que celui- ci est résistant à la copie ou la falsification, et qu'il constitue avec le terminal de lecture un ensemble doté de systèmes d'identification et authentification adaptés et sûrs et d'une capacité d'archivage (pour la tenue des compte de règlement et la mémorisation des rapports d'opération) et de calcul (pour les contrôles et imputations) suffisantes.
B.2.1.2 le terminal de paiement NP2
Le terminal de paiement NP2 sert à la lecture, l'authentification, la validation du support de paiement NP2 ; en connexion avec ce support et avec le terminal d'achat ou le serveur d'achat NP2, et avec le serveur de paiement NP2, il constitue l'ensemble réalisant le paiement selon le processus d'imputations de paiement élémentaire.
Le NP2 est applicable indifféremment à tout terminal de paiement dès lors que celui-ci, emprunté à l'art existant, aura intégré, par construction ou implémentation, les éléments du procédé NP2.
Pour certaines applications, pourra être installé sur certains terminaux de paiement NP2 un écran interactif (de type écran tactile) auquel peut être substituée l'utilisation de l'interface d'un support mobile intelligent (PDA, Smartphone) ; cette interface permettra, pour certains domaines et selon les options programmées pour la mise en jeu des règles d'imputation, l'interrogation du porteur qui sera alors en mesure de diriger ses différents achats vers différentes sources de financement.
Le terminal de paiement NP2 emprunté à l'art existant devra être en mesure de coopérer avec tous les supports de paiement NP2 utilisables dans le domaine d'application.
Quel que soit le support, l'ensemble fonctionnel formé une fois le support NP2 mis en relation avec le terminal de paiement NP2 doit satisfaire à toutes les exigences de sécurité applicables au domaine numérique. Terminal de paiement et support NP2 doivent constituer un ensemble doté de systèmes d'identification et authentification adaptés et sûrs et d'une capacité d'archivage (pour la tenue des compte de règlement et la mémorisation des rapports d'opération) et de calcul (pour les contrôles et imputations) suffisantes.
B.2.1.3 Ie terminal d'achat NP2
Le terminal d'achat NP2 (cf. figure 1) sert à la lecture et l'identification de l'objet de l'achat puis, après transmission de ces données au terminal de paiement NP2, à la réalisation des contrôles et à l'application des règles d'imputations par le serveur de paiement NP2.
Le terminal d'achat NP2 est un terminal de vente tel qu'il en existe en sortie de surface de vente (typiquement la caisse d'un supermarché ou d'un magasin ou d'une station-service,...) doté d'un mécanisme de saisie automatique ou manuelle de l'objet ou du service acheté (lecteur de codes- barres, lecteur RFID5 caisses automatiques dédiées à une gamme de produits, avec boutons préprogrammés ou écran tactile,...) complété, par construction ou par implémentation, de fonctions NP2 servant :
• à identifier l'objet de l'achat,
• à lire sur l'objet, dans sa mémoire, ou à récupérer sur un serveur, les caractéristiques de cet objet nécessaires à l'opération élémentaire d'imputation de paiement NP2,
• puis à les transmettre au terminal de paiement NP2 pour que le serveur de paiement
NP2,
• en relation avec les données relatives au porteur et aux modes de financement,
• après avoir éventuellement interrogé le porteur sur des options d'imputations, via l'interface du terminal de paiement ou celle du support de paiement,
• effectue la mise enjeu des règles de contrôle et d'imputation,
• et puisse alors procéder aux règlements OIPE successifs
• et réaliser les rapports d'opérations en vue de leur transmission.
Le terminal d'achat peut inclure, selon le domaine d'application, une interface vendeur lui permettant de préciser différents paramètres particuliers article par article, dont peuvent dépendre les règles d'imputations ou de prise en charge, ...
Dans certaines applications, cette interface peut également servir à interroger le porteur notamment sur ses choix d'imputation, soit directement, soit via l'interface du support de paiement NP2 ou du terminal de paiement NP2.
Le NP2 est applicable indifféremment à tout terminal d'achat dès lors que celui- ci, emprunté à l'art existant, aura intégré, par construction ou implémentation, les éléments du procédé NP2.
Le terminal d'achat NP2 emprunté à l'art existant devra être en mesure de coopérer avec tous les outils NP2 utilisés dans le domaine d'application.
Quel que soit l'objet ou le service acheté, l'ensemble fonctionnel formé par le terminal d'achat une fois mis en relation avec le terminal de paiement NP2 et, via celui-ci avec le support de paiement NP2, doit satisfaire à toutes les exigences de sécurité applicables au domaine monétique. Terminal d'achat, terminal de paiement et support NP2 doivent constituer un ensemble doté de systèmes d'identification et authentification adaptés et sûrs et d'une capacité d'archivage (pour la tenue des compte de règlement et la mémorisation des rapports d'opération) et de calcul (pour les contrôles et imputations) suffisantes.
B.2.1.4 Ie serveur d'achat NP2
Le serveur d'achat NP2 (cf. figure 2) est l'outil d'application des procédés NP2 aux opérations d'achat en ligne.
Constitue un serveur d'achat NP2 tout serveur de vente en ligne qui, par construction ou par implémentation, inclut les fonctionnalités de règlement NP2, c'est-à-dire principalement la transmission au serveur de paiement NP2 des données relatives à l'objet de l'achat, en particulier de celles nécessaires à la réalisation des contrôles et à l'application des règles d'imputations.
Le serveur d'achat NP2 pourra fonctionner en utilisateur d'un serveur de paiement NP2 extérieur auquel il sera connecté pour les besoins de l'opération ou bien encore inclure un serveur de paiement NP2 ; dans ce second schéma, le serveur d'achat NP2 devra, au moyen d'une connexion sécurisée, dialoguer avec le serveur de paiement NP2 voire directement le support de paiement NP2 afin de pouvoir faire réaliser par le serveur de paiement NP2 les opérations d'imputation de paiement élémentaire et l'enregistrement des rapports d'opération, à savoir :
• identifier l'objet de l'achat,
• récupérer les caractéristiques de cet objet nécessaires à l'opération élémentaire d'imputation de paiement NP2,
• puis les transmettre au serveur de paiement NP2 pour que,
• en relation avec les données relatives au porteur et aux modes de financement,
• soient ensuite mises enjeu les règles de contrôle et d'imputation,
• soient alors enregistrés les règlements OIPE successifs
• puis réalisées les transmissions de rapports d'opérations.
Le serveur d'achat peut inclure, selon le domaine d'application, une interface acheteur lui permettant de saisir en ligne ou une interface vendeur permettant à un opérateur de préciser différents paramètres particuliers article par article, dont peuvent dépendre les règles d'imputations ou de prise en charge, ...
Le NP2 est applicable indifféremment à tout serveur d'achat dès lors que celui- ci, emprunté à l'art existant, aura intégré, par construction ou implémentation, les éléments du procédé NP2.
Le serveur d'achat NP2 emprunté à l'art existant devra être en mesure de coopérer en tant que de besoin avec tous les outils NP2 utilisés dans le domaine d'application.
Quel que soit l'objet ou le service acheté, l'ensemble fonctionnel formé par le serveur d'achat une fois mis en relation avec le serveur de paiement NP2 et, via celui-ci avec le support de paiement NP2, doit satisfaire à toutes les exigences de sécurité applicables au domaine monétique. Serveur d'achat, serveur de paiement et support NP2 doivent constituer un ensemble doté de systèmes d'identification et authentifïcation adaptés et sûrs et d'une capacité d'archivage (pour la tenue des compte de règlement et la mémorisation des rapports d'opération) et de calcul (pour les contrôles et imputations) suffisante. B.2.1.5 le serveur de paiement NP2
Le serveur de paiement NP2 est l'outil logique qui effectue le règlement NP2, à partir des données reçues relatives à l'objet de l'achat, en particulier de celles nécessaires à la réalisation des contrôles et à l'application des règles d'imputations.
Connecté au terminal d'achat NP2 ou au serveur d'achat NP2, et au terminal de paiement NP2, c'est le serveur de paiement NP2 qui réalise les opérations d'imputation de paiement élémentaire et l'enregistrement des rapports d'opération, à savoir :
• en relation avec les données relatives au porteur et aux modes de financement,
• en fonction des caractéristiques de l'article et des règles de contrôle et d'imputation applicables
• mise en jeu de ces règles et contrôles
• puis enregistrement des rapports OIPE successifs
• puis transmissions des rapports d'opérations au programme de gestion des rapports d'opération NP2.
Le serveur d'achat NP2 devra être en mesure de coopérer avec tous les outils NP2 utilisés dans le domaine d'application.
Quel que soit l'objet ou le service objets de l'achat, l'ensemble fonctionnel formé par le serveur d'achat une fois mis en relation avec le serveur de paiement NP2 et, via celui-ci avec le support de paiement NP2, doit satisfaire à toutes les exigences de sécurité applicables au domaine monétique.
Serveur d'achat, serveur de paiement et support NP2 doivent constituer un ensemble doté de systèmes d'identification et authentifîcation adaptés et sûrs et d'une capacité d'archivage (pour la tenue des compte de règlement et la mémorisation des rapports d'opération) et de calcul (pour les contrôles et imputations) suffisantes.
B.2.1.6 Le programme de gestion porteur NP2
Le programme de gestion porteur NP2 sert à initialiser, organiser et gérer le support de paiement.
Il fonctionne comme une interface de lecture écriture du support de paiement NP2, disponible en ligne par connexion sur un serveur de gestion de la relation porteur NP2 ou sur un terminal de lecture ou sur le serveur de gestion de parc de l'émetteur du support de paiement NP2.
Le support de paiement NP2 inclut un compte principal au titre duquel le porteur ou un mandataire ou prestataire du porteur (banque, société émettrice de support de paiement, opérateur télécom, ...) sont tenus au paiement des créances résultant des paiements et règlements par ce support. Cette garantie de paiement pourra être mise enjeu notamment par débit direct.
Le support de paiement NP2 peut offrir un ensemble d'autres sources de financement que sont typiquement d'autres références de droits de débit, de moyens de paiements, des comptes prépayés, etc.
Le programme de gestion porteur permet
• la création, alimentation, imputation, suivi des enveloppes pré- payées,
• la fixation de règles d'imputation vers des budgets dédiés, soit automatique, soit au moyen de l'interface du terminal d'achat par option lors du règlement
• la possibilité de prévoir que, pour certaines enveloppes ou catégories de dépenses, le porteur sera interrogé sur ses choix d'imputations au moment du règlement
• la gestion des droits de tirage et des aides dont le porteur est susceptible de bénéficier, • la gestion des dépenses professionnelles,
• la définition et la gestion des contrôles et limitations qu'il décide, etc.
Le programme de gestion porteur NP2 est normalement accessible via le serveur de gestion de la relation porteur.
B.2.1.7 le programme de gestion marchand NP2
Le programme de gestion marchand NP2 sert d'une part à gérer la base de données Marchand/Article (MA),
II sert d'autre part d'interface de paramétrage des terminaux d'achat ou du serveur d'achat NP2. Il permet au marchand d'organiser ses terminaux et serveurs d'achat :
• mise au point des interfaces de caisse,
• gestion des caractéristiques des objets et services vendus
• ainsi que des contrôles et limitations associés,
• mise au point d'offres promotionnelles (bons d'achat, réductions, générales ou destinées à des clientèles ou des sources de financements spécifiques - comme les prépayés offerts à certains clients ou pour certains articles,...) par fixation de nouvelles règles au sein de la base de données RIC
• des offres liées à des financements (étalements de paiements, liaison avec des crédits consommation spécifiques, ...) etc.
Selon l'architecture de mise en œuvre choisie, le programme de gestion marchand pourra être accessible sur un serveur dédié, en connexion avec un serveur de gestion des parcs ou avec le serveur d'un opérateur NP2. Il se connectera au serveur de cet opérateur pour la transmission de nouvelles règles RIC liées à ses opérations promotionnelles, pour que celles-ci soient propagées dans les architectures de mise en œuvre via le serveur de gestion des parcs.
B.2.1.8 Le programme de gestion des règles d'imputation et contrôles NP2
Le programme de gestion des règles d'imputation et contrôles NP2 sert à définir les règles d'imputations et de contrôle, à les administrer dans la base de données des règles et contrôles (RIC), puis à les diffuser dans l'architecture de mise en œuvre, par lecture écriture des outils et serveurs NP2, des supports de paiement NP2 et des terminaux de lecture.
Ces dernières opérations sont normalement réalisées via le serveur de gestion de parc.
Il permet aux parties concernées de définir et d'organiser, chacun pour ce qui le concerne, les règles, contrôles, limitations et mécanismes de rapport qu'il souhaite.
L'application de ces règles et leur tenue à jour est assurée, opérée et contrôlée soit en temps réel par connexion aux serveurs utiles, soit par propagation périodique des paramètres sur les éléments de la chaîne de traitement NP2, selon le choix d'architecture de mise en œuvre.
B.2.1.9 Le programme de gestion des rapports d'opération NP2
Le programme de gestion des rapports d'opérations NP2 reçoit des serveurs de paiement les rapports d'opérations d'imputation de paiement élémentaire (ROIPE), les stocke puis il les traite pour distribution, selon l'architecture de mise en œuvre, vers d'une part les serveurs de compensation et de règlement et vers, d'autre part, le serveur de restitution de comptes NP2.
Comme indiqué précédemment, l'exploitation des rapports de paiement peut se faire à des fins diverses selon le domaine d'application : gestion comptable, contrôle, réalisation de comptes- rendus de gestion et de rapports d'exécution budgétaire, adaptation des règles de gestion et de contrôle, ciblage en commerce électronique, études commerciales, actions de promotions ciblées, etc.
Le procédé vise notamment à créer de la valeur en diminuant les coûts d'administration et en facilitant les contrôles par le développement de la gestion des métadonnées associées à chaque achat, au niveau utile de granularité des informations.
Le procédé permet, du fait de sa conception, de programmer une restitution des rapports d'opérations intégrant toutes les contraintes applicables en matière de confidentialité, secret des opérations, transparence et lutte anti-blanchiment
Les données sont transmises aux différents utilisateurs (payeur, financeurs, vendeur...), via le serveur de restitution de comptes NP2, après fabrication et formatage par le programme de gestion des rapports d'opérations NP2 et conformément aux législations et règles de confidentialité applicables selon le domaine et l'application.
B.2.2 les systèmes d'information NP2
Leur description est donnée ci-après à partir
• des données gérées
• des chaînes de traitement : lors du règlement, lors des opérations de compensation, pour la gestion du système,
• des diverses architectures de mise en œuvre
B.2.2.1 les données gérées.
Les données gérées intégrées dans un processus monétique doivent à ce titre être conformes aux règles imposées par les régulateurs.
Elles sont stockées sur différents éléments de la chaîne de traitement, selon l'architecture de déploiement retenue, la nature des supports et terminaux et le domaine particulier d'application.
Leur format est variable selon le domaine d'application; en l'état de l'art et en règle générale, il pourra notamment être du XML crypté.
Les caractéristiques Porteur/Financement PFi
Les données relatives aux différents financements supportés dans une application NP2 utiliseront les standards de la profession.
Elles doivent être gérées de manière à satisfaire aux exigences multiples de confidentialité, secret des transactions, transparence et connaissance de bout en bout nécessaires à la lutte antiblanchiment, à des niveaux adaptés en fonction du domaine d'application et du type de paiements assurés ainsi que de l'utilisateur rendu destinataire de tout rapport contenant ce type d'information.
Les caractéristiques Marchand/Article MA
Les caractéristiques Marchand/Article sont des données jusque là normalement inexistantes ou rudimentaires dans les processus et chaînes de traitement monétiques existants.
En revanche, dans le NP2, leur disponibilité est nécessaire, à des niveaux de détail variables selon le domaine d'application, pour la réalisation des opérations d'imputation et des contrôles associés.
Ces données descriptives seront soit reprises à partir, de nomenclatures pré- existantes dans le domaine d'application, soit définies ad hoc pour l'application de paiement NP2 mise en place sur un domaine, lors de la phase d'analyse préalable au déploiement. De manière typique, la gestion des données article empruntera à l'état de l'offre en systèmes de gestion des chaînes d'approvisionnement (supply chains), pour les appliquer dans le processus et les applications monétiques NP2.
Les Règles Imputations/Contrôles RIC
Le processus appelle la création de tables de règles utilisées pour les contrôles et imputations élémentaires, en fonction de l'objet ou du service acheté (article), du porteur, de la source de financement et de données saisies au moment de l'achat, liées aux conditions de celui-ci.
Ces données incluent de manière simple les règles déjà utilisées dans le domaine monétique (limites, périodes de validité, contrôle de listes de cartes ou supports de paiement volés, ...) mais sont étendues à toutes les règles spécifiques au processus NP2, nécessaires à son fonctionnement, notamment les règles d'imputation de tout ou partie du prix de l'article entre différentes sources de financement gérées et présentées par le support de paiement.
Les rapports d'opération
Les rapports d'opération sont, selon le procédé NP2,
• structurés au niveau le plus fin, par Opération d'Imputation de Paiement Élémentaire
(OIPE)
• ils rassemblent les données utiles relatives à
• l'article acheté,
• au porteur et à la nature du support,
• les descriptifs des circonstances du paiement (date, lieu, ...),
• les références de la source de financement et du payeur final,
• la quote part du prix imputée dans l'OIPE,
• la référence des contrôles et mécanismes d'imputation opérés lors de l'opération de paiement avec leur résultat et les données associées saisies par le vendeur ou l'acheteur lors du paiement,
• toutes autres données particulières au traitement et domaine d'application
Ces rapports sont retraités par le programme de gestion des rapports d'opération, avant transmission vers les différents utilisateurs, pour être adaptés à leurs besoins spécifiques et mis en conformité avec toutes les exigences de confidentialité
Le stockage des données complètes par l'opérateur NP2 lui permet de jouer le rôle de tiers de confiance et d'acteur efficace de la lutte anti-blanchiment
B.2.2.2 Schéma descriptif des chaînes de traitement NP2
A ce stade, sont présentées successivement les étapes d'une opération de règlement, les étapes des opérations de compensation consécutives et les diverses architectures de mise en oeuvre.
Les étapes du règlement
Le terme de "règlement" fait référence aux opérations effectuées par le porteur d'un support de paiement NP2, en un lieu et un moment, pour le règlement d'un ou de plusieurs articles, objets ou services, au moyen d'un terminal de paiement NP2. • étape 1: le payeur s'identifie (cf.fîgure 3) Le payeur connecte son support de paiement NP2 au terminal de paiement NP2 (qui fonctionne en connexion à un serveur central ou en fonctionnement asynchrone). Il procède à une authentification selon l'un des procédés de l'art existant.
Les opérations sont ensuite effectuées sur la base des informations contenues dans le support de paiement, complétées le cas échéant par les informations disponibles sur site central.
Le terminal de paiement entre en connexion avec le terminal d'achat NP2 ou le serveur d'achat NP2.
étape 2: les articles sont présentés au paiement (cf. figure 4)
Les articles, présentés au paiement par le porteur lors de l'achat, sont lus par le terminal d'achat NP2 selon un des nombreux procédés existants (lecture laser de codes barres, RFID, identification manuelle par le vendeur ou caissier, ...).
Selon l'application, les informations liées à l'article récupérées varient ; elles se limitent ou non aux informations lues par le terminal d'achat, complétées autant que nécessaire par les données disponibles sur l'article ou sur un serveur d'achat, et par les informations saisies à la caisse par le caissier.
Les informations sont alors envoyées au serveur de paiement NP2, qu'il soit central ou implémenté dans le terminal de paiement NP2 (ou le terminal d'achat), pour que ce serveur de paiement NP2 réalise les OIPE.
étape 3: l'OPE est assurée et contrôlée article par article
Le serveur de paiement NP2 dispose alors de deux des trois séries de données nécessaires au process NP2 :
• les données relatives à l'article,
• les données relatives au porteur et aux sources de financement dont il dispose,
II appelle alors, en fonction de ces éléments, les données relatives aux contrôles et règles d'imputation. Ces données proviennent du support de paiement et du terminal d'achat, le cas échéant complétées par d'autres extraites du serveur central.
En fonction de ces règles, le prix de l'article présenté est ventilé entre les différentes sources de financement disponibles.
Le process NP2 réalise, lors de l'OPE, l'affectation de la dépense relative à l'article à l'une des sources de financement disponibles, selon les règles d'imputation ainsi réunies.
L'imputation ne sera réalisée qu'après qu'aient été réalisés à l'étape 4 les contrôles prévus, qu'ils soient relatifs à l'article, au mode de financement, à des règles combinant ces données ou d'autres fixées par les données relatives aux contrôles et règles d'imputation, incluses dans le support de paiement, dans le lecteur de caisse ou le processeur NP2 même.
étape 4 : le règlement est imputé sur les diverses sources de financement (cf.figure 5)
Le serveur de paiement NP2 dispose alors de tous éléments pour effectuer la ou les OIPE relatives à un article donné.
L'imputation n'est toutefois effectuée qu'après qu'aient été réalisés les contrôles prévus, qu'ils soient relatifs à l'article, au mode de financement, à des règles combinant ces données ou d'autres fixées par les données relatives aux contrôles et règles d'imputation, incluses dans le support de paiement, dans le lecteur de caisse ou le processeur NP2 même. Si les conditions ne sont pas réunies, soit l'imputation se fait sur le compte principal, c'est-à-dire le compte sur lequel le porteur du support de paiement est tenu d'honorer sa dette élémentaire (compte prépayé dans la limite du montant crédité ou droit de débit direct consenti par le porteur à l'opérateur), soit la vente est refusée et l'article retiré (achat non autorisé).
Si toutes les conditions sont réunies, l'affectation de la dépense relative à la quote-part du prix de l'article à l'une des sources de financement disponibles est réalisée selon les règles d'imputation ainsi réunies et appliquées.
étape 5 : les rapports d'opération OIPE sont stockés ou transmis (cf.figure 6)
Le rapport d'opération - issu des OIPE, regroupe pour chaque élément les données relatives au payeur, au paiement, au financement imputé et montant associé ainsi que les données descriptives de l'article et des règles appliquées, utiles à l'application.
Ce rapport est stocké soit dans le moyen de paiement, soit dans le serveur central. Les données sont transmises par le serveur de restitution des comptes NP2 aux différents utilisateurs (porteur, payeur, fînanceurs, vendeur...) selon les besoins de l'application et conformément aux législations applicables et règles de confidentialité.
C'est le traitement de ces rapports d'opération qui permet la compensation des règlements, effectués par des traitements fonction de l'architecture adoptée pour le domaine d'application.
Les étapes de la compensation et de la restitution de comptes (cf.figure 7
Selon l'architecture de mise en œuvre, la compensation des imputations et des paiements s'effectue en temps réel ou de manière asynchrone.
Le mode centralisé correspond à un schéma classique client serveur. Il permet la réalisation de tous les contrôles en temps réel. Il supporte avantages et inconvénients d'architectures centrales (coût et contraintes de disponibilité, garanties de sécurité, ...).
Le mode asynchrone utilise les possibilités acquises par les architectures monétiques les plus performantes (gestion des suspends, tolérances de panne, répartition et réplication des informations entre les serveurs, ...).
Cette modalité de mise en œuvre n'est pas un élément de la présente invention, elle n'en est qu'une modalité variable selon le choix des supports de mise en œuvre, dont le procédé n'est que simple utilisateur.
Dans les deux cas, les étapes essentielles sont identiques ; la particularité d'un process réalisé à partir des rapports d'opération au niveau de l'imputation est commune aux deux architectures. étape 1 : le rapport d'OIPE parvient au programme de gestion des rapports d'opérations
NP2
Le serveur de paiement qui réalise les OIPE, qu'il soit implanté sur le terminal de paiement, le terminal d'achat ou le serveur d'achat, transmet, en temps réel ou en mode asynchrone, les rapports d'OIPE au serveur de restitution des comptes et de ROIPE où est implanté le programme de gestion des rapports d'opérations NP2. étape 2 : Ie programme de gestion des rapports d'opération NP2 génère un rapport d'Opération de compensation à partir des rapports d'OIPE
A réception de ce rapport, après- stockage et opérations d'archivage aux- fins légales et de back up, le programme de gestion des rapports d'opération NP2 procède en premier lieu à l'opération de compensation. Pour ce faire, il appelle les listes de distribution des rapports à générer en aval de l'opération. Ce programme génère en premier lieu, à partir du rapport et en fonction de ces règles, un rapport d'opération de compensation élémentaire, correspondant au montant d'imputation élémentaire, référençant l'émetteur et le bénéficiaire, pour transmission à un réseau de compensation acceptant. étape 3 : le programme de gestion des rapports d'opération envoie un rapport d'Opération de compensation au serveur de compensation
Selon les choix d'architecture, ces rapports sont transmis :
• soit au fil du traitement pour chaque OIPE
• soit stockés temporairement pour être transmis périodiquement par agrégats rassemblant, pour une période donnée, les opérations qui concernent un même bénéficiaire ou un même tiré.
Les rapports d'opérations de compensation sont transmis sans délai aux différents systèmes de compensation auxquels le serveur de compensation NP2 est connecté, selon les règles et formats de chacun de ces systèmes. étape 4: les rapports d'OIPE stockés par le programme sont exploités par le serveur de restitution de comptes NP2 pour générer les autres rapports d'opération
Après transmission du rapport de compensation, le programme de gestion des rapports d'opération NP2 procède à l'élaboration des autres rapports d'opérations.
La nature et le format de ces autres rapports à générer en aval de l'opération sont spécifiés dans le serveur de restitution de comptes NP2.
Le procédé permet, du fait de sa conception, de programmer une restitution des rapports d'opérations intégrant toutes les contraintes applicables en matière de confidentialité, secret des opérations, transparence et lutte anti-blanchiment
Les données sont transmises aux différents utilisateurs (payeur, financeurs, vendeur...), via le serveur de restitution de comptes NP2, après fabrication et formatage par le programme de gestion des rapports d'opérations NP2 et conformément aux législations et règles de confidentialité applicables selon le domaine et l'application.
Les architectures de mise en œuvre
Les modes de mise en œuvre sont, dans le procédé, adaptables en fonction du domaine, des outils et supports utilisés, des connexions disponibles et du nombre de parties impliquées.
Les modes de mise en œuvre
S'agissant des systèmes de communication employés pour la mise en œuvre du service, l'opération matérielle de paiement NP2 se distingue peu d'un paiement classique, par carte ou tout autre support matériel ou en ligne.
La différence, qui réside dans la nature des informations traitées et des opérations effectuées, reste globalement transparente à l'utilisateur.
Elle a cependant pour effet d'appeler des besoins en débit, vitesse de traitement et stockage supérieurs à ceux aujourd'hui employés en monétique. De tels besoins sont désormais rendus facilement accessibles par l'état de la technologie existante en matière de communications, protocoles internet, RFID, ...
La détermination de l'architecture réseau de mise en œuvre sur un domaine d'application donné dépend des particularités de ce domaine d'application et des technologies disponibles.
Pour l'essentiel, les éléments spécifiques liés au choix d'un procédé NP2 concernent les volumes de données utilisées et la nécessité d'opérer à la volée les opérations de contrôle et les opérations d'imputation sur les différentes sources de financement, telles qu'elles sont proposées par le support de paiement NP2.
De ce fait, le processus peut être mis en œuvre aussi bien dans des topologies organisées autour de serveurs centralisés que dans des schémas d'utilisation asynchrone.
Le choix du nombre de parties dans la chaîne de traitement aura une autre portée, le processus NP2 apportant une flexibilité nouvelle à cet égard.
Les répartitions de rôle entre opérateurs, marchands, financeurs et établissements de crédit
Les topologies de mise en œuvre peuvent se concevoir à deux, trois, quatre parties, voire plus.
• A deux parties, il correspond à une relation directe producteur ou distributeur vers le consommateur.
• A trois parties, il correspond à l'intervention d'un tiers prestataire de services de paiement, entre le vendeur et l'acheteur.
• A quatre parties, il peut correspondre
• au schéma classique actuel de la monétique (commerçant acquéreur, banque de l'acquéreur, banque émettrice de la carte, client porteur)
• ou à un schéma analogue au schéma tripartite, en intégrant l'intervention d'une banque associée, soit au commerçant soit au client.
D'autres schémas organisés entre les différents intervenants d'un même secteur sont envisageables, dans le cadre d'applications spécifiques à un domaine (par exemple, les domaines de la santé ou de l'assistance aux personnes âgées), ils peuvent réunir un nombre plus élevé encore de parties.
Le rôle nouveau que les opérateurs NP2 peuvent jouer.
La logique du procédé NP2 consiste à ne déterminer l'architecture d'un service nouveau de paiement sur un domaine donné qu'après analyse des besoins fonctionnels de l'application et définition des réseaux, terminaux et supports matériels mis en œuvre pour la construction de la chaîne de traitement.
La définition de cette topologie conduit à fixer une architecture d'exploitation répartissant entre les parties prenantes au système les rôles d'hébergement et de gestion des différents serveurs et les rôles d'administration des différentes applications et bases de données.
Dans le principe, la liberté est la plus grande dans la détermination de cette architecture mais elle est cependant soumise en pratique à deux types de contraintes : celles provenant des outils et systèmes disponibles chez les différents partenaires et de leurs performances ; et celles provenant des nombreuses contraintes réglementaires applicables à la matière.
Le premier rôle du prestataire de services NP2 consistera naturellement à apporter son savoir- faire dans les phases de conception et déploiement des chaînes de traitement.
Ce prestataire pourra aussi tout naturellement être chargé de la mise en œuvre de ces serveurs et responsable de la gestion de certains programmes NP2, en fonction des rôles que les parties prenantes à la chaîne de traitement souhaitent lui confier.
Il découle de la conception même du procédé mais aussi de plusieurs des contraintes réglementaires applicables à ce type d'opérations, à la prestation de services en matière de monnaie électronique et plus généralement de services financiers de cette nature, que pourraient s'avérer particulièrement pertinents les schémas confiant au prestataire de services NP2 le pilotage des programmes de services de paiement, l'administration et la gestion des bases de données, la tenue du programme de restitution des comptes, la conservation des ROIPE et l'exploitation des rapports produits par le programme de gestion des rapports d'opération. Ce schéma place en effet le prestataire dans une position de « tiers de confiance », rôle au titre duquel il serait détenteur de données complètes mais rôle qui, en contrepartie pourrait être strictement limité, par diverses contraintes, à la production de rapports vers chaque usager, qui soient conformes aux vues et règles de secret et de contrôle des informations qui sont applicables à chacun des destinataires.
La définition finale du rôle de ces prestataires découlera sans doute autant de la pratique que des évolutions réglementaires encore à venir dans le sillage de la mise en place du SEPA (Single European Payment Area).
B.2.2.3 les schémas d'administration des données NP2
Pour la mise en place d'un système de paiement dans un domaine d'application donné, un schéma d'administration doit être défini.
Par nature, il est fonction des options adoptées dans le choix des outils matériels et des architectures de mise en œuvre.
Les paragraphes ci-après décrivent les éléments essentiels nécessaires à l'administration des données et des chaînes de traitement NP2.
L 'outil de gestion prestataire NP2
L'outil de gestion prestataire NP2 se présente comme une interface de gestion et de paramétrage des éléments, traitements et données NP2 dont le prestataire NP2 est opérateur.
Selon les cas de figure, il s'agira de :
• paramétrage des supports émis et des outils de gestion porteur (lecteurs, serveurs, ...)
• paramétrage des outils acquéreur:
• terminal de paiement
• paramétrage du terminal d'achat ou du serveur d'achat NP2,
• paramétrage du ou des serveurs de paiement NP2
• paramétrage et gestion du serveur de gestion marchand NP2.
• mise au point, administration et gestion des diverses bases de données : PFi, MA, RCI
• ...
Les serveurs de paiement peuvent être soit localisés chez le prestataire NP2, soit logés au sein des terminaux d'achat ou des serveurs d'achat.
Le serveur de gestion des parcs NP2
Le serveur de gestion des parcs NP2 se présente comme une interface de gestion et de paramétrage des éléments, traitements et données NP2 réunis dans une même architecture, sous le contrôle d'une même partie.
Prestataire et marchand sont normalement chacun utilisateur pour ce qui le concerne d'un serveur de gestion des parcs.
Selon les cas de figure, il s'agira de :
• paramétrage des supports émis et des outils de gestion porteur (lecteurs, serveurs, ...)
• paramétrage des outils acquéreur:
• terminal de paiement
• paramétrage du terminal d'achat ou du serveur d'achat NP2, • paramétrage du ou des serveurs de paiement NP2 paramétrage et gestion du serveur de gestion marchand NP2.
Le serveur de gestion de la relation porteur NP2
Le serveur de gestion de la relation porteur NP2 est localisé au sein de l'une des parties au dispositif mis en place. En règle générale, il pourra s'agir de l'émetteur du support de paiement.
Compte-tenu de l'importance spécifique de ces fonctionnalités dans le procédé NP2, les principales modalités d'utilisation de ce serveur sont détaillées ci-après.
Constitution de réserves prépayées
Le porteur ou des personnes en relation avec le porteur peuvent, en utilisant une interface dédiée de mise en relation avec le programme de gestion porteur NP2, disponible sur le serveur de gestion de parc NP2, créditer une ou plusieurs des enveloppes créées par le porteur et rendues visibles par lui, après authentification, sur l'interface de gestion de son support de paiement NP2 ou du serveur de gestion de parc NP2. Ces mêmes personnes peuvent aussi accorder un droit de débit auquel seront associées des règles de contrôle d'imputations.
Ces crédits ou droit de débit sont normalement affectés à une enveloppe de crédit général ou bien à des enveloppes ou budgets dédiés à des dépenses particulières (par exemple pour certaines catégories d'achat : alimentaires, de santé, de certains biens, produits ou services ; pour certaines périodes correspondant par exemple à un budget vacances ; ...).
Sous réserve des lois et règlements protégeant la confidentialité et, le cas échéant, sous réserve de l'accord du porteur, la personne ayant crédité le compte NP2 du porteur ou lui ayant accordé un droit de débit direct pourra être rendu destinataire de tout ou partie des rapports d'opérations relatifs aux paiements imputés sur son compte ou sur les montants prépayés qu'il a crédités.
Affectation de dépenses à des financements
Le porteur peut, au moyen de son outil de gestion, créer au sein de son support de paiement NP2 ou sur le serveur de gestion de parc NP2 des enveloppes ou budgets dédiés à des dépenses particulières (par exemple pour certaines catégories d'achat : alimentaires, de santé, de certains biens, produits ou services ; pour certaines périodes correspondant par exemple à un budget vacances ; ...).
Chacune de ces enveloppes peut se voir affecter une source de financement particulière : débit sur tel ou tel compte courant, affectation à un compte de crédit consommation, imputation sur un compte sur lequel le porteur dispose d'un droit de débit, ... la mise en place de la règle d'imputation étant accompagnée de la définition de règles de contrôle pouvant interdire l'imputation, fixées par le porteur ou héritées du financeur ou du tiré.
Définition de limites et contrôles
Dans le procédé NP2, les parties concernées, qu'il s'agisse du porteur ou des financeurs, pourront définir au sein du support de paiement NP2 ou sur les serveurs de paiement et de gestion de parc NP2, toutes règles de contrôle ou d'imputations relatives au domaine d'application.
Ces règles de gestion sont normalement définies en référence à une typologie des objets ou services susceptibles d'être acheté et en référence aux diverses sources de financement. Elles peuvent être aisément posées et définies en relation avec les enveloppes ou budgets dédiés à des dépenses particulières (par exemple pour certaines catégories d'achat : alimentaires, de santé, de certains biens, produits ou services ; pour certaines périodes correspondant par exemple à un budget vacances ; ...). Chacune de ces enveloppes pourra se voir affecter des règles d'imputation et règles de contrôle réservant l'imputation sur une source de financement particulière aux cas où seront réunies un ensemble de conditions nécessaires.
Le défaut de respect de ces conditions peut être sanctionné soit par l'impossibilité d'acheter, soit par l'imputation automatique sur le compte principal du support de paiement.
Accès facilité à des financements contrôlés
Le procédé NP2 organisant un contrôle systématique de l'imputation et permettant dès l'achat la répartition des composantes du prix entre différents financeurs sera particulièrement adapté à l'introduction dans les applications monétiques de droits de débit consentis par des tiers financeurs, publics ou privés, professionnels ou particuliers, donateurs volontaires ou obligés ainsi que toutes entreprises ou établissements de crédit.
Les exemples d'application du procédé NP2 sont détaillés dans la partie qui leur est plus loin consacrée. De manière globale, le procédé facilite à tout un ensemble d'acteurs économiques l'accès à des financements contrôlés. Symétriquement pour ces financeurs, le procédé facilitera la gestion, du fait de la possibilité apportée par le procédé à l'ensemble des parties concernées de gérer, dans un domaine d'application donné, des règles et contrôles dont l'application sera systématique avant tout paiement et qui donnera lieu à production de rapport d'opérations utilisables sous forme de fichiers de données structurées, pour la restitution des comptes et pour les contrôles.
Cette garantie apportée par le système monétique NP2 facilitera pratiquement, juridiquement et psychologiquement l'octroi à des porteurs tiers de droits de débit sur tel ou tel compte courant, de type droit de débit direct.
Le serveur de gestion de la relation marchande NP2
Ce serveur permet l'accès aux programmes de gestion marchand NP2 décrit ci-dessus parmi les outils de mise en œuvre.
Ce serveur peut être implanté auprès de différentes parties selon l'architecture retenue. Il est normalement administré par le marchand ou par le prestataire NP2. Dans cette seconde hypothèse, le marchand utilisateur se connecte à ce serveur hébergé par le prestataire NP2.
Le serveur d'achat/paiement NP2
Ce serveur est décrit ci-dessus parmi les outils de mise en œuvre.
Ce serveur peut être implanté dans différents supports matériels et auprès de différentes parties selon l'architecture retenue.
Si l'ensemble constitué par le support de paiement NP2, le terminal de paiement NP2 et le terminal d'achat NP2 connectés ensemble est techniquement en mesure d'assurer dans des conditions satisfaisantes les traitements NP2 à la volée, ce serveur d'achat pourra être implémenté sur ces matériels.
Sans cela, dans une architecture typiquement centralisée, le serveur d'achat est normalement administré par le marchand ou par le prestataire NP2 ou par toute autre partie de la chaîne de traitement.
Dans cette seconde hypothèse, le marchand utilisateur se connecte à ce serveur hébergé par la partie prestataire du service de paiement NP2.
Le serveur de règlement compensation
Ce serveur héberge le programme de gestion des rapports d'opérations NP2 et assure les opérations décrites ci-dessus au titre des étapes de la compensation.
Ce serveur peut être implanté dans différents supports matériels et auprès de différentes parties selon l'architecture retenue. Compte-tenu des impératifs de confidentialité, ce serveur pourra trouver naturellement place chez le prestataire NP2.
Le serveur de restitution de comptes NP2
Ce serveur héberge le programme' de gestion des rapports d'opérations NP2 et assure les opérations décrites ci-dessus au titre des étapes de la restitution des comptes.
Ce serveur peut être implanté dans différents supports matériels et auprès de différentes parties selon l'architecture retenue.
Compte-tenu des impératifs de confidentialité, ce serveur pourra trouver naturellement place chez le prestataire NP2. .3 Les phases de déploiement sur un domaine d'application B.3.1 La phase initiale de conception des chaînes NP2
La phase de conception des chaînes NP2, normalement réalisée par un opérateur prestataire de services de paiement NP2 comporte :
• L'adaptation au domaine d'application
• L'adaptation NP2 de l'offre produit (adoption de nomenclatures de référencement, catégorisation des types d'achat, fixation des règles associées, mise en place d'outils marketing NP2, ...)
• le choix d'une architecture de traitement
• la mise au point des systèmes de compensation NP2
• le choix d'une topologie de mise en œuvre des bases de données et implantation des programmes NP2
• la définition des opérations de contrôle NP2
• la mise en place des bases de données PFi, MA, RIC
B.3.2 La phase industrielle
La phase industrielle de déploiement des chaînes de traitement NP2 à un domaine donné comporte normalement :
• l'implémentation du NP2 dans les outils matériels choisis et sur les serveurs retenus
• la préparation des supports de paiement :
• l'émission des supports de paiement
• la préparation des terminaux de paiement NP2
• la préparation des terminaux d'achat NP2
• l'installation des serveurs d'achats NP2
• l'installation des serveurs de paiement NP2 • la préparation des systèmes d'information
• la construction des bases de données et leur chargement
• l'installation des serveurs et de la gestion des parcs
• l'implémentation de l'architecture de connexion des serveurs de gestion • l'installation des serveurs de compensation et de gestion des rapports d'opération NP2
• la construction des systèmes de compensation NP2, à partir des règles de restitution de comptes et des standards des systèmes de compensation interopérés
• la construction des systèmes de restitution de compte et d'exploitation des rapports d'opération générés.
B.3.3 La phase d'exploitation
La phase d'exploitation comporte les fonctions, à répartir entre les parties :
• La gestion client du support de paiement
• La gestion marchand de l'offre produits et services
• La chaîne de traitement paiement
• la chaîne de traitement de compensation et règlements des paiements finaux
• la chaîne de traitement des rapports d'opération
C Exemples d'application C.1 Les fonctionnalités offertes parles systèmes de paiement NP2
Les fonctionnalités nouvelles concernent en particulier le client, le(s) financeur(s) et le marchand.
C.1.1 Pour le client
Pour le client, les applications tirées des systèmes de paiement NP2 apportent des améliorations et avantages significatifs.
Pour l'ensemble des porteurs, la mise en place d'une application sur un domaine particulier, capable d'intégrer différentes sources de financement susceptibles de partager le coût supporté dans l'achat de biens et services de ce domaine particulier, apporte, par construction, des avantages de simplicité et d'unicité.
L'intégration dans le système d'une interface de gestion porteur apporte à celui-ci la maîtrise de ses budgets.
La possibilité de poser des règles et de garantir par des contrôles le respect de ces règles contribue à cette maîtrise. Elle offre aux porteurs un outil puissant de gestion de ses ressources et de simplification des tâches d'administration domestique.
Par ailleurs, le fait de pouvoir disposer par l'intermédiaire d'un support de paiement monétique NP2 de sources de financement contrôlé, alimentées par prépaiement ou par droit de tirage, dont l'utilisation est strictement affectée et limitée à certains types de dépenses, donnera la possibilité à des clientèles spécifiques, notamment des personnes en difficulté, d'accéder aux facilités offertes par des moyens de paiement monétiques les plus modernes, dans des conditions nouvelles.
C.1.2 Pour le financeur
Symétriquement, du côté des financeurs, la possibilité d'ouvrir un droit de tirage ou d'affecter une somme prépayée à un porteur donné d'un support de paiement NP2, en ayant la garantie que cette somme ne pourra être employée que pour certaines dépenses, certains types d'achat ou dans certaines circonstances, constitue une perspective nouvelle appelée à de nombreuses applications pratiques.
C.l.2.1 client et alliés du client
Comme cela a été précédemment indiqué, dans un système NP2, le porteur du support de paiement peut lui-même définir des enveloppes affectées à certaines dépenses.
Le porteur peut en effet être intéressé à la gestion de budgets spécifiques pour certaines dépenses, par exemple certains types d'achat ou des dépenses faites dans certaines circonstances.
Ce faisant, le support moderne de paiement NP2 lui permettra de retrouver des habitudes tout à fait traditionnelles de gestion domestique (budget vacances, budget santé, budget habillement, budget loisirs, budget nourriture, budget de rentrée scolaire, budget enfant,...).
Ayant la possibilité de créer une enveloppe spécifique dont l'usage sera limité à un certain type de dépenses ou d'achats, le porteur aura également la faculté de solliciter de ses parents, amis ou alliés des dons sur cette enveloppe.
Ainsi des jeunes pourront-ils par exemple bénéficier de la part de leurs parents ou grands- parents d'une dotation en budget d'achat de livres scolaires (auprès de tel libraire spécialisé adhérent du système NP2, ou auprès d'un serveur de ventes en ligne ou encore d'un groupe de distribution de produits de loisirs, également adhérents du système NP2 et qui auront spécifié, via leur programme de gestion marchand, un codage relatif à la catégorie "livres scolaires/livres d'études/ouvrages scientifiques"). L'intérêt économique et commercial de cette possibilité d'affecter des montants prépayés à des dépenses encadrées et contrôlées est évident.
Cette faculté nouvelle ouvre pour les distributeurs un champ d'actions de promotion ciblées sur « l'argent de poche » que donneront aux jeunes leurs parents et alliés. Pour ceux-ci, l'usage de ce dispositif permet une gestion sûre des sommes données et facilite ainsi la décision de verser des sommes plus significatives sous forme d'argent de poche.
Ce champ de promotion sera d'autant plus prometteur que les outils de gestion marchand qui font partie du système NP2 offrent une gamme de possibilités d'usage aisé. Il sera ainsi très facile de diffuser ces offres via l'outil de gestion porteur, et de procéder à l'émission d'offres ciblées pour certains types d'articles, pour certains types de financement, pour certaines périodes ; pour reprendre le même exemple : une réduction particulière ou un bon d'achat pour les dépenses effectuées sur des enveloppes prépayées en période de rentrée scolaire pour des livres d'études ou des fournitures scolaires.
Le mécanisme des rapports d'opérations NP2 offre également de puissantes facilités d'analyse de l'efficacité commerciale de ces offres, permettant un ciblage efficient de ces opérations de promotion.
Un tel système permet très avantageusement de remplacer la mécanique des « bons d'achat » aujourd'hui lourde dans sa gestion et d'une manipulation délicate lors du passage en caisse.
De la même manière, un enfant ou un ayant-droit d'une personne âgée pourra lui octroyer un droit de tirage ou des budgets prépayés pour des dépenses de vie quotidienne en spécifiant, s'il le souhaite, que ces sommes ne peuvent servir à des achats d'alcool ou, par exemple, des dépenses de jeu ou des dépenses d'un montant supérieur à X. euros.
C.1.2.2 financeur public
Pour les financeurs publics, les systèmes de paiement NP2 présentent également un intérêt tout particulier.
Cela est particulièrement évident pour les organismes de sécurité sociale ou les collectivités territoriales, en particulier pour leurs dépenses d'aide sociale.
S'agissant du cas particulier des dépenses de santé, un exemple d'application du système NP2 pour une nouvelle gestion de la dépense de soins dans le système français de protection sociale est détaillé ci- après.
De manière plus générale, le système NP2 permet de relancer d'une manière cette fois satisfaisante les expériences jusque- là sans grand succès de « cartes de services » distribuées par les Mairies ou les collectivités publiques.
Par exemple, pour des publics particuliers comme les personnes âgées, les étudiants ou les scolaires, le système permet l'émission de supports de paiement NP2 pour le paiement à l'unité de prestations de service public, par exemple : de transport public, d'accès à des services de restauration collective, d'accès gratuit à des services de formalités ou de loisirs, etc..
Pour ces publics, lorsque des aides sont accordées sous forme d'un montant versé périodiquement pour certains types de dépenses, la disponibilité d'enveloppes prépayées dédiées à des dépenses de cette nature offre un système de gestion particulièrement aisée pour la distribution de ces aides.
La production de rapports d'opérations en aval des paiements constitue également un avantage majeur pour les collectivités dispensatrices de ces aides. Il sera en effet possible de disposer, par compilation de rapports d'opérations spécialement définis pour les besoins de restitution de compte de la collectivité, de traitements efficaces à même de satisfaire aux obligations de transparence et de contrôle de la dépense publique.
Ces outils de paiement NP2, utilisés pour la distribution d'aides publiques affectées à des publics et ou des dépenses particulières, auront également pour effet de diminuer mécaniquement les possibilités de fraude ainsi que de permettre des opérations de contrôle et de repérage des abus beaucoup plus aisées.
C.l.2.3 l'entreprise pour un de ses commettants
L'utilisation des outils monétiques dans la gestion par les entreprises des achats par les salariés pose toujours problème, que l'entreprise soit de grande ou de petite taille.
En l'état de l'art, les systèmes de cartes d'achat ( purchasing card), qui ne sont d'usage courant que dans un certain nombre de Pays, ne peuvent apporter de solution complètement satisfaisante dès lors qu'elles vont fonctionner sur le processus classique de paiement par solde et en utilisant des chaînes de traitement qui ne peuvent pas véhiculer d'information précise sur la nature des biens ou services achetés.
En revanche, par conception, dans le système NP2, les chaînes de traitement ont cette capacité et les programmes de gestion des rapports d'opérations peuvent être paramétrés pour s'insérer de manière immédiate et complète dans les systèmes d'information internes à l'entreprise, qu'il s'agisse des systèmes d'achat et d'approvisionnement ou du système de gestion comptable (ERP).
En pratique, pour la fabrication de telles cartes d'achat dans un environnement NP2, si une entreprise a déjà procédé au travail d'organisation de ses chaînes d'approvisionnement, il lui suffira d'adapter les codes MA à partir du système de codification déjà déployé dans l'entreprise.
Si ce travail d'organisation des chaînes approvisionnement n'a pas déjà été réalisé, il suffit d'adopter une codification standard en vigueur (de type ECML) ; s'agissant de l'utilisation des rapports d'opérations pour la tenue d'une comptabilité par nature de dépenses, les codes de position comptable, au degré de précision souhaitée, peuvent suffire ; pour l'utilisation de ces rapports dans le cadre d'une comptabilité analytique, le système de codification mise en place dans cette comptabilité analytique pourra par exemple être repris dans l'identification des porteurs habilité à détenir un support de paiement NP2.
Si un degré de précision plus fin est souhaité pour l'identification des porteurs, la définition des droits qui leur sont accordés, le niveau de contrôle associé à ces droits et le degré de précision des rapports d'opérations produits, la gestion de ces données PFi et RIC pourra être réalisée en liaison avec le système de gestion des ressources humaines (H. R. M.) de l'entreprise.
Pour des entreprises de taille plus modeste, notamment des T. P E., l'utilisation de supports de paiement NP2 apportera un bénéfice plus grand encore par la facilitation de la gestion et l'allégement des tâches matérielles et administratives, même si dans ce cas le niveau de finesse dans le traitement des rapports et le degré de contrôle reste élémentaire.
Les supports de paiement NP2 se prêtent donc tout spécialement au développement de l'utilisation de ses solutions, monétiques ou d'achat en ligne, au sein des entreprises ; ils y apporteront facilité, sécurité et économies de traitement.
Un autre exemple peut être donné par la mise en place d'un système de cartes pour la prise en charge des repas des collaborateurs d'une entreprise dans un ou plusieurs des restaurants environnants, voire au sein d'un réseau de restaurants (union, réseau de franchisés, restauration succursaliste,...). Des cartes dotées d'un système d'identification du porteur, collaborateur d'une entreprise, pourront ainsi permettre à ce salarié de prendre ses repas dans le ou les restaurants avec lesquels l'entreprise aura signé un contrat garantissant, dans des limites et conditions définies sous forme de règles d'imputation et de contrôle, la prise en charge par débit direct de son repas. Selon le cadre contractuel adopté par l'entreprise, auquel le salarié aura adhéré pour bénéficier de la carte, le complément de la prise en charge pourra être soit immédiatement acquitté auprès du restaurateur par le collaborateur, soit débité sur son compte. Du fait de la prise en charge par l'entreprise, tous les éléments nécessaires au contrôle des repas pris en charge lui seront transmis ; cependant, les opérations se traduiront par un seul débit périodique facilitant ainsi la tenue comptable. Une variante de cette carte peut permettre de prendre en charge les tiers invités à des « repas d'affaires », le système de reporting mis en place en aval appelant de la part de l'invitant le nom ou la justification des personnes qu'il a invitées.
C.l.2.4 banque ou entreprise de crédit
Pour une banque ou une entreprise de crédit, le déploiement de solutions de type NP2 permet de rénover l'offre de services en direction des trois publics précédents : particuliers, entreprises, collectivités publiques.
Sur un marché aujourd'hui objet de critiques croissantes concernant le coût des services de paiement dispensés par les établissements de crédit, il est important pour ces organismes bancaires d'enrichir le service rendu et de proposer des offres novatrices.
De plus, le système NP2 apporte par conception des solutions simples pour offrir et gérer des services nouveaux que les banques ont, jusqu'à présent, tenté de proposer à leur clientèle et qui se sont régulièrement soldés par des échecs du fait de la complexité d'utilisation pour les clients et du coût de gestion pour la banque.
Il en est ainsi, par exemple, de nombreuses tentatives d'associer à une carte de paiement des services de fidélisation, de bons d'achat ou de réductions ciblées négociées avec des réseaux commerçants ou distributeurs. L'absence de système d'information commun à ces univers, qu'apporteront les chaînes de traitement NP2, a jusqu'à présent privé ces initiatives de succès durable. Pour l'examen des avantages du système NP2 pour la gestion de tels programmes, on se reportera à la partie C 3.1.3.
C.1.3 pour le marchand
Les solutions NP2 ouvrent également de nouvelles perspectives aux distributeurs, producteurs, commerçants et marchands dans leurs offres et capacités de mise en marché.
C.l.3.1 avantages en BtoB
Les solutions de paiement NP2 sont initialement conçues pour des déploiements de solutions monétiques nouvelles.
Elles ouvrent cependant des perspectives également nouvelles et pertinentes en B to B, où le choix d'un serveur de paiement NP2 au sein du serveur d'achat NP2 crée la possibilité nouvelle de proposer aux entreprises des solutions d'approvisionnement qui dialogueront efficacement et aisément avec leurs systèmes d'information interne et notamment leur système comptable (ERP , ...)•
En BtoB, un progrès majeur résultera de ce que l'invention qui prévoit d'inclure dans le rapport d'opérations des informations nécessaires à ce type de traitement, permet de disposer via le serveur de gestion des rapports NP2 d'une exploitation des ROIPE, capable de produire divers rapports de paiement, de contrôle et d'analyse, avec facilité et la sécurité qu'ils soient conformes aux législations et règles imposées par la matière.
Au prix d'un paramétrage initial, ces solutions de paiement en ligne NP2 peuvent apporter aux entreprises les bénéfices généralement attendus d'opérations de mise en place de chaînes d'approvisionnement, avec cependant plus de facilité.
Ce déploiement pourra devenir d'autant plus aisé et rapide que des standards se mettront en place par des mécanismes d'alliance des opérateurs NP2 avec les offres de supply chain, d'ERP ou de CRM pour la définition de codifications PFi, MA et RIC.
C.l.3.2 offres nouvelles dédiées à des clientèles spécifiques
Un des principaux débouchés du processus NP2 résidera dans la possibilité, nouvelle sous cette forme pour le marchand, de créer des cartes spécifiques pour des clientèles particulières, pour lesquels des facilités de gestion de prépaiement et la richesse des contrôles effectués lors de l'achat constituent des éléments décisifs de l'accès à des moyens de paiement monétique d'usage courant.
Pour les distributeurs, la faculté d'émettre des cartes de paiement innovantes, sur des clientèles cibles particulières constitue un atout commercial majeur.
Dans le domaine de la grande distribution ou de la distribution spécialisée en direction des consommateurs, le choix de solutions NP2 permet d'innover par une offre adaptée aux besoins de clientèles cibles particulières.
Les exemples donnés infra sur des clientèles jeunes ou, au contraire, âgées peuvent être reproduits sur différents publics : majeurs en tutelle ou curatelle, bénéficiaires d'aides publiques,
L'octroi de supports de paiement NP2 par des distributeurs à ces clientèles aura le double effet d'élargir leur pouvoir d'achat et de les fidéliser pour des dépenses dans les circuits de ces distributeurs ou de ces alliances de distributeurs et de commerçants.
Une adoption rapide de ces solutions peut aussi constituer le facteur différentiant qui offrira enfin à ces entreprises de distribution le moyen de réussir le développement de leurs offres de services bancaires, initiés par des groupes de la grande distribution jusqu'alors seulement à petite échelle.
C.2 évolution des supports de paiement
Le procédé NP2 conduit normalement à accélérer l'évolution des moyens de paiement. Il doit faciliter le développement d'applications sur des nouveaux supports et l'entrée de nouveaux acteurs industriels ou opérateurs et prestataires de service.
C.2.1 Pour le secteur télécom
L'architecture NP2 offre une perspective réellement nouvelle au déploiement de solutions de paiement sur des supports matériels issus du monde des télécommunications.
Les puissances de calcul désormais disponibles sur des téléphones mobiles, la possibilité d'échanges de données sans contact, par différents protocoles de communication sécurisés (AVIFI, RFID, 3G, ...), la convergence des outils mobiles téléphone et PDA, ... toutes les évolutions engagées font de ces outils des maillons naturels d'une chaîne de traitement monétique NP2.
Au prix d'une implémentation de programmes dédiés aux traitements NP2, les différents équipements de la téléphonie mobile se prêteront naturellement à la construction de solutions industrielles de déploiement de ces nouveaux services de paiement dans de multiples domaines.
Réciproquement, cette technologie apporte dans une très large mesure des solutions préexistantes aux besoins spécifiques des chaînes de traitement en matière de supports, mise en relation, processing et conservation des données cryptées.
Pour les opérateurs NP2, comme pour les opérateurs de téléphonie mobile, une alliance est donc naturelle et de bénéfices réciproques.
C.2.2 Application aux moyens de paiement
L'introduction des procédés et l' implémentation des programmes NP2 dans les supports de paiement existants est la première condition nécessaire au développement du NP2.
En l'état de l'art, ces supports risquent de n'être guère adaptés au déploiement des solutions les plus complexes, exploitant toute la richesse du nouveau procédé. ; .il en sera de même pour les systèmes de communication associés à ces supports existants.
La création de valeur apportée par le NP2 doit permettre de réunir les conditions de rentabilité justifiant l'investissement de modernisation à faire, pour satisfaire les exigences de telles applications. C'est ainsi que devrait s'accélérer la diffusion des innovations liées aux moyens de paiement : développement du « sans contact », recours à des solutions de paiement à partir du PDA ou de « Smartphones » qui mettront à profit sa puissance de calcul et les aptitudes à la communication de ces assistants personnels, que celle-ci utilise ou non les réseaux GSM ou UMTS ou 3 G, où toutes nouvelles technologies de « sans contact ».
La puissance du NP2 permet même d'imaginer deux applications dématérialisées de la technologie pour réaliser des supports de paiement virtuels ou ponctuels.
• Création d'un support de paiement virtuel
Le dispositif NP2 pourra également être implémenté sous forme virtuelle, de "porte monnaie", ajoutant un outil de paiement sur des objets ayant une autre finalité première que le paiement.
Un exemple caractéristique est fourni par les cartes servant désormais de clef de chambre d'hôtel. L'intégration sur cette carte d'un support de paiement NP2 permet de simplifier grandement les opérations de réception et de départ de l'hôtel.
Pour une prise de réservation, les chaînes hôtelières enregistrent généralement les références d'un moyen de paiement en garantie, parfois un acompte, parfois encore un prix payé correspondant le plus souvent à un ensemble de prestations (chambre pour x nuits, petit déjeuner inclus ou non, repas avec ou sans boissons,...). Au moment du départ, les diverses consommations faites par le client sont récapitulées, les prestations prépayées en sont retirées, une facture globale est éditée et le solde est payé par le client, souvent au moyen d'une carte de crédit.
Grâce à l'implantation du processus NP2 sur la carte servant de clé de chambre, il sera possible à l'arrivée du client de charger le support de paiement d'une enveloppe prépayée récapitulant les prestations prévues dans le forfait déjà acquitté (équivalent du voucher), ainsi que les caractéristiques de sa carte de crédit présentée en garantie à la réception lors de l'arrivée. Durant le séjour, le client utilise sa clé en identifiant et mode de règlement des diverses prestations consommées. Celles incluses dans le forfait prépayé s'y imputent, celles qui n'y sont pas incluses sont accumulées pour être débité au moment du départ sur la carte présentée lors de l'arrivée. Au terme du séjour, le règlement est immédiat : la carte restituée permet l'édition d'une facture récapitulant toutes les prestations, précisant leur imputation sur le forfait prépayé et facturant le surplus sur le numéro de carte de crédit choisi par le client à l'arrivée.
• Création d'un support de paiement ponctuel
Le procédé permet la fabrication d'un « jeton d'achat » qui peut être très simplement mis en place sur un support de paiement NP2, comme l'ouverture d'un service de financement, correspondant à un crédit d'achat, dans une limite déterminée, sous certaines conditions d'exercice (durée de validité, lieu), pour certains produits ou dans certains magasins, pour l'achat de certains articles voire d'un article en particulier.
Le support de paiement devient dans ce cas porteur de l'équivalent d'un bon d'achat, d'un reçu de paiement ou d'un bon de retrait, lisible sur un terminal de paiement NP2, bénéficiant aussi de la sécurité du mode d'authentification du support et du porteur.
Ce crédit pourra être chargé sur le support de paiement NP2 de diverses manières : lors d'un passage en magasin au moment de la connexion du support de paiement sur le terminal de paiement, connecté au serveur d'achat qui émet alors le crédit ; par connection sur le serveur de gestion porteur avant le passage en magasin. Auparavant, le crédit aura pu être constitué par l'acheteur sur son interface de gestion porteur ou encore au terme d'un achat en ligne, en décidant de payer par l'une des sources de financement et de se faire émettre sous cette forme et sur son support NP2 l'équivalent pratique d'un reçu destiné au retrait de l'achat ; dans ce dernier cas de figure cependant, le passage du support sur le terminal de paiement NP2 pour le retrait de l'achat vaudra « bonne fin » et finalisera le paiement, ce qui pour le consommateur présente un avantage évident. C.2.3 Dans le e-commerce
La mise en place de serveurs d'achat NP2 apportera au commerce électronique de nouveaux outils de promotion, marketing, analyse des marchés et prospection de nouvelles clientèles, ...
Pour les consommateurs, entreprises ou particuliers, le procédé NP2 apporte la perspective de nouveaux services et de réduction des coûts de gestion en aval.
Sa mise en jeu pourrait se faire par les divers outils d'authentification fournis par l'état de l'art, compatibles avec les outils NP2, avant connection au serveur d'achat NP2, ou bien encore via un terminal de lecture local.
C.3 par domaines de mise en œuvre C.3.1 source d'innovations pour des distributeurs en BtoC
Ce processus monétique offre une grande richesse d'applications commerciales nouvelles ou d'innovations qui apportent des facilités inédites dans la gestion des méthodes classiques de promotion commerciale.
C.3.1.1 bons d'achat
Plusieurs de ces applications commerciales sont directement liées à ce que le processus de paiement incorpore des données relatives à l'objet ou au service acheté.
Cela permet notamment de gérer de manière fine et cependant économique en traitements, la panoplie des promotions, bons d'achat, bons de réduction, en ciblant de manière fine les clientèles concernées et en disposant a posteriori d'une vision complète de l'impact commercial de ces actions promotionnelles.
Le bon d'achat pourra être remplacé par l'octroi d'un crédit prépayé valable de manière spécifique pour certains articles, une certaine période, dans certains magasins,...
Le mécanisme des rapports d'opérations permet un suivi précis de l'utilisation de ces bons et facilite l'analyse de leur efficacité commerciale.
C.3.1.2 cartes de paiement dédiées à des clientèles spéciales
Deux exemples sont ici détaillés.
• Les majeurs protégés
La population des majeurs protégés, personnes âgées, majeurs en tutelle ou en curatelle, regroupe un nombre croissant de personnes pour lesquelles, à aujourd'hui, les systèmes de gestion de la dépense quotidienne restent lourds et très souvent vécus comme humiliants. Ces personnes se voient le plus souvent dotées d'un petit pécule, pour une période de temps limité, octroyé par des parents ou par leur administrateur.
Cette façon de faire laisse malgré tout sans solution le problème du contrôle de la prohibition de certains achats (dépenses de jeu, achats d'alcool,...).
Pourtant ces personnes disposent en général dans leur entourage de parents ou d'alliés disposés à leur assurer soit des versements périodiques, soit un droit de tirage sur un de leurs comptes à la condition, en contrepartie, que des garanties leurs soient apportées sur le type d'achat auquel pourra servir leur argent.
Les supports de paiement NP2 sont précisément conçus pour apporter ce type de garantie ainsi que pour faciliter mise en place d'un droit de débit direct ou le rechargement périodique d'enveloppes prépayées
En facilitant le paiement pour des clientèles en situation de faiblesse, le procédé contribuera à solvabiliser leurs besoins de consommation et à attirer des besoins de « consommation pour autrui », correspondant aux souhaits de leurs enfants, parents ou amis de leur permettre, à distance, une consommation facile mais encadrée et limitée à certains types de dépenses.
De tels supports de paiement sont également adaptés pour la distribution de certaines aides sociales par des administrations publiques venant en aide à ces populations pour leurs moyens de subsistance ou pour certains types de dépenses particuliers.
• Les jeunes
Les clientèles jeunes se prêtent également tout particulièrement à des initiatives commerciales significatives organisées autour de la diffusion de « cartes jeune ».
D'une part, ces cartes permettent de gérer très simplement des tarifs spéciaux pour ces clientèles.
D'autre part, le processus permet très aisément d'offrir des facilités nouvelles de prépaiement pour les parents et alliés de ces jeunes.
Ainsi, les sociétés de distribution s'ouvrent également un champ d'action commerciale permettant de capter « l'argent de poche » donné aux jeunes par leurs parents et grands-parents, en garantissant un encadrement par nature de biens et services achetés de la dépense qui sera effectuée sur le montant prépayé.
Il devient ainsi possible aux parents et alliés du jeune de lui donner l'argent nécessaire pour l'achat, par exemple, d'ouvrages scolaires, de loisirs ou d'articles de sport, pour le paiement de leur nourriture... en veillant que ce qui est affecté à ces divers types de dépenses ne pourra être utilisé à un autre usage.
Les supports de paiement NP2 sont précisément conçus pour apporter ce type de garanties ainsi que pour faciliter la mise en place d'un droit de débit direct ou le rechargement périodique d'enveloppes prépayées, par des tiers au bénéfice du porteur.
De tels supports de paiement sont également adaptés pour la distribution de certaines aides sociales par des administrations publiques octroyant des aides aux jeunes ou certaines catégories déjeunes (étudiants, chômeurs,...) et pour certains types de dépenses particuliers.
C.3.1.3 unions de producteurs ou de commerçants
Pour de telles Unions, la possibilité de se grouper pour offrir un service des paiements de ce nouveau type est une vraie opportunité de changer leur image et d'obtenir une meilleure reconnaissance donc une amélioration de la fréquentation, notamment pour les clientèles ciblées ou des types de consommation spécifiques.
Une application directe des possibilités des systèmes NP2 adaptée à ces unions est la mise en place d'un système de points de fidélité, accepté au sein de cette union, gérable de manière spécialement facile dans ce système. Les points de fidélité peuvent en effet être gérés comme une source de financement, crédités au fil des dépenses selon un règle définie ad hoc ; le crédit accumulé sur cette enveloppe devient libératoire selon des conditions fixées elles aussi par le système de règles RIC NP2 : le paiement par imputation sur cette ligne n'étant possible que dans certaines conditions (magasins, objets de l'achat, ...).
La gestion de ces points de fidélité sous cette forme aura aussi pour avantage de normaliser le mécanisme de suivi de cette « quasi monnaie » en fort développement, et qui commence à devenir une source d'incertitude même pour les autorités de régulation.
C.3.2 AtoC
C.3.2.1 La carte de consommation d'une aide publique
Du fait des capacités natives de contrôle de la nature des dépenses et du fait de la finesse de restitution des opérations, les solutions NP2 sont particulièrement adaptées à la gestion d'aides publiques. Selon le degré de détail et de complexité apporté aux règles et contrôles, ce système se prête même à la gestion d'aides subordonnées à diverses conditions.
Le chargement de comptes périodiquement prépayés ou l'attribution de droits de tirage avec limitation associée peuvent être deux modalités de dispense de ces aides via un support NP2.
Ce support peut être soit exclusivement consacré à la gestion des politiques d'une collectivité donnée (carte services d'une collectivité ou autorité locale), ou bien rassembler les aides des diverses collectivités destinées à un même public (étudiants, chômeurs, personnes âgées, handicapés, ...).
Le support porteur de ces aides peut être dédié à ce type de sources de financement ou bien se compléter d'une source de financement supplémentaire débitée sur le compte courant du porteur ou prépayée par lui. Dans cette hypothèse de création de cartes à la fois personnelles et de gestion d'aides publiques, les dépenses effectuées au delà des montants d'aide alloués ou en dehors des conditions exigées pourront être cependant acquittées par un même règlement, compensé sur plusieurs sources de financement. Cette modalité est d'utilisation plus discrète par les bénéficiaires.
C.3.2.2 La dépense de soins
Le cas de la gestion des dépenses de santé en France et de l'utilisation de la carte vitale constitue un autre excellent exemple de la puissance du système NP2.
Comme cela a déjà été indiqué plus haut, le monde de la santé en France organise une répartition du prix de la dépense de soins entre divers débiteurs et tiers payants :
• le ticket modérateur est la part restant à la charge de l'assuré social,
• la caisse de sécurité sociale porte une part de remboursement, variable selon le médicament et selon qu'il a ou non été prescrit par un médecin,
• la mutuelle intervient pour une quote part
• ainsi, le cas échéant, qu'une assurance complémentaire,
• il faut aussi intégrer les cas du dépassement d'honoraires, de la substitution en pharmacie d'un générique mieux remboursé à un médicament, etc.
En pratique, même avec l'utilisation de la carte vitale, les créances se règlent soit par un "jeu de cartes" au paiement, soit par la gestion de règles complexes de remboursement au niveau de systèmes centraux de compensation et de règlement, soit encore par un surcoût élevé de gestion manuelle.
Dans le schéma NP2, il est rendu aisé au consommateur, via l'interface porteur, de réunir sur un même support ses diverses sources de financement.
C'est en effet lui qui, pour peu qu'on lui en donne la possibilité de manière techniquement aisée, sera celui qui aura la meilleure vision de ses diverses ressources et mécanismes de couverture sociale. En en prenant conscience, il peut redevenir clairement responsable de ses choix et arbitrages.
En pratique, en sortie de pharmacie, le paiement par un seule carte NP2 dûment renseignée et paramétrée permettra de solder, par exemple :
• l'aspirine prescrite par le médecin traitement ; o acquittée à 65% par la CPAM o à 20% par la mutuelle o les 15% restant sur son compte principal
• le médicament à vignette bleue : o imputé à 35 % sur la CPAM o couvert à 30 % par la caisse mutuelle o le solde sur le compte principal
• mais aussi les articles de parapharmacie, par exemple : o les articles de consommation courante qui sont imputés sur le compte courant o les produits de maquillage qui pourraient être, par choix et règle posée par le porteur, réservés à une imputation sur un budget (beauté santé) correspondant à une enveloppe prépayée.
Le NP2 permet ainsi l'imputation différentiée article par article ainsi que, simultanément, le contrôle de l'imputation ou la répartition de la charge entre sources de financement.
Ce mécanisme se prête tout particulièrement au domaine de la Santé.

Claims

REVENDICATIONS
1. Procédé de paiement par un porteur à un marchand grâce à un moyen de paiement, caractérisé en ce qu'il est procédé par imputations successives, pour chaque produit, bien ou service présenté à l'achat, une imputation s'opérant entre plusieurs sources de financement, et consistant en un débit sur l'une des sources de financement ou un transfert depuis l'une de ces sources de financement ; et en ce que, à chaque imputation, sont lues des données stockées dans le moyen de paiement et/ou dans des bases de données d'un serveur de paiement, ces données étant accessibles par liaison à un système central ou sur une réplication locale, lesdites données étant utilisées par le serveur de paiement pour sélectionner puis confronter des règles d'imputation et de contrôle, définies, pour chaque source de financement, par le porteur du moyen de paiement ou par le financeur à des données fonction des caractéristiques :
• du bien, du produit ou du service présenté à l'achat
• des conditions de l'achat, comprenant par exemple la date, des vérifications matérielles opérées au moment de l'achat, des options choisies par l'acheteur ainsi qu'à des données issues d'une base de données relatives aux marchands et à des catégories de produits, biens ou services.
2. Procédé selon la revendication 1 , caractérisé en ce que l'imputation peut être opérée sur une fraction du prix du produit, bien ou service présenté à l'achat, chaque fraction de prix pouvant être imputée sur une source de financement différente.
3. Procédé selon la revendication 1 ou 2, dans lequel, pour chaque imputation est émis un rapport associant à l'imputation concernée l'enregistrement des éléments d'information requis pour le contrôle de cette imputation.
4. Procédé selon l'une des revendications 1 à 3, dans lequel l'application des règles de contrôle et d'imputation sert à contrôler la régularité et la licéité de chaque imputation au regard des règles choisies par le porteur et/ou le marchand et/ou le financeur.
5. Procédé selon l'une des revendications 1 à 4, dans lequel la gestion des données par imputations élémentaires de paiement aboutit pour chaque imputation à la double production, d'une part, d'un rapport de compensation émis pour le paiement de cette imputation et, d'autre part, à la production puis la gestion d'un rapport d'opération d'imputation élémentaire, intégrant les éléments d'information découlant du paiement et des contrôles effectués lors de l'imputation, notamment en vue de son exploitation ultérieure à des fins de contrôle, d'analyse ou d'exploitation statistique
6. Procédé selon l'une des revendications 1 à 5, dans lequel la gestion des rapports d'opération est organisée de telle sorte que chacun des destinataires ne peut recevoir d'informations issues de ces rapports que dans la proportion de droits à en connaître propres à chaque destinataire.
7. Procédé selon l'une des revendications précédentes, dans lequel des points de fidélité sont gérés sur une source de financement dédiée parmi celles intégrées au moyen de paiement, les points de fidélités étant accumulés au fur et à mesure des paiements, conformément aux règles d'imputation et de contrôle caractéristiques de l'acquisition de ces points de fidélité, suivis à l'aide des rapports relatifs à l'évolution de cette source de financement.
8. Procédé selon la revendication 7, dans laquelle les points de fidélité accumulés sur la source de financement dédiée peuvent être utilisés directement par tirage sur cette source de financement, conformément au règles d'imputation et de contrôle qui en régissent l'utilisation.
9. Procédé selon l'une des revendications précédentes, dans lequel une imputation est réalisée en fonction de données représentant un choix effectué par le porteur, notamment le choix de la source de financement qu'il souhaite imputer, ces données étant soit préalablement stockées soit saisies lors du paiement.
10. Procédé selon l'une des revendications précédentes, dans lequel une imputation est réalisée en fonction de données représentant des contrôles effectués par le marchand, ces données étant soit préalablement stockées soit saisies lors du paiement.
11. Système de paiement de biens, produits ou services, par un porteur, à un marchand permettant de procéder au paiement par imputations successives, pour chaque produit, bien ou service présenté à l'achat, une imputation s'opérant entre plusieurs sources de financement, et consistant en un débit sur l'une des sources de financement ou un transfert depuis l'une de ces sources de financement, le système comprenant :
- un support de paiement, propre au porteur ;
- un terminal de paiement, apte à lire et authentifier le support de paiement et à transmettre les données qu'il contient à un serveur de paiement ;
- un terminal d'achat, apte à identifier les biens, produits et services achetés, et à transmettre ces données à un serveur de paiement un serveur de paiement, connecté au terminal d'achat et au terminal de paiement pour en recevoir des données, réalisant les opérations d'imputations successives lors du paiement en fonction des données stockées dans des bases de données, ces bases étant accessibles par liaison à un système central ou sur une réplication locale, lesdites données étant utilisées par le serveur de paiement pour sélectionner puis confronter des règles d'imputation et de contrôle, définies, pour chaque source de financement, par le porteur du support de paiement ou par le financeur, à des données fonction des caractéristiques :
• du bien, du produit ou du service présenté à l'achat
• des conditions de l'achat, comprenant par exemple la date, des vérifications matérielles opérées au moment de l'achat, des options choisies par l'acheteur ainsi qu'à des données issues d'une base de données relatives aux marchands et à des catégories de produits, biens ou services.
12. Système selon la revendication 1 1 , caractérisé en ce que le serveur de paiement comprend des moyens pour opérer chaque imputation sur une fraction du prix du produit, bien ou service présenté à l'achat, chaque fraction de prix pouvant être imputée sur une source de financement différente.
13. Système selon la revendication 11 ou 12, dans lequel le serveur de paiement comprend des moyens pour émettre, pour chaque imputation, un rapport associant à l'imputation concernée l'enregistrement des éléments d'information requis pour le contrôle de cette imputation.
14. Système selon l'une des revendications 11 à 13, dans lequel l'application des règles de contrôle et d'imputation sert à contrôler la régularité et la licéité de chaque imputation au regard des règles choisies par le porteur et/ou le financeur et/ou le marchand.
15. Système selon l'une des revendications 11 à 14, dans lequel la gestion des données par imputations élémentaires de paiement permet au serveur de paiement de produire, pour chaque imputation, d'une part, un rapport de compensation émis pour le paiement de cette imputation et, d'autre part, un rapport d'opération d'imputation élémentaire, ce rapport intégrant les éléments d'information découlant du paiement et des contrôles effectués lors de l'imputation, notamment en vue de son exploitation ultérieure à des fins de contrôle, d'analyse ou d'exploitation statistique
16. Système selon l'une des revendications 11 à 15, dans lequel le serveur de paiement comprend des moyens de gestion des rapports d'opération, ces moyens étant tels que chacun des destinataires ne peut recevoir d'informations issues de ces rapports que dans la proportion de droits à en connaître propres à chaque destinataire.
17. Système selon l'une des revendications 11 à 16, dans lequel des points de fidélité sont gérés sur une source de financement dédiée parmi celles intégrées au support de paiement, les points de fidélité étant accumulés au fur et à mesure des paiements, conformément aux règles d'imputation et de contrôle caractéristiques de l'acquisition de ces points de fidélité, suivis à l'aide des rapports relatifs à l'évolution de cette source de financement.
18. Système selon la revendication 17, dans laquelle les points de fidélité accumulés sur la source de financement dédiée peuvent être utilisés directement par tirage sur cette source de financement, conformément aux règles d'imputation et de contrôle qui en régissent l'utilisation.
19. Système selon l'une des revendications 1 1 à 18, dans lequel une imputation est réalisée en fonction de données représentant un choix effectué par le porteur, notamment le choix de la source de financement qu'il souhaite imputer, ces données étant, soit préalablement stockées, soit saisies lors du paiement, sur le support de paiement ou le terminal de paiement.
20. Système selon l'une des revendications 1 1 à 19, dans lequel une imputation est réalisée en fonction de données représentant des contrôles effectués par le marchand, ces données étant, soit préalablement stockées, soit saisies lors du paiement sur le terminal d'achat.
21. Système selon l'une des revendications 11 à 20, comprenant une interface de gestion dédiée au porteur, comprenant des moyens permettant au porteur de créer et/ou de modifier les règles d'imputation et de contrôle applicables et/ou des sources de financement.
22. Système selon l'une des revendications 11 à 21 , comprenant une interface de gestion marchand, comprenant des moyens permettant au marchand de créer et/ou de modifier les règles d'imputation et de contrôle applicables et/ou des catégories de biens, produits ou services.
23. Système selon l'une des revendications 11 à 22, comprenant une interface de gestion financeur, comprenant des moyens permettant au financeur d'une des sources de financement de créer et/ou de modifier les règles d'imputation et de contrôle applicables.
24. Système de paiement à distance, par un porteur, de biens, produits ou services à un marchand et permettant de procéder au paiement par imputations successives, pour chaque produit, bien ou service présenté à l'achat, une imputation s'opérant entre plusieurs sources de financement, et consistant en un débit sur l'une des sources de financement ou un transfert depuis l'une de ces sources de financement, le système comprenant :
- un moyen de paiement, propre au porteur, pouvant réunir plusieurs sources de financement ; un serveur d'achat, apte à identifier les biens, produits et services présentés à l'achat par le porteur,
- un serveur de paiement, en liaison avec le serveur d'achat, réalisant les opérations d'imputations successives lors du paiement, en fonction de données fournies par le serveur d'achat et de données stockées dans des bases de données, ces bases étant accessibles par liaison à un système central ou sur une réplication locale, lesdites données étant utilisées par le serveur de paiement pour sélectionner puis confronter des règles d'imputation et de contrôle, définies, pour chaque source de financement, par le porteur du moyen de paiement ou par le financeur, à des données fonction des caractéristiques :
• du bien, du produit ou du service présenté à l'achat
• des conditions de l'achat, comprenant par exemple la date, des vérifications opérées au moment de l'achat, des options choisies par l'acheteur ainsi qu'à des données issues d'une base de données relatives aux marchands et à des catégories de produits, biens ou services.
25. Système selon la revendication 24, caractérisé en ce que le serveur de paiement comprend des moyens pour opérer chaque imputation sur une fraction du prix du produit, bien ou service présenté à l'achat, chaque fraction de prix pouvant être imputée sur une source de financement différente.
26. Système selon la revendication 24 ou 25, dans lequel, le serveur de paiement comprend des moyens pour émettre, pour chaque imputation, un rapport associant à l'imputation concernée l'enregistrement des éléments d'information requis pour le contrôle de l'imputation.
27. Système selon l'une des revendications 24 à 26, dans lequel l'application des règles de contrôle et d'imputation sert à contrôler la régularité et la licéité de chaque imputation au regard des règles choisies par le porteur et/ou le marchand et/ou le financeur.
28. Système selon l'une des revendications 24 à 27, dans lequel la gestion des données par imputations de paiement permet au serveur de paiement de produire, pour chaque imputation, d'une part, un rapport de compensation émis pour le paiement de cette imputation et, d'autre part, un rapport d'opération d'imputation élémentaire, ce rapport intégrant les éléments d'information découlant du paiement et des contrôles effectués lors de l'imputation, notamment en vue de son exploitation ultérieure à des fins de contrôle, d'analyse ou d'exploitation statistique.
29. Système selon l'une des revendications 24 à 28, dans lequel le serveur de paiement comprend des moyens de gestion des rapports d'opération, ces moyens étant tels que chacun des destinataires ne peut recevoir d'informations issues de ces rapports que dans la proportion de droits à en connaître propres à chaque destinataire.
30. Système selon l'une des revendications 24 à 29, dans lequel des points de fidélité sont gérés sur une source de financement dédiée parmi celles intégrées au moyen de paiement, les points de fidélité étant accumulés au fur et à mesure des paiements, conformément aux règles d'imputation et de contrôle caractéristiques de l'acquisition de ces points de fidélité, suivis à l'aide des rapports relatifs à l'évolution de cette source de financement.
31. Système selon la revendication 30, dans laquelle les points de fidélité accumulés sur la source de financement dédiée peuvent être utilisés directement par tirage sur cette source de financement, conformément aux règles d'imputation et de contrôle qui en régissent l'utilisation.
32. Système selon l'une des revendications 24 à 31 , dans lequel une imputation est réalisée en fonction de données représentant un choix effectué par le porteur, notamment le choix de la source de financement qu'il souhaite imputer, ces données étant, soit préalablement stockées dans le serveur d'achat, saisies lors du paiement et transmises au serveur d'achat.
33. Système selon l'une des revendications 24 à 32, dans lequel une imputation est réalisée en fonction de données représentant des contrôles effectués par le marchand, ces données étant préalablement stockées dans le serveur d'achat.
34. Système selon l'une des revendications 24 à 33, comprenant une interface de gestion dédiée au porteur, comprenant des moyens permettant au porteur de créer et/ou de modifier les règles d'imputation et de contrôle applicables.
35. Système selon l'une des revendications 24 à 34, comprenant une interface de gestion marchand, comprenant des moyens permettant au marchand de créer et/ou de modifier les règles d'imputation et de contrôle applicables.
36. Système selon l'une des revendications 24 à 35, comprenant une interface de gestion financeur, comprenant des moyens permettant au financeur d'une des sources de financement de créer et/ou de modifier les règles d'imputation et de contrôle applicables.
EP07848326A 2006-09-15 2007-09-17 Procédé et systèmes de paiement Ceased EP2074569A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US84494706P 2006-09-15 2006-09-15
PCT/FR2007/051953 WO2008032005A2 (fr) 2006-09-15 2007-09-17 Procédé et systèmes de paiement

Publications (1)

Publication Number Publication Date
EP2074569A2 true EP2074569A2 (fr) 2009-07-01

Family

ID=39135142

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07848326A Ceased EP2074569A2 (fr) 2006-09-15 2007-09-17 Procédé et systèmes de paiement

Country Status (3)

Country Link
US (1) US20110035268A1 (fr)
EP (1) EP2074569A2 (fr)
WO (1) WO2008032005A2 (fr)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2002336770A1 (en) 2001-09-24 2003-04-07 E2Interactive, Inc. D/B/A E2Interactive, Inc. System and method for supplying communication service
US20090182586A1 (en) * 2008-01-10 2009-07-16 Cohane Joseph P Point-of-sale, value-added payment processing system and method thereof
US10255609B2 (en) * 2008-02-21 2019-04-09 Micronotes, Inc. Interactive marketing system
EP2151794A1 (fr) * 2008-07-28 2010-02-10 Norpla - Card Systems Management GmbH Procédé d'exécution d'un paiement électronique
CN102918554A (zh) * 2010-05-25 2013-02-06 日本电气株式会社 虚拟货币的结算和汇寄处理方法，结算和汇寄处理系统及结算和汇寄处理程序
CN102906774A (zh) * 2010-05-25 2013-01-30 日本电气株式会社 用于使用多种清算手段来执行多清算的方法、用于执行多清算的设备、以及用于执行多清算的程序
US8442913B2 (en) * 2010-06-29 2013-05-14 Visa International Service Association Evolving payment device
US11055686B2 (en) 2012-08-08 2021-07-06 E2Interactive, Inc. S/M for providing, reloading, and redeeming stored value cards used in transit applications
US9569769B2 (en) 2012-09-17 2017-02-14 E2Interactive, Inc. Composite activation indicia substrate
US10062075B2 (en) * 2013-11-04 2018-08-28 E2Interactive, Inc. Systems and methods for using a dual function medical benefits card
US11120462B2 (en) 2013-11-04 2021-09-14 E2Interactive, Inc. Systems and methods for using indicia of membership as a partial authorization in a transaction
US20150127500A1 (en) * 2013-11-05 2015-05-07 Bank Of America Corporation Determining financial account payment hierarchy for recovery of payment in arrears
US9088654B2 (en) * 2013-11-05 2015-07-21 Bank Of America Corporation Communication disposition determination for unified recovery system for payments in arrears
US8971516B1 (en) * 2013-11-05 2015-03-03 Bank Of America Corporation Unified recovery system communication history tracking for payments in arrears
FR3019356B1 (fr) * 2014-03-25 2016-04-15 David Haddad Procede et systeme de paiement divise d'un produit ou service
EP3164837A1 (fr) * 2014-07-01 2017-05-10 Francesco Ricci Système de paiement électronique et procédé associé
US10621664B2 (en) * 2016-05-18 2020-04-14 Fannie Mae Using automated data validation in loan origination to evaluate credit worthiness and data reliability
FR3081076B1 (fr) * 2018-05-14 2023-12-08 Ingenico Group Procede de gestion d'au moins un remboursement d'une prestation de sante, dispositif et programme d'ordinateur correspondants

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998047116A1 (fr) * 1997-04-15 1998-10-22 Telefonaktiebolaget Lm Ericsson (Publ) Procede et appareil de paiement par telecommunications/transmission de donnees
US6084528A (en) * 1996-09-05 2000-07-04 Symbol Technologies, Inc. Intranet scanning terminal system
EP1098280A2 (fr) * 1999-11-02 2001-05-09 Ncr International Inc. Dispositif et méthode de fonctionnement d'un système de caisse d'enregsitrement
US20010042021A1 (en) * 1999-12-06 2001-11-15 Taiichi Matsuo Electronic settling system and electronic settling method
US20040044621A1 (en) * 2002-08-27 2004-03-04 Visa U.S.A., Inc. Method and system for facilitating payment transactions using access devices
US20040148252A1 (en) * 2001-01-26 2004-07-29 Jack Fleishman Online payment transfer and identity management system and method

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060178986A1 (en) * 2000-02-17 2006-08-10 Giordano Joseph A System and method for processing financial transactions using multi-payment preferences
US6805288B2 (en) * 2000-05-15 2004-10-19 Larry Routhenstein Method for generating customer secure card numbers subject to use restrictions by an electronic card
EP1170685A3 (fr) * 2000-06-29 2004-03-03 Hitachi, Ltd. Carte de crédit associée, ainsi système et méthode de règlement par carte de crédit
US20020095386A1 (en) * 2000-12-07 2002-07-18 Maritzen L. Michael Account control and access management of sub-accounts from master account
US7840495B2 (en) * 2001-08-03 2010-11-23 Jay Levenson System and method for the payment and accounting of petty disbursements
EP1450320A1 (fr) * 2003-02-21 2004-08-25 Swisscom Mobile AG Module de paiement avec plusieurs comptes bancaires, système de paiement et méthode de paiement
US20050137949A1 (en) * 2003-12-17 2005-06-23 Danny Rittman Automatic, characterized and prioritized transactions to credit card accounts from one credit card account, method and computer software
US20070164098A1 (en) * 2004-12-28 2007-07-19 ATM Khalid Staging of Financial Accounts: The Ultimate Charge Account and Ultimate Credit/ATM Card

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6084528A (en) * 1996-09-05 2000-07-04 Symbol Technologies, Inc. Intranet scanning terminal system
WO1998047116A1 (fr) * 1997-04-15 1998-10-22 Telefonaktiebolaget Lm Ericsson (Publ) Procede et appareil de paiement par telecommunications/transmission de donnees
EP1098280A2 (fr) * 1999-11-02 2001-05-09 Ncr International Inc. Dispositif et méthode de fonctionnement d'un système de caisse d'enregsitrement
US20010042021A1 (en) * 1999-12-06 2001-11-15 Taiichi Matsuo Electronic settling system and electronic settling method
US20040148252A1 (en) * 2001-01-26 2004-07-29 Jack Fleishman Online payment transfer and identity management system and method
US20040044621A1 (en) * 2002-08-27 2004-03-04 Visa U.S.A., Inc. Method and system for facilitating payment transactions using access devices

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"PORTABLE SELF-CHECKOUT RETAIL SYSTEM", IBM TECHNICAL DISCLOSURE BULLETIN, INTERNATIONAL BUSINESS MACHINES CORP. (THORNWOOD), US, vol. 35, no. 1A, 1 June 1992 (1992-06-01), pages 315 - 318, XP000308880, ISSN: 0018-8689 *

Also Published As

Publication number Publication date
WO2008032005A2 (fr) 2008-03-20
WO2008032005A3 (fr) 2008-06-12
US20110035268A1 (en) 2011-02-10

Similar Documents

Publication Publication Date Title
EP2074569A2 (fr) Procédé et systèmes de paiement
Baddeley Using e-cash in the new economy: An economic analysis of micro-payment systems
KR101882187B1 (ko) 지역 내발적 발전 플랫폼의 운영 시스템 및 방법
US7168616B2 (en) Bank card with lottery feature
US8311940B2 (en) Conditional balance management for non-issuer debit instruments
US20050165682A1 (en) Benefits card mechanisms
Kumaga The challenges of implementing electronic payment systems–The case of Ghana’s E-zwich payment system
WO2000036570A1 (fr) Procede et appareil de realisation de transactions commerciales electroniques avec des mineurs
CN103718200A (zh) 用于通过电子钱包支付的系统
CA2416550A1 (fr) Systemes de gestion d'avoirs perfectionnes
US20220398619A1 (en) A method for credit card integration within a product tree based multi-level marketing system
US20220398622A1 (en) Method for banking integration within a product tree based multi-level marketing system
Wah Banking on the Internet
WO2010033081A2 (fr) Système de serveur sécurisé pour transactions en ligne
US20210027261A1 (en) System and method for operating region-originating development platform
Pallathadka et al. Impact of COVID adoption of cashless methods among general public in India
US20180300707A1 (en) Payment method and systems
Carton et al. Developing a framework for mobile payments integration
Mehilli An empirical study on the adoption of cryptocurrency E-payment systems in Italian business platforms
Gupta E-Wallet: Challenges for rural market
Milkau A ‘Digital Euro’as an approach for frictionless payment processes
Council Report on new payment solutions
Park et al. STUDY ON THE IMPROVEMENT OF MOBILE GAME PAY MENT USING BLOCKCHAIN
DOLLAR International Cooperation in and Regulation of Fintech Development
Lukić et al. THE NEED AND THE CHALLENGES OF THE INTRODUCTION OF CENTRAL BANK DIGITAL CURRENCIES.

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20090414

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20091015

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20211123