EP1259916A2 - Procede de mise en oeuvre d'un processus de demande de credit en reseau - Google Patents

Procede de mise en oeuvre d'un processus de demande de credit en reseau

Info

Publication number
EP1259916A2
EP1259916A2 EP00986732A EP00986732A EP1259916A2 EP 1259916 A2 EP1259916 A2 EP 1259916A2 EP 00986732 A EP00986732 A EP 00986732A EP 00986732 A EP00986732 A EP 00986732A EP 1259916 A2 EP1259916 A2 EP 1259916A2
Authority
EP
European Patent Office
Prior art keywords
buyer
network
credit
management
seller
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP00986732A
Other languages
German (de)
English (en)
Inventor
Richard D. Cornelius
Andreas Stepniczka
Kevin Chu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Accenture Global Services GmbH
Original Assignee
Accenture LLP
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
Priority claimed from US09/470,039 external-priority patent/US7069234B1/en
Application filed by Accenture LLP filed Critical Accenture LLP
Publication of EP1259916A2 publication Critical patent/EP1259916A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Definitions

  • the present invention relates to networked interfaces and more particularly to conducting trade finance business operations including a credit application process.
  • a letter of credit is usually an irrevocable undertaking by a bank to pay the beneficiary of the letter, for example, a seller of goods, specified sums of money when certain conditions are fulfilled, to be charged to the account of the person, for example, the buyer of the goods, who causes the bank to issue the letter of credit.
  • the buyer instructs its bank to open an L/C in favor of the seller.
  • the buyer's bank advises the seller's bank that an L/C has been opened in favor of the seller, and the seller's bank accepts the buyer's bank's guarantee to pay.
  • the seller's bank advises the seller that an L/C has been opened in its favor, and the conditions which must be fulfilled for payment to occur.
  • the seller's bank makes an irrevocable promise to pay the seller upon presentation of appropriate documents.
  • the L/C document is considered an asset of the seller, and can be sold or assigned by the seller.
  • Documentation which the seller usually must present to obtain payment includes a bill of lading from its shipper, an invoice identifying the purchase, an appropriate insurance certificate, a certificate of inspection from an inspection firm confirming that the required goods are being shipped, export licenses and/or health inspection certificates, and certificates of origin used by customs personnel.
  • the seller's bank pays the seller, then collects payment from the buyer's bank and delivers the presented documents to the buyer's bank. In turn, the buyer's bank obtains payment from the buyer.
  • the shipper via a carrier, transports the goods to the buyer's location.
  • the carrier requires presentation of the bill of lading, which was delivered to the seller, before transferring possession of the goods to the buyer.
  • the buyer obtains the bill of lading from its bank after payment, and then the buyer and its broker arrange for presentation of the bill of lading to the carrier and delivery of the goods to the buyer's location.
  • the carrier delivers the goods to the buyer's broker at the customs entry point of the buyer's country.
  • the buyer and seller are assumed to be located in countries B and S, respectively.
  • the issuing bank is a bank in country B which has agreed with the buyer to issue a letter of credit in favor of the seller.
  • the paying bank is a bank in country S known to the seller which has guaranteed the letter of credit to the seller.
  • the intermediary bank which may be in country B, country S or a third country, is a bank trusted by both the issuing bank and the paying bank.
  • the buyer issues a purchase order based on an agreement previously concluded between the buyer and the seller. Then, the buyer approaches its chosen issuing bank and instructs the issuing bank to open a letter of credit in favor of the seller confirmed on its chosen paying bank.
  • the letter of credit may be confirmed, unconfirmed or standby. In a standby letter of credit, if the transaction proceeds properly, the standby L/C expires, but if the transaction does not proceed properly, the damaged party draws on the standby L/C.
  • the issuing bank is assumed in this example to have no direct relationship with the paying bank, so the issuing bank approaches an intermediary bank which accepts the guarantee to pay of the issuing bank.
  • the intermediary bank then approaches the paying bank, which accepts the guarantee to pay of the intermediary bank.
  • the paying bank then advises the seller that an L/C has been opened in its favor and that upon presentation of appropriate confirming documentation, including the Bill of Lading from a Shipper, the paying bank will pay the seller.
  • the paying bank In this scenario, that is, assuming a confirmed L/C, the paying bank must pay without recourse upon presentation of appropriate documentation.
  • the paying bank has recourse, that is, the paying bank passes the documentation to the issuing bank and obtains payment therefrom before paying the seller.
  • the seller finishes producing the goods and arranges for shipment with a shipper. Goods are passed to the shipper. The shipper transports the goods to a port of entry in the buyer's country.
  • the shipper Upon receipt of goods, the shipper provides the seller with a bill of lading. The seller presents the bill of lading and other confirming documentation to its paying bank in order to collect against the L/C. After verifying that the documentation is in order, the paying bank pays the seller.
  • the paying banlc presents the documentation and its proof of payment to the intermediary bank, which pays the paying bank.
  • the intermediary bank in turn presents the documentation and its proof of payment to the issuing bank, which pays the intermediary bank.
  • the issuing bank then obtains payment from the buyer and gives the buyer the confirming documentation including the bill of lading.
  • the buyer gives its agent, such as a broker, the bill of lading and other necessary documentation.
  • the buyer's agent obtains the goods from the shipper, clears the goods through customs in country B and arranges for delivery of the goods to the buyer.
  • the international trade is now completed.
  • An L/C shields the seller from the risk of non-payment by the buyer and reduces the risk to the buyer that the buyer will pay for goods not received.
  • the risk of non-payment is assumed substantially by the buyer's bank, which is assumed to be able to evaluate the risk of non-payment by the buyer.
  • the seller's bank assumes the risk of non-payment by the buyer's bank, which the seller's bank is assumed to be able to evaluate.
  • the banks require fees to compensate them for their risks and the expenses they incur in connection with the L/C.
  • the buyer's bank also requires that the buyer pledge collateral such as cash or marketable securities against the L/C or otherwise reduces its exposure in the event of nonpayment by the buyer.
  • Another problem is that the L/C holder can obtain payment with the correct documents, even if shipment has not actually occurred.
  • a bank incurs roughly the same expenses in connection with an L/C, independent of the value of the goods to which the L/C pertains.
  • the bank's fee is sometimes expressed as a percentage of the amount of the L/C, such as 1%. Assuming, for example, that the bank's expenses are $10,000, it will be appreciated that the bank is reluctant to open an L/C for transactions involving less than $1,000,000 of goods, as this business is not profitable for the bank. Thus, it is difficult for parties wishing to participate in international trade to use the L/C mechanism when the value of the goods involved in a transaction is small enough that the expense of an L/C becomes significant.
  • a system, method and article of manufacture are provided for a credit application process.
  • a credit application is received from a buyer utilizing a network.
  • the credit application is sent to a bank via the network. This is for assessing the credit of the buyer based on the credit application. If the credit is approved, the buyer is registered by assigning an identifier thereto.
  • a password is generated for the buyer. The identifier and the password are then stored in a database. Thereafter, the buyer is sent the password utilizing the network. In operation, the buyer may use the password and identifier to initiate transactions on the network. Further, the buyer is issued a card reflecting the identifier.
  • the card is delivered to the buyer by courier.
  • a notice is then sent to the bank upon receipt of the card by the buyer.
  • the credit application may include financial statements of the buyer.
  • the step of assessing the credit of the buyer may include approving a credit limit, and setting up a line of credit.
  • Figure 1 is a general depiction of a NTrade environment based on Internet utilization
  • Figure 2 is a diagram of the trade platform over which buyer and seller processes take place in real time
  • Figure 3 illustrates several eCommerce capabilities of the NTrade system, including elnformation Convergence, eProcurement, eBilling and elnvoicing, and eAuctioning;
  • Figure 4 is a schematic diagram of a hardware implementation of one embodiment of the present invention.
  • Figure 5 illustrates a process for affording a virtual trade financial framework
  • Figure 6 illustrates a variation of the process of Figure 5
  • Figure 7 illustrates operation of a virtual trade financial framework
  • Figure 8 depicts optional enhancements that may be offered and performed during operation of the virtual trade financial framework of Figure 7;
  • Figure 9 illustrates several areas which NTrade will fulfill in the eCommerce value chain
  • Figure 10 depicts a process flow of the NTrade framework
  • Figure 11 illustrates a process for application of a line of credit and access to the NTrade system for a buyer
  • Figure 12 illustrates a process for application for access to the NTrade system by a seller/merchant
  • Figure 13 is a flowchart of a process for initiating bidding in a virtual trade financial environment
  • Figure 14 expands on the bidding process of the NTrade system discusses above with reference to Figure 13;
  • Figure 15 is a flowchart illustrating a process for initiating a transaction in a virtual trade financial framework
  • Figure 16 is a flow diagram which expands on the process of Figure 15;
  • Figure 17 is a flow diagram for initiation of a transaction between a buyer and seller using combined purchase order proforma invoice submission
  • Figure 18 illustrates a process for a payment transaction during a trade
  • Figure 19 illustrates a payment process when there is no disagreement on the terms of the documents
  • Figure 20 depicts a payment process when there is a disagreement on the terms of the documents
  • igure 21 depicts a process for account settlement and/or financing for a buyer (importer) in the NTrade system
  • Figure 22 illustrates a payment process when a direct transfer of funds is available
  • Figure 23 is a flowchart illustrating a process for completing a purchase order/invoice
  • Figures 24 A and 24B illustrate a Purchase Order Performa Invoice (POPI);
  • Figure 25 depicts a combined Purchase Order Performa Invoice;
  • Figure 26 is a flowchart depicting a process for creating a finalized document relating to a transaction
  • Figure 27 illustrates the Main Menu Page of an electronic document checklist which may be used during the process of Figure 26;
  • Figure 28 is a flowchart illustrating a process for creating a financial transaction-related document;
  • Figure 29 illustrates a Document Page of an electronic document creator
  • Figure 30 depicts an electronic Documents Checklist
  • Figure 31 illustrates a NTrade compliance engine
  • Figure 32 illustrates a first option of documentary compliance in a NTrade system
  • Figure 33 illustrates a second option of documentary compliance in which the Bank checks physical documents while NTrade checks electronic documents
  • Figure 34 illustrates a third option of documentary compliance in which the buyer checks physical documents while NTrade checks electronic documents
  • Figure 35 illustrates a general architecture of the NTrade system, including a buyer station, a seller station, a processing hub, and a credit provider system;
  • Figure 36 illustrates an exemplary technical framework for a NTrade system
  • Figure 37 illustrates several potential security threats, including viruses, and internal attacks
  • Figure 38 illustrates security features which may be used with the technical framework of the NTrade system
  • Figure 39 illustrates several security principles and the services which provide them;
  • Figure 40 illustrates an embodiment of the present invention in which NTrade operates under applicable Visa Card and international commerce rules, with an avenue for dispute resolution via the ICC international court for arbitration;
  • Figure 41 illustrates a legal framework when the rules are set by the VTrade Enterprise
  • Figure 42 depicts the legal responsibilities of VTrade and the Bank
  • Figure 43 illustrates the legal responsibilities of the buyer and seller
  • Figure 44 shows a process for credit application and access
  • Figure 45 shows the continuation of the process for credit application and access of Figure 44
  • Figure 46 depicts a process for initiation of bidding
  • Figure 47 illustrates a process for submission of a VTrade POPI
  • Figure 48 illustrates a continuation of the process for submission of a VTrade POPI of Figure 47;
  • Figure 49 depicts a process for negotiation and finalization of the POPI
  • Figure 50 illustrates a process for facilitation of document checking during payment
  • Figure 51 illustrates continuation of the process for facilitation of document checking during payment
  • Figure 52 illustrates a process for account billing and VTrade account management
  • Figure 53 depicts three basic forms that eMarketplaces can take to serve different market functions
  • Figure 54 illustrates how the three marketplaces of Figure 53 may be brought together to create an eMarketplace
  • Figure 55 depicts a technical infrastructure of an eMarket
  • Figure 56 is a table setting forth descriptions of elements of the infrastructure including software/solutions, IT, fulfillment, and financial services/risk management;
  • Figure 57 is a table setting forth a process to create solutions to specific needs during a buy and sell process
  • Figure 58 illustrates another embodiment of the process for creating solutions to specific needs during a buy and sell process
  • Figure 59 illustrates an embodiment of the present invention provides that offers an integrated package of eEnabled financial services products in one or more of the five categories;
  • Figure 60 illustrates a TradeDirect system in accordance with one embodiment of the present invention
  • Figure 61 illustrates how TradeDirect may connect to outside firms to provide a wide breadth of services
  • Figure 62 depicts products/services that may be offered by one embodiment of the present invention.
  • Figure 63 illustrates a process for affording credit rating and reporting utilizing a network
  • Figure 64 is a flowchart of a process for approving a line of credit of a buyer utilizing a network
  • Figure 65 is a flowchart illustrating a process for affording a settlement function utilizing a network
  • Figure 66 is a flowchart that illustrates a process for affording information services while facilitating a transaction between a buyer and a seller utilizing a network
  • Figure 67 is a flowchart depicting a process for contracting and fulfilling a business to business trade utilizing a network according to one embodiment of the present invention
  • Figure 68 illustrates a process for allowing buyers and sellers to gather information about each other
  • Figure 69 is a flowchart that depicts a process for a credit application process
  • Figure 70 illustrates a process for screening a buyer before credit is given to the buyer by a credit provider
  • Figure 71 depicts a process for allowing a company to guard against risk before entering into a trade by allowing purchase of a risk management product
  • Figure 72 is a flowchart illustrates a process for initiation of an agreement utilizing a network
  • Figure 73 illustrates a process for initiating a transaction which includes an ePayment
  • Figure 74 illustrates a process for order fulfillment utilizing a network
  • Figure 75 illustrates a process for a fransaction in which a buyer sends an ePayment
  • Figure 76 is a flowchart of a process for performing a direct fund transfer utilizing a network
  • Figure 77 illustrates a process for open accounts information in accordance with an embodiment of the present invention
  • Figure 78 is a flowchart illustrating a process for account settlement utilizing a network
  • Figure 79 illustrates a process for financing or settling an account accordmg to one embodiment of the present invention
  • Figure 80 illustrates a process for procuring information during the course of a transaction in accordance with an embodiment of the present invention
  • Figure 81 is an illustration of the Integrated Development Environment Architecture (IDEA);
  • IDEA Integrated Development Environment Architecture
  • Figure 82 is an illustration showing a Development Organization Framework in accordance with one embodiment of the present invention.
  • Figure 83 is an illustration showing a security organization functional according to one embodiment of the present invention.
  • Figure 84 is an illustration showing the responsibilities of an Environmental Management Team
  • Figure 85 is an illusfration showing the responsibilities of an Application Team structure
  • Figure 86 is an illustration showing a model migration plan in accordance with one embodiment of the present invention.
  • Figure 87 is an illustration showing a single release capability development pipeline in accordance with one embodiment of the present invention.
  • Figure 88 is an illustration showing a multiple release capability development pipeline in accordance with one embodiment of the present mvention.
  • Figure 89 is an illustration showing a multiple release capability development pipeline with code base synchronization among three pipelines
  • Figure 90 is an illustration showing a Development Tools Framework in accordance with one embodiment of the present invention.
  • Figure 91 is an illustration showing information captured in the Repository and reused
  • Figure 92 is an illustration showing the Repository's central role in the development environment;
  • Figure 93 is an illustration showing an Operational Architecture Framework in accordance with one embodiment of the present invention.
  • Figure 94 illustrates an eCommerce Application Framework in a Development Architecture Framework
  • Figure 95 illustrates the relationship between the eCommerce Application Framework, possible eCommerce Selling Models, enabling technology, and enabling eCommerce Software Packages;
  • Figure 96 depicts the Relationship Management section of the eCommerce Application
  • Figure 97 illustrates a conceptual personalization architecture for implementing the Relationship Management section of the eCommerce Application Framework
  • Figure 98 illustrates a simple personalization process
  • Figure 99 is a graphical depiction of extents of personalization
  • Figure 100 illustrates a content catalog that can be used to manage an enterprise's content
  • Figure 101 illustrates an exemplary template with three Dynamic Content Areas (DC As) embedded within the template in accordance with a method of associating a rule and content to an interaction;
  • DC As Dynamic Content Areas
  • Figure 102 depicts a ShARE (Selection, Acquisition, Retention, and Extension) customer relationship model which addresses the changes in a shift to interactive marketing;
  • Figure 103 illustrates a flowchart for a method for administrating an e-Commerce system on a network in accordance with an embodiment of the present invention
  • Figure 104 illustrates components of the maintenance and administration portion of the of the eCommerce Application Framework in accordance with one embodiment of the present invention
  • Figure 105 illustrates the Order Processing portion of the eCommerce Application Framework of the present invention
  • Figure 106 illustrates a flowchart for a method for completing a transaction over a network in accordance with an embodiment of the present invention
  • Figure 107 depicts an example flow of business capabilities needed for complete order processing on an eCommerce implementation
  • Figure 108 illustrates a flowchart for a method for electronically serving a customer over a network in accordance with an embodiment of the present invention
  • Figure 109 illustrates key customer services of the Customer Services portion of the eCommerce Application Framework
  • Figure 110 illustrates the Security component of the eCommerce Application Framework in accordance with one embodiment of the present invention.
  • Figure 111 illustrates a flowchart for a method for ensuring security of an e-Commerce system on a network in accordance with an embodiment of the present invention.
  • Virtual Trading is a "method" of conducting the frade finance business that achieves the same results as traditional trade finance through a new value proposition and a rethought process.
  • physical documents are reduced. The number of parties involved are kept to the minimal.
  • Three key components of VTrade model are: - VTrade Enterprise, Payment Network and a Bank. It should be noted that though "Bank” is used throughout this document, it is intended that the term include any type of credit provider.
  • VTrade Enterprise provides a one-stop trade finance service via the Internet. It is a highly efficient process excellence factory with full automation in handling credit application, payment, trade document submission and other critical processes. The Bank extends trade credit to the buyers and provides funding for the trade transaction.
  • VTrade does not focus only on local or regional trade, but also on international trading, with a range of supporting facilitation services which will help Visa Members to develop a range of additional revenue sources from repeat business
  • VTrade deals in the underlying goods that are financed while traditional Trade Finance deals with the documents associated with the goods which are financed.
  • VTrade eliminates documents usually associated with international trade. It supports international frade in a similar fashion to the way credit card supports retail commercial transactions.
  • VTrade is to international trade finance transactions as what ATMs are to the retail banking transactions. VTrade allows "Trade
  • VTrade removes the inefficiencies in traditional Trade Finance business by eliminating the handling of documents which acted as surrogate to the actual goods traded.
  • traditional Trade Finance documents were used as surrogate to facilitate the proximity of payment of a trade transaction to the event of taking delivery of goods.
  • VTrade the process of processing the documents which are required under traditional Trade Finance is eliminated.
  • fraditional Trade Finance at a much lower cost.
  • the following table contrasts traditional frade finance and the VTrade environment.
  • VTrade system offers an exporter
  • VTrade eliminates amendment fees, discrepancy fees, SWIFT fees and Telex fees • 'Reduces internal costs through a decrease in the use of paper, mail, and messenger / courier expenses. VTrade simply eliminates paper thereby streamlining the flow of the frade process
  • VTrade is integrated with banks to guarantee payments are transferred exactly according to the buyer/seller contract.
  • VTrade connects all parties to a transaction thereby facilitating communication and information sharing.
  • VTrade allows the importer and the exporter to set the terms of their contract and control their own fransaction
  • VTrade system offers an importer
  • FIG. 1 is a general depiction of a VTrade environment 100 based on Internet 102 utilization.
  • a hub 104 controls and/or monitors operations and transactions in the environment, and particularly across the trade platform 106 between buyers 108 and sellers 110. Also included is a payment network 112.
  • Figure 2 is a diagram of the trade platform 106 over which buyer and seller processes take place in real time.
  • supply 202 is integrated with demand 204 to facilitate interaction and fransaction between the buyer 108 and seller 110.
  • Figure 3 illustrates several eCommerce capabilities of the VTrade system, including efrifbrmation Convergence 300, eProcurement 302, eBilling and elnvoicing 304, and eAuctioning 306.
  • Table 2 illustrates the general roles of the parties in the VTrade system.
  • a preferred embodiment of a system in accordance with the present invention is preferably practiced in the context of a personal computer such as an IBM compatible personal computer, Apple Macintosh computer or UNIX based workstation.
  • a representative hardware environment is depicted in Figure 4, which illustrates a typical hardware configuration of a workstation in accordance with a preferred embodiment having a cenfral processing unit 410, such as a microprocessor, and a number of other units interconnected via a system bus 412.
  • the workstation shown in Figure 4 includes a Random Access Memory (RAM) 414, Read Only Memory (ROM) 416, an I/O adapter 418 for connecting peripheral devices such as disk storage units 420 to the bus 412, a user interface adapter 142 for connecting a keyboard 424, a mouse 426, a speaker 428, a microphone 422, and/or other user interface devices such as a touch screen
  • RAM Random Access Memory
  • ROM Read Only Memory
  • I/O adapter 418 for connecting peripheral devices such as disk storage units 420 to the bus 412
  • user interface adapter 142 for connecting a keyboard 424, a mouse 426, a speaker 428, a microphone 422, and/or other user interface devices such as a touch screen
  • the workstation typically has resident thereon an operating system such as the Microsoft Windows NT or Windows/95 Operating System (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating system.
  • OS Microsoft Windows NT or Windows/95 Operating System
  • IBM OS/2 operating system the IBM OS/2 operating system
  • MAC OS the MAC OS
  • UNIX operating system the Microsoft Windows NT or Windows/95 Operating System
  • OOP object oriented programming
  • a preferred embodiment is written using JAVA, C, and the C++ language and utilizes object oriented programming methodology.
  • Object oriented programming (OOP) has become increasingly used to develop complex applications.
  • OOP moves toward the mainstream of software design and development, various software solutions require adaptation to make use of the benefits of OOP.
  • OOP is a process of developing computer software using objects, including the steps of analyzing the problem, designing the system, and constructing the program.
  • An object is a software package that contains both data and a collection of related structures and procedures. Since it contains both data and a collection of structures and procedures, it can be visualized as a self-sufficient component that does not require other additional structures, procedures or data to perform its specific task.
  • OOP therefore, views a computer program as a collection of largely autonomous components, called objects, each of which is responsible for a specific task. This concept of packaging data, structures, and procedures together in one component or module is called encapsulation.
  • OOP components are reusable software modules which present an interface that conforms to an object model and which are accessed at run-time through a component integration architecture.
  • a component integration architecture is a set of architecture mechanisms which allow software modules in different process spaces to utilize each others capabilities or functions. This is generally done by assuming a common component object model on which to build the architecture. It is worthwhile to differentiate between an object and a class of objects at this point.
  • An object is a single instance of the class of objects, which is often just called a class.
  • a class of obj ects can be viewed as a blueprint, from which many objects can be formed.
  • OOP allows the programmer to create an object that is a part of another object.
  • the object representing a piston engine is said to have a composition-relationship with the object representing a piston.
  • a piston engine comprises a piston, valves and many other components; the fact that a piston is an element of a piston engine can be logically and semantically represented in OOP by two objects.
  • OOP also allows creation of an object that "depends from” another object. If there are two objects, one representing a piston engine and the other representing a piston engine wherein the piston is made of ceramic, then the relationship between the two objects is not that of composition.
  • a ceramic piston engine does not make up a piston engine. Rather it is merely one kind of piston engine that has one more limitation than the piston engine; its piston is made of ceramic.
  • the object representing the ceramic piston engine is called a derived object, and it inherits all of the aspects of the object representing the piston engine and adds further limitation or detail to it.
  • the object representing the ceramic piston engine "depends from" the object representing the piston engine. The relationship between these objects is called inheritance.
  • the object or class representing the ceramic piston engine inherits all of the aspects of the objects representing the piston engine, it inherits the thermal characteristics of a standard piston defined in the piston engine class.
  • the ceramic piston engine object overrides these ceramic specific thermal characteristics, which are typically different from those associated with a metal piston. It skips over the original and uses new functions related to ceramic pistons.
  • Different kinds of piston engines have different characteristics, but may have the same underlying functions associated with it (e.g., how many pistons in the engine, igmtion sequences, lubrication, etc.).
  • a programmer would call the same functions with the same names, but each type of piston engine may have different/overriding implementations of functions behind the same name. This ability to hide different implementations of a function behind the same name is called polymorphism and it greatly simplifies communication among objects.
  • composition-relationship With the concepts of composition-relationship, encapsulation, inheritance and polymorphism, an object can represent just about anything in the real world. In fact, one's logical perception of the reality is the only limit on determining the kinds of things that can become objects in object- oriented software. Some typical categories are as follows:
  • Objects can represent physical objects, such as automobiles in a traffic-flow simulation, electrical components in a circuit-design program, countries in an economics model, or aircraft in an air-traff ⁇ c-confrol system.
  • Objects can represent elements of the computer-user environment such as windows, menus or graphics objects.
  • An object can represent an inventory, such as a personnel file or a table of the latitudes and longitudes of cities.
  • An object can represent user-defined data types such as time, angles, and complex numbers, or points on the plane.
  • OOP allows the software developer to design and implement a computer program that is a model of some aspects of reality, whether that reality is a physical entity, a process, a system, or a composition of matter. Since the object can represent anything, the software developer can create an object which can be used as a component in a larger software project in the future.
  • OOP enables software developers to build objects out of other, previously built objects.
  • C++ is an OOP language that offers a fast, machine-executable code. Furthermore, C++ is suitable for both commercial-application and systems-programming projects. For now, C++ appears to be the most popular choice among, many OOP programmers, but there is a host of other OOP languages, such as Smalltalk, Common Lisp Object System (CLOS), and Eiffel. Additionally,
  • OOP capabilities are being added to more fraditional popular computer programming languages such as Pascal.
  • Encapsulation enforces data abstraction through the organization of data into small, independent objects that can communicate with each other. Encapsulation protects the data in an object from accidental damage, but allows other objects to interact with that data by calling the object's member functions and structures.
  • Class hierarchies and containment hierarchies provide a flexible mechanism for modeling real-world objects and the relationships among them.
  • Class libraries are very flexible. As programs grow more complex, more programmers are forced to adopt basic solutions to basic problems over and over again.
  • a relatively new extension of the class library concept is to have a framework of class libraries. This framework is more complex and consists of significant collections of collaborating classes that capture both the small scale patterns and major mechanisms that implement the common requirements and design in a specific application domain. They were first developed to free application programmers from the chores involved in displaying menus, windows, dialog boxes, and other standard user interface elements for personal computers.
  • Frameworks also represent a change in the way programmers think about the interaction between the code they write and code written by others.
  • the programmer called libraries provided by the operating system to perform certain tasks, but basically the program executed down the page from start to finish, and the programmer was solely responsible for the flow of control. This was appropriate for printing out paychecks, calculating a mathematical table, or solving other problems with a program that executed in just one way.
  • event loop programs require programmers to write a lot of code that should not need to be written separately for every application.
  • the concept of an application framework carries the event loop concept further. Instead of dealing with all the nuts and bolts of constructing basic menus, windows, and dialog boxes and then making these things all work together, programmers using application frameworks start with working application code and basic user interface elements in place. Subsequently, they build from there by replacing some of the generic capabilities of the framework with the specific capabilities of the intended application.
  • Application frameworks reduce the total amount of code that a programmer has to write from scratch.
  • the framework is really a generic application that displays windows, supports copy and paste, and so on, the programmer can also relinquish control to a greater degree than event loop programs permit.
  • the framework code takes care of almost all event handling and flow of control, and the programmer's code is called only when the framework needs it (e.g., to create or manipulate a proprietary data structure).
  • a programmer writing a framework program not only relinquishes control to the user (as is also true for event loop programs), but also relinquishes the detailed flow of control within the program to the framework. This approach allows the creation of more complex systems that work together in interesting ways, as opposed to isolated programs, having custom code, being created over and over again for similar problems.
  • a framework basically is a collection of cooperating classes that make up a reusable design solution for a given problem domain. It typically includes objects that provide default behavior (e.g., for menus and windows), and programmers use it by inheriting some of that default behavior and overriding other behavior so that the framework calls application code at the appropriate times.
  • default behavior e.g., for menus and windows
  • programmers use it by inheriting some of that default behavior and overriding other behavior so that the framework calls application code at the appropriate times.
  • Behavior versus protocol Class libraries are essentially collections of behaviors that you can call when you want those individual behaviors in your program.
  • a framework provides not only behavior but also the protocol or set of rules that govern the ways in which behaviors can be combined, including rules for what a programmer is supposed to provide versus what the framework provides.
  • a framework embodies the way a family of related programs or pieces of software work. It represents a generic design solution that can be adapted to a variety of specific problems in a given domain. For example, a single framework can embody the way a user interface works, even though two different user interfaces created with the same framework might solve quite different interface problems.
  • a preferred embodiment of the invention utilizes HyperText Markup Language (HTML) to implement documents on the Internet together with a general-pvrrpose secure communication protocol for a transport medium between the client and the Newco. HTTP or other protocols could be readily substituted for HTML without undue experimentation. Information on these products is available in T. Berners-Lee, D. Connoly, "RFC 1866: Hypertext
  • HTML Markup Language - 2.0
  • R. Fielding H, Frystyk, T. Berners-Lee, J. Gettys and J.C. Mogul, "Hypertext Transfer Protocol - HTTP/1.1 : HTTP Working Group Internet Draft” (May 2, 1996).
  • HTML is a simple data format used to create hypertext documents that are portable from one platform to another.
  • HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains.
  • HTML has been in use by the World-Wide Web global information initiative since 1990.
  • HTML is an application of ISO Standard 8879; 1986 Information Processing Text and Office
  • HTML has been the dominant technology used in development of Web-based solutions.
  • HTML has proven to be inadequate in the following areas: • Poor performance;
  • UI User Interface
  • Custom “widgets” e.g., real-time stock tickers, animated icons, etc.
  • client-side performance is improved.
  • Java supports the notion of client-side validation, offloading appropriate processing onto the client for improved performance.
  • Dynamic, real-time Web pages can be created. Using the above-mentioned custom UI components, dynamic Web pages can also be created.
  • Sun's Java language has emerged as an industry-recognized language for "programming the Internet.”
  • Sun defines Java as: "a simple, object-oriented, distributed, inte ⁇ reted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword- compliant, general-pvnpose programming language.
  • Java supports programming for the Internet in the form of platform-independent Java applets.”
  • Java applets are small, specialized applications that comply with Sun's Java Application Programming Interface (API) allowing developers to add "interactive content” to Web documents (e.g., simple animations, page adornments, basic games, etc.).
  • API Java Application Programming Interface
  • Applets execute within a Java-compatible browser (e.g., Netscape Navigator) by copying code from the server to client. From a language standpoint, Java's core feature set is based on C++. Sun's Java literature states that Java is basically, "C++ with extensions from Objective C for more dynamic method resolution.”
  • ActiveX includes tools for developing animation, 3-D virtual reality, video and other multimedia content.
  • the tools use Internet standards, work on multiple platforms, and are being supported by over 100 companies.
  • the group's building blocks are called ActiveX Controls, small, fast components that enable developers to embed parts of software in hypertext markup language (HTML) pages.
  • ActiveX Controls work with a variety of programming languages including Microsoft Visual C++, Borland Delphi, Microsoft Visual Basic programming system and, in the future, Microsoft's development tool for Java, code named "Jakarta.”
  • ActiveX Technologies also includes ActiveX Server Framework, allowing developers to create server applications.
  • ActiveX could be substituted for JAVA without undue experimentation to practice the invention.
  • Figure 5 illustrates a process 500 for affording a virtual trade financial framework.
  • an agreement is established between a buyer and a seller for trading pmposes.
  • initiation and payment documents are received utilizing a network.
  • secondary documents such as an insurance certificate, inspection certificate, certificate of origin, invoice/declaration, counselor's invoice, sanction and boycott declaration, packing list, weight list, lab test report, and/or beneficiary certificate.
  • the secondary documents are sent to a bank to be checked in operation 508.
  • the buyer accesses the secondary documents via the bank.
  • Figure 6 illustrates a variation of the process of Figure 5.
  • the secondary documents are received via a facsimile fransmission.
  • the initiation and payment documents may include a combined purchase order proforma invoice.
  • the secondary documents may be stored, indexed and matched.
  • the secondary documents include an insurance certificate, inspection certificate, certificate of origin, invoice/declaration, counselor's invoice, sanction and boycott declaration, packing list, weight list, lab test report, and beneficiary certificate.
  • Figure 7 illustrates operation of a virtual trade financial framework 700.
  • a buyer 704 applies for a line of credit through the buyer's bank 706.
  • the buyer and seller 708 get together and agree to trade on VTrade at 710.
  • the buyer creates an electronic sales agreement.
  • the buyer and seller agree on the sales agreement.
  • VTrade stores transmitted documents, such as emails, presentation, and facsimiles, at 716.
  • VTrade facilitates payment release through a payment network.
  • the buyer's bank consolidates a bill and bills the buyer at 720.
  • Figure 8 depicts optional enhancements that may be offered and performed during operation of the virtual trade financial framework 700 of Figure 7.
  • Such enhancements can include allowing online auctions 800, integration to third parties 802, and linkages to online procurement sites 804. Online credit applications 806 may be permitted, as may integration to other payment network(s) 808.
  • Figure 9 illustrates several areas which VTrade will fulfill in the eCommerce value chain. Such areas include provider access 900, customer service 902, market making 904, buyer agency 906, customer access 908, risk management 910, and fulfillment 912.
  • Figure 10 depicts a process flow of the VTrade framework.
  • the buyer creates an electronic purchase order, which is used to create a combined purchase order proforma invoice.
  • the buyer and seller approve the combined purchase order proforma invoice at 1002.
  • the seller may contract for carriers, providers, etc. for aspects relating to the goods being traded.
  • the frade documents are sent to VTrade, which are then stored and indexed at 1008.
  • a check of the documents may also be made to ensure that all necessary documentation has arrived, etc.
  • the buyer can check the documents online.
  • the buyer's bank pays for the goods over an interface with VTrade at 1012 and sends a consolidated statement to the buyer at 1014, after which the buyer pays the bank at 1016.
  • Figure 11 illustrates a process for application of a line of credit and access to the VTrade system for a buyer.
  • the buyer's (applicant) application for credit is sent to the bank.
  • the application is processed at the credit provider (bank).
  • the new credit and VTrade enrollment information is registered and sent to the buyer in operations 1104 and 1106, respectively.
  • a VTrade card is sent to the buyer, as is acknowledgement of enrollment and receipt of the credit information in operation 1110.
  • Figure 12 illustrates a process for application for access to the VTrade system by a seller/merchant 1200. Numbers 1-7 enumeration the steps of the process.
  • FIG. 13 is a flowchart of a process 1300 for initiating bidding in a virtual frade financial environment.
  • a form is submitted to a plurality of buyers providing details on products or services available from a plurality of sellers. This is to prompt the submission of bids on the products or services.
  • Such forms can include paper documents, facsimiles, emails, etc.
  • the bids are then received from the buyers 1304 utilizing a network. Thereafter, in operation 1306, the bids are categorized based on a predetermined criteria. The categorized bids are subsequently sent to the sellers in operation 1308 utilizing the network.
  • offers are received from the sellers in response to the bids utilizing the network. The offers are displayed to the buyers in operation 1312 and the transactions between the buyers and the sellers are closed in operation 1314.
  • an identity of the buyers is authenticated prior to submitting the form thereto.
  • the identity is authenticated by requiring the submission of an identifier and a password.
  • the step of categorizing the bids may include ranking or segmenting the bids.
  • the criteria may include a geography and/or product category. Further, the bids and offers may be displayed on a site on the network.
  • FIG 14 expands on the bidding process of the VTrade system discusses above with reference to Figure 13.
  • VTrade bid forms are sent to buyers to invite bids.
  • the bids received from the buyers are captured and sorted in operation 1402.
  • interested sellers are permitted to receive the bid forms online and view them and then, in operation 1406, are allowed to submit competitive bid offers.
  • These bid offers are captured in operation 1408 and sent to the appropriate buyers. Operations 1402 through 1408 can be repeated until a buyer or seller accepts a bid.
  • interested buyers' manifestations of intent to transact are captured and transmitted to the sellers in operations 1410 and 1412, which closes the bidding.
  • Figure 15 is a flowchart illustrating a process 1500 for initiating a transaction in a virtual trade financial framework.
  • operation 1502 an agreement between a buyer and a seller is established for trading pu ⁇ oses.
  • a form is then received in operation 1504 indicating terms or conditions of the buyer.
  • a credit of the buyer is checked using a third party in operation 1506. The credit check is performed based on the form.
  • operation 1508 the seller is provided with the form and an indication as to the sufficiency of the credit of the buyer.
  • a response to the form and indication is subsequently received from the seller in operation 1510. Such response of the seller is forwarded to the buyer in operation 1512.
  • the agreement between the buyer and the seller may include payment terms.
  • an identity of the buyer may be authenticated prior to receiving the form.
  • the identity may be authenticated by requiring the submission of an identifier and a password.
  • the seller may be requested to become a registered member of the framework.
  • the agreement may be finalized after forwarding the response of the seller to the buyer.
  • FIG 16 is a flow diagram which expands on the process of Figure 15.
  • operation 1600 it is determined that a buyer and seller have agreed to transact on VTrade.
  • an invoice in this example a purchase order proforma invoice (POPI)
  • POPI purchase order proforma invoice
  • a request for a credit check is sent to the bank (or credit provider) in operation 1604.
  • the buyer's credit line is also earmarked in operation 1606 to indicate the amount of the purchase order to prevent the buyer from exceeding the maximum amount of credit.
  • the seller is alerted to start negotiating on the invoice. The initiation of negotiation is confirmed in operation 1610.
  • FIG. 17 is a flow diagram for initiation of a transaction between a buyer 1700 and seller 1702 using combined purchase order proforma invoice submission. Numerals 1-8 set forth the order of the process.
  • Figure 18 illustrates a process for a payment transaction during a trade.
  • trade documents are received from the seller.
  • goods are shipped for the seller.
  • the documents from the seller are stored and indexed online and made available for the buyer to view in operation 1804.
  • the documents are displayed to the buyer in operation 1806.
  • Payment authorization is also received from the buyer, upon which, in operation 1808, a diligence check is made or requested in order to initiate payment.
  • the amount of the payment is calculated in operation 1810.
  • operation 1812 proceeds from a credit drawdown are sent to the seller. All trade documents are released to the buyer in operation 1814 and the buyer is allowed to take delivery of the goods in operation 1816.
  • Figure 19 illustrates a payment process when there is no disagreement on the terms of the documents.
  • Reference numerals 1-7 provide the order of the steps of the process.
  • Figure 20 depicts a payment process when there is a disagreement on the terms of the documents.
  • Reference numerals 1-7 provide the order of the steps of the process.
  • Figure 21 depicts a process for account settlement and/or financing for a buyer (importer) in the VTrade system.
  • Reference numerals 1-5 provide the order of the steps of the process.
  • Figure 22 illustrates a payment process when a direct fransfer of funds is available. Numbers 1-6 set forth the order of the steps of the process.
  • Figure 23 is a flowchart illustrating a process 2300 for completing a purchase order/invoice.
  • an initial version of a form is received from the buyer indicating at least one requirement for the seller to fulfill.
  • the seller is then allowed to amend the form in operation 2304 thus generating a revision of the form.
  • Such version of the form that is received by the seller is then saved in operation 2306.
  • the buyer is then allowed to amend the form in operation 2308 thus generating a revision of the form.
  • Such version of the form that is received by the buyer is then saved in operation 2310.
  • fri operation the various versions of the form are made available for editing and use until there are no further amendments, and the purchase order/invoice is complete. See operations 2312,2314.
  • the amendments include changing terms of the form.
  • the form may include a combined purchase order proforma invoice.
  • the form may include a first section indicating a plurality of terms, a second section indicating requirements of the buyers with respect to the terms, and a third section indicating requirements of the sellers with respect to the terms.
  • the form is automatically sent to a database utilizing a network in response to the buyer and seller signing the form.
  • commercial shipping documents may be created utilizing input from the seller.
  • FIGs 24A and 24B illustrate an illustrative Purchase Order Performa Invoice (POPI) v2300.
  • the Purchase Order Proforma Invoice allows a buyer to submit an application to initiate a fransaction in VTrade electronically on VTrade Web.
  • the Buyer indicates the performance by seller or requirement for seller to fulfill via POPI.
  • the buyer submits the POPI to VTrade after completing all terms/performance required of the seller.
  • Buyer's bank checks and earmarks buyer's VTrade line of credit (LOC). Once the LOC is earmarked by the bank, confirmation is sent to seller by VTrade.
  • a confirmed/interested seller will negotiate sales/purchase terms with buyer using the POPI.
  • the seller will indicate fulfillment of the buyer's requirements on a Combined Purchase Order Proforma Invoice.
  • the buyer and seller will amend the POPI until agreeable terms are achieved.
  • the buyer and seller can submit each amendment on POPI via the submit pushbutton v2302,v2304.
  • Each amendment by trading parties on POPI will be reflected as a new version.
  • the VTrade Web allows old versions of amendments to be stored and viewed.
  • Figure 25 depicts a combined Purchase Order Performa Invoice 2500.
  • the Combined Purchase Order Proforma Invoice allows buyer to submit application to initiate transaction in VTrade over
  • VTrade Web The buyer indicates a requirement for the seller to fulfill on the Combined Purchase Order Proforma Invoice. The buyer submits Combined Purchase Order Proforma Invoice to VTrade after completing requirements. VTrade checks and earmarks buyer's line of credit. Once the line is earmarked by bank, confirmation is sent to the seller. The seller will indicate fulfillment of the buyer's requirements on the Combined Purchase Order Proforma Invoice.
  • FIG. 26 is a flowchart depicting a process 2600 for creating a finalized document relating to a transaction.
  • a buyer and a seller are allowed to negotiate terms of an agreement.
  • a form detailing the negotiated terms is displayed in operation 2604.
  • the buyer and seller may digitally sign the form in operation 2606.
  • Documents supporting the form are organized and stored in operation 2608.
  • payment to the seller is initiated only after receiving a verification of credit of the buyer.
  • the form may include a first section indicating the terms, a second section for allowing the buyer to sign off on the terms, and a third section for allowing the buyer to sign off on the terms.
  • the form may be displayed after the negotiation of the terms in response to the selection of an icon.
  • the documents supporting the form may be displayed.
  • the form may be automatically sent to a database utilizing a network in response to the buyer and seller finishing the signing of the form. Further, the payment may be completed only after checking the form and the receipt of payment authorization from the buyer.
  • Figure 27 illustrates the Main Menu Page of an electronic document checklist 2700 which may be used during the process of Figure 26.
  • the Electronic Document Creator (Main Menu) is the front page for the VTrade Electronic Document Creator. It is essentially a deal sheet for the buyer and seller to sign on once agreement is reached on all documents. The buyer and seller negotiate on terms of a transaction using the document creator. By pressing on the icon 2702 next to the documents indicated, buyer/seller is linked to the next layer which is the Electronic Document Creator (Document Page). Once there is agreement on the terms of a particular document (refer Document Creator), buyer and seller 'digitally signs' by selecting an icon 2704 next to the related document on the main menu page.
  • the Document Creator (Main Menu) also help track receipt of other related physical documents outside VTrade.
  • Figure 28 is a flowchart illustrating a process 2800 for creating a financial transaction-related document.
  • a buyer is allowed to select among a plurality of documents associated with a proposed transaction.
  • the buyer is permitted to indicate requirements of trade terms relating to the selected documents.
  • a seller may agree or amend the terms on an electronic document platform in operation 2806.
  • a new version of a form delineating the frade terms is generated in operation 2808.
  • each of the versions maybe viewed.
  • the frade terms may include shipping related terms.
  • the terms of the form may be filtered, so that the form may be outputted with only the terms included after filtering for various pu ⁇ oses.
  • standard documents associated with the form may be generated to be used with the form during the transaction.
  • the form may include a first section indicating a plurality of shipping terms, a second section indicating requirements of the buyers with respect to the terms, and a third section indicating fulfillment of the terms by the seller.
  • Figure 29 illustrates a Document Page 2900 of an electronic document creator.
  • the Electronic Document Creator provides the seller with the option of creating commercial shipping documents electronically.
  • the document creator allows buyer to indicate the requirements of the trade terms and seller to agree or amend the terms on an electronic document platform. Both buyer and seller can access Document Page from the Menu page.
  • the buyer and seller will negotiate only on the documents selected by the buyer on the VTrade Document Creator (Main Menu).
  • the VTrade document creator will have defined parameters and structured format within which only the most common trade requirements and information are included. Each amendment for the document creator will be captured on a new version.
  • Document Creator allows for old versions to be viewed. Once terms and conditions is agreed on the document- level, buyer and seller will sign-off on the icon next to the respective document on the Document Creator (Main Menu) page.
  • the VTrade Document Creator will allow creation of standardized documents (which could mirror the Generic Electronic Credit Instrument guideline currently being developed by the ICC Working Party).
  • Figure 30 depicts an electronic Documents Checklist 3000.
  • the Document Checklist is an online document checking facilitation list which allows the buyer to view and check the trade documents submitted by seller on-line via the VTrade Web.
  • the buyer By pressing on the icon 3002 next to the documents indicated, the buyer is linked to the next layer which is the stored documents submitted to VTrade.
  • the buyer signs agreement on overall terms and conditions of Document Checklist. If discrepancies are found by buyer, it is to be noted on the discrepancies column 3004 next to the respective documents in which the corresponding discrepancies are found. The buyer will sign on the checklist once all documents are checked.
  • Figure 31 illustrates a VTrade compliance engine 3100.
  • the compliance engine has a fully- automated compliance checking capability built into the VTrade Web solution, which comprises the VTrade Web front page, the front-end Combined Purchase Order Proforma Invoice and the Electronic Document Creator, all linked to bank and customer's back-end processing systems.
  • the compliance checking is performed through data validation on defined parameters of structured formats for text. Once the compliance engine finds all structured fields/tag are in compliance (clean), an automatic signal is sent to the bank/buyer for payment authorization. When payment authorization is received, the signal will prompt Visanet to credit the seller's account. Anytime the value of the data falls outside the parameter of the structured field, it is rejected as 'discrepant.' The rejection will be automatically sent and highlighted to both buyer and seller elecfronically. Only upon the completion of all checks of structured fields will discrepancy signal be sent to buyer and seller, who will renegotiate on the highlighted discrepancies on VTrade Web's electronic platform
  • Figure 32 illustrates a first option of documentary compliance in a VTrade system.
  • VTrade 3200 checks the electronic documents.
  • Figure 33 illustrates a second option of documentary compliance in which the Bank 3300 checks physical documents while
  • VTrade 3302 checks electronic documents.
  • Figure 34 illustrates a third option of documentary compliance in which the buyer 3400 checks physical documents while VTrade 3402 checks electronic documents.
  • Figure 35 illustrates a general architecture of the VTrade system, including a buyer station 3500, a seller station 3502, a processing hub 3504, and a credit provider system 3506.
  • Figure 36 illustrates an exemplary technical framework for a VTrade system. As shown, the VTrade ente ⁇ rise 3600 is connected to the external world 3602, which is where the buyers and sellers are located. The ente ⁇ rise is also connected to the payment system 3604.
  • Figure 37 illustrates several potential security threats, including viruses 3700, and internal attacks 3702.
  • Figure 38 illustrates security features which may be used with the technical framework of the VTrade system. Such features include encryption 3800, authentication 3802, and firewalls 3804.
  • Figure 39 illustrates several security principles 3900 and the services 3902, 3904, 3906 which provide them.
  • a VTrade system should provide the following security features:
  • Non-repudiation - Users are prevented from denying that they authorised the transaction Transaction Integrity - This ensures that stored or transmitted information in VTrade is unaltered • Non-refutability - This ensures that users can verify that the actual exchange took place by providing a digital receipt or similar proof of payment
  • Signature/validation allow the sender to sign its message before sending them and to validate its signature
  • Encryption/decryption of on-line transaction allow the sender to encrypt the messages he wants to send in order to keep its content secret
  • Authentication confirming the identity of parties involved in the transaction
  • Firewall and network security establishing a barrier between the VTrade co ⁇ orate network (secure network) and the external Internet (untrusted network). Only VTrade Members is granted access from outside based on user names and passwords, Internet IP address, or domain name
  • VTrade should operate under some group of recognized rules, preferably rules that are enforceable in foreign countries.
  • Figure 40 illustrates an embodiment of the present invention in which VTrade operates under applicable Visa Card and international commerce rules 4000,4002, with an avenue for dispute resolution via the ICC international court for arbitration.
  • Figure 41 illustrates a legal framework 4100 when the rules are set by the VTrade Ente ⁇ rise. These rules may apply to both the buyer and seller. All legal contracts outside the VTrade rules should also be established between parties.
  • Figure 42 depicts the legal responsibilities of VTrade 4200 and the Bank 4202.
  • Figure 43 illustrates the legal responsibilities of the buyer 4300 and seller 4302.
  • VTrade may provide a forum for buyers and sellers to settle unresolved disputes through VTrade Rules.
  • the handling of disputes under Traditional Trade Finance can be governed by rules in UCP 500 and URC 522 issued by the International Chamber of Commerce (ICC).
  • ICC International Chamber of Commerce
  • Both UCP 500 and URC 522 contain a complex set of rules relating the documents in International Trade.
  • VTrade may have its own set of rules which govern the underlying goods similar to how credit card rules for retail fransactions. Fri traditional trade finance, disputes can be settled bringing the case to the ICC International Court of Arbitration or to the courts under the normal law of contracts.
  • VTrade can provide a similar avenue of resolving disputes under VTrade rules.
  • Under fraditional Trade Finance the process of refusal of acceptance occurs when the importer refuses acceptance of the document giving him rights to the title of the goods. This can happen under two different situations:
  • the process of refusal of acceptance occurs when the importer refuses acceptance of the goods.
  • the exporter will seek redress from the Credit Provider who provided the guarantee that payment will made when the goods are shipped according to the purchase order.
  • the exporter can bring the case to the International Court of Arbitration to decide whether the exporter had met the terms of the purchase order. If the International Court of Arbitration holds judgment for the exporter, the Credit Provider will make payment to the exporter and seek recourse from the importer.
  • Figures 44-52 depict an illusfrative process flow for operation of the VTrade system with the steps organized in columns associated with the party performing or directing the step, i.e., a buyer 4400, buyer's bank 4402, VTrade 4404, seller's bank 4406, and a seller 4408.
  • Figure 44 shows a process for credit application and access, which continues at A in Figure 45.
  • Figure 46 depicts a process for initiation of bidding.
  • Figures 47 and 48 illustrate a process for submission of a VTrade POPI.
  • Figure 49 depicts a process for negotiation and finalization of the POPI.
  • Figures 50 and 51 illustrate a process for facilitation of document checking during payment.
  • Figure 52 illustrates a process for account billing and VTrade account management.
  • eMarketplaces can take three basic forms which intend to serve different market functions. These forms are:
  • Aggregator 5300 A one-stop shopping venue. It streamlines purchasing by concentrating many product catalogs for buyer groups
  • Auction 5302 A mechanism for liquidating su ⁇ lus at best possible prices. It enables a wide range of potential buyers to bid competitively for products at below market prices. Reverse auctions (Bids) can also exist where buyers post or submit product needs and sellers bid for that sale
  • eMarketplaces can target either vertical market segments or horizontal market needs.
  • the present invention is preferably practice in the context of a vertical market.
  • Players with common needs will naturally look to deep vertical eMarketplaces that cater to their specific needs. Therefore, horizontal hubs will be challenged to directly provide members with targeted industry knowledge and focused offerings. Further, fast movers will lock up key suppliers early making room in many market segments for only one player
  • Characteristics of a dynamic eMarketplace include:
  • FIG 55 an eMarket 5500 is supported by a technical infrastructure 5502.
  • electronic markets must offer key capabilities that span from "making the market” to supporting the infrastructure.
  • Figure 56 is a table setting forth descriptions of elements of the infrastructure including software/solutions 5600, IT 5602, fulfillment 5604, and financial services/risk management 5606.
  • Content includes developing information which allows users to develop a strong understanding of what they're trading and with whom. Examples include historical price/volume data, product/service information, and buyer/seller credit ratings.
  • Community includes providing information about related subject areas to members and allow them to exchange experiences. Examples include chat room, industry news, how-to's, and community contacts
  • Commerce includes creating a regulated forum for trade. Examples include open closed trading rooms, multi-dimensional tradeoffs (price/time), and real-time order matching or auction.
  • Electronic exchanges must also provide support services to facilitate trading. These are preferably part of the infrastructure.
  • Figure 57 is a table setting forth a process to create solutions to specific needs during a buy and sell process, fri operation 5700, the needs of the buyer and seller are identified and evaluated. In operation 5702, options are weighed. Negotiation and contract trading are allowed in operation 5704. Finally, a settlement is managed in operation 5706.
  • Figure 58 illustrates another embodiment of the process for creating solutions to specific needs during a buy and sell process.
  • operation 5800 the needs of the buyer and seller are identified and evaluated.
  • operation 5802 options are weighed.
  • negotiation and contract trading are allowed in operation 5804.
  • a settlement is managed in operation 5806.
  • One embodiment of the present invention offers an integrated package of eEnabled financial services products in one or more of the five categories shown in Figure 59. These categories are: reputation assessment 5900, financing 5902, risk management 5904, ePayments 5906, and information 5908.
  • Figure 60 illustrates a TradeDirect system 6000 in accordance with one embodiment of the present mvention.
  • TradeDirect includes an infrastructure 6002 which can be utilized by any number of business to business eMarketplaces.
  • TradeDirect also provides online counte ⁇ arty reputation assessment tools, financing, risk management tools, an ePayments facility, and information sources.
  • TradeDirect automates research, contracting, and fulfillment in business to business eMarketplaces.
  • Figure 61 illustrates how TradeDirect may connect to outside firms to provide a wide breadth of services, such as those found in Figure 62.
  • TradeDirect 6100 is connected to a plurality of eMarkets 6102, and may be connected to a payments network 6104, credit rating agency 6106, and a technology enabler 6108.
  • TradeDirect should offer products in one or more of the areas of Figure 62 to support business to business exchanges.
  • the areas include: credit ratings and reporting 6200, trade financing 6202, risk management 6204, settlement 6206, and information 6208.
  • Figure 63 illustrates a process 6300 for affording credit rating and reporting utilizing a network.
  • transactions between a plurality of buyers and sellers are facilitated by offering a plurality of services.
  • Such services may include allowing the buyers and the sellers to negotiate terms of the transactions via a site on a network, exchanging forms indicating the negotiated terms utilizing the network, assessing a credit of the buyers by interfacing banks associated with the buyers, and/or initiating payment from the buyers to the sellers.
  • a history associated with the fransactions is generated in operation 6304.
  • the history associated with the transactions is stored in a database in operation 6306.
  • the identity of the buyers and the sellers may be authenticated utilizing the network, which allows the buyers and the sellers to access to the history of other buyers and sellers in operation 6310.
  • the history may be supplemented with information on the buyers and sellers received from third parties.
  • the history of the buyers and the sellers may include ratings received from other buyers and sellers.
  • the history of the buyers and the sellers may inco ⁇ orate records of problems occurring during the delivery of the services.
  • Optional credit rating and reporting services which may be offered include:
  • TradeDirect credit history o TradeDirect will compile a credit history of firms which have used the
  • Figure 64 is a flowchart of a process 6400 for approving a line of credit of a buyer utilizing a network.
  • requests are received from a plurality of buyers for credit approval utilizing a network.
  • the credit of the buyers are assessed in operation 6404 by interfacing banks associated therewith.
  • a predetermined amount of credit is awarded to the buyers in operation 6406.
  • fri operation 6408 the buyers are allowed to negotiate terms of transactions with a plurality of sellers utilizing the network.
  • payment is initiated from the buyers to the sellers.
  • the sellers are provided with a guarantee on the payment up to the predetermined amount of credit.
  • the sellers are provided with the credit assessment when the terms of the transactions are being negotiated by the buyer and the seller.
  • request may be received from the buyers for an increase in credit utilizing the network.
  • the credit of the buyers may be again assessed by interfacing banks associated therewith in response to the requests. Further, an increased predetermined amount of credit may be granted to the buyers.
  • the sellers are then provided with a guarantee on the payment up to the increased predetermined amount of credit.
  • forms indicating the negotiated terms maybe exchanged utilizing the network.
  • the buyers may be optionally allowed to negotiate terms of the transactions with the sellers utilizing a site on the network.
  • Optional trade finance services which may be offered include:
  • TradeDirect may provide products with which buyers and sellers can minimize the risk of trading.
  • Optional risk management services which may be offered include:
  • Figure 65 is a flowchart illustrating a process 6500 for affording a settlement function utilizing a network.
  • a buyer and a seller are allowed to negotiate terms of a fransaction via a site on a network.
  • the terms include an amount of payment and a time frame thereof.
  • Forms indicating the negotiated terms are then exchanged between the buyer and the seller in operation 6504 utilizing the network.
  • a bank associated with the buyer a credit of the buyer is assessed in operation 6506. If the credit assessment is successful, payments are periodically executed from the buyer to the seller in operation 6508 per the terms of the transaction. The payments are executed automatically by accessing the bank associated with the buyer and authorizing payments to the seller.
  • the buyer Upon each execution of a payment, the buyer is sent electronic receipts via the network in operation 6510. fri one embodiment, evidence of the periodically executed payments is stored for later verification. Further, the seller may be sent electronic notices via the network upon each execution of a payment. As an option, risk associated with the transaction may be reduced by offering insurance.
  • Optional settlement services which may be offered include:
  • Figure 66 is a flowchart that illustrates a process 6600 for affording information services while facilitating a transaction between a buyer and a seller utilizing a network.
  • a buyer and a seller are first allowed to negotiate payment terms of a fransaction involving goods via a site on a network in operation 6602.
  • fri operation 6604 the payments terms and goods are compared with other payments terms and goods utilizing the network. Such comparison is also displayed.
  • access may also be had to a database of forms utilizing the network.
  • the buyer and seller are allowed to complete the forms to reflect the negotiated terms utilizing the network in operation 6608.
  • Rules and regulations relating to the goods may also be displayed in operation 6610.
  • payment is initiated from the buyer to the seller utilizing the network.
  • information may be displayed on procedures involving the goods utilizing the network.
  • Information may also be displayed on current events involving the goods utilizing the network.
  • risk associated with the fransaction may be reduced by offering insurance.
  • the buyer and the seller may be allowed to negotiate other terms of the transaction such as the volume of goods, delivery window, delivery location, and delivery mode.
  • Optional information services which may be offered include:
  • Figure 67 is a flowchart depicting a process 6700 for contracting and fulfilling a business to business frade utilizing a network according to one embodiment of the present invention.
  • operation 6702 a buyer and a seller are allowed to negotiate terms of a transaction via a site on a network until an agreement is reached.
  • operation 6704 the buyer and the seller are prompted to confirm a form reflecting the negotiation terms of the fransaction that have been agreed upon.
  • Such confirmed form is stored in a database.
  • Documents which support the transaction are received in operation 6706 utilizing the network.
  • Such documents are stored in the database in operation 6708.
  • the form and the documents in the database may be checked in operation 6710 based on a predetermined set of rules using a rule-based engine.
  • funds may be released to the seller upon the form and the documents being successfully checked.
  • the form is a combined purchase order proforma invoice.
  • a freight shipper and/or an insurer may be contracted to become involved in the fransaction.
  • authorization may be received from the buyer before the funds are released. Further, a consolidated statement may be sent to the buyer.
  • Figure 68 illustrates a process for allowing buyers 6800 and sellers 6802 to gather information about each other.
  • Reference numerals 1-4 set forth the order of the operations of the process.
  • Figure 69 is a flowchart that depicts a process 6900 for a credit application process, fri operation 6902, a credit application is received from a buyer utilizing a network, fri response to the receipt of the credit application, the credit application is sent to a bank via the network in operation 6904. This is for assessing the credit of the buyer based on the credit application. If the credit is approved, the buyer is registered in operation 6906 by assigning an identifier thereto. Next, in operation 6908, a password is generated for the buyer. The identifier and the password are then stored in a database in operation 6910. Thereafter, in operation 6912, the buyer is sent the password utilizing the network. In operation, the buyer may use the password and identifier to initiate transactions on the network. In operation 6914, the buyer is issued a card reflecting the identifier.
  • the card is delivered to the buyer by courier.
  • a notice is then sent to the bank upon receipt of the card by the buyer.
  • the credit application may include financial statements of the buyer.
  • the step of assessing the credit of the buyer may include approving a credit limit, and setting up a line of credit.
  • Figure 70 illustrates a process for screening a buyer 7000 before credit is given to the buyer by a credit provider 7002.
  • the operations which carry out the process are enumerated in order by numerals 1-6.
  • Figure 71 depicts a process for allowing a company to guard against risk before entering into a frade by allowing purchase of a risk management product.
  • the operations which carry out the process are enumerated in order by numerals 1-5.
  • Figure 72 is a flowchart illustrates a process 7200 for initiation of an agreement utilizing a network.
  • a buyer and a seller are allowed to negotiate terms of trade utilizing a network.
  • a form is received from the buyer in operation 7204 indicating the terms of trade utilizing the network.
  • Also received utilizing the network in operation 7206 is an identifier of the buyer.
  • the form is sent to a bank in operation 7208 for assessing the credit of the buyer utilizing the network.
  • the bank to which the credit application is sent is based on the identifier.
  • the form is forwarded to a seller along with the assessment of the credit of the buyer.
  • the seller is permitted to digitally sign the form utilizing the network.
  • the digitally signed form is received from the seller in operation 7214 utilizing the network, after which a notice is sent to the buyer in operation 7216 indicating that the digitally signed form has been received from the seller, thus initiating the agreement.
  • an identity of the buyer is authenticated prior to sending the form to the bank.
  • identity may be authenticated by requiring the submission of an identifier and a password.
  • the credit of the seller may be verified.
  • the form may include a combined purchase order proforma invoice.
  • Figure 73 illustrates a process for initiating a fransaction which includes an ePayment.
  • the operations which carry out the process are enumerated in order by reference numerals 1-6.
  • Figure 74 illustrates a process 7400 for order fulfillment utilizing a network.
  • a buyer and a seller are permitted to negotiate terms of a transaction utilizing a network.
  • a form is received from the seller or the buyer utilizing the network. Such form is created based on the fransaction terms and identifies a forwarding agent that receives a product associated with the transaction from the seller for the pu ⁇ ose of delivering the same to the buyer.
  • Payment is then initiated to the seller for the product in operation 7406. This is accomplished by interfacing a bank utilizing the network.
  • a notice is sent to the forwarding agent in operation 7408 upon the finalization of the payment for the pu ⁇ ose of releasing the product to the buyer.
  • a plurality of documents which support the fransaction are received from the buyer.
  • at least a portion of the documents may be forwarded to the bank for payment authorization pu ⁇ oses. Further, it may be confirmed that the documents are received within a predetermined time period. Still yet, the documents may be forwarded to the bank for facilitating the finalization of the payment.
  • the documents may be scanned and forwarded to the bank utilizing the network.
  • Figure 75 illustrates a process for a fransaction in which a buyer 7500 sends an ePayment sent through TradeDirect.
  • the operations which cany out the process are enumerated in order by. reference numerals 1-6.
  • Figure 76 is a flowchart of a process 7600 for performing a direct fund transfer utilizing a network, fri operation 7602, a buyer and a seller are allowed to negotiate payment terms of a fransaction utilizing a site on a network after which the seller ships goods associated with the transaction to the buyer.
  • an identity of the buyer is authenticated utilizing the network after which, in operation 7606, an indication is received from the buyer to pay the seller for the goods on the network.
  • a database is queried in order to retrieve payment information related to the buyer.
  • the present invention interfaces a bank in operation 7610 utilizing the network for effecting payment to the seller based on the payment information and the payment terms.
  • the payment information may include an identifier for the bank and an associated account identifier.
  • the direct fund transfer may be carried out by a party separate from the bank, the buyer, and the seller.
  • the buyer and the seller are allowed to negotiate payment terms of a transaction using a chafroom. Further, the identity of the buyer may be authenticated using a password.
  • Figure 77 illustrates a process for open accounts information in accordance with an embodiment of the present invention.
  • Reference numerals 1-6 set forth the order of the operations of the process.
  • Figure 78 is a flowchart illusfrating a process 7800 for account settlement utilizing a network, fri operation 7802, a buyer is allowed to select from a group of options in order to settle an account utilizing a network.
  • the options include settling a minimum balance, partially settling, settling a full balance, and applying for an import loan on payment due date.
  • the selected option is then received in operation 7804 utilizing the network.
  • finance interest may be booked against the buyer for an unpaid portion of the account if the selected option includes either settling a minimum balance or partially settling. If the selected option includes settling a full balance, the account may be reconciled in operation 7808.
  • an import loan may be booked and a credit line may be transfened to a frade loan line.
  • ownership of goods may be released to the buyer by transferring title thereto if the selected option includes either settling a minimum balance or partially settling.
  • a consolidated card statement may be sent to the buyer utilizing the network.
  • a third party who reconciles the account maybe engaged if the selected option includes settling a full balance.
  • Figure 79 illustrates a process for financing or settling an account according to one embodiment of the present invention.
  • Reference numerals 1-5 set forth the order of the operations of the process.
  • Figure 80 illustrates a process for procuring information during the course of a transaction in accordance with an embodiment of the present invention.
  • Reference numerals 1-4 set forth the order of the operations of the process.
  • FIG 81 is an illustration of the Integrated Development Environment Architecture (IDEA) that may be used to create a system for implementing the foregoing embodiments.
  • the Integrated Development Environment Architecture provides a development environment framework and associated guidelines that reduce the effort and costs involved with designing, implementing, and maintaining an integrated development environment.
  • IDEA takes a holistic approach to the development environment by addressing all three Business Integration components: organization, processes, and tools.
  • the development environment is a production environment for one or several systems development projects as well as for maintenance efforts. It requires the same attention as a similarly sized end-user execution environment.
  • the pu ⁇ ose of the development environment is to support the tasks involved in the analysis, design, construction, and maintenance of business systems, as well as the associated management processes.
  • the environment should adequately support all the development tasks, not just the code/compile/test/debug cycle. Given this, a comprehensive framework for understanding the requirements of the development environment can be used.
  • the investment required to design, set up, and tune a comprehensive, good development and maintenance environment is typically several hundred development days. Numbers between 400 and 800 days are commonly seen, depending on the platforms, target environment complexity, amount of reuse, and size of the system being developed and maintained.
  • Figure 82 is an illustration showing a Development Organization Framework in accordance with one embodiment of the present invention.
  • the development organization's size, structure, experience, and maturity should strongly influence the choice of tools and the way the tools are integrated. If this link is not understood, the benefit of tool support will be minimal in many areas, and may significantly reduce productivity.
  • a new business capability is infroduced, it is crucial to keep in mind the needs for training and organizational change that which may accompany the technical change.
  • BEVI Business Integration Methodology
  • the RAA profiles deliverable consists of statements about the responsibilities, accountability, and authority of each of the positions in the development organization. These statements define the role of each position in terms of:
  • Figure 83 is an illusfration showing a security organization according to one embodiment of the present invention.
  • a Security Management Team may have a security management 8300, under which are an administration team 8302, a projects & planning team 8304, and a business process security team 8306.
  • the size of the Security Management team, and the way in which it is integrated into the development organization depends on the degree to which security is a factor for each specific environment. For example, the security risks associated with an Internet-based online banking system are far greater than those of a fully isolated client/server system, and therefore warrant a larger team with broader responsibilities and greater influence.
  • the Information Management team is responsible for ensuring that the project's knowledge capital and information resources are managed effectively. This includes:
  • Information Management encompasses Repository management, but generally has a broader scope than merely the repository contents, because most repositories are not capable of holding all the information resources of a project. It is, for example, common to have key project information reside in a combination ofrepositori.es, teamware databases, flat files, and paper documents. It is the Information Management team's responsibility to ensure consistency across all these formats.
  • the Information Management team In addition to managing the information for the System Building team, the Information Management team must also manage the information resources of the other management processes - quality management, environment management, and project management.
  • the Information Management team is ultimately responsible for the contents of the repository. They need to have an intimate understanding of the repository structure and the rules that govern how different objects should be stored in the repository. Although most of the input to the repository are entered by designers, the Repository Management team must manage this population process. Rather than taking a policing role on the project, they should work as facilitators - helping the designers do things conectly the first time, thereby maintaining the integrity of the repository. Without strong repository management, the benefits of using a repository quickly diminish.
  • Folders can be very useful in gaining control over the overwhelming amount of information produced on a large project. Their utility greatly increases if they are managed appropriately. This management is based on easy-to-follow, easy-to-enforce standards.
  • the Quality team is responsible for defining and implementing the Quality Management Approach, which means defining what Quality means for the Program Leadership, and then implementing the procedures, standards, and tools required to ensure the delivery of a quality program.
  • the Quality Management Approach addresses concepts such as expectation management, quality verification, process management, metrics, and continuous improvement.
  • the Quality team Since quality is the result of the interaction of many teams working on multiple processes, the Quality team is responsible for ensuring effective cooperation between teams and good integration of the development processes. The Quality team must therefore forge strong links with all the other project teams.
  • the Quality team is not only responsible for ensuring the quality of the system building process.
  • the Quality team is also directly involved in ensuring the quality of the other IDEA management processes.
  • the Program Management team is responsible for delivering business capability, fri this respect, it is responsible for the System Building and other management teams.
  • other management responsibilities that do not have a specific team or role defined within IDEA also belong to the Program Management team. These include:
  • the Project Management team is responsible for producing a deliverable or set of deliverables. As such, it is responsible for:
  • the Configuration Management team is responsible for defining the approach the program takes to deal with scope, change control, version control, and migration confrol, and for putting in place the policies, processes, and procedures required to implement this approach.
  • Delivering a system on a release-based approach means delivering the system in a series of consecutive releases, increasing or refining functionality progressively.
  • Some of the main drivers to such an approach include:
  • the Release Management team is responsible for:
  • Release Management is more a role than a function. It is good practice to have as many areas as possible represented in the Release Management team; for example, Design, Construction, Configuration, and Environment Management team members would make up a typical Release Management team, each providing input based on their own perspective.
  • Figure 84 is an illustration showing the Environmental Management Team responsibilities.
  • the Service Group 8402 serves as a single point of contact for developers. It interfaces with the Architecture team to provide answers to questions from developers. To avoid adding overhead to the issue resolution process, the support group must be staffed adequately to ensure that all questions are answered. For example, the support group should recruit people from the Technology Infrastructure team at the completion of Technology Infrastructure development. Problem Management
  • Problem Management is concerned with the discrepancies that result from the testing process and the management of design problems detected during verification or validation steps throughout the development process.
  • the Problem Management team is responsible for defining the problem tracking and solution process, and for providing tools and procedures to support the solution process.
  • the Application team 8500 consists of three separate subteams: Application Architecture 8502, Application Development 8504, and System Test 8506.
  • Figure 85 is an illusfration showing the Application Team structure and responsibilities.
  • the structure of the Application team evolves as the development process continues - as the development of the application architecture components is completed, the Application Architecture team's roles may change. While the team continues maintaining the application architecture components, some team members may be deployed to the Application Development team. Here their roles can include helping application developers to conectly use the architecture components, providing development support, and performing code reviews, and so forth.
  • the technology infrastructure evolves throughout the project and responsibility for managing and evolving the infrastructure must be clearly defined. Therefore, rather than having a single amo ⁇ hous 'technical team' (responsible for operations, support, architecture evolution, and more), it is important to define a dedicated technology infrastructure team. By allowing the technology infrastructure team to focus on the technology infrastructure, rather than the day to day running of the environment, the project increases the chances that the technology infrastructure will provide good support for the business applications.
  • the Technology Infrastructure team is the team that will implement the IDEA framework.
  • the Development Process Model is a framework that facilitates the analysis of the many concunent processes of systems development. This analysis helps understand process interaction, which, in turn, affects organizational interaction and defines a need for tools integration.
  • the Process model is simple - at its core is the system building process, which is sunounded by eight key management processes.
  • Information Management manages the information that supports the entire project - information that is used both in systems building and in other management processes
  • Security Management covers all areas of development security, from coding standards, to security verification.
  • Quality Management pertains to all areas of the development environment d) Program and Project Management must manage all the management processes in addition to managing the systems building process
  • each of the processes must be defined at a greater level of detail than that which any methodology can achieve.
  • This additional specification consists of a set of procedures and standards that specify how to perform the work and what to produce at each step.
  • Standards specify what the results should look like. They may include industry standards and more formal (de jure) standards, such as POSFX compliance, but most standards are project specific and determine, for example, how to structure and name system components and where to place system components. Standards make it possible for a large team to exchange information effectively and to work productively together.
  • Procedures specify how to perform a task. They are generally guided by the methodology but provide information at a lower level of detail. They are highly environment-specific, and take into account the organization, the standards, and the tools in the environment. Procedures often specify the techniques to be used. They may specify which tools to use and how to use the tools that support these techniques.
  • Samples can sometimes convey a message much faster than pages of explanatory prose.
  • Sample programs are generally very useful.
  • Other samples may include logs, which demonstrate interaction with tools, a sample change request, or a sample request for technical support. Samples can sometimes be created efficiently by taking screen dumps. This can be much faster than specifying what the screen should look like in theory.
  • Samples and standards must be high quality - any quality breach will be multiplied when developers start using them. It is therefore imperative that samples and standards not be created in a vacuum but be based on concrete experience with the project's development environment. Some pilot development work often proves extremely useful when fine tuning the standards.
  • Security requirements are the outcome of the security Risk Assessment. This is the process of identifying business risks, identifying system vulnerabilities or weaknesses that can impact those risks, and recommending mechanisms to control the vulnerabilities. Specific confidentiality, integrity and availability requirements for the new system and the development environment are defined through this process.
  • Security standards, guidelines and procedures provide security direction to the implementation. They will help define how the security requirements developed through the Risk Assessment must be addressed in all areas of the development environment. They will include security standards for the development environment infrastructure, procedures for the development processes, standards for the design of the security architecture and security guidelines for programming. It is especially important to ensure the security of the development environment because if these systems are broken into and back doors are introduced, it may lead to later compromise of the production system. It will be the responsibility of all developers that these security controls are implemented and adhered to throughout the development process.
  • periodical security audits should be ananged, in order to verify that the processes and architecture and application components that are being developed conform to security proven practices. This may be done by an external body specializing in security (such as Global TIS - Security) in the form of interviews, architecture and code reviews, and automated tool assessment.
  • an external body specializing in security such as Global TIS - Security
  • Information Management generally involves Repository Management
  • SLA Service Level Agreement
  • Such an SLA typically defines how quickly a new data element is created and how repository changes are communicated. More generally it defines the division of responsibilities between the information management team and the other project teams at a detailed level.
  • Repository Management (8102)
  • Repository Management includes activities such as:
  • repositories do not provide sufficient versioning functionality, it is common to have more than one repository on large projects. Typically, there may be one repository for development, one for system test, and one for production. This allows better control, but also requires significant resources to move repository objects from the development environment to the system test environment.
  • the medium-sized project has a potential for productivity gains. If these gains are to be realized, great care must be taken when making conections during system test.
  • any enor analysis involving repository objects must take into account the possibility that these objects could have changed since the previous migration to system test. This situation can be managed by meticulously maintaining a comprehensive change log.
  • a single development environment may have to deal with multiple repositories:
  • one repository might be integrated with an upper-case design tool and the other with a lower-case generation tool
  • repositories may be distributed over different locations. In order to keep these repositories synchronized, well defined development processes must be implemented.
  • Repository Management can be divided into the following areas:
  • the data elements should usually be controlled by the Repository Management team, because they are the basic building blocks of the system and have broad reuse. Poorly defined data elements can cause inconsistency, redundancy, and generation enors. Data elements should therefore be locked at least by the time construction starts, and possibly earlier, depending on the discipline of the team. Project members must be allowed to browse the data elements, but only the Repository Management team should be allowed to modify or unlock data elements. In some repositories, it is difficult to restrict the creation of repository objects. If this is the case, it may be acceptable to let designers create data elements if these are reviewed and locked at the end of each day. Increased control can be obtained by having designers submit requests for new data elements to the repository administrator. This allows the repository manager to evaluate whether the new data element is justified, or whether an existing one should be used.
  • Requests for data element changes can be forwarded using a database or paper-based system. Based on functional and technical knowledge, the repository administrator evaluates the requests and may involve other teams to make appropriate decisions.
  • the database used to request data element changes during design and programming should be separate from the project's change request database. This will simplify and speed up the change process. When data elements have to be changed during system test, however, the impact can be much greater, and the regular change request database should be used.
  • dialog definitions, reports, messages, and so forth are usually maintained by the designers and programmers.
  • dialogs and report programs are tested, approved, and ready to be promoted to the system test environment, the related objects must be locked. This is the responsibility of the Repository Management team.
  • project-specific standards should exist for defining repository objects. These standards can form the basis for a repository validation program, which can run through the entire repository and report on detected deviations from standards. In some cases, this program can also enforce the standard.
  • Mass changes to the repository can be performed when the validation reports show the occunence of many standards violations that follow a common pattern. This may occur in cases where:
  • Certain reports should be run daily, such as the list of new data elements or modified data elements. These reports can serve as an audit trail of changes and can be used to communicate changes to the entire team. Procedures should specify which reports are run daily and what their distribution should be.
  • the Repository Management team performs certain analyses repeatedly. Standard analyses such as impact analyses should be specified in detail to facilitate staffing flexibility.
  • the Repository Management team can provide custom reports or ad hoc queries that satisfy particular needs.
  • Folders can be organized by type of component so that one folder contains all the include files, one folder contains the source modules, one folder contains executables, and so on.
  • Folders can also be organized functionally so that all the common components reside in one folder and each application area stores its components in its own folder. Choosing the strategy depends on how components are named, on the number of components, and on the tools used. If naming standards make it easy to identify the component type (for example, by using suffixes), organizing them by functional area is generally useful and straightforward to administer. Some tools assume that closely linked files (for example, source and object modules) reside in the same folder.
  • scratch folders may be useful in certain contexts, the proliferation of miscellaneous folders with cryptic names can make it very difficult to navigate the information.
  • Some useful ⁇ guidelines include:
  • media content means that it cannot be freated in the same way as 'standard' formats, such as source code or design documentation.
  • the major differentiating factors are its sheer volume (media files can range from a Kilobyte to multiple Gigabytes), and the complexity of its associated formats (i.e. it is not easy to 'look into' a media file and understand its contents).
  • Storage management concerns the methods of storing and retrieving media content.
  • the cost of data storage may be decreasing, but it is still the case that for large volumes of media it is often uneconomical to store everything on-line. For this reason, processes must be implemented to manage where data should be stored, and how it may be transitioned from one location to another.
  • Off-line Manual access, for example, CDs or tapes on shelves
  • accessibility On-line storage being the most accessible and most expensive, and off-line the cheapest but least accessible.
  • the decision of which method to use for which data may depend on a combination of its type, volume, version (i.e. latest or historic) and accessibility requirements.
  • Metadata about the media that is being stored is an important commodity that must be managed. As the volume of media content grows, it is vital to be able to understand characteristics of the media, in order to be able to manage it conectly. Examples of metadata include:
  • Media type for example, MPEG video, JPEG image
  • Media source for example, Source, author, creation date
  • Object Management processes are very similar to those involved with Repository Management. However, they should promote reuse through specific processes:
  • BJJM Business Integration Methodology
  • the Quality Management processes are covered by the following tasks:
  • the Quality Management Approach defines the following processes:
  • Processes and deliverables are key candidates.
  • the V-model is the prefened method by which the quality verification process is managed.
  • the V-model ensures that deliverables are verified, validated, and tested. It is based on the concept of stage containment (enforcing for a given deliverable the identification of the problems before it goes to the next stage) and entry and exit criteria (describes conditions in which a deliverable passes from one stage to another).
  • the quality verification process owner may not be responsible for executing the V-model, but is responsible for making sure that the V-model is in place and complied with.
  • Sample metrics include:
  • the first stage of the Continuous Improvement Process is to capture continuous improvement opportunities. These may include:
  • the Quality Management team While maintaining quality at a program level, the Quality Management team must liaise with each of the organizational units within the development environment in order to monitor the quality management processes within these units.
  • CMM Capability Maturity Model
  • the CMM provides a software organization with guidance on how to gain control over their processes for developing and maintaining software and how to evolve toward a culture of software engineering and management excellence.
  • the model defines five levels of software process maturity as well as how to move from one level to the level above.
  • the V-model is a framework that promotes stage containment by organizing the verification, validation, and testing in and across all the methodology elements throughout the delivery phase of the Business Integration Methodology.
  • the IMPROVE Job Aid (provided with the BIM Guide) describes the process for solving problems or improving a process. In this Job Aid, you will find an introduction to the five step process your team can use to solve both simple and complex problems.
  • the Quality Action Team (QAT) is responsible for applying IMPROVE to improve a process or solve a problem.
  • Program Management focuses on the continuous oversight needed to support the delivery of business capability through multiple projects and releases. Appropriate disciplines, techniques, and tools are used to plan and organize the work, and to manage the incremental delivery of the new business capability.
  • Program Management consists of three major activities, each split into a number of task packages.
  • Project Management focuses on providing specific deliverables through balanced management of scope, quality, effort, risk, and schedule. Project Management processes follow a cycle of planning the project's execution, organizing its resources, and controlling its work. The Project Management team oversees all other teams within the development environment.
  • Project Management comprises a single activity containing a number of task packages.
  • Configuration Management is not only the management of the components in a given environment to ensure that they collectively satisfy given requirements, but it is the management of the environment itself.
  • the environment consists not only of system components, but also of the maintenance of these components and the hardware, software, processes, procedures, standards, and policies that govern the environment.
  • Packaging is the combination of systems software and application component configurations (source code, executable modules, DDL and scripts, HTML) together with their respective documentation. It may also include the test-data, test scripts, and other components that must be aligned with a given version of the configuration. Packaging allows the grouping of components into deliverable packets of application software that can be developed, tested, and eventually delivered to the production environment. Packaging defines the underlying architecture that drives version, change, and migration control. Each of these control processes defines how changes to configuration packages are versioned and migrated to the various development and test phases in the systems development life cycle.
  • a sample packaging strategy would take into consideration some of the following factors in determining a unique method to handle a given configuration packet in terms of version, change, and migration confrol:
  • Base package type identifies the various types of application components that are developed during systems building such as executables, JCL, HTML scripts, and Java applets.
  • Package release type identifies the types of commonality that components can have. There are usually four basic types of components that are developed during systems building:
  • Package platform type - identifies the eventual delivery platform of the package. Identifying this early on in development and encapsulating this information within the package definition, allows developers to envisage the production environment at an early stage during the systems development life cycle.
  • a configuration management cube can be defined, which uniquely identifies version, change, and migration control characteristics of a given package.
  • the cube can be used to implement a table-driven configuration management control system for all software developed on the program.
  • the configuration confrol system consists of version and migration confrol. Therefore, the cube defines all processes associated with version confrol and migration of a package.
  • Version control and compatibility are key considerations when managing these packages. Note that version control not only applies to software components, but also to all components of a given package, including test scripts, test data, and design documentation. It is also of great importance to keep track of which version is in which environment. If incompatibilities are discovered, it must always be possible to "roll back" to a previous consistent state, that is, to revert to an earlier version of one or more components. It must be possible to define releases of a configuration - a list of version numbers, one for each component of the package which together form a consistent configuration. The smallest unit that can be version controlled should be the package as defined in the packaging plan. This ensures that the lowest common denominator in all version control activities is managed at the package level.
  • a systems building environment can have many development and test stages. On a large project these may include:
  • Migration of packages or consistent configurations from one stage to another is a central part of Configuration Management.
  • the key to successful migration is the knowledge of what constitutes each stage. Examples of migration include:
  • Figure 86 is an illusfration showing a model migration plan in accordance with one embodiment of the present invention.
  • the Figure 86 model allows the development and testing of architecture components independent of application components.
  • the Technology Architecture team can develop 8600, assembly test 8602, and system test 8604 their components before delivering them to the development environment for the application developers. This ensures that the architecture is thoroughly tested before being used by the Application teams.
  • the model also illustrates the progression of architecture and application components through the systems development life cycle.
  • the application developers can then develop 8606, assembly test 8608, and system test 8610 their components before user acceptance tests 8612.
  • the model is a temporal one and thus suggests that architecture must be present at a given stage before the introduction of application components.
  • the version control plan must align with the migration control plan.
  • the version control plan defines the points where version control activities will take place. In the above example, version confrol will take place at the development stages, architecture development and unit test, and application development and unit test.
  • Migration confrol defines how these version control configuration packages will be migrated successfully from one stage to the next until the package is eventually released to the production environment. d) Change control (8118)
  • Configuration Management becomes more complex in a component-based development environment as the system is broken down to a greater level of granularity.
  • Release Management involves coordinating activities that contribute to a release (for example, cross-project management) and the coordination of products that contribute to a release (such as architecture, integration, and packaging). It is concerned with managing a single release rather than cross-release management.
  • the Release Management approach documents critical decisions regarding the management, tracking, and integrity of all components and configurations within a given release.
  • the Release Management approach must be closely coordinated with the definition of the Configuration
  • the coordination of products that contribute to a release is the maintenance of a bill of materials for a release. It is an inventory of all software and hardware components that are related to a given release.
  • the development environment is directly affected by the Release Management strategy. The way a program decides to plan releases affects the complexity of the development environment.
  • Figure 87 is an illustration showing a single release capability development pipeline in accordance with one embodiment of the present invention.
  • the ability to perform all development stages for a given release can be defined as a development pipeline.
  • the pipeline consists of all development and testing stages necessary to release the software to production.
  • Figure 88 is an illusfration showing a multiple release capability development pipeline in accordance with one embodiment of the present invention.
  • MODE Management Of Distributed Environments
  • MODE provides an excellent framework for specifying the management responsibilities that apply to the development environment. These responsibilities are often assigned to the technical group, but as discussed above, there are benefits associated with establishing a dedicated environment management team.
  • the Environment Management component described here uses MODE as a framework, adopts MODE terminology, and focuses on those management tasks, which are particularly important in the development environment.
  • the development environment is simpler than the production environment. It is, for example, generally smaller in terms of the number of hardware components and the number of locations, fri other respects, however, the development environment is more complex. For example, the amount of change in this environment is generally higher than in the production environment. In fact, the environment can be so fluid that extreme care must be taken to maintain control. On a large engagement, one dedicated technical support person per ten designers and programmers is recommended. The greatest need for technical support is generally during detailed design and programming. It is, however, necessary to start building the technical support function before detailed design. All processes that are performed by the Environment management team must be documented in a centralized database that allows quick and easy reference.
  • Service Management provides the interface between the Environment Management team, the Development teams, and external vendors or service providers. It manages the level of service that is provided to the developers. In order to maintain this service, three areas must be managed:
  • SLAs Service Level Agreements
  • Service Level Agreement In order to plan and organize the development work appropriately, a Service Level Agreement (SLA) must be in place between the Service Management group (typically part of the Environment Management team) and the developers. As with all other components of the development environment, this agreement should be kept simple. It should specify the following:
  • the SLA should also specify how to measure this service (for example, system response times, request service times, backup frequencies).
  • the SLA must be managed. It may have to be modified as the environment changes, and it must be reviewed with developers on a regular basis to see if the service level is adequate.
  • the Environment Management team is responsible for providing the specified level of service, but frequently relies on external vendors and suppliers to perform certain tasks.
  • hardware service is typically provided by the hardware vendor.
  • the Environment Management team must ensure that external vendors provide their services as required. This generally means establishing a contract with the vendor and following up that the contract is respected.
  • the Help Desk function is an important part of the interface between the Service Management group and the developers.
  • the Help Desk makes sure that questions are answered and requests serviced in a timely manner by the right people.
  • the Help Desk is crucial to maintaining productivity.
  • the Help Desk needs particular focus when:
  • Efficient searches in the Help Desk database can, in some cases, be greatly facilitated by extending the basic functionality of the Help Desk tool. This can be achieved, for example, by adding a smart word search capability on top of the Help Desk history database.
  • the Help Desk In addition to serving internal project needs, the Help Desk must be prepared to coordinate the activities of external suppliers to solve problems. This occurs when several new versions of hardware and system software are introduced, and compatibility issues arise. Part of the coordination is the tracking of request IDs, which refer to the same question but which are assigned differently by each supplier. To manage communication with external vendors, a contacts database with the following information is useful:
  • Defining the SLA, with its specific, measurable criteria, is the basis for continuous improvement.
  • the continuous improvement effort may focus on providing the same level of service with fewer resources, or on providing better service.
  • An important part of quality management is ensuring that the Environment Management team understands the key performance indicators for service delivery, that these indicators are monitored, and that all personnel are adequately equipped with the tools and training to fill their responsibilities. While the entire team is responsible for delivering quality, the responsibility for Quality management should be assigned to a specific individual on the Environment Management team.
  • Confrol tasks may include checking and archiving activity logs. Standards and procedures that describe the control function must be established.
  • the Environment Management team must systematically monitor the development environment to ensure that it is stable, provides adequate response times, and satisfies the needs of the developers. This momtoring involves looking at trends and extrapolating them to anticipate problems with disk capacity, system performance, network traffic, and so forth.
  • Security management involves: • Defining security requirements
  • the resources required for delivering the service can be specified. Questions to address include the staffing of these resources and training to ensure that they are equipped to deliver service as agreed.
  • Strategic planning is traditionally regarded as being less important in a development environment than in the production environment, mainly because the development environment is often viewed as a temporary entity that does not wanant serious strategic considerations. This may be changing however, with the concept of the ente ⁇ rise-wide development environment - a single, generic development environment architecture that is tailored to each specific project. In this case, strategic planning for the development environment is vitally important if the environment is to evolve, and allow the organization to remain competitive. Strategic planning of the environment management function may, for example, include such questions as support for . multisite development and coordination of multisourced systems management.
  • the development environment is subject to constant change (for example, the addition of new tools, or changes to code libraries), which needs to be managed carefully.
  • the Managing Change component comprises three sub-components: Controlling Change, Testing Change, and Implementing Change.
  • testing should also verify that the expected positive benefits of the change are indeed obtained.
  • Problem Management is generally associated with the discrepancies that result from the testing process, though it may also be applied to the management of design problems detected during verification or validation steps. Problem Management is a crucial process in the system development life cycle. It ensures that quality software is designed, developed, and tested so that initial benefits defined in the business case are in fact realized. A development environment must have a formally defined problem management process to ensure that this objective is met.
  • Formal problem tracking helps to control the analysis and design process by maintaining documentation of all problems and their solutions. Problem tracking improves communication between developers and business representatives, which is particularly helpful in minimizing misunderstandings at later stages of the development cycle.
  • Such formal problem tracking also helps to facilitate the solution process by formalizing a procedure for reviewing, acting on, and solving problems in a timely manner.
  • management can minimize the risk of misunderstandings at a later date.
  • the documentation serves as an audit frail to justify design and implementation decisions.
  • the development environment varies by segment of a systems development project. The following model is used when discussing different components of the development environment.
  • the development process is iterative and can be entered at different stages depending on the complexity of the changes. Small conections may not require explicit design, and small enhancements may not require any high-level design.
  • the shaded, elliptical labels in the above figure indicate how the development process can be entered depending on the magnitude of the change.
  • the iterative nature of the development process is important since it implies that components of the development environment, which are put in place for design (for example), must be maintained, since they will continue to be used until the end of system test and beyond. Multiple releases of the business application may also be under concunent development at different stages. This may lead to very active use of design, construction, and testing tools at the same time.
  • Tool support may help enforce standards, and such tools are discussed under Tools - System Building - Analysis & Design
  • the design process includes numerous activities, which range from high-level general considerations to low-level detailed issues.
  • the overall objective of design is to transform functional and technical specifications into a blueprint of the system, one that will effectively guide construction and testing. While requirements analysis and specification deals with what the system must do, design addresses how the system will be constructed. Validating that the design actually meets the requirements for functionality, performance, reliability, and usability is essential.
  • the quality of the design process directly affects the magnitude of the efforts required to construct and test the system, as well as the maintenance effort. Investments in defimng high- quality design standards and procedures and integrating tools is therefore particularly important. It may, for example, have a direct impact on the degree of reuse achieved, fri addition, adequate training must be provided to ensure that the designers make optimal use of the environment provided.
  • parts of design may occur after system test starts, as in the case of an urgent change request, or when a significant inconsistency is detected in system test.
  • Some reverse engineering work may also occur before design or during construction.
  • Usability is an important (and often overlooked) consideration in system design. Usability is more than a well-designed user interface - the way in which business processes are modeled, how they are implemented within the system, and how they are presented to the user all contribute to the overall usability of the system. Usability is an iterative process of refinement that results in systems that are easy to learn, efficient, and enjoyable. In the very broadest sense, usability is the thoughtful, deliberate design approach that considers users throughout the solutions-building process, from start to finish. For this reason, usability guidelines should be defined and followed at every stage of system design. This, along with regular usability reviews and tests both internally, and by target user groups (by using prototypes), helps to reduce the risk of a poorly received system.
  • the User Interface has become increasingly important as systems become more and more user- facing. As multimedia technologies evolve allowing the development of richer user interfaces, so the design processes must adapt to reflect these new technologies. The processes that sunound the design of media content are similar to that of regular system design, and many of the same issues that apply to designing fraditional user interfaces also apply to the design of media content.
  • the major change is the involvement of media content designers - a group of people not traditionally associated with system design and development. As their presence is relatively new to the scene of systems development, it is often the case that media content designers are not fully integrated into the development team - a potentially costly mistake. It is important to ensure that media content designers are involved in the design process at a very early stage, and that they are fully integrated into the application design and construction teams.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un système, un procédé et un article manufacturé s'utilisant pour un processus de demande de crédit. Dans un premier temps, une demande de crédit émanant d'un acheteur utilisant un réseau est reçue. En réponse à cette demande de crédit, la demande de crédit est envoyée à une banque par l'intermédiaire du réseau, ce, afin d'évaluer le crédit dont dispose l'acheteur, sur la base de la demande de crédit. Si le crédit est approuvé, l'acheteur est accrédité par attribution d'un identificateur. Un mot de passe est ensuite produit pour l'acheteur. L'identificateur et le mot de passe sont mémorisés dans la base de données. Le mot de passe est ensuite envoyé à l'acheteur à l'aide du réseau. En application, l'acheteur doit utiliser le mot de passe pour lancer des transactions sur le réseau. De plus, l'acheteur se voit attribuer une carte portant l'identificateur.
EP00986732A 1999-12-22 2000-12-22 Procede de mise en oeuvre d'un processus de demande de credit en reseau Withdrawn EP1259916A2 (fr)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US470039 1983-02-28
US470805 1995-06-06
US469525 1995-06-06
US46952599A 1999-12-22 1999-12-22
US47080599A 1999-12-22 1999-12-22
US09/470,039 US7069234B1 (en) 1999-12-22 1999-12-22 Initiating an agreement in an e-commerce environment
PCT/US2000/035216 WO2001046889A2 (fr) 1999-12-22 2000-12-22 Procede de mise en oeuvre d'un processus de demande de credit en reseau

Publications (1)

Publication Number Publication Date
EP1259916A2 true EP1259916A2 (fr) 2002-11-27

Family

ID=27413103

Family Applications (1)

Application Number Title Priority Date Filing Date
EP00986732A Withdrawn EP1259916A2 (fr) 1999-12-22 2000-12-22 Procede de mise en oeuvre d'un processus de demande de credit en reseau

Country Status (3)

Country Link
EP (1) EP1259916A2 (fr)
AU (1) AU2291401A (fr)
WO (1) WO2001046889A2 (fr)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8781973B1 (en) 2004-09-24 2014-07-15 Bank Of America Corporation Event marketing automated system
US8312033B1 (en) 2008-06-26 2012-11-13 Experian Marketing Solutions, Inc. Systems and methods for providing an integrated identifier
US8738516B1 (en) 2011-10-13 2014-05-27 Consumerinfo.Com, Inc. Debt services candidate locator
US9853959B1 (en) 2012-05-07 2017-12-26 Consumerinfo.Com, Inc. Storage and maintenance of personal data
US9654541B1 (en) 2012-11-12 2017-05-16 Consumerinfo.Com, Inc. Aggregating user web browsing data
US9916621B1 (en) 2012-11-30 2018-03-13 Consumerinfo.Com, Inc. Presentation of credit score factors
US9406085B1 (en) 2013-03-14 2016-08-02 Consumerinfo.Com, Inc. System and methods for credit dispute processing, resolution, and reporting
US10102570B1 (en) 2013-03-14 2018-10-16 Consumerinfo.Com, Inc. Account vulnerability alerts
US9477737B1 (en) 2013-11-20 2016-10-25 Consumerinfo.Com, Inc. Systems and user interfaces for dynamic access of multiple remote databases and synchronization of data based on user rules
US9460286B1 (en) 2013-12-19 2016-10-04 Amdocs Software Systems Limited System, method, and computer program for managing security in a network function virtualization (NFV) based communication network
US9430262B1 (en) 2013-12-19 2016-08-30 Amdocs Software Systems Limited System, method, and computer program for managing hierarchy and optimization in a network function virtualization (NFV) based communication network
US10606718B1 (en) 2013-12-19 2020-03-31 Amdocs Development Limited System, method, and computer program for managing fault recovery in network function virtualization (Nfv) based networks
US9384028B1 (en) 2013-12-19 2016-07-05 Amdocs Software Systems Limited System, method, and computer program for preserving service continuity in a network function virtualization (NFV) based communication network
US9806979B1 (en) 2013-12-19 2017-10-31 Amdocs Software Systems Limited System, method, and computer program for optimizing a chain of virtual network functions in a network based on network function virtualization (NFV)
US9838265B2 (en) 2013-12-19 2017-12-05 Amdocs Software Systems Limited System, method, and computer program for inter-module communication in a network based on network function virtualization (NFV)
US10572361B2 (en) * 2017-04-28 2020-02-25 The Boeing Company Concurrent production use of a production enterprise system and testing of a modified enterprise system
US20200074541A1 (en) 2018-09-05 2020-03-05 Consumerinfo.Com, Inc. Generation of data structures based on categories of matched data items
US11238656B1 (en) 2019-02-22 2022-02-01 Consumerinfo.Com, Inc. System and method for an augmented reality experience via an artificial intelligence bot
US11941065B1 (en) 2019-09-13 2024-03-26 Experian Information Solutions, Inc. Single identifier platform for storing entity data
US11966402B2 (en) 2020-04-09 2024-04-23 Collibra Belgium Bv Context driven data profiling
US20220164873A1 (en) * 2020-11-24 2022-05-26 Collibra Nv Systems and methods for data enrichment
CN115952178A (zh) * 2022-12-01 2023-04-11 北京华宇九品科技有限公司 一种多层级关联数据异构数据同步方法

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2001046889A8 (fr) 2001-11-22
AU2291401A (en) 2001-07-03
WO2001046889A2 (fr) 2001-06-28

Similar Documents

Publication Publication Date Title
US7069234B1 (en) Initiating an agreement in an e-commerce environment
US7610233B1 (en) System, method and article of manufacture for initiation of bidding in a virtual trade financial environment
US6629081B1 (en) Account settlement and financing in an e-commerce environment
US7167844B1 (en) Electronic menu document creator in a virtual financial environment
US6473794B1 (en) System for establishing plan to test components of web based framework by displaying pictorial representation and conveying indicia coded components of existing network framework
US6904449B1 (en) System and method for an application provider framework
US7149698B2 (en) Business alliance identification in a web architecture Framework
US7165041B1 (en) Web-based architecture sales tool
US7315826B1 (en) Comparatively analyzing vendors of components required for a web-based architecture
US6536037B1 (en) Identification of redundancies and omissions among components of a web based architecture
US8121874B1 (en) Phase delivery of components of a system required for implementation technology
US6957186B1 (en) System method and article of manufacture for building, managing, and supporting various components of a system
US6519571B1 (en) Dynamic customer profile management
US6256773B1 (en) System, method and article of manufacture for configuration management in a development architecture framework
US6405364B1 (en) Building techniques in a development architecture framework
US7139999B2 (en) Development architecture framework
US6662357B1 (en) Managing information in an integrated development architecture framework
US6370573B1 (en) System, method and article of manufacture for managing an environment of a development architecture framework
US6697824B1 (en) Relationship management in an E-commerce application framework
US6324647B1 (en) System, method and article of manufacture for security management in a development architecture framework
US6701345B1 (en) Providing a notification when a plurality of users are altering similar data in a health care solution environment
US7403901B1 (en) Error and load summary reporting in a health care solution environment
WO2001046889A2 (fr) Procede de mise en oeuvre d'un processus de demande de credit en reseau
WO2000073956A9 (fr) Systeme, methode et article fabrique permettant de classer par ordre de priorite des composants d'une structure de reseau necessaires a la mise en oeuvre d'une technique
WO2000073955A9 (fr) Procedes, concepts et technologie pour systeme d'achat virtuel capable d'evaluer les besoins d'un client et de recommander un produit ou un service sur la base de ces besoins

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020718

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

17Q First examination report despatched

Effective date: 20100423

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ACCENTURE GLOBAL SERVICES GMBH

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

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

18D Application deemed to be withdrawn

Effective date: 20100904