EP2457201A1 - Procédé de gestion de requête électronique à l'aide d'une entité intermédiaire - Google Patents

Procédé de gestion de requête électronique à l'aide d'une entité intermédiaire

Info

Publication number
EP2457201A1
EP2457201A1 EP09780831A EP09780831A EP2457201A1 EP 2457201 A1 EP2457201 A1 EP 2457201A1 EP 09780831 A EP09780831 A EP 09780831A EP 09780831 A EP09780831 A EP 09780831A EP 2457201 A1 EP2457201 A1 EP 2457201A1
Authority
EP
European Patent Office
Prior art keywords
entity
request
intermediary
text message
communication network
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.)
Withdrawn
Application number
EP09780831A
Other languages
German (de)
English (en)
Inventor
Daniel Staeger
Bruno Hunziker
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.)
Halter's Chop Chop
Original Assignee
Halter's Chop Chop
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 Halter's Chop Chop filed Critical Halter's Chop Chop
Publication of EP2457201A1 publication Critical patent/EP2457201A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0815—Network architectures or network communication protocols for network security for authentication of entities providing single-sign-on or federations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity

Definitions

  • the present invention is related to a method for handling an electronic request between two entities with the aid of an intermediary entity, as well as to uses of the method.
  • these directories will provide some information regarding the types of goods and/or services being offered along with an address and contact data such as a telephone or fax number, and increasingly often also an e-mail address.
  • an address and contact data such as a telephone or fax number, and increasingly often also an e-mail address.
  • the prospective customer will either have to go to the locality of the vendor in order to do business with him directly, or alternatively send an inquiry or request to the vendor via e-mail or fax, or call the vendor to make a request over the telephone.
  • a customer may want to place an order or make a reservation with the vendor.
  • the vendor will typically want to be certain about the identity of the vendor and furthermore, will also want to receive a
  • the present invention is directed to a method for handling an electronic request between two entities with the aid of an intermediary entity comprising the steps of:
  • the intermediary entity forwarding the request as a first text message such as an SMS message via a secure, second communication network such as a GSM network, UMTS network, etc. to a second entity;
  • a secure, second communication network such as a GSM network, UMTS network, etc.
  • the second entity either indicating acceptance of the request by sending a second text message back to the intermediary entity via the second communication network, or rejecting the request by preferably not responding;
  • the intermediary entity logging a result concerning at least the preceding step in an activity log.
  • the second entity e.g. a vendor
  • the second entity is able to receive and acknowledge
  • GSM Global System for Mobile Communications
  • SMS short message service
  • the second entity does not need to have access to the Internet to be able to receive and respond to requests.
  • the fact that the second entity only requires a mobile terminal provides it with greater freedom and flexibility to move around and still be able to receive and respond to requests independent of location, which can be most beneficial in many applications.
  • the fact that the second entity indicates rejection of the request by not responding makes use of the method
  • the first entity is guaranteed to receive a response regarding the outcome of its request from the intermediary entity within a maximum response time, thus relieving the first entity of prolonged uncertainty and giving it the opportunity to send further request to another second entity, if the previous request was
  • the first entity and the second entity respectively, have to register for service with the intermediary entity prior to being able to send and receive, respectively, requests according to the inventive method.
  • the corresponding registration process comprises the steps of:
  • the entity seeking registration accessing a primary website, preferably maintained by the intermediary entity, via the first communication network and providing at least a call number associated with a text message service enabled device such a GSM mobile telephone operable within the second communication network and/or an e-mail address, respectively;
  • the intermediary entity sending a verification message as a text message via the second communication network and/or an e-mail via the first communication network, respectively, to the entity seeking registration;
  • acknowledgement message as text message via the second communication network and/or as an e-mail via the first communication, respectively, back to the
  • this aspect of the invention provides that before providing service the identities of both the first and second entity is verified by the intermediary entity, which can act as an independent, trusted third party, since the intermediary entity is neither a customer nor a vendor, and therefore is not a party to potential business agreements established between the first and second entity.
  • all the necessary contact information required to handle a request resides with the intermediary entity, thus for instance making it possible to keep anonymous the first entity until the second entity acknowledges the first entity's request und thus indicates willingness to enter into a business relationship with the first entity.
  • certain private contact information such as for instance the telephone number of the second entity' s mobile terminal with which it receives requests does not need to be
  • the registration process according to the invention provides the opportunity for the intermediary entity to demand acceptance of certain predefined business rules, which will be legally binding for all registered users.
  • certain predefined business rules which will be legally binding for all registered users.
  • An embodiment of the present invention is characterised in that the acknowledgement of acceptance is sent to the first and preferably also to the second entity, respectively, as a third and fourth text message, respectively, via the second communication network, and the acknowledgement of rejection is sent to the first and preferably also to the second entity, respectively, as a third and fourth text message, respectively, via the second communication
  • acknowledgement message is sent from the second entity through the intermediary entity to the first entity entirely via the secure, second network.
  • This is beneficial in view of the possibility of having to provide proof of the transmissions having taken place with the originator and recipient, respectively, of the request. Such proof is made possible when employing a secure
  • network i.e. a network that provides unambiguous
  • SIM subscriber identity module
  • IMSI international mobile subscriber identity
  • the first entity e.g. a customer
  • receives an acknowledgement of acceptance or rejection as a text message i.e. in a tangible form, which can for instance be used as receipt or as voucher when completing the
  • transaction initiated by the request More generally, it can be provided as evidence, e.g. to the second entity, when required to prove that the request was accepted.
  • acknowledgement is sent as a text message over a mobile communication network makes things very practical for the first entity, because it can move around freely whilst still being able to receive acknowledgement messages independent of location.
  • This embodiment of the inventive method further provides the second entity with a confirmation that its acceptance of the request was received within the maximum response time, and was therefore passed on to the first entity.
  • acknowledgement of acceptance is sent to one or more further entities as a text message via the second communication network.
  • the first entity e.g. a secretary has requested a reservation for a table of three for her boss and two further work colleagues
  • the secretary can be informed about the successful reservation but at the same time also all three dinning parties .
  • acknowledgement of acceptance is sent to the first and second entity, respectively, as a first and second e-mail, respectively, via the first communication network
  • acknowledgement of rejection is sent to the first and second entity, respectively, as a first and second e-mail, respectively, via the first communication network.
  • acknowledgement of acceptance is sent to one or more further entities as an e-mail via the first communication network.
  • the acknowledgement message is also provided through alternative means increasing the reliability of this embodiment of the inventive method for providing timely feedback. For instance, this can be especially useful when working at a computer in an office inside a building where reception of for example a GSM radio frequency signal is not possible because of the shielding effect of the walls, ceiling and floors made of reinforced concrete. The e-mail message can still be received in this situation.
  • the second entity retrieved from the primary website, so in case the first and/or second entity requires a status overview, such an overview is obtainable for instance via a computer that is connected to the Internet. This is especially helpful for the second entity if it has received a large number of requests and lost track of these, e.g. a restaurateur who has received many requests for table reservations spread out over many days, and who now wants to obtain an overview of the booking situation for the coming weekend in order to plan staffing of the service personnel.
  • contact information associated with the first entity is provided to the second entity as part of the data related to requests that have been accepted within the maximum response time.
  • contact information associated with the first entity e.g. its call number
  • the second entity is provided to the second entity as soon as the first entity' s request has be
  • the first entity to remain essentially anonymous until the second entity is prepared to fulfil the request of the first entity, but for instance requires the first entity' s contact information to fully do so.
  • this contact information allows the second entity to contact the first entity if necessary in conjunction with the request, e.g. the restaurateur calls the customer in order to inform the customer that the restaurant was flooded last night and all reservations need to be cancelled for the next couple of days.
  • the second entity by providing the second entity with contact information associated with the first entity only upon accepting a request within the maximum response time, it is possible to prevent the second entity from directly contacting the first entity, and thus circumventing the intermediary entity. The latter is especially undesirable in cases where the intermediary entity only charges a fee when a request has been accepted.
  • the maximum response time is set according to a corresponding entry in a user profile associated with the second entity.
  • the maximum response time can thus be set by the second entity according to its needs by changing the corresponding entry in its profile for instance by accessing the profile via the primary website or by calling the intermediary entity. This also allows to take into account the various possible requirements of different usages of the inventive method.
  • the maximum response time is set according to a corresponding entry sent by the first entity as part of the request and that this set maximum response time is provided to the second entity as part of the first text message.
  • the maximum response time can be set by the first entity, allowing it to communicate to the second entity how long it is willing to wait for a response. For instance the first entity may want to receive a response within a short time period, so that in case its request is rejected it can submit a further request to an alternative second entity.
  • the second entity can explicitly identify urgent requests and prioritise responding to them,
  • the intermediary entity selecting from a pool of call numbers allocated to the intermediary entity, a call number with present status "not in use” as an
  • originator call number changing the status of the corresponding call number in the pool of call numbers to "in use", and sending the first text message via the second communication network using the selected call number as the originator call number and the call number of the second entity as the recipient call number.
  • the caller ID i.e. the number displayed as the originator number on the recipient's terminal
  • the caller ID is the same for each of the call numbers that are in the pool of call numbers allocated to the intermediary entity when being used as an originator call number.
  • the intermediary entity can always identify itself to the second entity (and also to the first entity) by using the same caller ID even when employing different call numbers, thus making it easier for the second entity (as well as for the first entity) to clearly identify the caller as the intermediary entity.
  • step iv includes: - changing the status of the call number within the pool of call numbers corresponding to the recipient call number, used by the second entity to send the second text message to the intermediary entity, to "not in use” upon receiving the second text message, or if no second message is received within the maximum response time after sending of the first text message.
  • the intermediary entity can immediately reuse a call number within the pool as soon as a response from the second entity has been received or the maximum response time has elapsed.
  • the first entity accessing an offer website via the first communication network, said offer website presenting at least one offer provided by the second entity, the first entity selecting an offer provided by the second entity and generating a request
  • step i being carried out prior to sending the request to the intermediary entity according to step i.
  • the first entity can view the offerings of the second entity on a website and initiate a request for a specific offer via that website.
  • This website may be solely associated with the second entity and present only its offerings, or it may be a website presenting the offerings of different second entities, where the first entity can browse various offers and enter search criteria to find the offers of interest.
  • the latter especially provides small enterprises with an opportunity to present their offerings on a dedicated, centralised web platform without having to set up and maintain their own website.
  • a further embodiment of the present invention is characterised in that the unavailability period of time is set according to a corresponding entry in the user profile associated with the second entity.
  • offers associated with rejected requests are set to "not selectable" for a certain period of time, which can for instance be defined by the second entity.
  • the second entity allows the second entity to implicitly withdraw an offer for a certain amount of time, when it is no longer available, simply by rejecting an associated request. In this way, the second entity is not required to communicate with the offer website in order to withdraw such offers. Moreover, the second entity can at any time make an offer selectable again, especially in cases where an offer has been made unavailable due to missing to respond to a request within the maximum response time.
  • the inventive method can be used in conjunction with a number of applications as outlined in the following.
  • binding legal agreements are important in the context of "delivery versus payment"-type business transactions, where either the vendor or the customer takes on a certain financial risk by fulfilling their part of the business deal before the other party fulfils theirs. This is for example the case when a customer makes an advance payment and the vendor sends the goods to the customer once he has received this payment, or conversely, when the vendor sends goods to a customer who wants to look at them in detail before making a final decision as to whether he wants to pay for them or return them back to the vendor. In both instances the party taking the first step runs the risk of incurring a financial loss if the other party does not abide to their part of the deal.
  • the use of the inventive method provides a means for tracking the request from its initiation through to its acceptance and for identifying the involved parties with definiteness, all based upon the activity log recorded and maintained by the intermediary entity acting as a trusted, independent third party, possibly along with associated transport protocols
  • Another use of the inventive method and embodiments thereof is related to making a reservation at a locality such as a restaurant or a theatre, where the first entity corresponds to a prospective guest seeking a reservation such as a space, table and/or seating reservation at the locality of the second entity, and the second entity corresponds to a vendor providing a corresponding offering for instance via the offer website.
  • Especially service providers such as restaurants and bars, movie and music theatres, train operators, parking space providers, beauty and hairdresser salons, physicians and therapist, etc. offering (e.g. seating or parking) space at their facilities and/or their time to customers can benefit from the use of the inventive method in order to handle reservations and/or appointments efficiently and in a legally binder manner.
  • Such businesses will reserve their resources (e.g. space and/or time) for customers who have made reservations and/or appointments with them. If such a customer does not show up, the service provider will potentially suffer a loss of income, especially if other potential customers were turned down in the meantime due to the pending reservation and/or appointment of the no-show customer.
  • Reservations and/or appointments handled according to the inventive method are fully traceable and can provide proof of identity of the involved parties, thus providing the possibility of taking legal action against the no-show customer in order to receive compensation for lost profits.
  • customers of such service providers often want to make ad hoc, short-term
  • Yet another use of the inventive method and embodiments thereof is related to making an order in conjunction with a food take-away or take-out service, or a food home delivery service, where the first entity corresponds to a
  • the second entity corresponds to a vendor providing a corresponding offering for instance via the offer website.
  • a further use of the inventive method and embodiments thereof is related to providing unsolicited product and/or service offerings, especially for offerings having a very limited period of availability, for instance with an availability restricted to on the order of less than a day, where the first entity corresponds to a vendor of
  • the second entity corresponds to a potential buyer of corresponding products and/or services from the first entity.
  • inventive method for providing unsolicited product and/or service offerings such as for instance offers for sale of financial products, e.g. securities, stocks, bonds, options, derivatives, etc., offers for sale of commodities, e.g. heating oil, fuel, etc., special offers, e.g. promotional, discount, bargain or clearance offers, limited-availability offers, e.g. time-limited or limited-quantity offers, offers for selected customers, etc., enables vendors to rapidly distribute offerings to a specific community of potentially interested buyers.
  • the inventive method especially allows to rapidly receive back a definite purchase order from a buyer using technical means available to all potential buyers anytime and
  • the inventive method is beneficial in that it makes available the contact information of the vendor, i.e. the first entity, to the buyer, i.e. the second entity, upon acceptance of an offer, thus allowing the buyer to contact the vendor for instance to discuss details regarding the delivery of the purchased goods.
  • Potential buyers are able to sign up for certain types of offers and this information is stored as part of their user profile, which can be changed anytime for instance via the offer website. Consequently, a potential buyer only receives offers regarding items that are
  • inventive method and embodiments thereof is related to providing an order confirmation, where the first entity corresponds to a vendor of a product and/or service and the second entity corresponds to a buyer of the corresponding product and/or service from the first entity, and where the second entity has ordered a
  • first entity sends a request to the intermediary entity according to step i, the request prompting to confirm the order made by the second entity 2.
  • confirmations such as for instance confirmations of orders related to financial products, e.g. stock trades, etc. and particularly to orders having a high monetary value
  • the vendor i.e. the first entity, who has received the order from the buyer, i.e. the second entity, to verify the validity of the order by requesting a confirmation of the order from the customer via a secondary means, e.g. an SMS message, which is separate from the means via which the order was originally place, e.g. through a website.
  • a secondary means e.g. an SMS message
  • Such a use of the inventive method could also allow for instance a credit card provider to verify orders placed by a buyer over the Internet on a vendor' s website before approving the transaction with the customer's credit card.
  • FIG. 1 shows a block diagram of a system suitable for carrying out various embodiments of the inventive method
  • Fig. 2 shows a flowchart related to a specific embodiment of the inventive method.
  • the second entity corresponds to a vendor who makes available at least one offer, e.g. tables at a restaurant for dinning.
  • the second entity i.e. the vendor
  • the offer website 6' can be the website of the second entity 2, i.e. the vendor itself, or for instance the website of a
  • the offer website 6' can for example also be the website of a business association, which provides a web- based information platform for its members. Furthermore, the offer website 6' can coincide with the website of an intermediary entity 3, whose website is referred to here as the primary website 6.
  • the second entity 2 In order to be able to receive requests associated with its offers according to the inventive method the second entity 2 must sign up for service with the intermediary entity 3.
  • the second entity 2 preferably has to complete a registration process via the primary website 6, which can be accessed via an open, first communication network such as for instance the Internet 4, e.g. through the communication link Ll.
  • This registration process comprises providing at least a call number (e.g. the telephone number) associated with a text message service (e.g. short message service, SMS) enabled device such as a GSM mobile telephone as well as an e-mail address of the second entity 2.
  • a call number e.g. the telephone number
  • a text message service e.g. short message service, SMS
  • registration information associated with the second entity 2 is stored in the database 7 of the primary website 6. In order to verify the identity of the party seeking
  • the intermediary entity 3 sends a text message (e.g. an SMS) via a secure, second communication network such as the GSM network 5.
  • the text message may be delivered to the second entity's mobile terminal 11' for instance via an SMS gateway 8 operated by a separate gateway operator and an SMS service centre (SMS-SC) 9 operated by the GSM network operator X, since the second entity 2 is a subscriber of operator X' GSM network, e.g. through the communication links L3-L4-L5.
  • SMS-SC SMS service centre
  • the intermediary entity 3 can forward the text message directly to the SMS-SC 9, e.g. via the communication link L34, if the SMS gateway functionality is included as part of the the intermediary entity's own infrastructure.
  • the intermediary entity 3 accepts registration from the second entity 2 if the intermediary entity 3 receives back an acknowledgement text message (e.g. an SMS) from the second entity 2 in response to the intermediary entity' s text message.
  • the verification is performed via a secure, second communication network such as the GSM network 5 since the parties involved in all transmissions can be identified with absolute positiveness based on their international mobile subscriber identity (IMSI), which is contained in the subscriber identity module (SIM)
  • IMSI international mobile subscriber identity
  • SIM subscriber identity module
  • a potential customer such as a first entity 1 who is looking for example for a restaurant to have dinner there, will search for possible vendors (e.g. restaurants) by browsing the world wide web.
  • the potential customer such as the first entity 1 can do this using a computer 10 connected to the Internet 4 or alternatively using a mobile terminal incorporating wireless connectively such as a smartphone.
  • the latter has the advantage that it allows to access the Internet 4 from any location providing a corresponding wireless access.
  • the potential customer In order for the potential customer such as the first entity 1 to be able to take advantage of the inventive method for example to make a reservation, he will access an offer website 6' or directly the primary website 6.
  • the first entity 1, i.e. the customer, will search for a vendor, i.e. a second entity, that meets his needs, e.g. a restaurant which is located at a certain place and/or provides a certain kind of food, and submit a corresponding query to the vendor
  • a vendor i.e. a second entity
  • his needs e.g. a restaurant which is located at a certain place and/or provides a certain kind of food
  • the intermediary entity 3 will then look for vendors, which meet the search criteria in the database 7 (see block 203). If the intermediary entity 3 finds vendors, which match the search criteria (see block 204) it will check their availability (see block 205), e.g. check whether the corresponding restaurants are open and still have free tables for dinner. Subsequently, a list of matching vendors is provided to the first entity 1, i.e. the customer, which will retrieve this list from the website 6, e.g. via the communication link L2 (see block 206) . If there are no vendors which match the search criteria or the matching vendors are not available, e.g.
  • this negative search result is saved in a search log (see block 207), which is stored in the database 7, and a list of available alternative vendors is provided to the first entity 1, i.e. the customer, which will retrieve this list from the website 6, e.g. via the communication link L2 (see block 208) .
  • the first entity 1, i.e. the customer will either search for another vendor or select a vendor from the provided list of available vendors (see block 209) - this corresponds to selecting an offer
  • a request directed to the second entity 2, i.e. the selected vendor.
  • a request may specify for instance the first entity's, i.e. the customer's requirements related to the selected offer, e.g. date and time of reservation and number of guests, as well as the first entity's, i.e. the customer's requirements related to responding to the request such as for example a maximum response time.
  • the first entity 1, i.e. the customer In order to be able to submit the request the first entity 1, i.e. the customer, must provide login information, e.g. a user name and a password, to the primary website, which in turn requires that the first entity 1, i.e. the customer, has previously signed up for service with the intermediary entity 3, and therefore has completed the registration process as described above for a second entity 2, i.e. a vendor. After the login information, e.g. a user name and a password, to the primary website, which in turn requires that the first entity 1, i.e. the customer, has
  • the request can be submitted to the intermediary entity 3, e.g. via the communication link L2 (see block 211) .
  • the intermediary entity 3 determines from the database 7 the call number, e.g. the telephone number of a GSM telephone, of the vendor selected by the first entity, i.e. the customer, and selects a free originator call number from a pool of call numbers assigned to the intermediary entity 3 by for instance the SMS gateway operator or the GSM network operator, under which originator call number the request will be handled (see block 212) .
  • the call number e.g. the telephone number of a GSM telephone
  • the vendor selected by the first entity i.e. the customer
  • the intermediary entity 3 may add for instance the name of the first entity 1, i.e. the customer, to the request before forwarding it to the second entity 2. Additionally, in order to allow easy identification of the intermediary entity 3 as originator of the call, despite the fact that different originator call numbers from the pool of call numbers can be used, the caller ID, i.e. the number displayed as the originator number on the recipient's terminal, is set to a number that is known by the second entity 2 to be
  • the request is sent to the second entity' s mobile terminal 11' as a text message, e.g. via the SMS gateway 8 and the SMS-SC 9, e.g. through the communication links L3-L4-L5 (see block 213) .
  • the second entity 2 i.e. the vendor, is then able to read the text message on its mobile terminal 11/ (see block 214), and depending on whether it can meet the requirements of request it will then either accept or rejected the request (see block 215). Rejection of the request is preferably indicated by not responding to the request (see block 216) . On the other hand, if the request is to be accepted, this is indicated by sending back a text message to the intermediary entity 3, e.g.
  • SMS-SC 9 via the SMS-SC 9 and the SMS gateway 8, e.g. through the communication links L5-L4- L3 (see block 217), preferably using the mobile terminal's reply function without entering any answer text, where such a reply function will send a reply message to the SMS-SC 9 and the SMS gateway 8, e.g. through the communication links L5-L4- L3 (see block 217), preferably using the mobile terminal's reply function without entering any answer text, where such a reply function will send a reply message to the
  • the intermediary entity 3 within a predetermined maximum response time after sending the request to the second entity 2 (see block 218), where the value of the maximum response was previously set either according to an entry in the user profile of the second entity 2 or according to a entry sent by the first entity 1 as part of the request, the intermediary entity 3 confirms that the request has been accepted by providing an acknowledgement of acceptance to the first entity 1. Such an acknowledgement of
  • acceptance is sent in the form of a text message to the first entity's mobile terminal 11, e.g. via the SMS gateway 8 and the SMS-SC 9' operated by the GSM network operator Y, since the first entity 1 is a subscriber of operator Y, e.g. through the communication links L3-L6-L7 (see block 219) .
  • a further acknowledgement of acceptance is sent in the form of an e- mail to the first entity's e-mail address, e.g. through the communication link L2 (see block 221), e.g. via an e-mail server (not shown in Fig. 1) connected to the Internet 4.
  • the intermediary entity 3 indicates or confirms, respectively, that the request has been rejected by
  • Such an acknowledgement or confirmation, respectively, of rejection (see blocks 224 & 228, resp.) is sent in the form of a text message to the first entity' s mobile terminal 11, e.g. via the SMS gateway 8 and the SMS- SC 9', e.g. through the communication links L3-L6-L7 (see block 223), and to the second entity's mobile terminal 11', e.g. via the SMS gateway 8 and the SMS-SC 9, e.g. through the communication links L3-L4-L5 (see block 227),
  • a further acknowledgement or confirmation, respectively, of rejection is sent in the form of an e-mail to the first and second entity's e-mail address, respectively, e.g. through the communication link L2 (see block 225 & 229, resp.), e.g. via an e-mail server connected to the Internet 4.
  • the outcome of the request is saved in an activity log (see block 231) by the intermediary entity 3, which activity log is stored in the database 7.
  • the request is rejected the availability of the second entity's, i.e.
  • the vendor's offer according to the rejected request will be set to unavailable (see block 232) for an unavailability period of time following determination that the request has been rejected, after which unavailability period of time the corresponding offers will be set back to available again.
  • the availability of the second entity's, i.e. the vendor's offers is stored in the database 7. If the availability of an offer is set to unavailable, it cannot be selected by a potential customer such as the first entity 1.
  • the unavailability period of time i.e. the time until which an offer is unavailable, can also be set according to a corresponding entry in the user profile associated with the second entity 2, i.e. the vendor. This allows the second entity 2, i.e. the vendor to provide information regarding the availability of an offer, e.g.
  • intermediary entity 3 e.g. a first or a second entity, respectively, i.e. a customer or a vendor, respectively, can check the status of requests with which they are associated (see blocks 233 & 233', resp. ) . They can do so by accessing the primary website 6 via their computer 10 or 10', resp., providing their login information and then sending a status query, e.g. via the communication link L2 (see blocks 234 & 234', resp.). The intermediary entity 3 will then compile a list of all or some selected requests, depending on the query, which list contains data regarding the status of the individual requests (see blocks 235 & 236) , and make the list available via the primary website 6 to the party who sent the query.
  • the party can then retrieve the list (see blocks 238 & 238', resp.) from the website 6 to their computer 10 or 10', resp., e.g. via the communication link L2 (see blocks 237 & 237', resp.).
  • contact information e.g. a mobile telephone number, e-mail address, etc. of the first entity 1, i.e. the customer
  • the second entity 2 i.e. the vendor.
  • This information can be used by the second entity 2, i.e. the vendor to contact the first entity 1, i.e. the customer, in order to exchange further information related to the request if need be.
  • the first entity 1 corresponds to a vendor (or seller) of corresponding products and/or services and the second entity 2 corresponds to a potential buyer (or customer) of corresponding products and/or services.
  • a practical application of such a use of the inventive method could be to provide an offer for sale for a commodity such as heating oil at a discount price, where only a limited quantity is available at that price.
  • the seller 1 can efficiently distribute such an offer to a large number of potential buyers and receive back offer acceptance text messages from willing buyer according to the inventive method.
  • the first entity 1 when using the inventive method for providing order confirmations, the first entity 1
  • inventive method corresponds to a vendor (or seller) of products and/or services and the second entity 2 corresponds to a buyer (or customer) of the corresponding products and/or services from the first entity 1.
  • a practical application of such a use of the inventive method could be to confirm stock trades submitted for instance via the website of a bank, the confirmation being made by means of an text message according to the inventive method.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Accounting & Taxation (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention porte sur un procédé de gestion d'une requête électronique entre deux entités à l'aide d'une entité intermédiaire ainsi que sur les utilisations du procédé. Une première entité adresse une requête destinée à une seconde entité, par l'intermédiaire d'un premier réseau de communication ouvert tel qu'Internet à une entité intermédiaire qui transfère ensuite la requête sous forme de message texte tel qu'un message SMS par l'intermédiaire d'un second réseau de communication sécurisé tel qu'un réseau GSM, à la seconde entité, qui indique une acceptation de la requête par l'envoi d'un message texte à nouveau à l'entité intermédiaire, ou rejette la requête, par exemple en ne répondant pas. Ensuite, l'entité intermédiaire soit confirme que la requête a été acceptée si la seconde entité a répondu dans un délai maximal de réponse, soit indique dans le cas contraire un rejet de la requête par la seconde entité par l'envoi d'un message texte correspondant à la première entité.
EP09780831A 2009-07-20 2009-07-20 Procédé de gestion de requête électronique à l'aide d'une entité intermédiaire Withdrawn EP2457201A1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2009/059301 WO2011009479A1 (fr) 2009-07-20 2009-07-20 Procédé de gestion de requête électronique à l'aide d'une entité intermédiaire

Publications (1)

Publication Number Publication Date
EP2457201A1 true EP2457201A1 (fr) 2012-05-30

Family

ID=41328559

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09780831A Withdrawn EP2457201A1 (fr) 2009-07-20 2009-07-20 Procédé de gestion de requête électronique à l'aide d'une entité intermédiaire

Country Status (2)

Country Link
EP (1) EP2457201A1 (fr)
WO (1) WO2011009479A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003053083A2 (fr) * 2001-12-14 2003-06-26 Hotsip Ab Procede et passerelle pour l'envoi de messages instantanes entre des utilisateurs appartenant a des reseaux differents
GB2398969A (en) * 2003-02-27 2004-09-01 Ericsson Telefon Ab L M Message management between communication units with differing capabilities
US20060153346A1 (en) * 2005-01-11 2006-07-13 Metro Enterprises, Inc. On-line authentication registration system

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5959543A (en) * 1996-08-22 1999-09-28 Lucent Technologies Inc. Two-way wireless messaging system with flexible messaging
AU2003237090A1 (en) * 2002-04-22 2003-11-03 Inphonic, Inc. Method and system for short message service (sms) transactions for wireless devices
US7676235B2 (en) * 2006-08-09 2010-03-09 Itechtool Incorporated Method and system for transmitting and receiving SMS messages with remapped response codes

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003053083A2 (fr) * 2001-12-14 2003-06-26 Hotsip Ab Procede et passerelle pour l'envoi de messages instantanes entre des utilisateurs appartenant a des reseaux differents
GB2398969A (en) * 2003-02-27 2004-09-01 Ericsson Telefon Ab L M Message management between communication units with differing capabilities
US20060153346A1 (en) * 2005-01-11 2006-07-13 Metro Enterprises, Inc. On-line authentication registration system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2011009479A1 *

Also Published As

Publication number Publication date
WO2011009479A1 (fr) 2011-01-27

Similar Documents

Publication Publication Date Title
US8620365B2 (en) Method for handling an electronic request with the aid of an intermediary entity
US11593786B2 (en) Examples of delivery and/or referral service SMS ordering
US11669824B2 (en) Shared mobile payments
US11593852B2 (en) System and method for swapping event tickets
US9406032B2 (en) Financial fraud prevention method and system
KR101352530B1 (ko) 인맥정보를 이용한 선물 발송 시스템 및 그 방법
US20160063473A1 (en) Method and system for processing food orders
US10074064B2 (en) Systems and methods for managing and facilitating secure package delivery
US20090171805A1 (en) Method and System for Conditional Transactions
WO2015051365A2 (fr) Système de réservation en ligne pour ramassage local de produits auprès de multiples détaillants
TW200905600A (en) Virtual shopping mall management system
JP2013528848A (ja) 支払いの処理方法
JP6524205B1 (ja) 取引管理システム、取引管理装置、取引管理方法及び取引管理プログラム
US20120215695A1 (en) Managing recurring payments from mobile terminals
KR20100045586A (ko) 휴대용 이동통신단말기를 이용한 결제 서비스 방법 및 그 시스템
KR20100066379A (ko) 서비스 객체의 선택적 공유를 이용한 객체공유 서비스 제공 시스템 및 그 방법
EP2457201A1 (fr) Procédé de gestion de requête électronique à l'aide d'une entité intermédiaire
KR20020059499A (ko) 이메일을 이용한 선물리스트 전송 및 물품 결제방법
KR101576495B1 (ko) 거래처 공유 서비스 제공 방법
US11587107B2 (en) System and method for customer and business referrals with a smart device concierge system
KR20040017542A (ko) 온라인 알선 거래 방법 및 시스템
US20140052582A1 (en) Online system for person to person transaction
SG191554A1 (en) Financial fraud prevention method and system
JP2001350995A (ja) オンライン予約システム及び方法、予約業務処理装置、並びに記録媒体

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20120216

AK Designated contracting states

Kind code of ref document: A1

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

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20130409

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20131022