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.