WO2001073592A2 - System and method for purchasing a commercial asset via electronic commerce using single user action of buyer and seller - Google Patents

System and method for purchasing a commercial asset via electronic commerce using single user action of buyer and seller Download PDF

Info

Publication number
WO2001073592A2
WO2001073592A2 PCT/US2001/009759 US0109759W WO0173592A2 WO 2001073592 A2 WO2001073592 A2 WO 2001073592A2 US 0109759 W US0109759 W US 0109759W WO 0173592 A2 WO0173592 A2 WO 0173592A2
Authority
WO
WIPO (PCT)
Prior art keywords
seller
contract
buyer
trade
terms
Prior art date
Application number
PCT/US2001/009759
Other languages
French (fr)
Other versions
WO2001073592A8 (en
Inventor
Peter F. Fox
Original Assignee
Zulunet, Inc.
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 Zulunet, Inc. filed Critical Zulunet, Inc.
Priority to AU2001249487A priority Critical patent/AU2001249487A1/en
Publication of WO2001073592A2 publication Critical patent/WO2001073592A2/en
Publication of WO2001073592A8 publication Critical patent/WO2001073592A8/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/06Buying, selling or leasing transactions

Definitions

  • This invention relates to the field of electronic commerce, and more particularly, this invention relates to purchasing a commercial asset using electronic commerce.
  • a potential customer visits a web site and browses for a product by searching with a web browser as part of client software forming a user interface and through a database connected to the host processor acting as a web server. Payment is made by credit card after finding the product and entering a secure area of the web site.
  • the customer presses a submit or other button, the information is sent from the customer (user) or client's computer to a secure transaction server over the Internet in an encrypted fashion.
  • the transaction server receives the encrypted information, decrypts it, and then verifies the account with the credit card company to ensure that the card is valid.
  • the transaction server confirms the order back to the customer, also refreshing the web page, which can be printed by the customer.
  • the transaction server also sends an order to a warehouse, which ships the product to the customer.
  • a "cookie” is positioned as a small piece of data on a customer's hard disk, which is used to identify that client or user station. Whenever the database is searched and the customer clicks on the item, then a new piece of data can be written to the cookie to identify the item. The cookie can be used to tell a web server what items to display on the page. When the items are actually bought, the items can be deleted from the cookie.
  • a seller completes an item form, indicating what item is to be auctioned, and then transmits the data to an auction site's database to create a record for the seller.
  • a web page is created when a potential bidder accesses the database.
  • the program or script takes information from the database to create the web page.
  • the bidder views the item via the web page and wants to bid on it, the bidder fills out a form to update the auction record in the database.
  • the web page describing the auction is updated, the new bid is reflected for all potential bidders .
  • the auction closes and the database is queried to determine which bidder has the highest bid.
  • the bidder and seller then contact each other privately to negotiate or arrange for shipping.
  • a method and system for purchasing a commercial asset includes the step of retrieving a listing of at least one potential seller of a commercial asset that a buyer desires to purchase. At least one seller is selected from the listing to obtain a quotation of contract terms for purchasing a commercial asset. A request for quotation of the commercial asset to be purchased is transmitted to a selected seller and this is viewed by a potential seller on a computer screen to determine if a response is appropriate. If the response is appropriate, a worksheet contract template can be retrieved and data entered into the worksheet contract template corresponding to a quotation of contract terms to be offered by the seller to the buyer. This quotation of contract terms is forwarded to the buyer and displayed on a computer screen. Based on the single user action of the buyer, the contract terms can be accepted, negotiations with the seller entered, or the contract and any negotiation terms saved into a legal repository.
  • the single user action comprises the step of depressing a button.
  • the proposed contract terms can also be modified within the worksheet contract template and the displayed contract template viewed by the buyer and updated as the seller modifies any proposed contract terms. It is also possible to display on a computer screen a window having a listing of a plurality of quotations of contract terms in response to selecting a plurality of different sellers. These contract terms can be forwarded into the worksheet contract template in response to a single user action of a seller.
  • the worksheet contract template is specific to a commercial asset. The user can invite into an on-line, networked trade forum the seller of the commercial asset and establish a real-time communication channel with the seller.
  • the on-line, networked trade forum can be terminated and a time established in which the on-line, trade forum will be reconvened.
  • the commercial asset includes one of manufactured goods, money used for credit, money used for insurance risk mitigation, or physical transport mode to move any manufactured goods.
  • the computer network can include a publicly accessible communications network.
  • a database search can be conducted and the buyer and potential seller matched within the management server to produce search results.
  • the listing of potential sellers can be a plurality of potential sellers and the plurality are selected.
  • FIG. 1 is a schematic, fragmentary drawing showing the international trade logistics of goods, transport and money or finance, which are integrated via business-to-business commerce with the sourcing, ordering and delivery of these services.
  • FIG. 2 is a schematic, block diagram showing the trade portal with the management host server and the networked connection between the on-line users and service providers.
  • FIG. 3 is a high level schematic, block diagram showing the management host server that works in conjunction with the storage manager (server) for the primary legal repository and replica legal repository, XML filters, and EDI translator service.
  • FIG. 4 is another high level, schematic, block diagram showing the interrelationship among the management host server, user and service providers.
  • FIG. 5 is another schematic drawing showing the management host server and its connection to various users and service providers to integrate the electronic markets of goods, finance and insurance, transport and regulatory, e.g., customs.
  • FIG. 6 is a flow chart illustrating the functional flow of an example of the basic method of the present invention.
  • FIG. 7 is a schematic, block diagram showing various client, e.g., user stations that have a user interface for access to the different electronic markets and legal repository.
  • FIG. 8 shows another schematic block diagram of the information ' flow among various servers and applications in one aspect of the present invention.
  • FIG. 9 shows a graphical user interface (GUI) that is an example of a GUI that could be used in the present invention.
  • GUI graphical user interface
  • FIG. 10 is a system diagram illustrating the basic function and flow of information among the operations control center and a shipper (buyer) and cargo carrier (seller) .
  • FIG. 11 is a more detailed diagram of the operations control center and the flow of information between a cargo carrier and shipper.
  • FIG. 12 is a diagram illustrating an example of the contract formation between a cargo carrier and shipper.
  • FIG. 13 is a schematic drawing of a graphical user interface showing indicia on an aircraft graphic pertaining to cargo space, and an open data entry window for configuring the cargo space.
  • FIG. 14 is an open window showing a reservations page for a user that can be registered as either a buyer, seller or both, and showing a "work-in- progress" screen to cover the spread of work and what kinds of quotes are pending and incoming, and what contracts are pending and active.
  • FIG. 15 is an open window showing a screen having a toolbar selection for aircraft availability posting for listing aircraft and showing other elements of the toolbar.
  • FIG. 16 is an open window similar to FIG. 15 with the same toolbar, but the aircraft search item selected and displayed charter search results.
  • FIG. 17 is a data entry window used for entering elements of a search for a on-demand charter and displaying on-demand charter search results.
  • FIG. 18 is an open window that verifies an on-demand charter request for quotation has been sent and the location where it has been sent.
  • FIG. 19 is similar to FIG. 18, and shows a long-term charter request, and what information has been sent.
  • FIG. 20 is another open window showing a summary for viewing by a seller of a specific request for quotation.
  • FIG. 21 is an example of the type of data entry boxes are displayed for creating an on-demand quotation and calculating a response to a buyer.
  • FIG. 22 illustrates an open window viewed by a buyer and showing quotation results.
  • FIG. 23 is an open window for a trade forum, also known as Zulu Forum, showing what users are actie and can be met for negotiations and discussion.
  • FIGS. 24-26 show various agreements of aircraft charters that are initially viewed by the seller (FIGS. 24 and 24A) , forwarded to the buyer (FIGS. 25 and 25A) , and after acceptance (FIGS. 26 and 26A) .
  • FIG. 27 shows the type of information that is stored in the legal repository of the present invention.
  • the present description proceeds with a methodology and system description of effecting and managing a commercial transaction among a plurality of parties in the networked computer environment (FIGS. 1-9) .
  • Different service providers such as sellers of cargo flights, each own or control a commercial asset such as a charter flight.
  • These assets are negotiated in an on-line, networked, trade forum.
  • FIGS. 14-26 there follows a description of an example using a system of facilitating cargo charter flights and cargo space reservations (FIGS. 10-13), followed by a more detailed explanation of an example of a series of exchanges between a buyer and seller for an aircraft charter, as shown in FIGS. 14-26.
  • a shipper is defined as any person that organizes the movement of purchased goods.
  • a shipper could be a person working for an intermediary company that organizes the shipment of goods for others.
  • a shipper could also be a person working for an organization that produces the goods for shipment, a person working for the organization that buys the goods, an individual selling goods, or an individual buying goods.
  • the shipper is also in some instances in the description referred to by the term "buyer.”
  • a service provider is defined as any person owning or controlling an asset, where an asset is one of: (1) manufactured goods; (2) money used for credit or insurance risk mitigation; or (3) a physical transport mode used to move goods.
  • a service is the use of assets by a service provider on behalf of a shipper.
  • the term "user” will refer to a shipper who uses the trade portal and system for locating goods and services, integrating goods, transport, finance and services, and even acting as a moderator for real-time negotiation.
  • service provider is also referred to as “cargo carrier” for transporting cargo with a shipper having cargo to be shipped to a destination, and also “seller, " such as a seller of aircraft charters or cargo space.
  • FIG. 1 illustrates the three major areas of international trade logistics which are the key to the asset market, such as goods 10, transport 12 and money 14, e.g., finance/insurance. These electronic markets are integrated in the supply chain. Goods can be sourced, and ordered with appropriate financing and insurance, and then transported in delivery.
  • the horizontal portal works with a user 22, e.g., shipper or buyer, who is on-line and has a user interface application 24 that interfaces with a host management server 26, which has an associated database, various associated functions and applications, such as a real-time Trade Forum, Trade File, Trade Link, Trade Alerts and Trade News, as will be explained in greater detail below.
  • the Trade Portal also provides a vertical portal 20b for locating goods and services with multi-party and Internet enabled service providers 30 that can network with the trade portal 20.
  • the horizontal portal 20a aspect of the trade portal 20 integrates the process for goods, transport, finance and services, such as quoting, contracting, tracking and paying.
  • the vertical portal 20b aspect allows a user to locate goods and services.
  • FIG. 3 illustrates a user 22 at a user station 22a that is in communication via the Internet 32 to the web server 34 that is part of the host management server 26, which includes a trade forum application 36 that establishes a trade forum for real-time exchange and negotiating.
  • a storage manager and server 38 is operated and associated with a primary legal repository 40, e.g., database, and a replica legal repository 42, e.g., database, for redundancy in case the repository 40 is inoperative.
  • the repository 40 contains information about service providers 30 and contract or templates used for transacting and negotiating in business, as will be explained below.
  • Extensible Mark-up Language (XML) filters connect to the repositories 40,42, and work in conjunction with Electronic Data Interexchange (EDI) translator service 46, which could receive signals and information from remote sources 46a (FIG. 7) .
  • EDI Electronic Data Interexchange
  • the Electronic Data Interexchange translator service allows a transfer of information between organizations and machine-readable form in order to carry out business transactions, while also allowing translation services for inherent language differences.
  • the basic flow of information is the same as in conventional business except that electronic messages take the place of paper.
  • FIG. 4 illustrates yet another more detailed view of the trade portal 20, and the management host server 26 that is connected to the user station 22a having a client software for browsing the Internet and enabling software for connecting into the trade portal 20.
  • the user station 22a is operated by a shipper who connects via the Internet to the trade portal 20 and management host server 26, and establishes real-time communication channels between the user and each service provider that is entered and on-line in a trade forum.
  • the on-line negotiations could be instituted, for example, afer requests for quotation are sent by a shipper or buyer to a seller or cargo carrier, i.e., service provider, and terms must be negotiated.
  • the independent communication channels prevent a respective service provider from learning any negotiation terms of respective other service providers that are in communication with the user within the on-line, networked trade forum, and are shown by the dashed line configuration 21.
  • a record of the negotiated terms are maintained within the legal repository 40 as part of a database.
  • the service providers include service providers 30a of goods that have their computers at their stations connected to the management host server 26, service providers 30b for transport services that have their computers of their stations connected to the management host server, and service providers 30c for finance services.
  • the finance service provider is not connected at this time in the example shown.
  • Each of the illustrated service providers for goods has a realtime communication channel with the user, but cannot determine the negotiations of any other respective service provider that is linked into the on-line trade forum. When negotiations have been completed, one service provider 30a for goods that has come close to final negotiations with the user could invite service providers for transport services into the trade forum to discuss transport services and begin negotiations.
  • the trade portal 20 includes the management host processor 26 that generates a web site, such as the ZulunetTM web site, as described below with reference to the graphical user interface drawings shown as examples in FIGS. 14-26.
  • the trade portal 20 offers other information services related to international trade domestic tracking, and related information in a similar manner how other ' Internet portals provide services directed to a specific group, such as women or college students.
  • Internet-enabled or “trade-enabled” refers to an Internet or EDI system used by a third party, who has implemented a network interface specification for connections and communicating with the trade portal, and has accepted the commercial and contractual terms of linking its site into the trade portal and associated servers to allow the real-time trade.
  • a network interface specification is a specification of the communications protocols and message formats used to support the interaction of Internet-enabled systems that connect to the trade portal.
  • a trade link application 50 (FIG.
  • FIG. 5 illustrates the management host server
  • Web pages 58,60 relating to transport and goods can also be brought up by the user, giving information about the various service providers of those goods and transport services. It is also possible to bring up web pages about regulatory agencies, e.g., customs information.
  • FIG. 6 illustrates an example of a basic flow chart of a method that could be used with the present invention.
  • FIG. 6 is only illustrative of various types and the flow of information that can occur in the process. Naturally, FIG. 6 is not limiting, but only represents one example of the method. For purposes of clarity, reference numerals begin with the number 100, and run sequentially.
  • the user initially starts (block 100) and connects via the Internet to the trade portal (block 102) .
  • HTML codes are forwarded by the management host server, and the client software forming the user interface brings up a main web page for the "ZulunetTM" trade portal. While connected to this trade portal, the user can search a database for commercial assets to be negotiated, which could include goods, transport, finance, insurance or other services, as suggested and known to those skilled in the art (block 104).
  • the user 22 searches for relevant templates to be presented to service providers (block 106), or obtains a user prepared template.
  • These templates contain legal and commercial forms, having terms that define the business relationship to be negotiated.
  • the template also defines the business rules of the trade forum.
  • the templates can be formed as a spreadsheet type form or other format that would express the various legal and commercial terms.
  • the service providers 30 are then invited to the trade forum (block 108) and a real-time communication channel is established to each service provider (block 110) .
  • the application software can vary as known to those skilled in the art for establishing the communication channels. An example is a software program entitled Net Meeting by Microsoft Corporation. Other examples are known to those skilled in the art.
  • the user 22 will negotiate with various service providers for one asset or a plurality of different assets. Portions of the template or the entire template are then presented before the service provider (block 112) via the service provider software interface that is Internet-enabled and operable with the trade portal. In some instances, it may not be necessary to have a service provider view an entire template, but only portions of the template that are relevant to the particular services are presented before the service provider.
  • the user can act as a moderator during the negotiation of commercial and legal terms that define the template (block 114) .
  • the template is updated, or revised (block 116) , as negotiations continue, and if the negotiations are complete and a contract made (block 118), then the session is terminated (block 120) and the transaction is tracked via the template (block 122) .
  • a user or shipper can bring up the template and determine if a scheduled cargo carrier flight has been delayed or other problems have occurred in the shipment.
  • the management host server as part of the trade portal can contact a shipper or user if there is a problem, such as through e-mail, paging, cellular service, by phone operator, or other means known to those skilled in the art.
  • the process then ends if there have been no problems (block 124) . If negotiations are not complete (block 118), it is possible that the moderator (e.g., shipper) or other party desires to cancel the session and reconvene at a later time. Thus, a time is established to reconvene (block 126) and the session terminated (block 128). The session is reconvened at the appointed time and date, and the template is brought up before the service providers and user (block 130) with the template defining the record of the negotiations that have previously occurred.
  • the moderator e.g., shipper
  • FIGS. 7 and 8 disclose in block, schematic format applications that are available through the trade portal via the main Zulunet web page or other means operative with the client software interface application.
  • This open, real-time trading system using the trade portal allows many market participants to share information and coordinate the trade process and interactions among the goods, finance and transport markets. Equal participation by users in an open market allows the participants to cooperate to the extent of promoting the collective capability of the total market space, without removing the incentive to compete. In essence, a small number of companies, e.g., FEDEX and UPS, own significant percentages of the total market space through the use of proprietary and closed trading systems. The remainder of the market is fragmented among multiple small to medium companies.
  • the trade portal 20 allows a major portion of the remainder of the market to be "de-fragmented" through the use of the open trading network system, which allows the electronic replication of the existing trade process and its related paper documents and associated overheads of duplication, rigid process and assumptions about relationships between market participants.
  • the trade portal 20 through which service providers can promote and sell the use of their assets and related services, creates a larger open market for all participants, than could be achieved through closed systems, as described before.
  • Shippers can now electronically coordinate the purchasing of goods and related finance with the acquisition and management of transport facilities from origin to destination.
  • the trade portal 20 allows coordination and purchase of goods, transport and finance by routing consistent information, entered once, between these markets.
  • the open and publicly accessible trade portal acts as a funnel to attract a large part of the open trade logistics market and acts similar to an intelligent switch for coordinating the purchase of goods, transport and finance, by routing consistent information, entered once, between these markets.
  • a user such as a shipper, can electronically navigate to service provider sites and view and respond to service offers from these service providers 30.
  • the shipper can view and use market information, e.g., rates, schedules, news, competitor intelligence, etc., and locate and order goods in an Internet-enabled, service goods market, such as receive order related information from a buyer, who has ordered goods.
  • the shipper can locate, order, and manage and track transport facilities in Internet-enabled transport markets, and locate, order and manage financial instruments in Internet-enabled finance markets or receive information relevant to the transport process from a buyer who has ordered financial instruments.
  • the shipper can also send and receive information in the form of industry standard electronic documents to participants using traditional supply chain management systems, and store and retrieve a record of transactions used to complete a specific consignment.
  • Service providers 30 also have advantages of the present invention.
  • a service provider is able to: (1) navigate all Internet-enabled sites that connect to the trade portal; (2) advertise new services and rates to shippers; (3) publish market information; (4) receive and respond to orders for finance, insurance and transport; (5) publish available inventory or financial services; and (6) publish status information in regard to the physical carriage of the consignment and the documentary milestones, e.g., letter of credit accepted, declared, insure secured, and other associated documents. They also have access to a greater market than possible than if the service providers developed their own closed systems. The service providers can have a better return on assets deployed, and direct access to shippers. They also have lower marketing overheads and lower implementation overheads .
  • the trade portal coordinates related activities in the financial and transport electronic markets, allowing accuracy and efficiency through sharing common information, without re-entry between the three electronic markets of goods, finance and transport.
  • a single point can be used to track the progress of a consignment through all phases of the supply chain.
  • Use of the trade portal and its real-time communication, and use of the template can drive transactions through the cooperating systems of the underlying service providers and generate more revenue from these systems.
  • the trade portal can generate revenue, which could include: (1) advertising commissions; (2) membership fees; (3) usage fees for various services related to the trade network; and (4) information feed commissions.
  • Service providers also establish intimate relationships with their customers when using the open trade system and trade portal. This openness can be reinforced by branding, product packaging rules and implemented business processes.
  • Service providers 30 also may elect to perform any role in the trade process they choose and may act on behalf, of others. For example, a trade bank may perform the role of shipping clerk in regard to documentation on behalf of a shipper. Service providers 30 can also elect to have their own customers enjoy the benefits of the trade portal through connection to their specific service provider's portal.
  • a service provider 30 could offer financial services and could have buyers and sellers, for example, shippers and cargo carriers, directly connected to its own Internet-enabled portal, but use goods, catalogues and transport services from other electronic markets. Any participant may join in any market, i.e., goods, finance and transport, and will automatically be given access to the other two markets in a coordinated manner.
  • FIG. 7 illustrates a high level schematic, block diagram of the trade portal in one aspect of the present invention.
  • An operational web site for the trade portal would have a hierarchy of trade portal web pages, such as Zulunet web pages.
  • An example of these web pages could include a splash page 150, such as shown in FIG. 9, a corporate web site page and, an individualized user home page 152 that is the interface for an individualized home office application via the trade portal.
  • Other web pages and applications that can be selected include the trade forum 36, trade alerts 154, trade news 156, and trade link 50.
  • Other web pages that are not shown in block diagram could include a charters entry screen page for chartering aircraft flights, a reservations entry screen for reserving cargo space on an aircraft, a third party entry screen, a network shopping home page, a catalog entry screen, a trade and finance home page to access data about trade and finance, a finance company entry screen, a network services home page, and/or services company entry screen.
  • a charters entry screen page for chartering aircraft flights a reservations entry screen for reserving cargo space on an aircraft
  • a third party entry screen a network shopping home page, a catalog entry screen, a trade and finance home page to access data about trade and finance, a finance company entry screen, a network services home page, and/or services company entry screen.
  • Each specified page is accessible from the page one higher in the hierarchy, as known to those skilled in the art.
  • a home page 152 could provide access to the trade forum 36, trade alerts 154, trade news 156, and trade link applications 50.
  • a trade reservations page could enter an initial trade network service that is wholly owned and operated by the trade portal operator.
  • Other screens could be developed and hosted by third parties. It is an objective that such sites that develop the other screens and services should carry a certification mark to show users coming in through a third party site that they are within ' the trade portal community and provide them with access to other community sites.
  • the home page application 152 for individual users provides an interface to all other services, as described in the following sections. The user can tailor the home page software to display elements of information to his/her specific needs [i.e., "personalization"].
  • An electronic market access component 160 forms a network link and allows users to access products and services provided by service providers.
  • This electronic market access component is presented to network users as four sub-portals: (1) a trade shop application 162 provides access to a variety of electronic catalogue services; (2) a trade port application 164 gives access to a variety of transport services; (3) a trade bank application 166 provides access to a variety of financial and insurance services; and (4) a trade services application 168 gives access to a variety of ancillary service providers.
  • the trade forum 26 provides the on-line, real-time, networked trading forum.
  • the moderator is essentially the person representing the buyer of a product or service, at any point in time, and can control the rules of the on-line trade forum through the underlying application.
  • the person performing the role of the moderator may change during the course of a real-world transaction, i.e., sourcing to fulfillment, but for the majority of the time would be the person representing the shipper.
  • An individual on-line trade forum is unique to a single real-world transaction.
  • the rules of any individual on-line trade forum are set by the application the moderator chooses to initiate within the on-line trade forum.
  • the application with the template controls what the participant (s) may view and/or update.
  • a trade forum 36 contains four main functional areas: (1) the application space that contains the complete structured information set and rules for the trade; (2) a chat system that allows users to establish multiple independent on-line meetings enabling participants to communicate in an unstructured manner, e.g., free text, about the application area being negotiated; (3) a directory system that allows users, including service providers, to register themselves as participants and allows other users to locate them by user defined criteria; and (4) an interface to the trade file application 52 to facilitate the storage of legal records in the repository and the transmission of EDI documents.
  • the application space is divided into logical areas, e.g., parties, schedules, and similar related trade areas. Moving the mouse over different buttons on an interface will present the user with different interfaces, which are used to enter relevant data.
  • logical areas e.g., parties, schedules, and similar related trade areas. Moving the mouse over different buttons on an interface will present the user with different interfaces, which are used to enter relevant data.
  • any part of the full trading process can be input at any time as a user and service provider negotiates and build up agreements about the various elements of the trade, which are then reflected in the template.
  • a third party is connected to the trade portal via an EDI link or any other type of link, i.e., VAN or Internet, and requires a standard document set, then a user can request the production of such a document from the trade forum application 36.
  • the trade forum application 36 will validate that the required information is submitted before executing a request.
  • a document exchange service referred to as the trade file application 50, supports four primary functions: (1) registration, storage and maintenance of contractual arrangements and their associated on-line dialogues between participants, i.e., "the legal repository" 40; (2) translation of information from the legal repository 40 into standards based electronic documents, e.g., EDIFACT, ANSI, XML, etc.; (3) sending and receiving standards based electronic documents over communications facilities, e.g., Internet, EDI networks, etc.; and (4) translation of information from electronic documents that are received over the communications facilities, and submission of this information to the legal repository, and propagation of the information to the relevant forum.
  • the legal repository 40 supports four primary functions: (1) registration, storage and maintenance of contractual arrangements and their associated on-line dialogues between participants, i.e., "the legal repository" 40; (2) translation of information from the legal repository 40 into standards based electronic documents, e.g., EDIFACT, ANSI, XML, etc.; (3) sending and receiving standards based electronic documents over communications facilities, e
  • the contents of the legal repository that is part of the document exchange server are updated under the following circumstances.
  • the application template is stored when a trade forum is initiated for trade.
  • the updated state of an application template and the trade forum log is stored when: (a) a forum is terminated; (b) a participant leaves a forum permanently; (c) a participant joins a forum initially; (d) a contractual commitment is made; and (e) an event is recorded in the forum indicating the completion of a legal commitment, e.g., goods received.
  • a standards based electronic document is sent to or received from the translator.
  • the applications template can also be updated when a session is terminated to be reconvened at a future time and date.
  • a market intelligence component referred to before as trade news 156 (FIG. 7), consists of a number of third party information feeds that are related to the activities of the three main markets, i.e., goods, transport and finance. Users can select subsets of these information feeds to create their own individual service which is
  • the trade link application 50 is an interface to trade-enabled markets for goods, transport and finance. Once a user has located a product or service, he/she can submit the information via the trade link application to the trade forum and enter a negotiation phase.
  • the trade file application 52 is the interface to the document exchange system, and displays the contents of the legal repository in a manner analogous to a filing cabinet. It allows a user to view contract commitments in timed sequence along with any associated forum logs. Users can drill down to an individual contract or log to view the entire contents.
  • the system administrator for the trade portal who could be located at an operations control center, on the other hand, can manage translator and network components of the document exchange.
  • the trade news 156 can provide an interface to the news feeds and market information.
  • a user can dynamically select information content that is then "pushed" into the interface as it is updated.
  • the user can click on any item to drill down to view an increasing level of detail.
  • the information will typically be derived from public electronic news vendors, e.g., Reuters, or from network enabled service providers, e.g., FX rates from a bank.
  • the user interface is a web-based interface used to locate and buy products and services, carry out on-line real-time contract negotiations, closure and fulfillment tracking.
  • FIG. 8 illustrates the flow of information between the various components as has been described above.
  • Various boxes in the diagram correspond to different functions and applications as described before, which opened through user interaction.
  • the Site Navigation Dialogue application provides user with hypertext links through which they can navigate to underlying third party services and locate relevant products and services.
  • Selection Dialogue application 172 (1) returns details of any product selected by the user to trigger a quotation process; or (2) returns details of products ordered within a third party site to trigger a fulfillment process; and (3) returns details of contracts formed by users so that the relevant inventory can be updated on a third party site.
  • the Contract Execution Dialogue application 174 allows a user to interact with the legal repository and (1) commit, store and track contracts in real-time; (2) receive information about events in the fulfillment process; and (3) send control messages to cause the legal repository to export legal documents to the EDI translator and network system.
  • the Event Dialogue application 176 allows the trade forum application to present raw information to the trade alerts application 154.
  • the Logistics Events and News Dialogue application 178 allows a personalization manager application 180 to present events and news information through a single interface to a user where the user has determined the categories of information and their presentation dynamically. All applications accessible within the trade portal 20 have a single consistent view of companies and individuals for the purpose of authenticating access to the individual components and for the purpose of identifying these parties uniquely as counter parties in on-line trading.
  • the on-line trade forum 36 interfaces with the legal repository 40 by means of a real-time message protocol that isolates the trade forum 36 from the complexities of the legal repository.
  • the storage manager and server 38 analyses messages and either stores or retrieves data from the legal repository within the context of the messages sent by the trade forum application 36.
  • FIG. 9 An example of an initial entry to the user interface application is via a menu on the splash web page as illustrated in FIG. 9.
  • this is an example only of a web page that could be used, but is not limiting for the present invention, as any number of web page examples are possible as known to those skilled in the art.
  • the term "Zulu" has been applied to the trade portal.
  • FIG. 9 illustrates that the pull-down menu could include selections for Transport, Finance, Goods, Services, and general information about the trade portal, Zulunet Incorporated.
  • a trade link application could have the following functions: (1) to provide an outward hyperlink from the user interface to each of the home pages for the underlying web sites to enable users to search for goods and services; and (2) to provide an inward interface to transfer order details from a site to the trade forum as a means to initiate an on-line negotiation process.
  • FIGS. 10, 11 and 12 illustrate another aspect of the invention where a cargo carrier, i.e., seller, negotiates through request for quotes and contract offers with a shipper, i.e., buyer.
  • the system is operative through a publicly accessible communications network, e.g., Internet, and described relative to the document exchange system, inventory database, flight tracking system and other servers and databases.
  • a publicly accessible communications network e.g., Internet
  • both the cargo carrier 212 and the shipper 214 can manage the process from ordering to completion through access via a publicly accessible communications network 216, e.g., the Internet, to an operations control center 218 having a management server 220 that allows document exchange via a document exchange server 222, inventory control via an inventory database 224, and flight tracking via a flight tracking system server 226.
  • a publicly accessible communications network 216 e.g., the Internet
  • an operations control center 218 having a management server 220 that allows document exchange via a document exchange server 222, inventory control via an inventory database 224, and flight tracking via a flight tracking system server 226.
  • These components and servers could be included as software programs in one computer as noted in the dashed lines at 228. It is also possible that the management server and other servers could be separate computer systems, such as separate, but networked personal computers.
  • the operations control center 218 can include appropriate staff to assist a cargo carrier 212 or shipper 214 towards a charter contract.
  • the entire system 210 is preferably a web-based system accessible via the Internet and
  • a shipper has the benefit of an open, trusted market in which price is based on actual supply and demand.
  • Charter costs can be reduced by switching to a single charter price system that removes opportunities for hidden, additional costs for dead legs and unflown billable miles.
  • a "leg” is a specific path between two points, such as San Francisco and Orlando.
  • a "route” is typically one or more legs, such as San Francisco to Orlando or Orlando to San Francisco or San Francisco to Orlando to Miami.
  • the “tail number” is a unique identifier for a specific aircraft, as known to those skilled in the art.
  • the term “flight” refers to a specific execution of a route by specific tail number, such as flight UA432 at 1700 on January 11, 2000.
  • the charter contract can include an ad-hoc charter, which is a contract between a shipper and cargo carrier for the one-time charter of a specific tail number for a specific leg.
  • the charter contract can include a scheduled charter, which is a contract between a shipper and cargo carrier for an aircraft to fly the same route more than one time, to fly from San Francisco to Orlando to Miami and back to San Francisco, every Thursday for the next three months .
  • Cargo carriers can bid for charter flights on the basis of a requested leg at a price the market will bear at the time of transaction.
  • cargo carriers can openly sell all legs of a flight plan without conflicting with the initial leg, allowing better revenues through an extended market for standing assets.
  • the system and method allows reduced administration costs through an efficient and timely ordering and management process and shorter aircraft turnaround times because of earlier loading information and greater certainty through an electronic audit trail.
  • FIG. 10 also illustrates that the shipper and cargo carrier can operate through graphical user interfaces (GUI) 230, 232 displayed at respective terminals indicated by the dotted lines at 234 and 236.
  • GUI graphical user interfaces
  • the GUI's 230, 232 allow for document exchange, aircraft charter inventory location and flight tracking for the shipper, and inventory maintenance, document exchange and flight tracking for the cargo carrier.
  • Various chartering scenarios can exist. For example, an ad-hoc aircraft with a specific tail number could be idle unless contracted for charter. The location of the aircraft is dependent on the last charter flight. If the aircraft is idle at an airport, it can be charted for any route within the aircraft's capability. The aircraft could be relocated to another airport to meet a charter request, provided the aircraft can meet the timing and load requirements.
  • an aircraft may not be the same tail number and could fly a route on a regular basis, but have idle periods within its schedule that could be made available for chartering.
  • a route could be operated by a carrier, such as from City A to City B to City C and back to City B and then City A, every Monday through Friday, leaving City A at 0900 and returning to City A at 1700.
  • a carrier such as from City A to City B to City C and back to City B and then City A, every Monday through Friday, leaving City A at 0900 and returning to City A at 1700.
  • the aircraft could be available for charter under the same rules as any ad-hoc charter, with the exception that the aircraft must be back at City A before 0900 on Monday.
  • Performing aircraft can also operate on scheduled routes .
  • An operator of scheduled routes can use an aircraft from another carrier and control that aircraft. For example, the operator could request a charter for regularly scheduled routes, e.g., from City A to City B to City C and back to City B and City A, every day Monday through Friday,
  • aircraft can be in two availability categories: (1) aircraft specifically owned for purposes of chartering, and which are available for charter when the aircraft is not an active charter; and (2) aircraft flying regular scheduled routes for specific business purposes, e.g., air courier operations, which have significant idle periods between scheduled routes, and are therefore available for chartering.
  • Aircraft could be available for charter when a shipper desires an ad-hoc scheduled charter. For a shipper, it is not relevant whether an aircraft is one used for ad-hoc charters or operated on regularly scheduled routes. It is only relevant if it has an availability window that matches the charter request parameters.
  • a shipper could be a carrier that operates scheduled routes but uses charter aircraft to operate the flights, for example, a company owned or controlled aircraft.
  • FIG. 11 shows that the management server 220 uses logical matching rules 240 to match a shipper and a cargo carrier.
  • the matching rules are based upon supply inquiries, also known herein as shipper inquiries, and carrier demand inquiries, which are stored in the inventory database 224 as associated with management server 220 at the operations control center 218.
  • the matching rules 240 are based on commercial standards. To match aircraft availability to a charter opportunity, the aircraft type must be able to accommodate the weight and size of a proposed cargo load and be able to fly a specified distance from the point of origin. It must be present or relocate to the point of origin in sufficient time to collect a cargo load and complete the route from the origin to a shipper destination.
  • a seller of ad-hoc availability for an aircraft can operate scheduled routes and allow for the relocation of an aircraft to its start point for regular scheduled operations.
  • the seller must specify a start point in order for the management server to calculate its true availability.
  • the current location of an aircraft should be specified for ad-hoc charters to allow the management server to calculate what aircraft are capable of being at the origin on time. It could be possible to ignore the current location of an aircraft, but this would lead to bogus offers where a seller could never make the aircraft available in time to meet the criteria of a requested charter. It is possible that a cargo carrier has elected to do so only for marketing purposes.
  • the management server will strike a balance between having offers of high integrity and imposing numerous constraints that would make sellers reluctant to place inventory on the system.
  • the current location of an aircraft does not have to be specified for scheduled charters.
  • a cargo carrier can relocate its aircraft from anywhere in the world to gain a long-term scheduled contract. For example, if a charter opportunity for multiple flights over an extended period arises, the current location of an aircraft could be irrelevant because the cargo carrier 12 could elect to relocate an aircraft and crew over a substantial distance to acquire a long-term charter contract.
  • the cost could be an issue for the first flight, but in practice, any negotiation between the shipper and cargo carrier would be extended, and a decision to re-charter for a long-term contract could be taken in advance.
  • a potential shipper 214 specifies origin and destination and the management server 220 calculates the distance and matches the route to aircraft capability.
  • a potential cargo carrier 212 specifies the aircraft type, but it does not have to specify a destination, because the aircraft is available for any destination within its capabilities. Because the system is open, shippers 214 and cargo carriers 212 can view all availability, and all active searches through individual shippers and cargo carriers. They modify their own information. The system allows cargo carriers 212 and shippers 214 to view all supply and demand, creating a more dynamic market. Pricing responses reflect supply and demand. Because it is impossible to prevent some individuals from entering bogus requests and/or availability, any staff located at the operations control center 218 can review all records and delete those that are appropriate via a GUI 242.
  • shipment inquiry is an entry in the inventory database 224, and specifies a shipper's criteria for interest in active availability records or related information.
  • An "availability record” is an entry into the management server 220 and inventory database 224 that specifies a cargo carrier's available aircraft.
  • a “carrier demand inquiry” is an entry in the inventory database 224 and management server 220 that specifies a cargo carrier's interest in active shipper inquiries.
  • active refers to a record that is flagged by a user for use by the system and any searching, viewing or matching processes.
  • Inactive refers to a record that is stored by a user for later use and not to be used in current searching or matching process. The user could still view and modify that record, however.
  • the graphical user interfaces 230, 232 allow the shipper 214 and cargo carrier 212 to interact with the management server 220 located at the operations control center 218.
  • the graphical user interfaces provide the ability to create, store, view, modify and make "active” or “inactive” and allows a user to delete availability records based on location, aircraft type and time.
  • Shipper inquiries can be created, stored, viewed and modified and made "active” or “inactive” based on location, freight characteristics and time. Active availability records could be viewed that match a shipper inquiry at the time it is made active.
  • the graphical user interfaces 230, 232 allow notification to be received of new, active availability records, which match existing active shipper inquiries.
  • Carrier demand inquiries can be created, stored, viewed, modified and made “active” or “inactive” based on location, freight characteristics and time.
  • "Active" shipper inquiries can be viewed that match a carrier demand inquiry at the time it is made “active”.
  • New "active" shipper inquiries can be received to allow notification that match existing "active” carrier demand inquiries.
  • the graphical user interfaces 230, 232 also allow for the negotiation and managing of a charter contract through the document exchange server and allows tracking on a geographic display, such as provided by a third party.
  • One advantageous aspect of the present invention is the use of the system as if no distinction exists between a cargo carrier and a shipper. Any user could act as either cargo carrier 212 or shipper 214 as happens in the real world. All cargo carriers 212 and shippers 214 could view current demand as shown by active shipper inquiries and determine a price negotiation position.
  • the "active" status for any shipper inquiry or demand inquiry can be set "once” or "for a defined period”. If an "active" status is set "once,” then the submission of a record is viewed by the management server 220 as a one-time query and only shows active availability records or supply/demand inquiries as appropriate to the original inquiry stored in the inventory database.
  • the "active" status for an availability record can be "active" or "inactive” because the availability record is defined by user input relative to the availability of an aircraft.
  • An originator can delete all inquiries and records, and the system could have to purge all records and inquiries that become “inactive” because an end date is earlier than a current date.
  • Any staff located at the operations control center 218 would have access to the same user interfaces as the cargo carrier and shipper via the graphical user interface 242. This allows the staff to act on behalf of either party by fully or partially managing a charter process.
  • the staff would also have administration screens as part of their GUI 242 to facilitate the addition and maintenance of user records, which control access to the overall management server and other components of the system.
  • the management server 220 of the present invention works in association with the inventory database 224 to allow shippers 214 and cargo carriers 212 to communicate information between them in real time about aircraft supply and demand.
  • the inventory database 224 stores shipper and carrier demand inquiries and availability records.
  • the management server 220 provides the matching capabilities through the use of a set of business rules for validating the input of all shipper and carrier demand inquiries and availability records.
  • the management server matches active inquiries and records at the time of input, and on a periodic basis defined by a system administrator at the operations control center 218. A publisher can automatically inform users of new inquiries and availability records that match current active inquiries.
  • the system administrator can also set up an entitlement system at the operations control center 218 to control a users ' s access rights.
  • the management server 220 obtains information from the inventory database 224 of availability records that are directly input by cargo carriers via an Internet browser through the terminal of the cargo carrier. It is also possible to obtain information from an interconnected information system of a cargo carrier or from an interconnected system of a third party, e.g., OAG, that could provide information on behalf of the cargo carrier.
  • the shippers can provide shipper inquiries from an internal database or directly from the interconnected information system of a shipper.
  • the document exchange server 222 allows for the filing of electronic documents, such as quotations, orders, shipping instructions, contracts, advice and other legal documents.
  • electronic documents such as quotations, orders, shipping instructions, contracts, advice and other legal documents.
  • the document exchange server 222 provides both parties with a set of electronic documents to conclude orders and manage a charter process to completion.
  • the documents are "filed" in a database memory of the document exchange server 222, such that authorized parties can track the progress of the process. All documents have a corresponding acknowledgment document or response for the formal confirmation of receipt and acceptance of information.
  • FIG. 12 illustrates an example of a basic flow in a contract negotiations.
  • the basic flow could include a request for quote 260 from a buyer or a shipper followed by a contract offer 262 from the seller, or cargo carrier or other service provider. This offer would include various terms that would be displayed on window.
  • a discussion of terms 264 follows with a contract confirmation 266.
  • Ancillary services 268, such as truck loading, palletization and other details are discussed, followed by a load list 270 and proof of delivery 272.
  • Typical documents stored and processed by the centralized document exchange server 222 include a request for quote, a quote, an order, an order confirmation, i.e., a charter contract, a load list, delivery confirmation, and a discussion of terms and timing.
  • the quotation/order process applies to the charter contract, but could also be used for handling ramp services, consolidation and trucking processes.
  • the flight tracking system server 226 allows both the shipper 214 and cargo carrier 212 to track in flight aircraft based on tail number. Tracking can be done via a graphical user interface or similar computer display means. It is possible to use a third party service, as known to those skilled in the art, to track the aircraft.
  • the operations control center 218 will typically be staffed 24 hours a day, 7 days a week.
  • the same graphical user interface 242 and Internet tools used by the staff are the same as the GUI 230, 232 and Internet tools used by shippers and cargo carriers.
  • the staff at the center 218 can provide services ranging from facilitating a charter to ad-hoc requests for information or assistance.
  • the center 218 could have a repository (database) 270 of relevant industry related news, which can be accessed by the shipper and cargo carrier through their graphical user interfaces 230, 232 via the communications network 216.
  • FIG. 12 illustrates the information flow that exists among the shipper 214, operations control center 218 and management server 220, and inventory database 224, where matching rules 240 are processed with cargo carrier and shipper inputs to match a shipper and cargo carrier based on availability.
  • the document exchange server 222 with the management server 220 obtains the quotations from one or more cargo carriers to manage information exchange during the chartering process.
  • Cargo carriers 212 can advertise availability and shippers 214 to match the advertised availability with their shipping requirements. Because the entire system and method is open to both shippers and cargo carriers, the management server 220 and inventory database 224 can store all availability records and inquiries to allow matching by the management server at the instant of creation, or over time. Users can create new records and inquiries by making minor modifications to old records and inquiries rather than re-entering the information from scratch.
  • the system can operate in an asynchronous mode because there does not have to be a relationship in time or sequence between the users for the management server, the inventory database, and the document exchange server.
  • a shipper 214 could possibly make an inquiry the second before or after the cargo carrier 214 enters an availability request that meets any requested criteria. In the former case, the inquiry would produce a match, but in the latter case, the inquiry would not produce a match.
  • the asynchronous mode allows shipper and carrier demand inquiries to be stored, and retain a specified "active" validity period to ensure a likelihood that supply and demand will be matched. Because any user may not be on-line at the time of a status change that causes a "match" with the specified criteria, the management server 220 incorporates a "publisher" function 272 that pushes the changed status to a user, via a user specified mechanism, such as a browser, pager, or e-mail. It is possible to generate high volumes of pushed data, thus, all "active" inquiries could be pushed by the system to minimize data traffic.
  • the cargo carrier 212 specifies availability by creating an "active" availability record, specifying the aircraft type, the origin (s) at which it can be made available, and over what time period.
  • the shipper 214 can specify the shipper or supply requirements by creating an active supply, i.e., shipper inquiry, either by entering a new inquiry or by modifying a currently stored inquiry.
  • the cargo carrier can set the inquiry "active" for a period in which the shipper is interested in receiving any bids.
  • the shipper inquiry also specifies the start and end date for the charter, which may be different from the "active" period. For example, a shipper may wish to receive offers for the next 24 hours for a charter flight that is requested to leave in three days.
  • Each leg of a route could be created as an "inactive" shipper inquiry.
  • the shipper can then convert the required inquiries to "active" shipper inquiries.
  • a user would view matching availability records on the respective graphical user interface. If an inquiry has been made active with a defined time period, the user can automatically receive an update whenever a newly entered availability record meets the criteria originally specified in the supply inquiry.
  • the management server 220 automatically sets any active record to inactive if the active period and date or the requested charter goods delivery date is later than the current date.
  • Any user can monitor the total requests submitted by prospective shippers by submitting an active carrier demand inquiry with an appropriate selection criteria.
  • the carrier demand inquiry is made active, the user will view any matching "active" shipper inquiries. If the inquiry has been made “active” with a defined time period, the user can automatically receive an update whenever a newly entered "active" shipper request meets the criteria originally specified in the carrier demand inquiry.
  • Any user can monitor the total requests submitted by possible cargo carriers by submitting an "active" shipper inquiry with appropriate selection criteria.
  • the carrier demand inquiry is made
  • the user will view any matching availability records. If the inquiry has been made “active” with a defined time period, the user can automatically receive an update whenever a newly entered availability record meets the criteria specified in the shipper inquiry.
  • a shipper cannot view how many cargo carriers may be observing the state of "active" shipper inquiries without submitting an availability record.
  • a possible cargo carrier can watch the market before deciding to make the cargo carrier's aircraft available. Once decided, this cargo carrier can then make a bid by creating an "active" availability record, matching the requested supply criteria, and this will then immediately become known to the possible shipper.
  • the management server 220 works in conjunction with the inventory database 224 to allow a digital exchange between the shipper and cargo carrier for brokering aircraft charters.
  • Three types of exchange dynamic records can be stored, such as: (1) "I want" indicating a shipper's need; (2) “I have -- indicating the availability of an aircraft from a cargo carrier; and (3) "Tell me who is looking for", which tells the initiator how many other shippers have the same requirement.
  • the response to "Tell me who is looking" is a list of all active "I want".
  • These logical inputs can be used by either the shipper or cargo carrier to provide intelligence on the state of the market and what price the market will bear.
  • a shipper or cargo carrier can use a "I want" to observe what other cargo carriers are offering in specific market segments. Because the various records are stored, a regularly repeating matching program can be run to match records in all three categories on a continuing basis.
  • a business emergency occurs, such as a production line closing if parts are not supplied within half a day.
  • the manufacturer perceives that a charter is the only option.
  • the shipper logs onto the network and enters a website to access the management server 220 having in association with it the inventory database 224, document exchange server 222 and flight tracking system server 226.
  • the shipper 214 selects a source, destination and timing of the charter on a map based graphical user interface.
  • the shipper can additionally set a period where it will consider offers from cargo carriers. Any relevant charter availability that is pre-registered with the management server 220 and inventory database 224 is immediately displayed to the shipper at its terminal.
  • a shipper If a shipper has indicated a willingness to consider further offers from cargo carriers over a defined period, then the request is published to all the cargo carriers that are registered with the management server with a declared interest in the type of aircraft required for origin and destination points. Any such offers will be automatically displayed on the shipper screen during the specified period. From the total list of available charters, the shipper selects those of interest and uses the document exchange server to issue an electronic request for quotation (RFQ) . The cargo carriers respond to the RFQ on-line by selecting appropriate terms from those shown on the form and add any additional terms and free text and specify the price for the transaction.
  • RFQ electronic request for quotation
  • the shipper then reviews the responses and issues an order by clicking an "accept" or other button, i.e., response.
  • the shipper can then advertise all other legs on the service through the communications network via new contractual terms.
  • the shipper 214 and cargo carrier 212 can then carry on an electronic exchange through the remainder of the charter period to clarify details of the physical activity taking place, and if necessary, record amendments to the original terms.
  • the pallet details Prior to any goods being delivered to the airport, the pallet details are provided to the ramp agent via a document provided by the document exchange server 222. This allows the ramp agent to preplan the load process and guarantee speedy aircraft turnaround time.
  • the physical trucking, palletization and loading/unloading processes occur as normal, but parties are coordinated through the document exchange server.
  • FIG. 13 illustrates an open window such as viewed by a buyer or shipper that requires cargo space to be preserved on an aircraft.
  • This type of graphical user interface is advantageous because the entire aircraft may not be charted, but only certain cargo spaces that are defined on the aircraft. For purposes of discussion, reference numerals describing this window being in the 300 series.
  • FIG. 13 illustrates an open window 330a of a graphical user interface 330, such as used on a windows based computer platform at the shipper terminal 334.
  • the GUI 330 shows a graphical depiction of an aircraft cargo hold 330b with predetermined cargo spaces labeled with an alphanumeric code, such as A1-E6.
  • the graphical user interface for the cargo hold 330b could be color coded for each cargo space A1-E6 or other identifying scheme or indicia that would distinguish between reserved and unreserved or available cargo space on the aircraft.
  • the cargo spaces referred by the alphanumeric code B4, B5, B6 and C1-C5 have X's indicating that those cargo spaces are reserved and no longer available for reserving by a shipper.
  • any type of indicia could be used, as suggested to by those skilled in the art.
  • the shipper, cargo carrier and administrator at the operation control center would all have access to the same graphical depiction of the cargo hold.
  • the shipper may initially have a list of different aircraft that meet the shipper's needs.
  • the graphical depiction of FIG. 2 could come on screen, giving the shipper the advantage of determining what cargo space is available and entering appropriate data relating to the cargo space reservation.
  • a separate cargo hold configuration window 330c for data entry could open with specific shipping, price, destination and terms tabs 331a-d, corresponding to various shipping parameters that can be user selected.
  • the shipping tab 331a has been depressed showing cargo space that is to be reserved.
  • a drop down list 331e allows the shipper to select a required volume.
  • the type of containers that are desired can be selected through a drop down menu 331f.
  • the shipping weight that the shipper would probably require can be selected via a drop down menu 331g.
  • FIGS. 14-26A there are shown various graphical user interface screens and open windows as displayed on a computer screen for both buyers and sellers. These open windows and screens represent examples of what kind of information and graphics can be displayed and what data entry boxes could be displayed for entering data and navigating into and through various search pages and search result pages.
  • FIGS. 14-26A represent different open windows and graphical user interface screens, they are only one example in any number of different types of windows, data entry boxes, graphical user interface screens and other screens that can be displayed as known to those skilled in the art.
  • FIG. 14 represents an open window of a home reservations page 400 known as a My Cargo Reservations Page having an upper set of selection buttons 402 for the Zulu forum 404 that allows entry into a trade forum for on-line and real-time negotiations.
  • the aircraft charter button 406 allows entry into screens and pages for searching and obtaining aircraft charter information and obtaining requests for quotes and sending requests for quotes.
  • FIG. 14 shows this open window of the home reservations page known as the My Cargo Reservations Page, where a user is registered as both a buyer and seller.
  • the page shows a "work-in-progress" screen to cover an entire spread of work.
  • a buyer views information regarding any reservations for an aircraft charter or cargo space that the buyer is buying, while a seller views information regarding the cargo space or aircraft charter that they are selling.
  • the system has configured the "work-in-progress" screen to cover the entire spread of work with buyer and seller.
  • the first column 410 lists pending quote requests that are submitted requests for quotes
  • the second column 412 lists incoming quotes from a seller that are answers to submitted requests for quotes.
  • Any pending contracts that are related to submitted contracts awaiting buyer approval are listed in the third pending contracts column 414 and any active contracts that are completed contracts with goods in transit are listed in the fourth column 416.
  • the cargo carrier or seller, also for any other asset provider
  • Any pending quotes in column two 412 show the quotes that the seller has responded to.
  • Any pending contracts in column three 414 are the booking requests received from a buyer awaiting the seller's approval, and the active contracts in column four 416 correspond to the completed contracts with goods in transit.
  • a My Accounts button 420 allows a buyer or seller to view a personal account
  • the view contract history button 412 allows a contract history to be viewed. Selecting this button could retrieve a file from a database of the legal repository where various quotes, chat records, condition of contracts, contracts and tracking records are kept in a contractual record and kept in a legal repository (FIG. 27) .
  • an open window screen such as shown in FIG. 15 could be displayed that includes another toolbar with buttons for allowing an aircraft search 424, aircraft availability posting 426, what the market is doing, i.e., market research 428, services 430, aircraft configurations 432, "Contact Us” 434 and logout 436.
  • an aircraft availability posting is displayed by a seller to allow entry of data relating to scheduled aircraft availability and the listing of aircraft by sellers that are available for charter. These can be sorted by airport ID and by different types of aircraft. Various columns of data can be entered, such as the aircraft type, location, the date available to and from, the time to and from, the available days, the active, and whether the information should be deleted.
  • a data entry screen (not shown) is retrieved that allows a potential buyer to search for aircraft based on .their selection criteria.
  • This search criteria could be for an "on-demand charter" or "long-term charter.”
  • the charter search results are retrieved and placed in table format 440 as in FIG. 16 where the airport ID is listed, the aircraft type, the rate per hour, the rate per mile, the date/time available and whether a request for quotation should be sent or not.
  • Potential buyers can select one or more of the search results for quotation and press the "Send Request" button 442 to bring up Zulunet and initiate a quotation/contracting process.
  • the screen in FIG. 14 displays a "work-in-progress" screen to cover the entire spread of work.
  • FIG. 17 illustrates a data entry window 444 for entering data into the screen to determine an on-demand charter.
  • Charter search results that are obtained are shown in the search results box 446.
  • a similar type of screen would be used for a long-term charter search.
  • FIGS. 18 and 19 show an example of the type of open window screens that could be displayed when an "on-demand charter" request or "long-term charter” request is made, and showing in an information box 448 what requests were sent to different carriers.
  • FIG. 20 illustrates an open window similar to that shown in FIG. 14, but showing data that are displayed after the seller receives specific "requests for quotations" so that a seller can determine whether a response is appropriate.
  • Information is displayed regarding the origin, destination, ready to ship, delivery, aircraft type, dimensions, weight and special conditions. This data gives the seller the information necessary to determine whether a response to the request for quote is appropriate.
  • the seller presses the "Create Quote” button 452 and retrieves a data entry window (FIG. 21) for creating an "on-demand charter" or "long-term charter” quotation.
  • FIG. 21 shows an open window screen, which is used by a seller to calculate a response to the buyer.
  • the data is for "Create an On-Demand Quotation.”
  • Complex rules and data look-ups can be specific to an individual contract template and its worksheet.
  • the worksheet can be specific to an aircraft charter. This is the worksheet template that can be used as a basis of a negotiation and would be specific to the subject of negotiation, i.e., in this specific example for an aircraft charter.
  • any type of commercial asset could be negotiated and the negotiation or contract template as it is brought up is specific to the commercial asset.
  • Such information as the company name, an individual name, street address, city, state, zip code, country code, telephone number, e-mail address and contract template can be displayed.
  • a standard DHL on-demand contract template could be retrieved, or alternatively, there is illustrated a generic on-demand that is not specific to DHL.
  • the lower portion of the worksheet shows different data that can be entered by the seller such as the airport ID, airport city, distance, aircraft type, cost, taxes, distance, route time, aircraft cost, short legs, wait times, overnight fees, airport fees, load/unload, other fees, tax other fees, cargo reservations fee, discount, excise tax, the imposition time and arrive late time, and a grand total. If a "New Quotation" button 460 is selected, the worksheet contents can be erased while, if the "Submit Quotation” button 462 is selected, the worksheet can be summarized into a contract that is viewed by the buyer on screen.
  • FIG. 22 shows an open window box for the
  • On-De and Charter Quotation Results that are viewed by a buyer.
  • This data represents what sellers have submitted quotes and details the information.
  • This window can be viewed together with any screens showing an agreement of an aircraft charter (FIGS. 24-26). It is possible that different proposed contracts for different sellers could be displayed on-screen and the buyer could navigate among different contracts.
  • FIG. 22 if the buyer selects the negotiate button 470, then the buyer will be taken to a trade forum, also known as Zulu forum, where different users could be connected in real-time as described above.
  • FIG. 23 shows an open window similar to FIG. 14, but displaying the different users that are on-line for negotiation.
  • FIGS. 24-26 show on-screen agreements, such as retrieved from a Constant template database. As information is changed, the buyer would receive the information shown in the agreement of aircraft charter sent from the seller and the information could be studied and the buyer could accept the terms of that contract agreement and book the charter by selecting with a mouse or other means the block labeled the accept the terms of the contract agreement (FIG. 25A) and book the charter. FIG. 26 shows that once the agreement is made, the contract is active and no changes are permitted.
  • the status of the contract as goods are delivered and shipped can be tracked. It is also possible to enter into real-time negotiations to discuss peripheral aspects of the contract and the transit of any goods in past contract formation process. It is evident that the present invention is advantageous and allows not only real-time negotiation, but a single action that can be performed, such as clicking a mouse, by both the seller and buyer to form a contract for an aircraft charter or any other commercial asset.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

A method for purchasing a commercial asset is disclosed. A list of potential sellers can be retrieved and a certain portion of a list selected and a request for quotation transmitted. When a response is appropriate, a worksheet contract template can be retrieved and contract terms forwarded. Through a single user action of the buyer, the contract terms can be accepted as offered by the seller, negotiations can be entered into with the seller for different terms, or the contract proposal and any negotiation terms can be saved in a legal repository.

Description

SYSTEM AND METHOD FOR PURCHASING A
COMMERCIAL ASSET VIA ELECTRONIC COMMERCE
USING SINGLE USER ACTION OF BUYER AND SELLER
Field of the Invention
This invention relates to the field of electronic commerce, and more particularly, this invention relates to purchasing a commercial asset using electronic commerce.
Background of the Invention
In co-pending patent application serial no. 09/537,852, a method and system of effecting a commercial transaction among a plurality of parties in a networked computer environment is disclosed. The invention addresses the problem of the Internet in everyday business and allowed a real-time and on-line, networked trade forum to be established with real-time communication channels between the user and each service provider that enters the trade forum. This invention solved the problem of providing an open, real-time trade or web portal to provide a choice of logistics and finance options for buyers and sellers, such as shippers and cargo carriers, insurance companies, finance companies and associated service providers who use the Internet. For example, the use of the Internet in everyday business lead to a much greater market transparency between buyers of goods and services and owners of products and saleable assets, i.e., finished goods, financial instruments, including insurance, and transportation facilities. Asset owners have been able to gain more power and use it directly in their relationships with their ultimate buyers.
More businesses are gravitating to the Internet for directly connecting buyers and sellers of goods through many rapidly emerging electronic markets. This is especially relevant in the cargo charter industry, where shippers (buyers) and cargo carriers (sellers) can be brought together to facilitate charter services. Other business-to-business markets can only use a few catalogue products, which provide a standard means to interchange information. Thus, a limited amount of work will provide access to a large number of markets . Business-to-business users of these catalogues are currently given access to a limited number of closed logistics and trade systems, e.g., FEDEX, UPS, USPS, and similar services. These users are also only given access to limited financial services, e.g., credit card, direct account transfer and fixed contract purchasing, none of which suit many of the demands of the business-to-business trade. Some supply chain integration is locked in the old world of paper documents and replicated in silicon, either through electronic data interexchange (EDI) , or on the Internet. This process is not a real-time process and is complicated to use when multiple parties are involved.
For example, most on-line shopping sites are built on databases. A potential customer visits a web site and browses for a product by searching with a web browser as part of client software forming a user interface and through a database connected to the host processor acting as a web server. Payment is made by credit card after finding the product and entering a secure area of the web site. When the customer presses a submit or other button, the information is sent from the customer (user) or client's computer to a secure transaction server over the Internet in an encrypted fashion. The transaction server receives the encrypted information, decrypts it, and then verifies the account with the credit card company to ensure that the card is valid. The transaction server confirms the order back to the customer, also refreshing the web page, which can be printed by the customer. The transaction server also sends an order to a warehouse, which ships the product to the customer.
If an on-line shopping cart is used, then a "cookie" is positioned as a small piece of data on a customer's hard disk, which is used to identify that client or user station. Whenever the database is searched and the customer clicks on the item, then a new piece of data can be written to the cookie to identify the item. The cookie can be used to tell a web server what items to display on the page. When the items are actually bought, the items can be deleted from the cookie.
In an on-line auction, a seller completes an item form, indicating what item is to be auctioned, and then transmits the data to an auction site's database to create a record for the seller. A web page is created when a potential bidder accesses the database. The program or script takes information from the database to create the web page. When a potential bidder views the item via the web page and wants to bid on it, the bidder fills out a form to update the auction record in the database. When the web page describing the auction is updated, the new bid is reflected for all potential bidders . After a predetermined period of time, the auction closes and the database is queried to determine which bidder has the highest bid. The bidder and seller then contact each other privately to negotiate or arrange for shipping. However, even though a real-time, on-line and network trade forum is established, it is necessary to provide a means for quickly forming contracts, entering on-line negotiations or saving data to a legal repository with minimum user effort and interaction.
Summary of the Invention In accordance with the present invention, a method and system for purchasing a commercial asset includes the step of retrieving a listing of at least one potential seller of a commercial asset that a buyer desires to purchase. At least one seller is selected from the listing to obtain a quotation of contract terms for purchasing a commercial asset. A request for quotation of the commercial asset to be purchased is transmitted to a selected seller and this is viewed by a potential seller on a computer screen to determine if a response is appropriate. If the response is appropriate, a worksheet contract template can be retrieved and data entered into the worksheet contract template corresponding to a quotation of contract terms to be offered by the seller to the buyer. This quotation of contract terms is forwarded to the buyer and displayed on a computer screen. Based on the single user action of the buyer, the contract terms can be accepted, negotiations with the seller entered, or the contract and any negotiation terms saved into a legal repository.
In accordance with one aspect of the present invention, the single user action comprises the step of depressing a button. The proposed contract terms can also be modified within the worksheet contract template and the displayed contract template viewed by the buyer and updated as the seller modifies any proposed contract terms. It is also possible to display on a computer screen a window having a listing of a plurality of quotations of contract terms in response to selecting a plurality of different sellers. These contract terms can be forwarded into the worksheet contract template in response to a single user action of a seller. The worksheet contract template is specific to a commercial asset. The user can invite into an on-line, networked trade forum the seller of the commercial asset and establish a real-time communication channel with the seller. The on-line, networked trade forum can be terminated and a time established in which the on-line, trade forum will be reconvened. The commercial asset includes one of manufactured goods, money used for credit, money used for insurance risk mitigation, or physical transport mode to move any manufactured goods. The computer network can include a publicly accessible communications network. A database search can be conducted and the buyer and potential seller matched within the management server to produce search results. In still another aspect of the present invention, the listing of potential sellers can be a plurality of potential sellers and the plurality are selected. Brief Description of the Drawings
Other objects, features and advantages of the present invention will become apparent from the detailed description of the invention which follows, when considered in light of the accompanying drawings in which:
FIG. 1 is a schematic, fragmentary drawing showing the international trade logistics of goods, transport and money or finance, which are integrated via business-to-business commerce with the sourcing, ordering and delivery of these services.
FIG. 2 is a schematic, block diagram showing the trade portal with the management host server and the networked connection between the on-line users and service providers.
FIG. 3 is a high level schematic, block diagram showing the management host server that works in conjunction with the storage manager (server) for the primary legal repository and replica legal repository, XML filters, and EDI translator service. FIG. 4 is another high level, schematic, block diagram showing the interrelationship among the management host server, user and service providers.
FIG. 5 is another schematic drawing showing the management host server and its connection to various users and service providers to integrate the electronic markets of goods, finance and insurance, transport and regulatory, e.g., customs.
FIG. 6 is a flow chart illustrating the functional flow of an example of the basic method of the present invention.
FIG. 7 is a schematic, block diagram showing various client, e.g., user stations that have a user interface for access to the different electronic markets and legal repository. FIG. 8 shows another schematic block diagram of the information ' flow among various servers and applications in one aspect of the present invention.
FIG. 9 shows a graphical user interface (GUI) that is an example of a GUI that could be used in the present invention.
FIG. 10 is a system diagram illustrating the basic function and flow of information among the operations control center and a shipper (buyer) and cargo carrier (seller) .
FIG. 11 is a more detailed diagram of the operations control center and the flow of information between a cargo carrier and shipper.
FIG. 12 is a diagram illustrating an example of the contract formation between a cargo carrier and shipper.
FIG. 13 is a schematic drawing of a graphical user interface showing indicia on an aircraft graphic pertaining to cargo space, and an open data entry window for configuring the cargo space.
FIG. 14 is an open window showing a reservations page for a user that can be registered as either a buyer, seller or both, and showing a "work-in- progress" screen to cover the spread of work and what kinds of quotes are pending and incoming, and what contracts are pending and active.
FIG. 15 is an open window showing a screen having a toolbar selection for aircraft availability posting for listing aircraft and showing other elements of the toolbar.
FIG. 16 is an open window similar to FIG. 15 with the same toolbar, but the aircraft search item selected and displayed charter search results. FIG. 17 is a data entry window used for entering elements of a search for a on-demand charter and displaying on-demand charter search results.
FIG. 18 is an open window that verifies an on-demand charter request for quotation has been sent and the location where it has been sent.
FIG. 19 is similar to FIG. 18, and shows a long-term charter request, and what information has been sent. FIG. 20 is another open window showing a summary for viewing by a seller of a specific request for quotation.
FIG. 21 is an example of the type of data entry boxes are displayed for creating an on-demand quotation and calculating a response to a buyer.
FIG. 22 illustrates an open window viewed by a buyer and showing quotation results.
FIG. 23 is an open window for a trade forum, also known as Zulu Forum, showing what users are actie and can be met for negotiations and discussion.
FIGS. 24-26 show various agreements of aircraft charters that are initially viewed by the seller (FIGS. 24 and 24A) , forwarded to the buyer (FIGS. 25 and 25A) , and after acceptance (FIGS. 26 and 26A) .
FIG. 27 shows the type of information that is stored in the legal repository of the present invention.
Detailed Description of the Preferred Embodiments
The present description proceeds with a methodology and system description of effecting and managing a commercial transaction among a plurality of parties in the networked computer environment (FIGS. 1-9) . Different service providers, such as sellers of cargo flights, each own or control a commercial asset such as a charter flight. These assets are negotiated in an on-line, networked, trade forum. Afterwards, there follows a description of an example using a system of facilitating cargo charter flights and cargo space reservations (FIGS. 10-13), followed by a more detailed explanation of an example of a series of exchanges between a buyer and seller for an aircraft charter, as shown in FIGS. 14-26. For purposes of this description, a shipper is defined as any person that organizes the movement of purchased goods. For example, a shipper could be a person working for an intermediary company that organizes the shipment of goods for others. A shipper could also be a person working for an organization that produces the goods for shipment, a person working for the organization that buys the goods, an individual selling goods, or an individual buying goods. The shipper is also in some instances in the description referred to by the term "buyer."
A service provider, on the other hand, is defined as any person owning or controlling an asset, where an asset is one of: (1) manufactured goods; (2) money used for credit or insurance risk mitigation; or (3) a physical transport mode used to move goods. In contrast to a service provider, a service is the use of assets by a service provider on behalf of a shipper. Throughout this description, the term "user" will refer to a shipper who uses the trade portal and system for locating goods and services, integrating goods, transport, finance and services, and even acting as a moderator for real-time negotiation. In some instances in this description, "service provider" is also referred to as "cargo carrier" for transporting cargo with a shipper having cargo to be shipped to a destination, and also "seller, " such as a seller of aircraft charters or cargo space.
A commercial transaction is effected among a plurality of parties in a networked computer environment using real-time communication channels between a user, such as a shipper, and a number of invited service providers. FIG. 1 illustrates the three major areas of international trade logistics which are the key to the asset market, such as goods 10, transport 12 and money 14, e.g., finance/insurance. These electronic markets are integrated in the supply chain. Goods can be sourced, and ordered with appropriate financing and insurance, and then transported in delivery. An Internet trade portal 20, illustrated generally in the block diagram of FIG. 2, includes aspects of a horizontal portal 20a and vertical portal 20b. The horizontal portal works with a user 22, e.g., shipper or buyer, who is on-line and has a user interface application 24 that interfaces with a host management server 26, which has an associated database, various associated functions and applications, such as a real-time Trade Forum, Trade File, Trade Link, Trade Alerts and Trade News, as will be explained in greater detail below. The Trade Portal also provides a vertical portal 20b for locating goods and services with multi-party and Internet enabled service providers 30 that can network with the trade portal 20. The horizontal portal 20a aspect of the trade portal 20 integrates the process for goods, transport, finance and services, such as quoting, contracting, tracking and paying. The vertical portal 20b aspect allows a user to locate goods and services.
FIG. 3 illustrates a user 22 at a user station 22a that is in communication via the Internet 32 to the web server 34 that is part of the host management server 26, which includes a trade forum application 36 that establishes a trade forum for real-time exchange and negotiating. A storage manager and server 38 is operated and associated with a primary legal repository 40, e.g., database, and a replica legal repository 42, e.g., database, for redundancy in case the repository 40 is inoperative. The repository 40 contains information about service providers 30 and contract or templates used for transacting and negotiating in business, as will be explained below. Extensible Mark-up Language (XML) filters, as known to those skilled in the art, connect to the repositories 40,42, and work in conjunction with Electronic Data Interexchange (EDI) translator service 46, which could receive signals and information from remote sources 46a (FIG. 7) . The Electronic Data Interexchange translator service allows a transfer of information between organizations and machine-readable form in order to carry out business transactions, while also allowing translation services for inherent language differences. As is well known in EDI, the basic flow of information is the same as in conventional business except that electronic messages take the place of paper. FIG. 4 illustrates yet another more detailed view of the trade portal 20, and the management host server 26 that is connected to the user station 22a having a client software for browsing the Internet and enabling software for connecting into the trade portal 20. For purposes of this description, the user station 22a is operated by a shipper who connects via the Internet to the trade portal 20 and management host server 26, and establishes real-time communication channels between the user and each service provider that is entered and on-line in a trade forum. The on-line negotiations could be instituted, for example, afer requests for quotation are sent by a shipper or buyer to a seller or cargo carrier, i.e., service provider, and terms must be negotiated.
The independent communication channels prevent a respective service provider from learning any negotiation terms of respective other service providers that are in communication with the user within the on-line, networked trade forum, and are shown by the dashed line configuration 21. A record of the negotiated terms are maintained within the legal repository 40 as part of a database. As illustrated, the service providers include service providers 30a of goods that have their computers at their stations connected to the management host server 26, service providers 30b for transport services that have their computers of their stations connected to the management host server, and service providers 30c for finance services. The finance service provider is not connected at this time in the example shown. Each of the illustrated service providers for goods has a realtime communication channel with the user, but cannot determine the negotiations of any other respective service provider that is linked into the on-line trade forum. When negotiations have been completed, one service provider 30a for goods that has come close to final negotiations with the user could invite service providers for transport services into the trade forum to discuss transport services and begin negotiations.
Separate communication channels as shown in dotted line 21a configuration are established.
The trade portal 20 includes the management host processor 26 that generates a web site, such as the Zulunet™ web site, as described below with reference to the graphical user interface drawings shown as examples in FIGS. 14-26. The trade portal 20 offers other information services related to international trade domestic tracking, and related information in a similar manner how other' Internet portals provide services directed to a specific group, such as women or college students.
Also, throughout this description, the term "Internet-enabled" or "trade-enabled" refers to an Internet or EDI system used by a third party, who has implemented a network interface specification for connections and communicating with the trade portal, and has accepted the commercial and contractual terms of linking its site into the trade portal and associated servers to allow the real-time trade. A network interface specification is a specification of the communications protocols and message formats used to support the interaction of Internet-enabled systems that connect to the trade portal. A trade link application 50 (FIG. 7) can be provided as a proprietary software code that provides a standardized interface, based on the network interface specification, to facilitate the connection of third party systems into the trade portal, while a trade file application 52, is a personalized, on-line and real-time application that allows a user to locate, order and manage goods, transport and finance in an integrated manner via the services of the trade portal 20. FIG. 5 illustrates the management host server
26 as sending the appropriate HTML files to a user to bring up a main web page 54, which can direct a user to other web pages, such as finance and insurance web pages 56, where further information can be obtained about finance and insurance service providers. Web pages 58,60 relating to transport and goods can also be brought up by the user, giving information about the various service providers of those goods and transport services. It is also possible to bring up web pages about regulatory agencies, e.g., customs information.
FIG. 6 illustrates an example of a basic flow chart of a method that could be used with the present invention. FIG. 6 is only illustrative of various types and the flow of information that can occur in the process. Naturally, FIG. 6 is not limiting, but only represents one example of the method. For purposes of clarity, reference numerals begin with the number 100, and run sequentially.
The user initially starts (block 100) and connects via the Internet to the trade portal (block 102) . HTML codes are forwarded by the management host server, and the client software forming the user interface brings up a main web page for the "Zulunet™" trade portal. While connected to this trade portal, the user can search a database for commercial assets to be negotiated, which could include goods, transport, finance, insurance or other services, as suggested and known to those skilled in the art (block 104).
The user 22 then searches for relevant templates to be presented to service providers (block 106), or obtains a user prepared template. These templates contain legal and commercial forms, having terms that define the business relationship to be negotiated. The template also defines the business rules of the trade forum. The templates can be formed as a spreadsheet type form or other format that would express the various legal and commercial terms. The service providers 30 are then invited to the trade forum (block 108) and a real-time communication channel is established to each service provider (block 110) . The application software can vary as known to those skilled in the art for establishing the communication channels. An example is a software program entitled Net Meeting by Microsoft Corporation. Other examples are known to those skilled in the art. The service providers 30, as noted before, each own or control an asset to be negotiated. Typically, the user 22 will negotiate with various service providers for one asset or a plurality of different assets. Portions of the template or the entire template are then presented before the service provider (block 112) via the service provider software interface that is Internet-enabled and operable with the trade portal. In some instances, it may not be necessary to have a service provider view an entire template, but only portions of the template that are relevant to the particular services are presented before the service provider.
Throughout the real-time communication, the user can act as a moderator during the negotiation of commercial and legal terms that define the template (block 114) . The template is updated, or revised (block 116) , as negotiations continue, and if the negotiations are complete and a contract made (block 118), then the session is terminated (block 120) and the transaction is tracked via the template (block 122) . For example, a user or shipper can bring up the template and determine if a scheduled cargo carrier flight has been delayed or other problems have occurred in the shipment. Naturally, the management host server as part of the trade portal can contact a shipper or user if there is a problem, such as through e-mail, paging, cellular service, by phone operator, or other means known to those skilled in the art. The process then ends if there have been no problems (block 124) . If negotiations are not complete (block 118), it is possible that the moderator (e.g., shipper) or other party desires to cancel the session and reconvene at a later time. Thus, a time is established to reconvene (block 126) and the session terminated (block 128). The session is reconvened at the appointed time and date, and the template is brought up before the service providers and user (block 130) with the template defining the record of the negotiations that have previously occurred. Negotiation occurs again (block 132), and if a contract or other agreement consummated (block 134), the session is terminated (block 136) and the transaction is tracked via the template (block 138) as before, and then ended when completed (block 140) . If negotiations are not complete, then the steps of blocks 126 through 134 are repeated.
FIGS. 7 and 8 disclose in block, schematic format applications that are available through the trade portal via the main Zulunet web page or other means operative with the client software interface application.
This open, real-time trading system using the trade portal, allows many market participants to share information and coordinate the trade process and interactions among the goods, finance and transport markets. Equal participation by users in an open market allows the participants to cooperate to the extent of promoting the collective capability of the total market space, without removing the incentive to compete. In essence, a small number of companies, e.g., FEDEX and UPS, own significant percentages of the total market space through the use of proprietary and closed trading systems. The remainder of the market is fragmented among multiple small to medium companies. The trade portal 20 allows a major portion of the remainder of the market to be "de-fragmented" through the use of the open trading network system, which allows the electronic replication of the existing trade process and its related paper documents and associated overheads of duplication, rigid process and assumptions about relationships between market participants.
The trade portal 20 through which service providers can promote and sell the use of their assets and related services, creates a larger open market for all participants, than could be achieved through closed systems, as described before. Shippers can now electronically coordinate the purchasing of goods and related finance with the acquisition and management of transport facilities from origin to destination. The trade portal 20 allows coordination and purchase of goods, transport and finance by routing consistent information, entered once, between these markets. The open and publicly accessible trade portal acts as a funnel to attract a large part of the open trade logistics market and acts similar to an intelligent switch for coordinating the purchase of goods, transport and finance, by routing consistent information, entered once, between these markets. A user, such as a shipper, can electronically navigate to service provider sites and view and respond to service offers from these service providers 30. The shipper can view and use market information, e.g., rates, schedules, news, competitor intelligence, etc., and locate and order goods in an Internet-enabled, service goods market, such as receive order related information from a buyer, who has ordered goods. The shipper can locate, order, and manage and track transport facilities in Internet-enabled transport markets, and locate, order and manage financial instruments in Internet-enabled finance markets or receive information relevant to the transport process from a buyer who has ordered financial instruments. The shipper can also send and receive information in the form of industry standard electronic documents to participants using traditional supply chain management systems, and store and retrieve a record of transactions used to complete a specific consignment. Service providers 30 also have advantages of the present invention. A service provider is able to: (1) navigate all Internet-enabled sites that connect to the trade portal; (2) advertise new services and rates to shippers; (3) publish market information; (4) receive and respond to orders for finance, insurance and transport; (5) publish available inventory or financial services; and (6) publish status information in regard to the physical carriage of the consignment and the documentary milestones, e.g., letter of credit accepted, declared, insure secured, and other associated documents. They also have access to a greater market than possible than if the service providers developed their own closed systems. The service providers can have a better return on assets deployed, and direct access to shippers. They also have lower marketing overheads and lower implementation overheads .
Shippers now have access to open markets for transport and finance, enabling them a choice and therefore price and delivery option benefits. The trade portal coordinates related activities in the financial and transport electronic markets, allowing accuracy and efficiency through sharing common information, without re-entry between the three electronic markets of goods, finance and transport. A single point can be used to track the progress of a consignment through all phases of the supply chain. Use of the trade portal and its real-time communication, and use of the template, can drive transactions through the cooperating systems of the underlying service providers and generate more revenue from these systems. The trade portal can generate revenue, which could include: (1) advertising commissions; (2) membership fees; (3) usage fees for various services related to the trade network; and (4) information feed commissions.
Service providers also establish intimate relationships with their customers when using the open trade system and trade portal. This openness can be reinforced by branding, product packaging rules and implemented business processes.
Service providers 30 also may elect to perform any role in the trade process they choose and may act on behalf, of others. For example, a trade bank may perform the role of shipping clerk in regard to documentation on behalf of a shipper. Service providers 30 can also elect to have their own customers enjoy the benefits of the trade portal through connection to their specific service provider's portal. A service provider 30 could offer financial services and could have buyers and sellers, for example, shippers and cargo carriers, directly connected to its own Internet-enabled portal, but use goods, catalogues and transport services from other electronic markets. Any participant may join in any market, i.e., goods, finance and transport, and will automatically be given access to the other two markets in a coordinated manner.
FIG. 7 illustrates a high level schematic, block diagram of the trade portal in one aspect of the present invention. An operational web site for the trade portal would have a hierarchy of trade portal web pages, such as Zulunet web pages. An example of these web pages could include a splash page 150, such as shown in FIG. 9, a corporate web site page and, an individualized user home page 152 that is the interface for an individualized home office application via the trade portal. Other web pages and applications that can be selected include the trade forum 36, trade alerts 154, trade news 156, and trade link 50. Other web pages that are not shown in block diagram could include a charters entry screen page for chartering aircraft flights, a reservations entry screen for reserving cargo space on an aircraft, a third party entry screen, a network shopping home page, a catalog entry screen, a trade and finance home page to access data about trade and finance, a finance company entry screen, a network services home page, and/or services company entry screen. Naturally, these are only examples of different web pages and services that could be provided via the trade portal and associated web site. Each specified page is accessible from the page one higher in the hierarchy, as known to those skilled in the art. For instance, a home page 152 could provide access to the trade forum 36, trade alerts 154, trade news 156, and trade link applications 50.
Although not illustrated in detail, a trade reservations page could enter an initial trade network service that is wholly owned and operated by the trade portal operator. Other screens could be developed and hosted by third parties. It is an objective that such sites that develop the other screens and services should carry a certification mark to show users coming in through a third party site that they are within 'the trade portal community and provide them with access to other community sites. The home page application 152 for individual users provides an interface to all other services, as described in the following sections. The user can tailor the home page software to display elements of information to his/her specific needs [i.e., "personalization"].
An electronic market access component 160 (FIG. 7) forms a network link and allows users to access products and services provided by service providers. This electronic market access component is presented to network users as four sub-portals: (1) a trade shop application 162 provides access to a variety of electronic catalogue services; (2) a trade port application 164 gives access to a variety of transport services; (3) a trade bank application 166 provides access to a variety of financial and insurance services; and (4) a trade services application 168 gives access to a variety of ancillary service providers.
The trade forum 26 provides the on-line, real-time, networked trading forum. The users 22, such as shippers, having located product through the electronic market access component 160, can negotiate with each other to conclude deals, translate these into formal contracts, and manage the ongoing process until the goods reach their final destination. At any point in time, a "moderator," such as the user, controls the rights of other participants in the particular on-line forum.
Participants can be invited or "caused to exit" by the moderator, or leave voluntarily. The moderator is essentially the person representing the buyer of a product or service, at any point in time, and can control the rules of the on-line trade forum through the underlying application. The person performing the role of the moderator may change during the course of a real-world transaction, i.e., sourcing to fulfillment, but for the majority of the time would be the person representing the shipper.
An individual on-line trade forum is unique to a single real-world transaction. The rules of any individual on-line trade forum are set by the application the moderator chooses to initiate within the on-line trade forum. The application with the template controls what the participant (s) may view and/or update. There is no relationship between any two trade forums but the system can support many trade forums that are active at the same time. This allows major buyers to tailor the system to their own needs, i.e., branding, validation rules, and process. A trade forum 36 contains four main functional areas: (1) the application space that contains the complete structured information set and rules for the trade; (2) a chat system that allows users to establish multiple independent on-line meetings enabling participants to communicate in an unstructured manner, e.g., free text, about the application area being negotiated; (3) a directory system that allows users, including service providers, to register themselves as participants and allows other users to locate them by user defined criteria; and (4) an interface to the trade file application 52 to facilitate the storage of legal records in the repository and the transmission of EDI documents.
Unlike a conventional supply chain management system based on the standardized trading documents, e.g., purchase orders, invoice, etc., the application space is divided into logical areas, e.g., parties, schedules, and similar related trade areas. Moving the mouse over different buttons on an interface will present the user with different interfaces, which are used to enter relevant data. Thus, about any part of the full trading process can be input at any time as a user and service provider negotiates and build up agreements about the various elements of the trade, which are then reflected in the template.
If a third party is connected to the trade portal via an EDI link or any other type of link, i.e., VAN or Internet, and requires a standard document set, then a user can request the production of such a document from the trade forum application 36. In this case, the trade forum application 36 will validate that the required information is submitted before executing a request.
A document exchange service, referred to as the trade file application 50, supports four primary functions: (1) registration, storage and maintenance of contractual arrangements and their associated on-line dialogues between participants, i.e., "the legal repository" 40; (2) translation of information from the legal repository 40 into standards based electronic documents, e.g., EDIFACT, ANSI, XML, etc.; (3) sending and receiving standards based electronic documents over communications facilities, e.g., Internet, EDI networks, etc.; and (4) translation of information from electronic documents that are received over the communications facilities, and submission of this information to the legal repository, and propagation of the information to the relevant forum.
The contents of the legal repository that is part of the document exchange server are updated under the following circumstances. The application template is stored when a trade forum is initiated for trade. The updated state of an application template and the trade forum log is stored when: (a) a forum is terminated; (b) a participant leaves a forum permanently; (c) a participant joins a forum initially; (d) a contractual commitment is made; and (e) an event is recorded in the forum indicating the completion of a legal commitment, e.g., goods received. At the time, a standards based electronic document is sent to or received from the translator. The applications template can also be updated when a session is terminated to be reconvened at a future time and date. A market intelligence component, referred to before as trade news 156 (FIG. 7), consists of a number of third party information feeds that are related to the activities of the three main markets, i.e., goods, transport and finance. Users can select subsets of these information feeds to create their own individual service which is tailored to their specific needs.
As noted before, the user home page consists of four major elements, as also discussed below. A user can tailor elements of the information to his/her specific needs to allow "personalization". The trade link application 50 is an interface to trade-enabled markets for goods, transport and finance. Once a user has located a product or service, he/she can submit the information via the trade link application to the trade forum and enter a negotiation phase.
The trade file application 52 is the interface to the document exchange system, and displays the contents of the legal repository in a manner analogous to a filing cabinet. It allows a user to view contract commitments in timed sequence along with any associated forum logs. Users can drill down to an individual contract or log to view the entire contents. The system administrator for the trade portal, who could be located at an operations control center, on the other hand, can manage translator and network components of the document exchange.
The trade news 156 can provide an interface to the news feeds and market information. A user can dynamically select information content that is then "pushed" into the interface as it is updated. The user can click on any item to drill down to view an increasing level of detail. The information will typically be derived from public electronic news vendors, e.g., Reuters, or from network enabled service providers, e.g., FX rates from a bank.
The user interface is a web-based interface used to locate and buy products and services, carry out on-line real-time contract negotiations, closure and fulfillment tracking.
FIG. 8 illustrates the flow of information between the various components as has been described above. Various boxes in the diagram correspond to different functions and applications as described before, which opened through user interaction.
The Site Navigation Dialogue application provides user with hypertext links through which they can navigate to underlying third party services and locate relevant products and services. The Product
Selection Dialogue application 172 (1) returns details of any product selected by the user to trigger a quotation process; or (2) returns details of products ordered within a third party site to trigger a fulfillment process; and (3) returns details of contracts formed by users so that the relevant inventory can be updated on a third party site.
The Contract Execution Dialogue application 174 allows a user to interact with the legal repository and (1) commit, store and track contracts in real-time; (2) receive information about events in the fulfillment process; and (3) send control messages to cause the legal repository to export legal documents to the EDI translator and network system. The Event Dialogue application 176 allows the trade forum application to present raw information to the trade alerts application 154. The Logistics Events and News Dialogue application 178 allows a personalization manager application 180 to present events and news information through a single interface to a user where the user has determined the categories of information and their presentation dynamically. All applications accessible within the trade portal 20 have a single consistent view of companies and individuals for the purpose of authenticating access to the individual components and for the purpose of identifying these parties uniquely as counter parties in on-line trading. For this reason there is a central directory service that can be used to synchronize company and personal records. Referring once again to FIG. 3, the on-line trade forum 36 interfaces with the legal repository 40 by means of a real-time message protocol that isolates the trade forum 36 from the complexities of the legal repository. The storage manager and server 38 analyses messages and either stores or retrieves data from the legal repository within the context of the messages sent by the trade forum application 36.
An example of an initial entry to the user interface application is via a menu on the splash web page as illustrated in FIG. 9. Naturally, this is an example only of a web page that could be used, but is not limiting for the present invention, as any number of web page examples are possible as known to those skilled in the art. The term "Zulu" has been applied to the trade portal.
Selecting "myZulunet" corresponds to the opening user interface and will take the user to another screen or window, that acts as a "shell" in which all other applications run. The benefit is that all the application interfaces will respond to commands on the shell, e.g., minimize, maximize, close, etc. FIG. 9 illustrates that the pull-down menu could include selections for Transport, Finance, Goods, Services, and general information about the trade portal, Zulunet Incorporated.
A trade link application could have the following functions: (1) to provide an outward hyperlink from the user interface to each of the home pages for the underlying web sites to enable users to search for goods and services; and (2) to provide an inward interface to transfer order details from a site to the trade forum as a means to initiate an on-line negotiation process.
FIGS. 10, 11 and 12 illustrate another aspect of the invention where a cargo carrier, i.e., seller, negotiates through request for quotes and contract offers with a shipper, i.e., buyer. The system is operative through a publicly accessible communications network, e.g., Internet, and described relative to the document exchange system, inventory database, flight tracking system and other servers and databases. For purposes of discussion with regards to FIGS. 10, 11 and 12, reference numerals begin in the 200 series.
As shown in FIG. 10, illustrating an example of the overall system at 210, both the cargo carrier 212 and the shipper 214 can manage the process from ordering to completion through access via a publicly accessible communications network 216, e.g., the Internet, to an operations control center 218 having a management server 220 that allows document exchange via a document exchange server 222, inventory control via an inventory database 224, and flight tracking via a flight tracking system server 226. These components and servers could be included as software programs in one computer as noted in the dashed lines at 228. It is also possible that the management server and other servers could be separate computer systems, such as separate, but networked personal computers. The operations control center 218 can include appropriate staff to assist a cargo carrier 212 or shipper 214 towards a charter contract.
The entire system 210 is preferably a web-based system accessible via the Internet and
Worldwide Web with an appropriate network, web address such as CargoReservations.com or CargoCharters.com, thus allowing transport services to be made publicly available through a portal for the global trade community. The term "public" can refer to the access required by the global trade community. The system can occur as a stand-alone service to provide a user interface to manage freight space.
The system has several benefits. A shipper has the benefit of an open, trusted market in which price is based on actual supply and demand. Charter costs can be reduced by switching to a single charter price system that removes opportunities for hidden, additional costs for dead legs and unflown billable miles. As referred to in this description, a "leg" is a specific path between two points, such as San Francisco and Orlando. A "route" is typically one or more legs, such as San Francisco to Orlando or Orlando to San Francisco or San Francisco to Orlando to Miami. The "tail number" is a unique identifier for a specific aircraft, as known to those skilled in the art. The term "flight" refers to a specific execution of a route by specific tail number, such as flight UA432 at 1700 on January 11, 2000. A "charter contract" is a contract between a shipper and cargo carrier in which the cargo carrier undertakes to supply an aircraft on specified terms, e.g., ACMI=aircraft , crew, maintenance and insurance. The charter contract can include an ad-hoc charter, which is a contract between a shipper and cargo carrier for the one-time charter of a specific tail number for a specific leg. The charter contract can include a scheduled charter, which is a contract between a shipper and cargo carrier for an aircraft to fly the same route more than one time, to fly from San Francisco to Orlando to Miami and back to San Francisco, every Thursday for the next three months .
Cargo carriers can bid for charter flights on the basis of a requested leg at a price the market will bear at the time of transaction. Thus, cargo carriers can openly sell all legs of a flight plan without conflicting with the initial leg, allowing better revenues through an extended market for standing assets. The system and method allows reduced administration costs through an efficient and timely ordering and management process and shorter aircraft turnaround times because of earlier loading information and greater certainty through an electronic audit trail.
FIG. 10 also illustrates that the shipper and cargo carrier can operate through graphical user interfaces (GUI) 230, 232 displayed at respective terminals indicated by the dotted lines at 234 and 236. The GUI's 230, 232 allow for document exchange, aircraft charter inventory location and flight tracking for the shipper, and inventory maintenance, document exchange and flight tracking for the cargo carrier. Various chartering scenarios can exist. For example, an ad-hoc aircraft with a specific tail number could be idle unless contracted for charter. The location of the aircraft is dependent on the last charter flight. If the aircraft is idle at an airport, it can be charted for any route within the aircraft's capability. The aircraft could be relocated to another airport to meet a charter request, provided the aircraft can meet the timing and load requirements.
Also, an aircraft may not be the same tail number and could fly a route on a regular basis, but have idle periods within its schedule that could be made available for chartering. In this ad-hoc charter, a route could be operated by a carrier, such as from City A to City B to City C and back to City B and then City A, every Monday through Friday, leaving City A at 0900 and returning to City A at 1700. Between Friday at 1700 and Monday at 0900 every week, the aircraft could be available for charter under the same rules as any ad-hoc charter, with the exception that the aircraft must be back at City A before 0900 on Monday. Chartered aircraft can also operate on scheduled routes . An operator of scheduled routes can use an aircraft from another carrier and control that aircraft. For example, the operator could request a charter for regularly scheduled routes, e.g., from City A to City B to City C and back to City B and City A, every day Monday through Friday, leaving City A at 0900 and returning to City A at 1700.
For purposes of this description, aircraft can be in two availability categories: (1) aircraft specifically owned for purposes of chartering, and which are available for charter when the aircraft is not an active charter; and (2) aircraft flying regular scheduled routes for specific business purposes, e.g., air courier operations, which have significant idle periods between scheduled routes, and are therefore available for chartering. Aircraft could be available for charter when a shipper desires an ad-hoc scheduled charter. For a shipper, it is not relevant whether an aircraft is one used for ad-hoc charters or operated on regularly scheduled routes. It is only relevant if it has an availability window that matches the charter request parameters. In the present invention, a shipper could be a carrier that operates scheduled routes but uses charter aircraft to operate the flights, for example, a company owned or controlled aircraft.
FIG. 11 shows that the management server 220 uses logical matching rules 240 to match a shipper and a cargo carrier. The matching rules are based upon supply inquiries, also known herein as shipper inquiries, and carrier demand inquiries, which are stored in the inventory database 224 as associated with management server 220 at the operations control center 218. The matching rules 240 are based on commercial standards. To match aircraft availability to a charter opportunity, the aircraft type must be able to accommodate the weight and size of a proposed cargo load and be able to fly a specified distance from the point of origin. It must be present or relocate to the point of origin in sufficient time to collect a cargo load and complete the route from the origin to a shipper destination. A seller of ad-hoc availability for an aircraft can operate scheduled routes and allow for the relocation of an aircraft to its start point for regular scheduled operations. The seller must specify a start point in order for the management server to calculate its true availability. Also, the current location of an aircraft should be specified for ad-hoc charters to allow the management server to calculate what aircraft are capable of being at the origin on time. It could be possible to ignore the current location of an aircraft, but this would lead to bogus offers where a seller could never make the aircraft available in time to meet the criteria of a requested charter. It is possible that a cargo carrier has elected to do so only for marketing purposes. The management server will strike a balance between having offers of high integrity and imposing numerous constraints that would make sellers reluctant to place inventory on the system. The current location of an aircraft does not have to be specified for scheduled charters. A cargo carrier can relocate its aircraft from anywhere in the world to gain a long-term scheduled contract. For example, if a charter opportunity for multiple flights over an extended period arises, the current location of an aircraft could be irrelevant because the cargo carrier 12 could elect to relocate an aircraft and crew over a substantial distance to acquire a long-term charter contract. The cost could be an issue for the first flight, but in practice, any negotiation between the shipper and cargo carrier would be extended, and a decision to re-charter for a long-term contract could be taken in advance.
A potential shipper 214 specifies origin and destination and the management server 220 calculates the distance and matches the route to aircraft capability. A potential cargo carrier 212 specifies the aircraft type, but it does not have to specify a destination, because the aircraft is available for any destination within its capabilities. Because the system is open, shippers 214 and cargo carriers 212 can view all availability, and all active searches through individual shippers and cargo carriers. They modify their own information. The system allows cargo carriers 212 and shippers 214 to view all supply and demand, creating a more dynamic market. Pricing responses reflect supply and demand. Because it is impossible to prevent some individuals from entering bogus requests and/or availability, any staff located at the operations control center 218 can review all records and delete those that are appropriate via a GUI 242.
For purposes of this description, "shipper inquiry" is an entry in the inventory database 224, and specifies a shipper's criteria for interest in active availability records or related information. An "availability record" is an entry into the management server 220 and inventory database 224 that specifies a cargo carrier's available aircraft. A "carrier demand inquiry" is an entry in the inventory database 224 and management server 220 that specifies a cargo carrier's interest in active shipper inquiries. The term "active" refers to a record that is flagged by a user for use by the system and any searching, viewing or matching processes. "Inactive" refers to a record that is stored by a user for later use and not to be used in current searching or matching process. The user could still view and modify that record, however. The graphical user interfaces 230, 232 allow the shipper 214 and cargo carrier 212 to interact with the management server 220 located at the operations control center 218. The graphical user interfaces provide the ability to create, store, view, modify and make "active" or "inactive" and allows a user to delete availability records based on location, aircraft type and time. Shipper inquiries can be created, stored, viewed and modified and made "active" or "inactive" based on location, freight characteristics and time. Active availability records could be viewed that match a shipper inquiry at the time it is made active. The graphical user interfaces 230, 232 allow notification to be received of new, active availability records, which match existing active shipper inquiries. Carrier demand inquiries can be created, stored, viewed, modified and made "active" or "inactive" based on location, freight characteristics and time. "Active" shipper inquiries can be viewed that match a carrier demand inquiry at the time it is made "active". New "active" shipper inquiries can be received to allow notification that match existing "active" carrier demand inquiries. The graphical user interfaces 230, 232 also allow for the negotiation and managing of a charter contract through the document exchange server and allows tracking on a geographic display, such as provided by a third party.
One advantageous aspect of the present invention is the use of the system as if no distinction exists between a cargo carrier and a shipper. Any user could act as either cargo carrier 212 or shipper 214 as happens in the real world. All cargo carriers 212 and shippers 214 could view current demand as shown by active shipper inquiries and determine a price negotiation position. The "active" status for any shipper inquiry or demand inquiry can be set "once" or "for a defined period". If an "active" status is set "once," then the submission of a record is viewed by the management server 220 as a one-time query and only shows active availability records or supply/demand inquiries as appropriate to the original inquiry stored in the inventory database. The "active" status for an availability record can be "active" or "inactive" because the availability record is defined by user input relative to the availability of an aircraft. An originator can delete all inquiries and records, and the system could have to purge all records and inquiries that become "inactive" because an end date is earlier than a current date.
Any staff located at the operations control center 218 would have access to the same user interfaces as the cargo carrier and shipper via the graphical user interface 242. This allows the staff to act on behalf of either party by fully or partially managing a charter process. The staff would also have administration screens as part of their GUI 242 to facilitate the addition and maintenance of user records, which control access to the overall management server and other components of the system.
The management server 220 of the present invention works in association with the inventory database 224 to allow shippers 214 and cargo carriers 212 to communicate information between them in real time about aircraft supply and demand. The inventory database 224 stores shipper and carrier demand inquiries and availability records. The management server 220 provides the matching capabilities through the use of a set of business rules for validating the input of all shipper and carrier demand inquiries and availability records. The management server matches active inquiries and records at the time of input, and on a periodic basis defined by a system administrator at the operations control center 218. A publisher can automatically inform users of new inquiries and availability records that match current active inquiries. The system administrator can also set up an entitlement system at the operations control center 218 to control a users ' s access rights.
The management server 220 obtains information from the inventory database 224 of availability records that are directly input by cargo carriers via an Internet browser through the terminal of the cargo carrier. It is also possible to obtain information from an interconnected information system of a cargo carrier or from an interconnected system of a third party, e.g., OAG, that could provide information on behalf of the cargo carrier. The shippers can provide shipper inquiries from an internal database or directly from the interconnected information system of a shipper.
The document exchange server 222 allows for the filing of electronic documents, such as quotations, orders, shipping instructions, contracts, advice and other legal documents. When a shipper 214 and one or more cargo carriers 212 have identified a possible match in charter requirements and availability, the document exchange server 222 provides both parties with a set of electronic documents to conclude orders and manage a charter process to completion. The documents are "filed" in a database memory of the document exchange server 222, such that authorized parties can track the progress of the process. All documents have a corresponding acknowledgment document or response for the formal confirmation of receipt and acceptance of information.
FIG. 12 illustrates an example of a basic flow in a contract negotiations. The basic flow could include a request for quote 260 from a buyer or a shipper followed by a contract offer 262 from the seller, or cargo carrier or other service provider. This offer would include various terms that would be displayed on window. A discussion of terms 264 follows with a contract confirmation 266. Ancillary services 268, such as truck loading, palletization and other details are discussed, followed by a load list 270 and proof of delivery 272. Typical documents stored and processed by the centralized document exchange server 222 include a request for quote, a quote, an order, an order confirmation, i.e., a charter contract, a load list, delivery confirmation, and a discussion of terms and timing. The quotation/order process applies to the charter contract, but could also be used for handling ramp services, consolidation and trucking processes.
The flight tracking system server 226 allows both the shipper 214 and cargo carrier 212 to track in flight aircraft based on tail number. Tracking can be done via a graphical user interface or similar computer display means. It is possible to use a third party service, as known to those skilled in the art, to track the aircraft. The operations control center 218 will typically be staffed 24 hours a day, 7 days a week. The same graphical user interface 242 and Internet tools used by the staff are the same as the GUI 230, 232 and Internet tools used by shippers and cargo carriers. The staff at the center 218 can provide services ranging from facilitating a charter to ad-hoc requests for information or assistance. The center 218 could have a repository (database) 270 of relevant industry related news, which can be accessed by the shipper and cargo carrier through their graphical user interfaces 230, 232 via the communications network 216. As noted before, FIG. 12 illustrates the information flow that exists among the shipper 214, operations control center 218 and management server 220, and inventory database 224, where matching rules 240 are processed with cargo carrier and shipper inputs to match a shipper and cargo carrier based on availability. The document exchange server 222 with the management server 220 obtains the quotations from one or more cargo carriers to manage information exchange during the chartering process.
Cargo carriers 212 can advertise availability and shippers 214 to match the advertised availability with their shipping requirements. Because the entire system and method is open to both shippers and cargo carriers, the management server 220 and inventory database 224 can store all availability records and inquiries to allow matching by the management server at the instant of creation, or over time. Users can create new records and inquiries by making minor modifications to old records and inquiries rather than re-entering the information from scratch.
The system can operate in an asynchronous mode because there does not have to be a relationship in time or sequence between the users for the management server, the inventory database, and the document exchange server. A shipper 214 could possibly make an inquiry the second before or after the cargo carrier 214 enters an availability request that meets any requested criteria. In the former case, the inquiry would produce a match, but in the latter case, the inquiry would not produce a match.
The asynchronous mode allows shipper and carrier demand inquiries to be stored, and retain a specified "active" validity period to ensure a likelihood that supply and demand will be matched. Because any user may not be on-line at the time of a status change that causes a "match" with the specified criteria, the management server 220 incorporates a "publisher" function 272 that pushes the changed status to a user, via a user specified mechanism, such as a browser, pager, or e-mail. It is possible to generate high volumes of pushed data, thus, all "active" inquiries could be pushed by the system to minimize data traffic.
The cargo carrier 212 specifies availability by creating an "active" availability record, specifying the aircraft type, the origin (s) at which it can be made available, and over what time period. The shipper 214 can specify the shipper or supply requirements by creating an active supply, i.e., shipper inquiry, either by entering a new inquiry or by modifying a currently stored inquiry. The cargo carrier can set the inquiry "active" for a period in which the shipper is interested in receiving any bids. The shipper inquiry also specifies the start and end date for the charter, which may be different from the "active" period. For example, a shipper may wish to receive offers for the next 24 hours for a charter flight that is requested to leave in three days.
It is also possible to upload current schedules for all customers who are shippers and registers in an OAG. Each leg of a route could be created as an "inactive" shipper inquiry. The shipper can then convert the required inquiries to "active" shipper inquiries. At this time, a user would view matching availability records on the respective graphical user interface. If an inquiry has been made active with a defined time period, the user can automatically receive an update whenever a newly entered availability record meets the criteria originally specified in the supply inquiry. The management server 220 automatically sets any active record to inactive if the active period and date or the requested charter goods delivery date is later than the current date.
Any user can monitor the total requests submitted by prospective shippers by submitting an active carrier demand inquiry with an appropriate selection criteria. When the carrier demand inquiry is made active, the user will view any matching "active" shipper inquiries. If the inquiry has been made "active" with a defined time period, the user can automatically receive an update whenever a newly entered "active" shipper request meets the criteria originally specified in the carrier demand inquiry.
Any user can monitor the total requests submitted by possible cargo carriers by submitting an "active" shipper inquiry with appropriate selection criteria. When the carrier demand inquiry is made
"active," the user will view any matching availability records. If the inquiry has been made "active" with a defined time period, the user can automatically receive an update whenever a newly entered availability record meets the criteria specified in the shipper inquiry.
In one aspect of the present invention, it is possible to view only "active" availability records. Thus, a shipper cannot view how many cargo carriers may be observing the state of "active" shipper inquiries without submitting an availability record. A possible cargo carrier can watch the market before deciding to make the cargo carrier's aircraft available. Once decided, this cargo carrier can then make a bid by creating an "active" availability record, matching the requested supply criteria, and this will then immediately become known to the possible shipper.
The management server 220 works in conjunction with the inventory database 224 to allow a digital exchange between the shipper and cargo carrier for brokering aircraft charters. Three types of exchange dynamic records can be stored, such as: (1) "I want..." indicating a shipper's need; (2) "I have..." indicating the availability of an aircraft from a cargo carrier; and (3) "Tell me who is looking for...", which tells the initiator how many other shippers have the same requirement. The response to "Tell me who is looking..." is a list of all active "I want...". These logical inputs can be used by either the shipper or cargo carrier to provide intelligence on the state of the market and what price the market will bear. A shipper or cargo carrier can use a "I want..." to observe what other cargo carriers are offering in specific market segments. Because the various records are stored, a regularly repeating matching program can be run to match records in all three categories on a continuing basis.
An example of the open system as previously described in detail, a business emergency occurs, such as a production line closing if parts are not supplied within half a day. Again, the manufacturer (shipper) perceives that a charter is the only option. The shipper logs onto the network and enters a website to access the management server 220 having in association with it the inventory database 224, document exchange server 222 and flight tracking system server 226. The shipper 214 selects a source, destination and timing of the charter on a map based graphical user interface. The shipper can additionally set a period where it will consider offers from cargo carriers. Any relevant charter availability that is pre-registered with the management server 220 and inventory database 224 is immediately displayed to the shipper at its terminal. If a shipper has indicated a willingness to consider further offers from cargo carriers over a defined period, then the request is published to all the cargo carriers that are registered with the management server with a declared interest in the type of aircraft required for origin and destination points. Any such offers will be automatically displayed on the shipper screen during the specified period. From the total list of available charters, the shipper selects those of interest and uses the document exchange server to issue an electronic request for quotation (RFQ) . The cargo carriers respond to the RFQ on-line by selecting appropriate terms from those shown on the form and add any additional terms and free text and specify the price for the transaction.
The shipper then reviews the responses and issues an order by clicking an "accept" or other button, i.e., response. By securing the primary leg of a charter, the shipper can then advertise all other legs on the service through the communications network via new contractual terms. The shipper 214 and cargo carrier 212 can then carry on an electronic exchange through the remainder of the charter period to clarify details of the physical activity taking place, and if necessary, record amendments to the original terms. Prior to any goods being delivered to the airport, the pallet details are provided to the ramp agent via a document provided by the document exchange server 222. This allows the ramp agent to preplan the load process and guarantee speedy aircraft turnaround time. The physical trucking, palletization and loading/unloading processes occur as normal, but parties are coordinated through the document exchange server. The shipper and cargo carrier track the progress of an aircraft via the tracking system and a graphical user interface, based on the communications network. Other details of the overall system as described can be found in U.S. patent application serial no. 09/500,312, filed February 8, 2000, entitled "SYSTEM AD METHOD OF FACILITATING CARGO CHARTER FLIGHTS, the disclosure which is hereby incorporated by reference in its entirety. FIG. 13 illustrates an open window such as viewed by a buyer or shipper that requires cargo space to be preserved on an aircraft. This type of graphical user interface is advantageous because the entire aircraft may not be charted, but only certain cargo spaces that are defined on the aircraft. For purposes of discussion, reference numerals describing this window being in the 300 series.
FIG. 13 illustrates an open window 330a of a graphical user interface 330, such as used on a windows based computer platform at the shipper terminal 334.
The GUI 330 shows a graphical depiction of an aircraft cargo hold 330b with predetermined cargo spaces labeled with an alphanumeric code, such as A1-E6. The graphical user interface for the cargo hold 330b could be color coded for each cargo space A1-E6 or other identifying scheme or indicia that would distinguish between reserved and unreserved or available cargo space on the aircraft. For example, the cargo spaces referred by the alphanumeric code B4, B5, B6 and C1-C5 have X's indicating that those cargo spaces are reserved and no longer available for reserving by a shipper. Instead of an X, any type of indicia could be used, as suggested to by those skilled in the art. The shipper, cargo carrier and administrator at the operation control center would all have access to the same graphical depiction of the cargo hold. Naturally, the shipper may initially have a list of different aircraft that meet the shipper's needs. When a particular aircraft is selected from a list received from a search request or "match" within the reservation management server, the graphical depiction of FIG. 2 could come on screen, giving the shipper the advantage of determining what cargo space is available and entering appropriate data relating to the cargo space reservation.
When an unreserved space, such as Al, is selected, such as by clicking a mouse pointer on the cargo space on the graphical user interface, a separate cargo hold configuration window 330c for data entry could open with specific shipping, price, destination and terms tabs 331a-d, corresponding to various shipping parameters that can be user selected. For example, the shipping tab 331a has been depressed showing cargo space that is to be reserved. A drop down list 331e allows the shipper to select a required volume. Additionally, the type of containers that are desired can be selected through a drop down menu 331f. The shipping weight that the shipper would probably require can be selected via a drop down menu 331g. Similar drop down menus, data entry boxes, or other data entry formats could be shown for the price, destination and terms tabs 331b-d. This illustrated graphical user interface is only one example of the type of graphical user interface that could be used for the present invention. Other graphical user interfaces could be designed and used as suggested to by those skilled in the art.
Other details of the overall system as described can be found in U.S. patent application serial no. 09/526,352, filed March 16, 2000, entitled "SYSTEM AND METHOD OF RESERVING CARGO SPACE ON AIRCRAFT FLIGHTS," the disclosure which is hereby incorporated by reference in its entirety.
Referring now to FIGS. 14-26A, there are shown various graphical user interface screens and open windows as displayed on a computer screen for both buyers and sellers. These open windows and screens represent examples of what kind of information and graphics can be displayed and what data entry boxes could be displayed for entering data and navigating into and through various search pages and search result pages. Although FIGS. 14-26A represent different open windows and graphical user interface screens, they are only one example in any number of different types of windows, data entry boxes, graphical user interface screens and other screens that can be displayed as known to those skilled in the art. For purposes of this description and throughout the figures, the various trade forum, trade files and other trade areas are also at times represented by a trade designation known as "Zulu." An example of a website location is CargoReservations.com and is displayed on various windows . Although any number of different types of commercial assets as described above could be used, the screens are directed to a cargo reservations process where an aircraft charter or cargo space is reserved. Throughout the following description, reference numerals used with the description begin in the 400 series .
FIG. 14 represents an open window of a home reservations page 400 known as a My Cargo Reservations Page having an upper set of selection buttons 402 for the Zulu forum 404 that allows entry into a trade forum for on-line and real-time negotiations. The aircraft charter button 406 allows entry into screens and pages for searching and obtaining aircraft charter information and obtaining requests for quotes and sending requests for quotes.
FIG. 14 shows this open window of the home reservations page known as the My Cargo Reservations Page, where a user is registered as both a buyer and seller. The page shows a "work-in-progress" screen to cover an entire spread of work. In1 this example, a buyer views information regarding any reservations for an aircraft charter or cargo space that the buyer is buying, while a seller views information regarding the cargo space or aircraft charter that they are selling. In the particular example shown in FIG. 14, the system has configured the "work-in-progress" screen to cover the entire spread of work with buyer and seller.
In the area for the buyer that is labeled "Reservations I'm Buying:", there are shown four columns. The first column 410 lists pending quote requests that are submitted requests for quotes, and the second column 412 lists incoming quotes from a seller that are answers to submitted requests for quotes. Any pending contracts that are related to submitted contracts awaiting buyer approval are listed in the third pending contracts column 414 and any active contracts that are completed contracts with goods in transit are listed in the fourth column 416. In the area for the cargo carrier (or seller, also for any other asset provider) , shown as "Reservations I'm Selling:", there are quote requests that are shown in the first column 410 that displays any requests for quotes received from a buyer. Any pending quotes in column two 412 show the quotes that the seller has responded to. Any pending contracts in column three 414 are the booking requests received from a buyer awaiting the seller's approval, and the active contracts in column four 416 correspond to the completed contracts with goods in transit.
A My Accounts button 420 allows a buyer or seller to view a personal account, and the view contract history button 412 allows a contract history to be viewed. Selecting this button could retrieve a file from a database of the legal repository where various quotes, chat records, condition of contracts, contracts and tracking records are kept in a contractual record and kept in a legal repository (FIG. 27) .
If the aircraft charter button 496 at the top toolbar is depressed, an open window screen such as shown in FIG. 15 could be displayed that includes another toolbar with buttons for allowing an aircraft search 424, aircraft availability posting 426, what the market is doing, i.e., market research 428, services 430, aircraft configurations 432, "Contact Us" 434 and logout 436. As shown in FIG. 15, an aircraft availability posting is displayed by a seller to allow entry of data relating to scheduled aircraft availability and the listing of aircraft by sellers that are available for charter. These can be sorted by airport ID and by different types of aircraft. Various columns of data can be entered, such as the aircraft type, location, the date available to and from, the time to and from, the available days, the active, and whether the information should be deleted. Other data could be entered, such as what aircrafts are available on-demand and what are available for the long term. If the aircraft search button 424 on the toolbar is depressed, a data entry screen (not shown) is retrieved that allows a potential buyer to search for aircraft based on .their selection criteria. This search criteria could be for an "on-demand charter" or "long-term charter." The charter search results are retrieved and placed in table format 440 as in FIG. 16 where the airport ID is listed, the aircraft type, the rate per hour, the rate per mile, the date/time available and whether a request for quotation should be sent or not. Potential buyers can select one or more of the search results for quotation and press the "Send Request" button 442 to bring up Zulunet and initiate a quotation/contracting process. The screen in FIG. 14 displays a "work-in-progress" screen to cover the entire spread of work.
FIG. 17 illustrates a data entry window 444 for entering data into the screen to determine an on-demand charter. Charter search results that are obtained are shown in the search results box 446. A similar type of screen would be used for a long-term charter search.
FIGS. 18 and 19 show an example of the type of open window screens that could be displayed when an "on-demand charter" request or "long-term charter" request is made, and showing in an information box 448 what requests were sent to different carriers.
FIG. 20 illustrates an open window similar to that shown in FIG. 14, but showing data that are displayed after the seller receives specific "requests for quotations" so that a seller can determine whether a response is appropriate. Information is displayed regarding the origin, destination, ready to ship, delivery, aircraft type, dimensions, weight and special conditions. This data gives the seller the information necessary to determine whether a response to the request for quote is appropriate. The seller presses the "Create Quote" button 452 and retrieves a data entry window (FIG. 21) for creating an "on-demand charter" or "long-term charter" quotation.
FIG. 21 shows an open window screen, which is used by a seller to calculate a response to the buyer. In this particular example, the data is for "Create an On-Demand Quotation." Complex rules and data look-ups can be specific to an individual contract template and its worksheet. The worksheet can be specific to an aircraft charter. This is the worksheet template that can be used as a basis of a negotiation and would be specific to the subject of negotiation, i.e., in this specific example for an aircraft charter. Naturally, any type of commercial asset could be negotiated and the negotiation or contract template as it is brought up is specific to the commercial asset. Such information as the company name, an individual name, street address, city, state, zip code, country code, telephone number, e-mail address and contract template can be displayed. For example, in the contract template box 456, a standard DHL on-demand contract template could be retrieved, or alternatively, there is illustrated a generic on-demand that is not specific to DHL.
The lower portion of the worksheet shows different data that can be entered by the seller such as the airport ID, airport city, distance, aircraft type, cost, taxes, distance, route time, aircraft cost, short legs, wait times, overnight fees, airport fees, load/unload, other fees, tax other fees, cargo reservations fee, discount, excise tax, the imposition time and arrive late time, and a grand total. If a "New Quotation" button 460 is selected, the worksheet contents can be erased while, if the "Submit Quotation" button 462 is selected, the worksheet can be summarized into a contract that is viewed by the buyer on screen. FIG. 22 shows an open window box for the
"On-De and Charter Quotation Results" that are viewed by a buyer. This data represents what sellers have submitted quotes and details the information. This window can be viewed together with any screens showing an agreement of an aircraft charter (FIGS. 24-26). It is possible that different proposed contracts for different sellers could be displayed on-screen and the buyer could navigate among different contracts. As shown in FIG. 22, if the buyer selects the negotiate button 470, then the buyer will be taken to a trade forum, also known as Zulu forum, where different users could be connected in real-time as described above. FIG. 23 shows an open window similar to FIG. 14, but displaying the different users that are on-line for negotiation.
FIGS. 24-26 show on-screen agreements, such as retrieved from a contrat template database. As information is changed, the buyer would receive the information shown in the agreement of aircraft charter sent from the seller and the information could be studied and the buyer could accept the terms of that contract agreement and book the charter by selecting with a mouse or other means the block labeled the accept the terms of the contract agreement (FIG. 25A) and book the charter. FIG. 26 shows that once the agreement is made, the contract is active and no changes are permitted.
It is possible that the status of the contract as goods are delivered and shipped can be tracked. It is also possible to enter into real-time negotiations to discuss peripheral aspects of the contract and the transit of any goods in past contract formation process. It is evident that the present invention is advantageous and allows not only real-time negotiation, but a single action that can be performed, such as clicking a mouse, by both the seller and buyer to form a contract for an aircraft charter or any other commercial asset.
Many modifications and other embodiments of the invention will come to the mind of one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed, and that the modifications and embodiments are intended to be included within the scope of the dependent claims.

Claims

THAT WHICH IS CLAIMED IS:
1. A method for purchasing a commercial asset comprising the steps of: retrieving a listing of at least one potential seller of a commercial asset that a buyer desires to purchase; selecting at least one seller from the listing to obtain a quotation of contract terms for purchasing the commercial asset; transmitting to a selected seller via a computer network a request for quotation of the commercial asset to be purchased; viewing by the potential seller on a computer screen the request for quotation, and if a response is appropriate, retrieving a worksheet contract template and entering data into the worksheet contract template corresponding to a quotation of contract terms to be offered by the seller to the buyer; forwarding the quotation of contract terms entered into the worksheet contract template to the buyer; and displaying on a computer screen a contract template having the contract terms offered by the seller to the buyer, and based on a single user action of the buyer, accepting the contract terms offered by the seller, entering into negotiations with the seller for different terms, or saving the contract and any negotiation terms into a legal repository.
2. A method according to Claim 1, wherein said single user action comprises the step of depressing a button.
3. A method according to Claim 1, of modifying proposed contract terms within the worksheet contract template, and updating the displayed contract template viewed by the buyer as the seller modifies any proposed contract terms.
4. A method according to Claim 1, and further comprising the step of displaying on a computer screen a window having a listing of a plurality of quotations of contract terms in response to selecting a plurality of different sellers.
5. A method according to Claim 1, and further comprising the step of forwarding the quotation of contract terms entered into the worksheet contract template in response to a single user action of the seller.
6. A method according to Claim 1, wherein the worksheet contract template is specific to commercial asset.
7. A method according to Claim 1, wherein the entering of negotiations comprises the step of a user inviting into an on-line, networked trade forum the seller of the commercial asset and establishing a real-time communication channel with the seller.
8. A method according to Claim 7, and further comprising the step of terminating the on-line, networked trade forum and establishing a time in which the on-line, trade forum will be reconvened.
9. A method according to Claim 1, wherein said commercial asset comprises one of manufactured goods, money used for credit, money used for insurance risk mitigation, or a physical transport mode to move any manufactured goods .
10. A method according to Claim 1, wherein said computer network comprises a publicly accessible communications network.
11. A method according to Claim 1, wherein said step of retrieving comprises the step of conducting a database search and matching within a management server a buyer and potential seller to produce search results.
12. A method for purchasing a commercial asset comprising the steps of: retrieving a listing of a plurality of potential sellers of a commercial asset that a buyer desires to purchase; selecting a plurality of potential sellers from the listing to obtain a quotation of contract terms for purchasing the commercial asset; transmitting to each of the selected plurality of potential sellers via a computer network a request for quotation of the commercial asset to be purchased; viewing by the each of the potential sellers on a computer screen the request for quotation, and if a response is appropriate, retrieving a worksheet contract template and entering data into the worksheet contract template corresponding to a quotation of contract terms to be offered by a potential seller to the buyer; each responding potential ■ seller forwarding the quotation of contract terms entered into the worksheet contract template to the buyer; and displaying on a computer screen for each responding potential seller a contract template having the contract terms offered by the potential seller to the buyer, and based on a single user action of the buyer, accepting the contract terms offered by one of the potential sellers, entering into negotiations with one of the potential sellers for different terms, or saving at least one contract template and any negotiation terms into a legal repository.
13. A method according to Claim 12, wherein said single user action comprises the step of depressing a button.
14. A method according to Claim 12, of modifying proposed contract terms within the worksheet contract template, and updating the displayed contract template viewed by the buyer as the seller modifies any proposed contract terms.
15. A method according to Claim 12, and further comprising the step of forwarding the quotation of contract terms entered into the worksheet contract template in response to a single user action of the seller.
16. A method according to Claim 12, wherein the worksheet contract template is specific to commercial asset.
17. A method according to Claim 12, wherein the step of entering of negotiations comprises the step of a user inviting into an on-line, networked trade forum the seller of the commercial asset and establishing a real-time communication channel with the seller.
18. A method according to Claim 17, and further comprising the step of terminating the on-line, networked trade forum and establishing a time in which the on-line, trade forum will be reconvened.
19. A method according to Claim 12, wherein said commercial asset comprises on of manufactured goods, money used for credit, money used for insurance risk mitigation, or a physical transport mode to move any manufactured goods .
20. A method according to Claim 12, wherein said computer network comprises a publicly accessible communications network.
21. A method according to Claim 12, wherein said step of retrieving comprises the step of conducting a database search and matching within a management server a buyer and seller to produce search results.
PCT/US2001/009759 2000-03-28 2001-03-27 System and method for purchasing a commercial asset via electronic commerce using single user action of buyer and seller WO2001073592A2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001249487A AU2001249487A1 (en) 2000-03-28 2001-03-27 System and method for purchasing a commercial asset via electronic commerce using single user action of buyer and seller

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US53785200A 2000-03-28 2000-03-28
US09/537,852 2000-03-28
US57577700A 2000-05-22 2000-05-22
US09/575,777 2000-05-22

Publications (2)

Publication Number Publication Date
WO2001073592A2 true WO2001073592A2 (en) 2001-10-04
WO2001073592A8 WO2001073592A8 (en) 2002-03-07

Family

ID=27065622

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/009759 WO2001073592A2 (en) 2000-03-28 2001-03-27 System and method for purchasing a commercial asset via electronic commerce using single user action of buyer and seller

Country Status (2)

Country Link
AU (1) AU2001249487A1 (en)
WO (1) WO2001073592A2 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107527272A (en) * 2017-08-30 2017-12-29 广东信基蜂巢科技有限责任公司 A kind of method of commerce based on internet, electronic equipment and storage medium

Non-Patent Citations (1)

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

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107527272A (en) * 2017-08-30 2017-12-29 广东信基蜂巢科技有限责任公司 A kind of method of commerce based on internet, electronic equipment and storage medium

Also Published As

Publication number Publication date
AU2001249487A1 (en) 2001-10-08
WO2001073592A8 (en) 2002-03-07

Similar Documents

Publication Publication Date Title
US11900442B1 (en) System and method for identifying and co-ordinating an alternate delivery of one or more selected items
US7072857B1 (en) Method for providing online submission of requests for proposals for forwarding to identified vendors
US7363271B2 (en) System and method for negotiating and providing quotes for freight and insurance in real time
AU2005331893B2 (en) Travel service broker system and method
US8135621B2 (en) System and method for supporting anonymous transactions
US8280781B1 (en) Automatically purchasing a gift from a wishlist
US20020095355A1 (en) Computer-implemented international trade system
US20040139001A1 (en) Network based business to business portal for the retail convenience marketplace
US20060195333A1 (en) Registry/repository based private market generator
US7376611B1 (en) Demand aggregation and distribution system
MXPA03006987A (en) Computerized commission based trading operations.
US20050144082A1 (en) Systems and methods for ordering from multiple vendors
US20050144129A1 (en) Systems and methods for paying vendors using CCR data
US20090307144A1 (en) Methods and systems for offering and selling advertising
US8065385B2 (en) Transferring information and records via a data structure for a physical item in the control of a user
JP2004503036A (en) Method, apparatus and system for network-based peer-to-peer business transactions
US20030130900A1 (en) Internet-based system and method for electronically fulfilling purchase orders for chemical and plastic products
US20050177468A1 (en) Request for quote system and method
JP2004515847A (en) Reverse auction method and system
WO2001059652A2 (en) System and method of facilitating cargo charter flights
Mallick Essentials of E-Commerce B. Com 2nd Semester-Syllabus Prescribed by National Education Policy
WO2001073592A2 (en) System and method for purchasing a commercial asset via electronic commerce using single user action of buyer and seller
US7707094B1 (en) System and method for electronically sourcing products
KR20010099243A (en) Wire and Unwired E-Commerce Method and Solution by messenger and messenger network
WO2001071534A2 (en) System and method of reserving cargo space on aircraft flights

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: C1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

D17 Declaration under article 17(2)a
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP

DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)