WO2000072214A1

WO2000072214A1 - Method of processing reservation deposits

Info

Publication number: WO2000072214A1
Application number: PCT/US2000/014425
Authority: WO
Inventors: Paul G. Martin; Bradley Y. Matsuda
Original assignee: Passkey.Com, Inc.
Priority date: 1999-05-25
Filing date: 2000-05-25
Publication date: 2000-11-30
Also published as: EP1214672A4; CA2371793A1; AU5163300A; EP1214672A1

Abstract

A method of processing reservation deposits provides for classifying prospective visitors to an event (11, 13, and 15) and the accommodations available for reservation to the visitors. Attendee attrition is minimized by assigning dates prior to the start of the event for processing of credit card authorizations, collection of deposits, and full or partial refunds for cancellations. An increasing scale of penalties is applied between the processing fee date and a cancellation close date after which deposits are entirely forfeited upon cancellation. Business rules may be applied to the reservation, collection and cancellation payment process as a function of the classes of attendees and the accommodations.

Description

METHOD OF PROCESSING RESERVATION DEPOSITS Background of the Invention

This invention provides a method of processing guest hotel room reservation deposits, and making refunds for cancelled hotel reservations for conventions and similar events. More specifically, the invention provides a method by which a single entity can service multiple prospective guests making reservations among multiple hotels in connection with a convention or similar event, and can provide reservation status information to the guests and hotels, the convention sponsor, meeting planners, housing managers, and other personnel having a need for such information.

It is known in the art to provide a central information system for convention hotel reservations to the various parties concerned with planning for, and attendance at, a convention. However, the processing of reservations, reservation deposits, and reservation deposit refunds has, heretofore, required direct communication between attendees and the respective hotels in which rooms are being made available, or their agents. Reservation processing is further complicated by the need to enforce different sets of hotel attendance rules applicable to each respective convention, concerning matters such as level of accommodations, hotel locations relative to meeting centers, and proximity of different classes of attendees to one another.

In addition to the large number of personnel and substantial effort that must be dedicated to the processing of convention hotel reservations, prior art systems further suffer insofar as they encourage multiple booking of hotel rooms by convention attendees, and the resulting attendee attrition which follows as unneeded reservations are cancelled.

Summary of the Invention

The present invention overcomes the above described shortcomings of the prior art in providing a method of processing reservation deposits including storing, in a computer memory, data describing a plurality of rooms, the data comprising a quality classification for each room indicative of a class of visitors to whom reservations of said room are to be limited, and an inventory code for each of a plurality of dates indicative of whether or not the room is available for occupancy on each of the dates. For each visitor, there is stored in the computer memory, data describing a reservation request made by the visitor, the data describing the reservation request including a visitor class code assigned to the visitor, data indicating the stay dates for which at least one room is sought to be reserved by the visitor, and data identifying a financial institution and account therein from which collection of a deposit to secure the visitor's reservation may be made.

The visitor class code is compared with the quality classification for each room having an inventory code indicating that the room is available for each of the dates for which the reservation is sought. In response to the comparison signaling the availability on each of the stay dates, of a room having a classification corresponding to the visitor class code, the inventory code for the room is changed to indicate that it is no longer available, the room being reserved to the visitor,

For each visitor whose reservation has not been cancelled by the processing fee date, a collection request is generated for collecting the visitor's deposit payment from the financial institution. For each visitor whose reservation has not been cancelled by a reservation closing date, a transfer of funds to the hotel is initiated on a funds transfer date, the funds being equal in amount to a portion of the deposit from which there is excluded a processing fee.

A database with records of reservation requests and respective deposit payment offers is maintained. A comparison is made of the present time and a predetermined time for processing the reservation deposits and, if the present time is equal to or greater than the predetermined processing time, for each record of a reservation requested by a visitor, a collection request for transferring funds from a financial institution in which an account has been opened for the benefit of the visitor for payment of the deposit is initiated.

For each record of a request for cancellation of a reservation by a visitor, the time of the request is compared with the processing time, and from the comparison a determination is made as to whether a refund is due in response to the cancellation. A processing fee which is a function of the elapsed time between the processing time and the cancellation request time is subtracted from the deposit . The present time is also compared with a predetermined funds transfer date later than the close time, and if the present time is later than the close time, a fund transfer request for transferring funds to a financial institution in which an account has been opened for the benefit of the beneficiary merchant is initiated. Description of the Drawings

Fig. 1 is a schematic diagram showing the communication paths between attendees of an event and a commerce processor for performing the method of the preferred embodiment of the invention.

Fig. 2 is a flow diagram depicting steps of the method of the preferred embodiment of the invention. Fig. 3 is a graph of events versus time for the processing of deposits in accordance with the method of the preferred embodiment of the invention.

Fig. 4 is a graph of events versus time for the processing of cancellation refund requests in accordance with the method of the preferred embodiment of the invention.

Fig. 5 is a chart showing the relationship among modules of a computer program for performing the method of the preferred embodiment of the invention. Fig. 6 is a schematic block diagram of a module of the computer program illustrated to in Fig. 5.

Fig. 7 is a schematic block diagram of another module of the computer program illustrated to in Fig. 5.

Fig. 8 is a schematic block diagram of still another module of the computer program illustrated to in Fig. 5.

Fig. 9 is a schematic block diagram of a further module of the computer program illustrated to in Fig. 5.

Fig. 10 is a schematic block diagram of a still a further module of the computer program illustrated to in Fig. 5.

Description of the Preferred Embodiment

Referring now to Fig. 1 of the drawings, individual attendees or their agents can make hotel reservations by communicating with a central reservation and deposit management facility operated under the control of a software-based reservation management system, sometimes hereinafter referred to as a commerce processor. The commerce processor is capable of processing reservation deposits, which includes both payments and refunds. The computer program automates the process of authorizing credit cards used as a deposit in reserving a hotel room as well as initiating the transfer of funds from the payment processor to the specified merchant. The program also reports all failed transactions, which may then be investigated and resolved.

Communication with the reservation facility can take any form including telephone, fax, email or even personal visit to the central reservation facility. However, the most advantageous form of communication will be by accessing the central reservation facility's web site on the Internet .

Attendees may be of different classes, each of which will receive correspondingly different treatment in accordance with business rules usually promulgated by the convention sponsor. For example attendees may be respectively classified as general conference attendees 11, very important (VIP) conference attendees 13, and conference speaker attendees 15.

Requests for reservations received in the central reservation and deposit management facility, orally or in writing, are converted into machine readable form. Referring additionally to Fig. 2, requests for reservations received in the central reservation and deposit management facility are made by the visitor or attendee, or an agent, completing a form on a web page that is accessible on the Internet, thereby ensuring compatibility with the central reservation and deposit management facility software. These forms are provided with the necessary menus and controls, e.g., check boxes, dropdown lists, combo boxes and the like as will be known to those skilled in the art. Rules for data entry, such as field sizes, capitalization, punctuation are enforced at the form level and necessary conversions of obvious errors can be made to ensure consistency with the input data requirements of the commmerce processor software. Reservation requests from the various classes of attendees, in machine readable form, are stored in a reservation database accessible by a computer on which the commerce processor program resides . Associated with each reservation is a deposit fee payable to the operator of the commerce processor as a service charge for entering each reservation received into the reservation database and a processing fee for collecting the funds in payment of the deposit.

Each reservation in the master reservation system is entered into a commerce transaction process table for processing on dates which will normally be predetermined for each event that is being attended. Referring to Figs. 3 and 4, reservations are accepted over a continuous range of dates beginning with a reservation open date and ending with a close date after which reservations are no longer accepted and deposit refunds are no longer made.

In the preferred embodiment of the invention, the commerce processor program credits its operator with two payments for each reservation. The first payment is earned, on all reservations, on a predetermined date subsequent to the reservation open date . The second payment is a processing service charge which is earned when the deposit payment is processed for collection on a predetermined date subsequent to the deposit fee date. No processing fee payment is earned on reservations cancelled before the processing fee date.

Referring to Fig. 2, the commerce processor software cyclically compares the current date with the predetermined deposit fee date, processing fee date, close date, and a funds transfer date for each reservation and performs the actions scheduled for those dates .

Each record of a reservation requested in connection with the event is selected from the commerce transaction process table. If payment of the reservation deposit by credit card has been requested, an authorization request is constructed and transmitted to a clearing house for such requests. A record of the authorization request is entered into a commerce transaction history table.

A corresponding authorization response request is then received from the clearing house. The commerce processor software tests the response and, if a credit card charge authorization has been granted, an order to charge the deposit to the credit card account is constructed and retransmitted to the clearing house.

The clearing house transmits an acknowledgement of the credit card charge order to the reservation facility which is reported to the commerce processor software. In response to a successful acknowledgment, the commerce processor software then causes a confirmation of the reservation to be transmitted to the attendee by email . The commerce processor software then tests for whether there are more reservations to be processed and, if there are, repeats the foregoing procedure. If there are no more reservations, processing is halted until another reservation is received.

If a successful acknowledgement of the credit card deposit charge order is not received, a record of the failure is written to a table of failed acknowledgement requests for later follow-up and is also recorded in the log of failed commerce transactions. Reservations may be received before and after the processing fee date. Reservations received before the processing fee date are batch processed on the processing fee date. Reservations received after the processing fee date are generally individually processed substantially immediately after receipt.

If a credit card charge authorization has been denied in response to an authorization request sent to the clearing house, a record of the failed transaction is entered into a daily log by the commerce processor software. Manual follow-up of failed authorization requests and charge acknowledgements can be done at a terminal from which the commerce transaction history table and failed commerce transaction log can be accessed.

Referring again to Fig. 1, the commerce processor software includes a group inventory manager module 17. The group inventory manager module 17 is connected to a database containing hotel inventory records 19 each of which can be associated with a hotel room. The rooms can be categorized into blocks, each block being preassigned to different type or class of attendees. That is one block may be assigned for occupancy by general attendees 11, another block for VIPs 13 and a third block for speakers 15.

Inventory is broadly categorized as "available" or "booked. " As each room reservation is accepted, one or more fields of each relevant record in the inventory database is updated to reflect the assignment of a room to the reservation. Assigned rooms are classified as "booked" and removed from the blocks of rooms available for assignment to fill future reservations.

Thus, the group inventory manager module 17, receives requests for inventory from multiple classes of possible attendees, filters available inventory and offers only inventory that complies with business rule constraints in the database, allocates inventory based on business rules for attendee class, length of stay and number of guests, imposes and discloses constraints on cancellation, updates the information in an inventory configurator module 21, and receives messages from a payment controller module 23.

Referring additionally to Figs. 5 and 6, an inventory configurator module 21 of the commerce processor program code is provided with data specifying the number and quality of rooms available at each hotel property participating in the convention. Data may also be provided ranking each hotel property in accordance with desirability, taking into account such factors as distance to convention events, condition of physical plant, and amenities offered to guests.

In accordance with business rules set forth in the code contained in the inventory configurator module 21, the inventory configurator module 21 allocates a different attendee code to each class of attendee. Depending on the size of the convention, the inventory configurator module

21 may assign individual rooms or blocks of rooms for occupancy by different classes of attendees . A minimum number of nights for which each room or block of rooms may be reserved is designated by the inventory configurator module 21 as a function of the class of attendee, i.e., attendee code, for which the room or block of rooms has been allocated. The number of guests who are to occupy each room is also designated by the inventory configurator module 21 as a function of attendee code corresponding to the room, or the block of rooms or which it is a member.

In accordance with agreements between the convention sponsors and participating hotel merchants, different rooms or blocks of rooms may be removed from the participating hotels' regular inventories of rooms available to the general public, for different ranges of dates. For example, it may be desired to have VIPs 13 arrive earlier than other attendees to participate in special functions. Or, speakers 15 who are only giving presentations over one or two days of a longer convention may require rooms for a briefer range of dates than other attendees. In order to accommodate differences in stay dates, the inventory configurator module 21 receives business rules and applies the rules to each block of rooms as a function of the codes of the attendees respectively/ assigned to the block of rooms.

Room rates can also be assigned by the inventory configurator module 21 to each block of rooms according to the class of attendees to whom the rooms are assigned. For example, the rooms occupied by speakers 15 may be paid for by the convention sponsor and allowed a discount in accordance with the convention sponsor's contract with the hotel (s) . The group inventory control manager module 17 arbitrates requests for reservations from, and assignment of rooms to, attendees. The group inventory manager module 17 receives reservation requests from multiple classes of attendees, and their agents, upon their transmission to the central reservation facility.

Upon receipt of a reservation request, the group inventory manager module 17 interrogates the room inventory database in accordance rules stored in the inventory configurator module 21. That is, the room inventory is filtered in accordance with the class of attendee for whom a reservation is requested and the pool of unassigned rooms. Other factors used in filtering the room inventory may include the type and length of stay for which a reservation is being sought, that is the number of nights and beginning date of the stay, and the number of guests who, with the attendee, are to occupy the reserved room(s) . Thus the requester is offered a room only from those blocks of rooms which have been allocated to attendees of the requester's class, that is those rooms associated with the attendee code of the reservation requester, the requested time and type of stay, and the number of guests sharing the room(s) . Cancellation terms and penalties applicable to the class of attendee are also disclosed to the reservation requester at the time that the reservation is booked. The group inventory manager module 17 communicates directly with the inventory configurator module 21 to apply the business rules governing the reservation of rooms to the attendees for whom reservations are sought.

In addition to having code for performing room inventory management and allocation functions, the commerce processor software includes code for processing reservation deposits. The payment controller module 23

(see Fig. 10) includes payment configurator code in which there are stored business rules governing the handling of reservation deposits, authorizations and refunds. The payment controller has payment configurator code which determines the processing fee dates for each of the types of transactions, i.e., credit card authorizations, collection of deposits by initiating charges to credit cards or depositing checks for collection, and issuing of credits to credit cards for refundable cancellations. The payment controller has credit card controller code for transmitting charge and credit transaction requests to an electronic payments system, and check controller code for transmitting requests for collection of deposits made by check to a banking system.

The payment controller module 23 can have stored within it, for each class of attendee, a plurality of dates in the cycle of the processing of a payment listed in chronological order as follows:

1. Reservation Open Date - The date when reservations can first be made for an attendee of a given class. 2. Deposit fee date - The date by which the attendees deposit must be received in order to avoid cancellation of the reservation.

3. Processing fee date - The date by which a predetermined portion of the attendee's deposit is earned by and paid to the operator of the commmerce processor, and is nonrefundable to the attendee . In the preferred embodiment of the invention, the processing fee is a fixed fee per transaction collected once for each attendee reservation. If desired, the processing fee can be computed as a percentage of the value of the attendee's stay to the participating hotel.

4. Cancellation Close Date - The date by which the entire reservation deposit becomes nonrefundable to the attendee . 5. Funds Transfer date - The date on which the operator of the central reservation and deposit management facility transfers to the room provider hotel merchants, the reservation deposits, less refunds made prior to the cancellation close date and processing fees earned by the central reservation and deposit management facility operator.

6. Event date - The date on which the convention or other sponsored event begins . For each date in the event cycle, the payment controller code determines, for each attendee on behalf of whom a reservation requests has been made, which processes are to be performed, including credit card authorization, charging of deposit to credit card account, deposit of reservation check for collection by financial institution, and refund of deposit by issuance of check or credit to attendee ' s credit card account .

The payment controller code presorts the various processes by type and then transmits the data for batch processing. For example, all credit card authorization requests may be transmitted via credit card controller code to an external electronic payments system for approval. Similarly, authorized credit card deposits may be communicated to the electronic payments system in a batch process by the credit card controller code. Check payments are routed, in bulk, to the banking system for collection via check controller code.

As status messages are received from financial institutions and other parties to the payment settlement process they are distributed for access by those having a need to know. Result messages indicative of the timeliness and validity of deposits are communicated to the group inventory manager module 17 to ensure that rooms are assigned only to attendees who have paid their reservation deposits .

Thus, the payment controller module 23 employs payment configurator code for determining when to process each type of transaction, requests sets of transactions to be processed from the attrition enforcer module 29, groups transactions to be processed into similar types for batch processing, e.g., authorizations, collections, and refunds and packages them for delivery to the corresponding -In¬

payment system. In addition, the payment controller module 23 has code for distributing status messages for access by parties to the settlement process. Finally, the payment controller provides result messages to the inventory manager which enable rooms for which reservations have been cancelled to be returned to available inventory.

A major benefit achievable with the central reservation and deposit management facility of the invention is a substantial reduction in multiple bookings and cancelled reservations. Maintaining and enforcement of business rules governing the refund and forfeiture of deposits discourages cancellations in general . Enforcement of an escalating scale of deposit forfeiture amounts encourages attendees who must cancel to do so as early as possible to enable the rooms to be returned to available inventory and rebooked.

An account for each beneficiary merchant, e.g., hotel operator, is established in an attrition manager module 25 (see Fig. 7) in the commmerce processor software. Business rules directed to reduction of attendee attrition are stored for each combination of beneficiary merchant and attendee class. Initial date threshold manager code stores a processing fee date for the commencement of deposit forfeiture, and threshold dollar manager code stores forfeiture dollar amounts which are to be applied as a function of date of cancellation. There is no forfeiture on cancellations made prior to the processing fee date. Forfeiture charges begin to be applied and increase with time from the processing fee date until the cancellation close date. There is a one hundred percent forfeiture of deposits on cancellations made after the cancellation close date. Unit count limit manager code provides a predetermined limit on the number of rooms that can be reserved by a deposit to a single credit card for attendees of each class. VIPs 13 may thereby be allowed to reserve more rooms on a credit card than may general attendees 11.

The unit count limit manager code compares the number of rooms sought to be reserved with a predetermined limit on the number of units that can be charged to a single credit card for the respective class of attendee, irrespective of the amount of the charge. If the result of the comparison indicates that the number of rooms sought to be reserved on a credit card is less than or equal to the predetermined limit assigned to the respective class of attendee, the attendee's credit card is charged with the deposit amount as will hereinafter be explained.

Thus, the attrition manager module 25 receives secured user input, establishes participating beneficiary merchant (e.g. hotel operator) accounts, establishes an inventory unit count limit per credit card for each class of attendee, establishes initial threshold processing fee dates, establishes all threshold processing dollar amounts, establishes record writing dates for all other steps, and establishes charge amounts for credit card transactions.

An attrition adjuster module 27 (see Fig. 8) contains code for determining the times at which cancellation penalties are applied in steps occurring from the processing fee date until the cancellation close date, the amount applied at each step having been established in the threshold dollar manager code of the attrition manager module 25. Attrition rules are applied by class of attendee. Thus VIPs 13 may be given more favorable treatment on cancellation than the treatment given to general attendees 11. The attrition adjuster code also provides for adjusting the attrition step by class of attendee. For example, the deposit of a general attendee 11 may be penalized more in more frequently occurring steps than the deposit of a VIP 13.

Thus, the attrition adjuster records an attrition rule for each attendee class, records multiple attrition rule steps for each attendee class, records attrition step threshold dates for each attendee class, and records an attrition step dollar cost for each attendee class.

An attrition enforcer module 29 (see Fig. 9) has a clock input for continuously receiving time signals from a time agent. Threshold listener/trigger code determines when a time has been reached at which refunds for prospective cancellations are to be penalized and triggers a reduction in the portion of the deposit which may thereafter be refunded in response to a cancellation. The threshold listener/trigger code signals action broker code to direct that a signal be sent to a payment controller module 23 via action actor code. The action/actor code updates the threshold listener/trigger code in preparation for the next penalty event.

Thus, the attrition enforcer identifies a financial charge (transaction) for each time threshold crossed by each attendee as a function of the attendee's class, identifies a progress charge amount inversely related to proximity to the event start date, and computes a diminishing refund for each prospective cancelled reservation consistent with the rule for each class of attendee as established by the attrition adjuster. It is to be appreciated that the foregoing is a description of a preferred embodiment of the invention to which variations and modifications may be made without departing from the spirit and scope of the invention.

Claims

hat is claimed is:

1. A method of reserving rooms for visitors seeking hotel accommodations comprising storing, in a computer memory, data describing a plurality of rooms, said data comprising a quality classification for each room indicative of a class of visitors to whom reservations of said room are to be limited, and an inventory code for each of a plurality of dates indicative of whether or not said room is available for occupancy on each of said dates, for each visitor storing in said computer memory data describing a reservation request made by said visitor, the data describing said reservation request comprising a visitor class code assigned to said visitor, data indicating the stay dates for which at least one room is sought to be reserved by said visitor, and data identifying a financial institution and account therein from which collection of a deposit to secure said visitor's reservation may be made, for each visitor, making a comparison of said visitor class code with the quality classification for each room having an inventory code indicating that said room is available for each of the dates for which said reservation is sought, and in response to said comparison signaling the availability, on each of said stay dates, of a room having a classification corresponding to said visitor class code, changing said inventory code for said room to indicate that it is no longer available, said room being reserved to said visitor, for each visitor whose reservation has not been cancelled by a processing fee date, generating a collection request for collecting said visitor's deposit payment from said financial institution, and for each visitor whose reservation has not been cancelled by a reservation closing date, initiating a transfer of funds to said hotel on a funds transfer date, said funds being equal in amount to a portion of said deposit.

2. A method according to claim 1 further wherein said closing date is later than said processing fee date.

3. A method according to claim 2 wherein said funds transfer date is later than said closing date.

4. A method according to claim 1 further comprising, for each visitor, charging a reservation fee comprising a processing fee, the amount of said portion of said transferred funds being less than or equal to the amount of said deposit reduced by said reservation fee.

5. A method according to claim 4 further comprising, for each visitor, charging a deposit fee, the amount of said reservation fee being equal to the sum of said deposit fee and said processing fee.

6. A method according to claim 1 further comprising for each visitor whose reservation has been cancelled on or before the fourth date corresponding to said visitor, initiating a refund of funds to said visitor, said funds being equal in amount to the deposit collected from the account of said visitor.

7. A method according to claim 1 further comprising for each visitor whose reservation has been cancelled on or after the processing fee date and before a cancellation date intermediate said processing fee date and said fund transfer date, computing a cancellation charge amount as a function of the date of cancellation of said reservation, and computing the difference between the amount of the deposit collected from the account of said visitor and the amount of said cancellation charge , and if the amount of said cancellation charge is less than the amount of the deposit collected from the account of said visitor, initiating a refund of funds to said visitor.

8. A method according to claim 7 wherein said cancellation charge amount is equal to the sum of a reservation fee amount and a cancellation penalty amount.

9. A method according to claim 8 wherein in accordance with said function said cancellation penalty amount increases as the date of cancellation approaches said fifth date.

10. A method according to claim 8 wherein said reservation fee comprises a processing fee charged on or after said fourth date.

11. A method according to claim 8 wherein said reservation fee comprises a deposit fee charged on or after said second date.

12. A method according to claim 7 further comprising, for each visitor whose reservation has been cancelled on or after said corresponding sixth date one of a range of fifth dates, equal to or later than said fourth date corresponding to said visitor, initiating a transfer of funds to said hotel, said funds being equal in amount to a portion of said deposit.

13. A method of processing reservation deposits of visitors seeking hotel accommodations from a beneficiary merchant in connection with a future event comprising maintaining a database with records of reservation requests and respective deposit payment offers, comparing the present time with a predetermined time for processing said reservation deposits and, if the present time is equal to or greater than said predetermined processing time, for each record of a reservation requested by a visitor, initiating a collection request for transferring funds from a financial institution in which an account has been opened for the benefit of said visitor for payment of said deposit.

14. A method of processing reservation deposits in accordance with claim 13, further comprising, for each record of request for cancellation of a reservation by a visitor, comparing the time of said request with said processing time, determining from said comparison whether a refund is due in response to said cancellation, and if a refund is determined to be due, computing the amount of said refund as a function of said cancellation request time and said processing time, and initiating a refund of said amount to said visitor.

15. A method of processing reservation deposits in accordance with claim 14 wherein said computation includes subtracting from said deposit a deposit fee irrespective of whether said cancellation request time is earlier or later than said processing time.

16. A method of processing reservation deposits in accordance with claim 14 wherein said computation includes subtracting from said deposit a processing fee, said processing fee being a function of the elapsed time between said processing time and said cancellation request time .

17. A method of processing reservation deposits in accordance with claim 16 wherein each of said visitors is assigned to a class of visitors and said processing fee is also a function of the class assigned to said visitor.

18. A method of processing reservation deposits in accordance with claim 16 wherein said processing fee increases as said elapsed time increases.

19. A method of processing reservation deposits in accordance with claim 13, further comprising, for each record of request for cancellation of a reservation by a visitor, comparing the time of said request with a close time subsequent to said processing time, and if said cancellation request time is later than said closing time determining that no refund is due in response to said cancellation request.

20. A method of processing reservation deposits in accordance with claim 13, further comprising, comparing said present time with a predetermined funds transfer date later than said close time, and if said present time is later than said close time, initiating a fund transfer request for transferring funds to a financial institution in which an account has been opened for the benefit of said beneficiary merchant.