[go: up one dir, main page]

WO2008125937A2 - Telecommunication system for secure transaction management, and related method - Google Patents

Telecommunication system for secure transaction management, and related method Download PDF

Info

Publication number
WO2008125937A2
WO2008125937A2 PCT/IB2008/000836 IB2008000836W WO2008125937A2 WO 2008125937 A2 WO2008125937 A2 WO 2008125937A2 IB 2008000836 W IB2008000836 W IB 2008000836W WO 2008125937 A2 WO2008125937 A2 WO 2008125937A2
Authority
WO
WIPO (PCT)
Prior art keywords
seller
buyer
processing means
central processing
delivery code
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
PCT/IB2008/000836
Other languages
French (fr)
Other versions
WO2008125937A8 (en
Inventor
Giuseppe Asselle
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 WO2008125937A2 publication Critical patent/WO2008125937A2/en
Publication of WO2008125937A8 publication Critical patent/WO2008125937A8/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06QINFORMATION 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/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems

Definitions

  • the present invention relates to a telecommunication system, as well as to an associated method, for the secure management of transactions pertaining to products and/or services.
  • Telecommunication systems which are adapted to put a buyer in contact with a seller of products or a provider of services (hereafter also simply referred to as seller) for making transactions; in particular, in the last few years the so-called electronic commerce (e-commerce) has become increasingly important as a part of the overall commercial trade volume.
  • e-commerce electronic commerce
  • the spread of the Internet has doubtlessly played a fundamental role in this respect.
  • a user of a client device can in fact connect to a plurality of servers to gain access to a plurality of on-line e-commerce sites, e.g. in order to buy products or request services of various kinds.
  • the present invention provides a telecommunication system for managing transactions of products and/or services and an associated management method, as set out in claims 1 and 11, respectively.
  • - Fig. 1 is a block diagram of a general architecture of a transaction management telecommunication system according to an embodiment of the present invention
  • - Fig. 2 is a flow chart showing the steps involved in associating a purchase offer with a sale offer in the telecommunication system of Fig. 1;
  • - Figs. 3-11 are screens displayed on one or more client devices during the steps of the flow chart of Fig. 2; and - Figs. 12 and 13 are flow charts showing the steps involved in executing a transaction in the telecommunication system of Fig. 1.
  • a telecommunication system 1 for managing transactions pertaining to products and/or services comprises an interconnection network 2 adapted to allow a telecommunication connection to be established and data to be exchanged between a server 3, controlled by an entity that manages, supervises and monitors telecommunication system 1, and at least a first and a second client devices 4, 5, respectively controlled by a buyer and by a seller/provider.
  • the buyer and the seller/provider may be a company or a private person, and are subscribers of the e- commerce telecommunication service provided by server 3.
  • Interconnection network 2 is generally the Internet network, but it may also be any other wired or wireless network adapted to allow data to be exchanged between the machines belonging to telecommunication system 1, e.g.
  • first and second client devices 4, 5 may be any devices adapted to allow access to the network resources; therefore, though they are depicted in Fig. 1 as personal computers, they may also be a PDA (Personal Digital Assistant), e mobile telephone with network access functionality, a decoder (also called “set-top box”), or any other known Internet terminal.
  • server 3 comprises a central processing unit 6, a central memory 7, and a communication interface module 8 adapted to allow data to be sent and received through interconnection network 2.
  • server 3 hosts an e-commerce site for managing transactions of products and services among registered users; for this purpose, central memory 7 stores a plurality of web pages, e.g. created by using the HTML language (Hypertext Markup Language), as well as a plurality of databases.
  • HTML language Hypertext Markup Language
  • user information such as name, address, preferences, previously placed orders
  • the retrieval of user information may be facilitated by the use of a "cookie" conveniently stored in the respective client device.
  • central processing unit 6 of server 3 operates and interacts with the aforementioned databases and communication interface module 8 in order to supply web pages to a client device, in particular by reacting to selections and data sent by a user of the client device through interconnection network 2.
  • Each of the first and second client devices 4, 5 is provided with a local processing unit 10 (e.g. a CPU - Central Processing Unit) and with a local memory 11 for storing data and applications, among which at least one communication interface (e.g. a web browser) for interfacing to interconnection network 2 and accessing the e-commerce site hosted by server 3.
  • each client device has data input means 12 (e.g. a keyboard or a mouse) adapted to allow the user to interact with telecommunication system 1, in particular to send data to server 3, as well as visualization means 13 (e.g. a display) for displaying, among other things, web pages 14 and data associated thereto.
  • the connection between the client devices and the server may take place through a secure channel (e.g. an SSL [Secure Sockets Layer] channel), in order to reduce the risk of interception of sensible data.
  • SSL Secure Sockets Layer
  • a banking body 15 and a guarantor body 16 are also connected to interconnection network 2, both of which are bound to the entity that manages telecommunication system 1 by a specific agreement (or convention) which regulates their reciprocal co-operation for the provision of the telecommunication service.
  • guarantor body 16 may be an insurance company, a bank, a financial company, or a public or private fund constituted or intended specifically for this purpose.
  • telecommunication system 1 also comprises a transaction control device 18 owned by the users who have subscribed to the telecommunication service.
  • Transaction control device 18 is, for example, a non-programmable portable electronic device, and may be configured as a stand-alone device or as a peripheral device of a respective client device to which it is connected, for example, by means of a USB connector 19.
  • Transaction control device 18 is also fitted with an alphanumerical display, an alphanumerical keypad (or a similar input device) for data input, signalling means, e.g. LEDs, and an electronic circuit including a memory and a local processor.
  • Transaction control device 18, and in particular the memory and local processor thereof are advantageously equipped with tamper-resistant technology, thus avoiding any undesired external access and in particular not allowing the memory contents to be read from the outside.
  • a user wanting to buy a product or a service accesses server 3 through first client device 4, in particular the home page of the e-commerce site hosted by server 3.
  • a screen is thus displayed on visualization means 13 of first client device 4, shown by way of example in Fig.
  • each transaction is made under a specific guarantee granted to the buyer by guarantor body 16.
  • the buyer when subscribing to the telecommunication service, the buyer must select a guarantor (of which he/she is a customer) to be referred to among a list of guarantors bound to the entity that manages telecommunication system 1 by specific agreements.
  • the entity that manages telecommunication system 1 then communicates the buyer data to the selected guarantor body; the latter verifies that the buyer is actually one of his customers and has a line of credit for the issue of guarantees. Only if such verifications have a positive outcome, the buyer's subscription will be accepted and the procedure can proceed.
  • the buyer has the possibility to enter a purchase offer which, if accepted, will be stored in purchase offer database 9a of central memory 7 of server 3.
  • Entering a purchase offer involves inputting data about said offer, among which, as shown by way of example in the screenshot of Fig.5: market sector; product/service type; state, region and place of delivery; description of the object; expiry date of the offer and consequently the deadline of the delivery/implementation of the product/service ; associated INCOTERMS code; and payment method.
  • the buyer may also select a first transaction execution mode, called “deposit version”, and a second transaction execution mode, called “guarantee version” (both of which will be described in detail below).
  • the buyer must also enter the code (or another identifier) of the guarantor body 16 designated when the subscription was made.
  • the process flow implemented in telecommunication system 1 proceeds to block 24, wherein the entity that manages telecommunication system 1 verifies the purchase offer entered by the buyer.
  • said verification is essentially limited to checking that the various fields have been filled in and that the data entered is consistent.
  • the entity that manages the telecommunication system sends the purchase offer details, e.g. through interconnection network 2, to guarantor body 16, which then verifies the actual existence of a line of credit for the issue of guarantees in favour of the buyer.
  • the purchase offer identification code may for example consist of a progressive day field followed by a field corresponding to the date of entry, in turn followed by a field consisting of the code of the associated guarantor body, if present (guarantee version) or a fixed code (deposit version).
  • a purchase offer identification code may be "55100220076033", where "55” is the progressive day field, "10022007” is the field stating the date of entry, and "6033" is the field of the guarantor/fixed code.
  • the purchase offer entered can be freely consulted by selecting the item for viewing the purchase offer list on the site's home page. Figs.
  • each new purchase offer can be sent automatically by server 3 to all users who have subscribed to a mailing list correlated to the purchase offer, e.g. based on a specific market sector or place of purchase. In particular, it should be underlined that at this level the purchase offer is wholly encoded but still completely anonymous.
  • the published purchase offer will then be removed from the site if any of the following conditions occur: the buyer places an order by accepting one of the received sale offer (as described below); the buyer cancels the purchase offer; the maximum purchase offer publication time set by the telecommunication service expires.
  • a seller/provider connected to server 3 through interconnection network 2 may, through second client device 5, view the various published purchase offers and enter one or more sale offers in response to corresponding purchase offers.
  • the detailed screen of each purchase offer includes an item for entering a corresponding sale offer.
  • the seller/provider After having entered his/her user code and password (and, if necessary, after having subscribed to the telecommunication service in the same manner as previously described), the seller/provider enters at least one offered price and possibly some additional details about the sale offer, see screenshot of Fig. 9.
  • the entered sale offer is confirmed, the data thereof is stored in sale offer database 9b of server 3, and a sale offer identification code is assigned and sent to the seller/provider.
  • Said code may consist, for example, of the corresponding purchase offer identification code followed by a progressive field; the sale offer identification code corresponding to the purchase offer identification code "55100220076033" may be, for example, "55100220076033 0014".
  • the entered sale offer is also wholly encoded but still anonymous.
  • the buyer receives each sale offer relating to a previously entered purchase offer from server 3, e.g. by e-mail.
  • the buyer can view on-line the list of sales offers relating to a particular purchase offer by selecting the appropriate item on the home page, thus displaying the screen of Fig. 10.
  • the sale offer list is only accessible to the buyer (thus requiring the entry of an identification code and a password).
  • the buyer then waits, block 32 until a satisfactory sale offer is found (of course, said waiting period ends at the expiry of the purchase offer, which is then removed). If the buyer sees a satisfactory sale offer, he/she selects said offer from the sale offer list, block 34. For this purpose, a confirmation summary screen is then displayed, Fig. 11, through which the buyer can confirm the association between the purchase offer identification code and the sale offer identification code displayed on the screen.
  • block 36 after having received from first client device 4 the information about the association between the purchase offer and the sale offer, the entity that manages telecommunication system 1 assigns a buyer delivery code to the buyer and a seller delivery code to the seller/provider, which codes will be used for ensuring a secure transaction, thus providing in particular: the certainty that the product will be delivered or the service will be provided to the buyer, and the certainty that the amount due will be paid to the seller.
  • the respective delivery codes are secret keys, and are sent exclusively to the respective consignees, e.g. by e- mail or sms or possibly in paper format by ordinary mail.
  • the seller delivery code is tied to the buyer delivery code, so that afterwards it will be possible to verify the code association.
  • the buyer delivery code is a random code generated by central processing unit 6 of server 3 (e.g. through a pseudorandom generator), and consists of a matrix or a string of alphanumerical characters having a predefined length, e.g. twenty elements (said code may therefore be something like "A5Yp6gWP0Khp076PRw2G").
  • the seller delivery code consists of a random portion of the buyer delivery code, extracted randomly by central processing unit 6 through a suitable random extraction procedure.
  • the seller delivery code may consist of sixteen elements, whether or not consecutive, each having the same value and position as one element included in the buyer delivery code (the seller delivery code may therefore be "A5-p6-WP0K-p076PR-2G” or "A5Yp-Gwp-Kh-076PRw-G", where the characters "-" indicate the presence of a respective character in the string of the buyer delivery code).
  • the seller/provider enters the seller delivery code, received from server 3 through interconnection network 2, into transaction control device 18 (by manual input or through an automatic procedure, after having connected transaction control device 18 to second client device 5). Due to the tamper-resistant nature of the circuitry of transaction control device 18, the code entered into the memory is not accessible from the outside to personnel who have not been authorized to use said device.
  • the entity that manages telecommunication system 1 puts the buyer in contact with the seller/provider by sending to each party the personal data and addresses of the other party, obtained from personal database 9c. Furthermore, this stage also includes the execution of those preliminary steps that afterwards will allow the product/service to be paid and the transaction to be completed. More in detail, in the deposit version the buyer credits the amount corresponding to the price stated in the order to a current account registered at banking body 15 in the name of the entity that manages telecommunication system 1, specifying as a crediting reason the purchase offer identification code which the order refers to. Said amount is kept in said account waiting to be transferred to the seller/provider when the transaction is completed.
  • guarantor body 16 issues, being instructed to do so by the entity that manages telecommunication system 1 , a first- request autonomous guarantee in favour of the seller/provider, again specifying the identification code of the purchase offer that the order refers to; guarantor body 16 verifies that the line of credit for issuing the guarantee exists and is available, in which case it will issue said guarantee, without however delivering the paper original neither to the buyer nor to the seller/provider. The guarantee is thus issued but not yet active, since it is waiting to be requested by the seller/provider.
  • the following block 38 carries out a step of interaction between the buyer and the seller/provider, who come into contact with each other to define the details of the delivery of the product(s) or provision of the service(s). Subsequently the product is delivered to the buyer, e.g. through a carrier, or the service agreed upon is provided.
  • the provision of a service requires several deadlines, as many delivery codes and as many payments will be made (or guarantees will be issued) as the number of deadlines stated in the order.
  • block 40 the buyer or an appointed person checks the quantity and quality thereof.
  • the seller/provider can now verify, block 46, the authenticity of the code received from the buyer and can then proceed with delivering the product/providing the service only if this verification has a positive outcome.
  • the seller/provider compares the random portion of the code he/she owns with the whole buyer delivery code, verifying that the values and positions in the matrix or character string match. This verification can give the seller/provider the certainty of the authenticity of the buyer's identity, as well as the certainty that the latter actually carried out the preliminary procedures required by telecommunication system 1 in order to ensure the payment of the amount due (transfer to current account or issue of guarantee).
  • the verification of the authenticity of the buyer delivery code is carried out automatically by transaction control device 18, without the user knowing the procedure for generating the delivery codes nor the relationship between them.
  • the local processor of said device can appropriately process the seller delivery codes stored therein and the buyer delivery code (entered by the seller, e.g. through the input means of said device) in order to verify that the seller delivery code can actually be obtained by starting from the buyer delivery code through a predetermined function (also permanently stored in transaction control device 18).
  • the device can perform a value and position "matching" of the characters contained in the two codes, and verify that the seller delivery code really matches a random portion of the buyer delivery code; as an alternative, transaction control device 18 may be set up to implement suitable asymmetrical cryptography functions, or hash functions, in order to verify the correspondence between the seller and buyer delivery codes.
  • the positive outcome of this verification may be signalled to the seller/provider through the signalling means, e.g. by turning on the LED.
  • the seller/provider will not complete the delivery of the product or provision of the service, block 48. Otherwise, block 50, the seller/provider will communicate to the entity that manages telecommunication system 1, e.g.
  • the problems found will be reported to the seller/provider and the amount due will not be paid.
  • the temporarily deposited sum will not be drawn by the seller/provider. Said sum will subsequently be made available to the buyer by the entity that manages telecommunication system 1 under a specific buyer's request subject to the seller/provider's approval. The sum in the current account is also released if the transaction has been completed successfully but the seller/provider has not requested the amount due within a certain period of time (stated in the purchase order).
  • Fig. 13 at a block 58 subsequent to block 50 the entity that manages telecommunication system 1, after having verified the correspondence and exactness of the buyer delivery code received from the seller/provider, authorizes guarantor body 16 to issue and activate the guarantee, which is thus drawn by the same seller/provider.
  • the parties will then wait for said transfer to take place, block 62. If a bank transfer containing the order codes (purchase offer identification code and delivery code) is executed within the expected times, the buyer may request that the guarantee be cancelled, block 64. In order to obtain said cancellation, block 66, the buyer sends a corresponding request to server 3, specifying the essential data of the bank transfer made in favour of the seller/provider.
  • the entity that manages the telecommunication system then sends a transfer confirmation request to banking body 15 entrusted by the buyer to make said transfer. If a confirmation is received from said banking body at block 68, at a subsequent block 70 the managing entity will instruct guarantor body 16 to cancel the guarantee and restore the buyer's line of credit for issuing further guarantees.
  • the process flow will proceed to a block 72 wherein, when the established terms expire, the guarantee will be cancelled and the buyer's line of credit will be restored with the amount corresponding to the cancelled guarantee.
  • the buyer does not make the bank transfer within the times and terms due
  • the seller/provider will inform the entity that manages telecommunication system 1 that he/she intends to excuss the guarantee, and said entity will in turn communicate said intention to the buyer.
  • the method waits for the buyer to communicate the essential data of the executed bank transfer to the managing entity for a predetermined period of time.
  • the managing entity will, after having received from banking body 15 a confirmation that the transfer has been made, notify the seller/provider, block 78. Otherwise, block 80, said entity will inform the guarantor body 16 that the payment has not been made, and will confirm said non-payment to the seller/provider, so that the latter can request the examination of the guarantee to same guarantor body 16. In any case, it should be underlined once more that the procedure implemented in telecommunication system 1 ensures that the seller/provider can at all events receive the payment due once the product has been delivered or the service has been provided.
  • the resulting transaction management telecommunication system can be used to advantage by a larger number of users, who are normally discouraged by the lack of security so far associated with e-commerce environments. Furthermore, such a system can be implemented in a simple and economical manner by exploiting existing telecommunication infrastructures.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne un système de télécommunication (1) destiné à gérer une transaction entre un acheteur et un vendeur d'un produit ou d'un service, dans lequel une unité centrale (3) est commandée par un gestionnaire du système de télécommunication (1), ainsi qu'une première et une seconde unité locale (4, 5) qui sont respectivement commandées par l'acheteur et le vendeur et sont configurées de manière à interagir à distance avec l'unité centrale (3) via un réseau d'interconnexion (2) afin d'établir une association entre une offre d'achat et une offre de vente. En particulier, l'unité centrale (3) est configurée de manière à générer et communiquer à l'acheteur et au vendeur des codes de livraison respectifs en réponse à ladite association ; ceux-ci peuvent être utilisés pendant une étape d'interaction mutuelle, de manière à assurer une transaction sécurisée.The present invention relates to a telecommunication system (1) for managing a transaction between a buyer and a seller of a product or service, in which a central unit (3) is controlled by a manager of the telecommunications system ( 1), as well as a first and a second local unit (4, 5) which are respectively controlled by the buyer and the seller and are configured to remotely interact with the central unit (3) via a network. interconnection (2) to establish an association between an offer to buy and an offer to sell. In particular, the central unit (3) is configured to generate and communicate to the buyer and the seller respective delivery codes in response to said association; these can be used during a mutual interaction step, so as to ensure a secure transaction.

Description

TELECOMMUNICATION SYSTEM FOR SECURE TRANSACTION MANAGEMENT, AND RELATED METHOD
DESCRIPTION
The present invention relates to a telecommunication system, as well as to an associated method, for the secure management of transactions pertaining to products and/or services.
Telecommunication systems are known which are adapted to put a buyer in contact with a seller of products or a provider of services (hereafter also simply referred to as seller) for making transactions; in particular, in the last few years the so-called electronic commerce (e-commerce) has become increasingly important as a part of the overall commercial trade volume. The spread of the Internet has doubtlessly played a fundamental role in this respect. In a known manner, a user of a client device can in fact connect to a plurality of servers to gain access to a plurality of on-line e-commerce sites, e.g. in order to buy products or request services of various kinds.
However, an important limitation associated with said telecommunication systems is generally found in the fact that the buyer cannot be certain that the product or service ordered will actually be delivered/provided, nor that said product will be undamaged and exactly as ordered; on the other hand, the seller/provider cannot be certain that the amount due will actually be paid. This problem is a deterrent for many potential e- commerce users, especially when large amounts of money are involved. It is therefore the object of the present invention to overcome, at least partly, the aforementioned drawbacks and problems suffered by the prior art.
The present invention provides a telecommunication system for managing transactions of products and/or services and an associated management method, as set out in claims 1 and 11, respectively. For a better understanding of the present invention, a number of preferred embodiments thereof will now be described by way of non-limiting example with reference to the annexed drawings, wherein:
- Fig. 1 is a block diagram of a general architecture of a transaction management telecommunication system according to an embodiment of the present invention; - Fig. 2 is a flow chart showing the steps involved in associating a purchase offer with a sale offer in the telecommunication system of Fig. 1;
- Figs. 3-11 are screens displayed on one or more client devices during the steps of the flow chart of Fig. 2; and - Figs. 12 and 13 are flow charts showing the steps involved in executing a transaction in the telecommunication system of Fig. 1.
As shown in Fig. 1 , a telecommunication system 1 for managing transactions pertaining to products and/or services comprises an interconnection network 2 adapted to allow a telecommunication connection to be established and data to be exchanged between a server 3, controlled by an entity that manages, supervises and monitors telecommunication system 1, and at least a first and a second client devices 4, 5, respectively controlled by a buyer and by a seller/provider. The buyer and the seller/provider may be a company or a private person, and are subscribers of the e- commerce telecommunication service provided by server 3. Interconnection network 2 is generally the Internet network, but it may also be any other wired or wireless network adapted to allow data to be exchanged between the machines belonging to telecommunication system 1, e.g. a LAN (Local Area Network), a WAN (Wide Area Network), an Intranet network, etc. In addition, first and second client devices 4, 5 may be any devices adapted to allow access to the network resources; therefore, though they are depicted in Fig. 1 as personal computers, they may also be a PDA (Personal Digital Assistant), e mobile telephone with network access functionality, a decoder (also called "set-top box"), or any other known Internet terminal. More in detail, server 3 comprises a central processing unit 6, a central memory 7, and a communication interface module 8 adapted to allow data to be sent and received through interconnection network 2. In the currently preferred embodiment, server 3 hosts an e-commerce site for managing transactions of products and services among registered users; for this purpose, central memory 7 stores a plurality of web pages, e.g. created by using the HTML language (Hypertext Markup Language), as well as a plurality of databases. In particular, as will be clarified later on, there are at least one purchase offer database 9a, one sale offer database 9b, and one personal database 9c, the latter containing user information (such as name, address, preferences, previously placed orders) about users who have subscribed to the telecommunication service. The retrieval of user information may be facilitated by the use of a "cookie" conveniently stored in the respective client device. In a per se known manner, central processing unit 6 of server 3 operates and interacts with the aforementioned databases and communication interface module 8 in order to supply web pages to a client device, in particular by reacting to selections and data sent by a user of the client device through interconnection network 2.
Each of the first and second client devices 4, 5 is provided with a local processing unit 10 (e.g. a CPU - Central Processing Unit) and with a local memory 11 for storing data and applications, among which at least one communication interface (e.g. a web browser) for interfacing to interconnection network 2 and accessing the e-commerce site hosted by server 3. Furthermore, each client device has data input means 12 (e.g. a keyboard or a mouse) adapted to allow the user to interact with telecommunication system 1, in particular to send data to server 3, as well as visualization means 13 (e.g. a display) for displaying, among other things, web pages 14 and data associated thereto. Advantageously, the connection between the client devices and the server may take place through a secure channel (e.g. an SSL [Secure Sockets Layer] channel), in order to reduce the risk of interception of sensible data.
In much the same way as described above, a banking body 15 and a guarantor body 16 are also connected to interconnection network 2, both of which are bound to the entity that manages telecommunication system 1 by a specific agreement (or convention) which regulates their reciprocal co-operation for the provision of the telecommunication service. In particular, guarantor body 16 may be an insurance company, a bank, a financial company, or a public or private fund constituted or intended specifically for this purpose. In addition, according to an embodiment of the present invention telecommunication system 1 also comprises a transaction control device 18 owned by the users who have subscribed to the telecommunication service. Transaction control device 18 is, for example, a non-programmable portable electronic device, and may be configured as a stand-alone device or as a peripheral device of a respective client device to which it is connected, for example, by means of a USB connector 19. Transaction control device 18 is also fitted with an alphanumerical display, an alphanumerical keypad (or a similar input device) for data input, signalling means, e.g. LEDs, and an electronic circuit including a memory and a local processor. Transaction control device 18, and in particular the memory and local processor thereof, are advantageously equipped with tamper-resistant technology, thus avoiding any undesired external access and in particular not allowing the memory contents to be read from the outside. With reference to the flow chart of Fig. 2 and to the screenshots of Figs. 3-11, the following will describe the method implemented in telecommunication system 1 in order to establish an association between a demand and an offer of products and/or services, and the resulting contact between a buyer and a seller/provider enabled to use the telecommunication service. During an initial step (block 20), a user wanting to buy a product or a service accesses server 3 through first client device 4, in particular the home page of the e-commerce site hosted by server 3. A screen is thus displayed on visualization means 13 of first client device 4, shown by way of example in Fig. 3 (though it is clear that this screen, just like all the following screens, may be replaced with alternative and equivalent implementations), which offers the user the possibility of at least: entering a purchase offer; looking at a list of purchase offers; and looking up a list of sale offers (associated with a particular purchase offer previously entered, if present).
When the item for entering a purchase offer is selected, the procedure proceeds to step 22 and to the screen shown in Fig. 4 for the authentication of the buyer, who must enter a user code and a password, previously assigned or chosen when he/she subscribed to the telecommunication service; if the user is not yet registered, the procedure will require that he/she agrees and subscribes to telecommunication system 1. In particular, according to an embodiment of the present invention, each transaction is made under a specific guarantee granted to the buyer by guarantor body 16. In such a case, when subscribing to the telecommunication service, the buyer must select a guarantor (of which he/she is a customer) to be referred to among a list of guarantors bound to the entity that manages telecommunication system 1 by specific agreements. The entity that manages telecommunication system 1 then communicates the buyer data to the selected guarantor body; the latter verifies that the buyer is actually one of his customers and has a line of credit for the issue of guarantees. Only if such verifications have a positive outcome, the buyer's subscription will be accepted and the procedure can proceed. Once it has been confirmed that the buyer is a subscriber of telecommunication system 1, the buyer has the possibility to enter a purchase offer which, if accepted, will be stored in purchase offer database 9a of central memory 7 of server 3. Entering a purchase offer involves inputting data about said offer, among which, as shown by way of example in the screenshot of Fig.5: market sector; product/service type; state, region and place of delivery; description of the object; expiry date of the offer and consequently the deadline of the delivery/implementation of the product/service ; associated INCOTERMS code; and payment method. Besides, the buyer may also select a first transaction execution mode, called "deposit version", and a second transaction execution mode, called "guarantee version" (both of which will be described in detail below). In the guarantee version, the buyer must also enter the code (or another identifier) of the guarantor body 16 designated when the subscription was made. As the purchase offer is confirmed by the buyer, the process flow implemented in telecommunication system 1 proceeds to block 24, wherein the entity that manages telecommunication system 1 verifies the purchase offer entered by the buyer. In particular, in the deposit version said verification is essentially limited to checking that the various fields have been filled in and that the data entered is consistent. In addition to said verification, in the guarantee version the entity that manages the telecommunication system sends the purchase offer details, e.g. through interconnection network 2, to guarantor body 16, which then verifies the actual existence of a line of credit for the issue of guarantees in favour of the buyer.
In the event that, for any reason, this verification is not successful, at a block 26 subsequent to block 24 the purchase offer is discarded and an error message is sent to first client device 4 of the buyer (e.g. by e-mail) to inform the latter about the problems detected. If on the contrary said verification has a positive outcome, at a block 28 subsequent to block 24 the purchase offer is stored in purchase offer database 9a and published on the e-commerce site hosted by server 3. A purchase offer identification code is then assigned to said offer, which code is sent to the buyer (e.g. again by e-mail); the purchase offer identification code may for example consist of a progressive day field followed by a field corresponding to the date of entry, in turn followed by a field consisting of the code of the associated guarantor body, if present (guarantee version) or a fixed code (deposit version). For example, a purchase offer identification code may be "55100220076033", where "55" is the progressive day field, "10022007" is the field stating the date of entry, and "6033" is the field of the guarantor/fixed code. At this point, the purchase offer entered can be freely consulted by selecting the item for viewing the purchase offer list on the site's home page. Figs. 6-8 are screens that may be displayed by a client device, respectively containing the following items: a search mask which can be used for retrieving a group of purchase offers that meet certain criteria; the list of purchase offers found, in this case relating to a certain market sector; and a summary sheet of one of said purchase offers, which shows all details thereof that are available on-line. Advantageously, each new purchase offer can be sent automatically by server 3 to all users who have subscribed to a mailing list correlated to the purchase offer, e.g. based on a specific market sector or place of purchase. In particular, it should be underlined that at this level the purchase offer is wholly encoded but still completely anonymous. The published purchase offer will then be removed from the site if any of the following conditions occur: the buyer places an order by accepting one of the received sale offer (as described below); the buyer cancels the purchase offer; the maximum purchase offer publication time set by the telecommunication service expires.
At this point, block 30, a seller/provider connected to server 3 through interconnection network 2 may, through second client device 5, view the various published purchase offers and enter one or more sale offers in response to corresponding purchase offers. To this end, as shown in said Fig. 8, the detailed screen of each purchase offer includes an item for entering a corresponding sale offer. After having entered his/her user code and password (and, if necessary, after having subscribed to the telecommunication service in the same manner as previously described), the seller/provider enters at least one offered price and possibly some additional details about the sale offer, see screenshot of Fig. 9. When the entered sale offer is confirmed, the data thereof is stored in sale offer database 9b of server 3, and a sale offer identification code is assigned and sent to the seller/provider. Said code may consist, for example, of the corresponding purchase offer identification code followed by a progressive field; the sale offer identification code corresponding to the purchase offer identification code "55100220076033" may be, for example, "55100220076033 0014". Just like the purchase offer, the entered sale offer is also wholly encoded but still anonymous. Advantageously, the buyer receives each sale offer relating to a previously entered purchase offer from server 3, e.g. by e-mail. Furthermore, the buyer can view on-line the list of sales offers relating to a particular purchase offer by selecting the appropriate item on the home page, thus displaying the screen of Fig. 10. According to an embodiment of the present invention, the sale offer list is only accessible to the buyer (thus requiring the entry of an identification code and a password). The buyer then waits, block 32 until a satisfactory sale offer is found (of course, said waiting period ends at the expiry of the purchase offer, which is then removed). If the buyer sees a satisfactory sale offer, he/she selects said offer from the sale offer list, block 34. For this purpose, a confirmation summary screen is then displayed, Fig. 11, through which the buyer can confirm the association between the purchase offer identification code and the sale offer identification code displayed on the screen. According to a main aspect of the present invention, block 36, after having received from first client device 4 the information about the association between the purchase offer and the sale offer, the entity that manages telecommunication system 1 assigns a buyer delivery code to the buyer and a seller delivery code to the seller/provider, which codes will be used for ensuring a secure transaction, thus providing in particular: the certainty that the product will be delivered or the service will be provided to the buyer, and the certainty that the amount due will be paid to the seller. The respective delivery codes are secret keys, and are sent exclusively to the respective consignees, e.g. by e- mail or sms or possibly in paper format by ordinary mail. Moreover, they are tied to each other in a univocal manner; in particular, the seller delivery code is tied to the buyer delivery code, so that afterwards it will be possible to verify the code association. In a currently preferred embodiment, the buyer delivery code is a random code generated by central processing unit 6 of server 3 (e.g. through a pseudorandom generator), and consists of a matrix or a string of alphanumerical characters having a predefined length, e.g. twenty elements (said code may therefore be something like "A5Yp6gWP0Khp076PRw2G"). The seller delivery code consists of a random portion of the buyer delivery code, extracted randomly by central processing unit 6 through a suitable random extraction procedure. For example, the seller delivery code may consist of sixteen elements, whether or not consecutive, each having the same value and position as one element included in the buyer delivery code (the seller delivery code may therefore be "A5-p6-WP0K-p076PR-2G" or "A5Yp-Gwp-Kh-076PRw-G", where the characters "-" indicate the presence of a respective character in the string of the buyer delivery code).
In an embodiment of the present invention, the seller/provider enters the seller delivery code, received from server 3 through interconnection network 2, into transaction control device 18 (by manual input or through an automatic procedure, after having connected transaction control device 18 to second client device 5). Due to the tamper-resistant nature of the circuitry of transaction control device 18, the code entered into the memory is not accessible from the outside to personnel who have not been authorized to use said device.
Similarly, other techniques may also be used for generating the buyer delivery code and then obtaining the seller delivery code as a function of said buyer delivery code. In particular, it is possible to use an asymmetric cryptography technique (e.g. RSA type) using a pair of public/private keys, a digital signature and authentication technique, or a suitable hash function for generating the seller delivery code by starting from the supplier delivery code. These techniques being per se known, they will not be described any further.
At this point, the entity that manages telecommunication system 1 puts the buyer in contact with the seller/provider by sending to each party the personal data and addresses of the other party, obtained from personal database 9c. Furthermore, this stage also includes the execution of those preliminary steps that afterwards will allow the product/service to be paid and the transaction to be completed. More in detail, in the deposit version the buyer credits the amount corresponding to the price stated in the order to a current account registered at banking body 15 in the name of the entity that manages telecommunication system 1, specifying as a crediting reason the purchase offer identification code which the order refers to. Said amount is kept in said account waiting to be transferred to the seller/provider when the transaction is completed. In the guarantee version, based on the price stated in the order, guarantor body 16 issues, being instructed to do so by the entity that manages telecommunication system 1 , a first- request autonomous guarantee in favour of the seller/provider, again specifying the identification code of the purchase offer that the order refers to; guarantor body 16 verifies that the line of credit for issuing the guarantee exists and is available, in which case it will issue said guarantee, without however delivering the paper original neither to the buyer nor to the seller/provider. The guarantee is thus issued but not yet active, since it is waiting to be requested by the seller/provider.
The following block 38 carries out a step of interaction between the buyer and the seller/provider, who come into contact with each other to define the details of the delivery of the product(s) or provision of the service(s). Subsequently the product is delivered to the buyer, e.g. through a carrier, or the service agreed upon is provided. In particular, when the provision of a service requires several deadlines, as many delivery codes and as many payments will be made (or guarantees will be issued) as the number of deadlines stated in the order.
When the buyer receives the product (or the service is provided), block 40, the buyer or an appointed person checks the quantity and quality thereof.
Should this verification have a negative outcome, block 42 after block 40, the buyer will reject the product (or service), and consequently he/she will not give the buyer delivery code to the seller/provider. In this regard, it should be underlined that the transfer of the sum previously frozen in the current account to the seller/provider, or the issue of the guarantee original to the same seller/provider, and thus the activation of said guarantee, are carried out upon order from the entity that manages telecommunication system 1 only if the seller/provider can prove to be the owner of the correct buyer delivery code. It should therefore be appreciated that this procedure ensures effective guarantee for the buyer, who has the possibility of authorizing the payment agreed upon only if he/she is satisfied with the transaction.
If, on the contrary, said verification has a positive outcome, block 44, the buyer will communicate to the seller/provider the buyer delivery code received when the order was placed.
By using his/her own seller delivery code, the seller/provider can now verify, block 46, the authenticity of the code received from the buyer and can then proceed with delivering the product/providing the service only if this verification has a positive outcome. In particular, the seller/provider compares the random portion of the code he/she owns with the whole buyer delivery code, verifying that the values and positions in the matrix or character string match. This verification can give the seller/provider the certainty of the authenticity of the buyer's identity, as well as the certainty that the latter actually carried out the preliminary procedures required by telecommunication system 1 in order to ensure the payment of the amount due (transfer to current account or issue of guarantee).
In an embodiment of the present invention, the verification of the authenticity of the buyer delivery code is carried out automatically by transaction control device 18, without the user knowing the procedure for generating the delivery codes nor the relationship between them. For this purpose, the local processor of said device can appropriately process the seller delivery codes stored therein and the buyer delivery code (entered by the seller, e.g. through the input means of said device) in order to verify that the seller delivery code can actually be obtained by starting from the buyer delivery code through a predetermined function (also permanently stored in transaction control device 18). In the simplest case, the device can perform a value and position "matching" of the characters contained in the two codes, and verify that the seller delivery code really matches a random portion of the buyer delivery code; as an alternative, transaction control device 18 may be set up to implement suitable asymmetrical cryptography functions, or hash functions, in order to verify the correspondence between the seller and buyer delivery codes. The positive outcome of this verification may be signalled to the seller/provider through the signalling means, e.g. by turning on the LED. In the event that the authenticity verification has a negative outcome, the seller/provider will not complete the delivery of the product or provision of the service, block 48. Otherwise, block 50, the seller/provider will communicate to the entity that manages telecommunication system 1, e.g. through interconnection network 2, the buyer delivery code received from the buyer and the purchase offer identification code to which the offer relates; the method will then proceed with the execution of the steps required for the payment of the amount due, in different manners depending on whether the transaction is conducted with or without assistance from guarantor body 16. More in detail, in the deposit version, Fig. 12, at a block 52 subsequent to block 50 central processing unit 6 of server 3 verifies the exactness of the received data, in particular the correct association between the purchase offer identification code and the buyer delivery code (both of which are stored in central memory 7). If the data is correct, block 54, the amount due will be paid to the seller by transferring the funds previously deposited by the buyer in the current account registered in the name of the entity that manages telecommunication system 1.
Otherwise, block 56, the problems found will be reported to the seller/provider and the amount due will not be paid. In this case, and also when the buyer refuses to disclose the buyer delivery code because of a missing or improper product or because of a service improperly provided or not provided at all, the temporarily deposited sum will not be drawn by the seller/provider. Said sum will subsequently be made available to the buyer by the entity that manages telecommunication system 1 under a specific buyer's request subject to the seller/provider's approval. The sum in the current account is also released if the transaction has been completed successfully but the seller/provider has not requested the amount due within a certain period of time (stated in the purchase order).
In the guarantee version, Fig. 13, at a block 58 subsequent to block 50 the entity that manages telecommunication system 1, after having verified the correspondence and exactness of the buyer delivery code received from the seller/provider, authorizes guarantor body 16 to issue and activate the guarantee, which is thus drawn by the same seller/provider.
Within the expiry of the term fixed for the payment(s), as stated in the order details, the buyer will have to transfer the amount due to the seller/provider's current account, block 60.
The parties will then wait for said transfer to take place, block 62. If a bank transfer containing the order codes (purchase offer identification code and delivery code) is executed within the expected times, the buyer may request that the guarantee be cancelled, block 64. In order to obtain said cancellation, block 66, the buyer sends a corresponding request to server 3, specifying the essential data of the bank transfer made in favour of the seller/provider. The entity that manages the telecommunication system then sends a transfer confirmation request to banking body 15 entrusted by the buyer to make said transfer. If a confirmation is received from said banking body at block 68, at a subsequent block 70 the managing entity will instruct guarantor body 16 to cancel the guarantee and restore the buyer's line of credit for issuing further guarantees. Otherwise, and also when at block 64 the buyer does not request the cancellation of the guarantee, the process flow will proceed to a block 72 wherein, when the established terms expire, the guarantee will be cancelled and the buyer's line of credit will be restored with the amount corresponding to the cancelled guarantee. If at block 60 the buyer does not make the bank transfer within the times and terms due, at a block 74 subsequent to block 62 the seller/provider will inform the entity that manages telecommunication system 1 that he/she intends to excuss the guarantee, and said entity will in turn communicate said intention to the buyer. At a subsequent block 76, the method waits for the buyer to communicate the essential data of the executed bank transfer to the managing entity for a predetermined period of time.
If such a communication occurs within the fixed term, the managing entity will, after having received from banking body 15 a confirmation that the transfer has been made, notify the seller/provider, block 78. Otherwise, block 80, said entity will inform the guarantor body 16 that the payment has not been made, and will confirm said non-payment to the seller/provider, so that the latter can request the examination of the guarantee to same guarantor body 16. In any case, it should be underlined once more that the procedure implemented in telecommunication system 1 ensures that the seller/provider can at all events receive the payment due once the product has been delivered or the service has been provided.
The advantages of the system and method described herein are apparent from the above description.
In particular, they allow for effectively creating a new type of e-commerce channel which can put the demand and offer of products and services in contact with each other while providing certainty of both delivery and payment. Therefore, the resulting transaction management telecommunication system can be used to advantage by a larger number of users, who are normally discouraged by the lack of security so far associated with e-commerce environments. Furthermore, such a system can be implemented in a simple and economical manner by exploiting existing telecommunication infrastructures.
The presence of two possible payment versions, i.e. bank deposit and guarantee, additionally allows to meet different users' needs. Finally, it is clear that what has been described and illustrated herein may be subject to changes or variations without departing from the protection scope of the present invention, as set out in the appended claims.
In particular, it is apparent that other technologies, in particular a different network architecture or a different encoding of the exchanged data, may be used in order to implement the described method.
It is also apparent that the system and method described herein are applicable to any type of product and/or service transaction.

Claims

1. Telecommunication system (1) for managing a transaction between a buyer and a seller of a product or service, comprising:
- central processing means (3) controlled by a manager of said telecommunication system (1); and - local processing means (4, 5) controlled by said buyer and seller and set up to interact remotely with said central processing means (3) through an interconnection network (2) in order to establish an association between a purchase offer and a sale offer; characterized in that said central processing means (3), in response to said association, are so set up as to generate and communicate to said buyer and seller respective delivery codes which can be used during a mutual interaction step for the purpose of ensuring a secure transaction.
2. System according to claim 1, wherein said delivery codes comprise a buyer delivery code and a seller delivery code, the latter being tied to said buyer delivery code by a definite relationship; said mutual interaction comprising the exchange of said delivery codes and the verification of the existence of said definite relationship, and the execution of said transaction being subordinated to the outcome of said verification.
3. System according to claim 2, comprising an electronic verification device (18) which can be actuated by at least one of said buyer and seller and which is set up to carry out said verification.
4. System according to claim 3, wherein said exchange of codes comprises the communication of said buyer delivery code from said buyer to said seller if said buyer properly receives said product or service from said seller, and said electronic verification device (18) is so set up as to receive said buyer delivery code and process it together with said seller delivery code for the purpose of allowing said seller to carry out said verification.
5. System according to any of claims 2-4, wherein said central processing means (3) comprise code generating means set up to generate said buyer delivery code as a random sequence of alphanumerical characters, and said seller delivery code as a randomly extracted portion of said sequence; said buyer delivery code and seller delivery code being secret keys.
6. System according to any of the preceding claims, wherein said local processing means (4, 5) comprise: a first client device (4), controlled by said buyer, and set up to interact with said central processing means (3) for entering a purchase offer; and a second client device (5), controlled by said seller, and set up to interact with said central processing means (3) for entering a sale offer in response to said purchase offer; said first client device (4) being additionally set up to interact with said central processing means (3) for establishing said association between said sale offer and said purchase offer.
7. System according to claim 6, wherein said purchase offer and sale offer can be viewed anonymously, and said central processing means (3) are also set up to communicate personal data of said buyer and seller to said seller and buyer, respectively, in response to said established association, thus allowing the execution of said mutual interaction step.
8. System according to claim 6 or 7 when dependent on claim 2, wherein said first client device (4) is also set up to interact with said central processing means (3) for the purpose of implementing preliminary steps for making a payment of an amount due to said seller as said transaction is completed; said second client device (5) is set up to interact with said central processing means (3) for communicating that the existence of said definite relationship has been verified; and said central processing means (3) are set up to enable the execution of said payment in response to said verification confirmation.
9. System according to claim 8, wherein said preliminary steps comprise the deposit of said amount due in a fund controlled by said manager of said telecommunication system (1), or the issue of a guarantee for said amount in favour of said seller by a guarantor body (16) connected to said telecommunication system (1); and said central processing means (3) are so set up as to authorize the transfer of said amount from said fund to said seller, or the issue of said guarantee, in response to said verification confirmation.
10. System according to any of the preceding claims, wherein said interconnection network (2) is an Internet network, and said central processing means comprise a server (3) adapted to host an Internet site.
11. Method for managing a transaction between a buyer and a seller of a product or service in a telecommunication system (1) provided with central processing means (3) controlled by a manager of said telecommunication system (1) and local processing means (4, 5) controlled by said buyer and seller and set up to interact remotely with said central processing means (3) through an interconnection network (2), said method comprising the step of:
- in said local processing means (4, 5), establishing an association between a purchase offer and a sale offer; characterized by comprising the step of:
- in said central processing means (3), generating and communicating to said buyer and seller, in response to said established association, respective delivery codes which can be used during a mutual interaction step for the purpose of ensuring a secure transaction.
12. Method according to claim 11, wherein said delivery codes comprise a buyer delivery code and a seller delivery code, which is tied to said buyer delivery code by a definite relationship, and said mutual interaction comprises an exchange of said delivery codes and a verification of the existence of said definite relationship; also comprising the step of: - in said central processing means (3), enabling the execution of said transaction as a function of the outcome of said verification.
13. Method according to claim 12, wherein said mutual interaction step comprises the following subsequent steps:
- said seller delivers said product or provides said service; - said buyer evaluates the quality of said product or service and communicates said buyer delivery code to said seller if said evaluation has a positive outcome;
- said seller carries out said verification of said definite relationship between the buyer delivery code received from said buyer and said seller delivery code, and then proceeds with delivering said product or providing said service if said verification has a positive outcome, also comprising the following step:
- in said local processing means (4, 5), said seller communicates the outcome of said verification to said central processing means (3).
14. Method according to claim 12 or 13, wherein said generation step comprises the generation of said buyer delivery code as a random sequence of alphanumerical characters and the generation of said seller delivery code as a randomly extracted portion of said sequence; said buyer delivery code and seller delivery code being secret keys.
15. Method according to any of claims 11-14, wherein said interaction step comprises the following steps: said buyer enters a purchase offer; said seller enters a sale offer in response to said purchase offer; said buyer establishes said association between said sale offer and said purchase offer.
16. Method according to claim 15, wherein said purchase offer and sale offer can be viewed anonymously; also comprising the following step:
- in said central processing means (3), personal data of said buyer and seller are communicated to said seller and buyer, respectively, in response to said established association, thus allowing said mutual interaction step to be carried out.
17. Method according to any of claims 12-16 when dependent on claim 12, wherein said interaction step also comprises the implementation, by said buyer, of preliminary steps for making a payment of an amount due to said seller as said transaction is completed; also comprising the step of communicating, by said seller, the outcome of said verification, said enabling step comprising enabling the execution of said payment as a function of said outcome.
18. Method according to claim 17, wherein said preliminary steps comprise the deposit of said amount due in a fund controlled by said manager of said telecommunication system (1), or the issue of a guarantee for said amount in favour of said seller by a guarantor body (16) connected to said telecommunication system (1); and said enabling step comprises the authorization of the transfer of said amount from said fund to said seller, or the issue of said guarantee, as a function of said outcome.
19. Computer product, characterized by being adapted to implement, when loaded in central processing means(3) and in local processing means (4, 5) belonging to a telecommunication system (1) according to any of claims 1-10, a method for managing a transaction between a buyer and a seller of a product or service according to any of claims 11-18.
PCT/IB2008/000836 2007-04-11 2008-04-08 Telecommunication system for secure transaction management, and related method Ceased WO2008125937A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
ITTO20070252 ITTO20070252A1 (en) 2007-04-11 2007-04-11 TELEMATIC SYSTEM FOR THE SECURE MANAGEMENT OF TRANSACTIONS, AND ITS METHOD
ITTO2007A000252 2007-04-11

Publications (2)

Publication Number Publication Date
WO2008125937A2 true WO2008125937A2 (en) 2008-10-23
WO2008125937A8 WO2008125937A8 (en) 2008-12-11

Family

ID=39764929

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2008/000836 Ceased WO2008125937A2 (en) 2007-04-11 2008-04-08 Telecommunication system for secure transaction management, and related method

Country Status (2)

Country Link
IT (1) ITTO20070252A1 (en)
WO (1) WO2008125937A2 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ITTO20090136A1 (en) * 2009-02-25 2010-08-25 Giuseppe Asselle CONTROL SYSTEM FOR THE MANAGEMENT OF ACCESSES TO RESERVED AREAS
CN117541341A (en) * 2023-10-24 2024-02-09 福建大数据交易有限公司 Big data delivery method and system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
No Search *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ITTO20090136A1 (en) * 2009-02-25 2010-08-25 Giuseppe Asselle CONTROL SYSTEM FOR THE MANAGEMENT OF ACCESSES TO RESERVED AREAS
WO2010097745A1 (en) * 2009-02-25 2010-09-02 Giuseppe Asselle Control system for managing access to restricted areas
US8730005B2 (en) 2009-02-25 2014-05-20 Giuseppe Asselle Control system for managing access to restricted areas
CN117541341A (en) * 2023-10-24 2024-02-09 福建大数据交易有限公司 Big data delivery method and system

Also Published As

Publication number Publication date
ITTO20070252A1 (en) 2008-10-12
WO2008125937A8 (en) 2008-12-11

Similar Documents

Publication Publication Date Title
US7797237B2 (en) Electronic financial transaction system and method providing real-time authentication service through wire/wireless communication network
JP5377602B2 (en) Transaction processing method, coordinator server, and transaction method
US7835960B2 (en) System for facilitating a transaction
EP0734556B1 (en) Network based payment system and method for using such system
KR101379168B1 (en) Multiple party benefit from an online authentication service
US6752313B1 (en) Method and system for establishing a credit card transaction processing merchant account
US20010029485A1 (en) Systems and methods enabling anonymous credit transactions
US20160328705A1 (en) Mediated conversion of cryptographic currency and other funding sources to gold
CN102341817A (en) Payment system
JP2002063532A (en) Order settlement system
CN101443821A (en) In-lane money transfer systems and methods
US20150026037A1 (en) System, method and apparatus to provide a multi-channel retail layaway service using physical retail point-of-sale and on-line virtual payment systems
BG108478A (en) A secure on-line payment system
AU775065B2 (en) Payment method and system for online commerce
WO2001029637A2 (en) System and method for secure electronic transactions
US10733643B2 (en) Systems, devices and methods for computer automated assistance for disparate networks and internet interfaces
US20050015304A1 (en) Secure purchasing over the internet
WO2008125937A2 (en) Telecommunication system for secure transaction management, and related method
KR20020064473A (en) System and method for servicing electronic payment assurance integrated with electronic wallet
KR20060124375A (en) Trading system and user authentication method through this system
KR20060082012A (en) Electronic payment method and system using a mobile phone

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08737395

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08737395

Country of ref document: EP

Kind code of ref document: A2