Patent Application
20080147516
The present disclosure is directed generally to an apparatuses, methods, and systems for completing purchases, and more particularly, to apparatuses, methods and systems to facilitate and effectuate cross-border payments.
The process of exporting and importing merchandise, or effectuating cross-border trade, is an old process, and in many ways has changed little over the centuries. Many of the traditional entities involved in the trade process are the same: the carrier, the freight agent, the bank, the insurer, the government regulatory agency, the buyer and the seller. Traditionally, the export-import process utilizes hard copy documents for information distribution and storage, multiple third party service providers are managed and coordinated by the trading parties themselves, i.e., management and control of the transaction process and regulatory responsibilities are conducted in-house. Additionally, letters of credit are used as methods of payment and collection. The traditional process is document-based, requiring paper documentation to evidence various elements of the transaction, from quotation to the transfer of ownership and collection of proceeds. This scenario is still prevalent today among most small to mid-sized firms engaged in trade. As such, import/export has long been a physical and interpersonal activity. Buyers, sellers and agents need to negotiate terms, and then have to navigate formidable cross-border regulations and paperwork to engage in the trade of goods. Cross-border trade can also include exporters, forwarders, carriers, brokers, importers, banks, customs, and other players that are involved in facilitating trade.
Over time, various online Business-to-Business (B2B) trade-related web sites have been launched that include trade boards, barter sites, vertical exchanges and portals. Trade boards offer member buyers and sellers trade leads. These trade leads most often contain hyper-links to vendor websites, so that any buyer-seller discovery happens separately between the two trading parties. Examples of these types of B2B sites include TradeXpro.com, and Eceurope.com. Barter sites serve specific sellers who need to sell over-stocked or distress products and often use auction software. Examples of these types of B2B sites include Liquidation.com. Also, sellers may compete for visiting buyers focused on specific products within a given industry. For example, the AgriSeek exchange features agricultural commodities, products and services; Industry2Industry.com links buyers of industrial equipment to its member vendors' websites; the European Plant Exchange serves growers, suppliers and traders of plants and seed in Europe; and Elemica.com, formed by 22 founding chemical companies, facilitates the buying and selling of bulk chemicals on its site. B2B portals offer multi-vertical exchanges. Examples of B2B portals include B2Business.net, Bocat.com, Alibaba.com and Worldbid.com.
The disclosure details implementations of apparatuses, methods, and systems to effectuate cross-border transaction payments; i.e., a Payment Facilitation Engine (or simply “Engine”). In contrast, current B2B trade portals: 1) do not provide infrastructure to categorize and/or identify goods and/or services for import/export; 2) do not provide an integrated mechanism of acquisition to determine total costs that incorporate regulatory, customs, shipping, handling, timing and/or other logistical requirements for acquisition of goods; 3) do not provide Engine driven transfer facilitation to determine and provide such logistical requirements (e.g., the generation and execution of the appropriate regulatory, customs, shipping, etc. forms and delivery to the appropriate destinations); and 4) and do not facilitate payments as between the parties. As such, current B2B trade portals are expensive, difficult to use, introduce great inefficiencies, and do not solve the aforementioned problems with existing export-import transactions. In short, existing B2B portals do not offer end-to-end (E2E) electronic cross-border transaction mechanism that facilitates the navigation of intense import-export bureaucracies and processes. The present disclosure overcomes all the aforementioned failings.
Through its various components, the cross-border Payment Facilitation Engine creates new markets by generating and facilitating payment. In one embodiment, the Engine manages the transaction by: creating a transaction “template” based on transaction information (i.e., HS product code, ISO country code, etc), alerting the buyer to potential problem areas, and updating of important upcoming dates and actions, and handling payment arrangements. The Engine creates all the required documents, integrates all events and parties, including the financial institutions, and allows parties to track the status of the payments on-line at any time. In one embodiment, the Engine provides the user with a template to ensure all pertinent information is detailed, so that payment responsibilities of the trading partners are clearly defined and transparent prior to engagement. The Engine has many numerous and revolutionary components to facilitate cross-border payment, such as, but not limited to: a payment matrix that employs interrelated rules and data sets pertinent to the exchange of payments and transfer of financial instrument as between seller, buyer and any intermediary financial institutions; an exchange facility which discerns differences in currency as between buyers and sellers and automatically render all financial transactions in the user's native currency. The Engine may also be equipped to manage fluctuations in exchange rates.
In one embodiment, the Engine may obtain a selection for a desired item from presented goods and services. The Engine may then determine a country of destination and origin for the selected items as well as a least expensive payment method, based on cross-border regulations and restrictions. The Engine then determines a currency exchange strategy to manage fluctuations in exchange rates and provides materials to effect payment from the buyer of the desired item to the seller of the desired item.
The accompanying appendices and/or drawings illustrate various non-limiting, representative, inventive aspects in accordance with the present disclosure:
The leading number of each reference numeral indicates the first drawing in which that reference numeral is introduced. For example, communications network 150 is first introduced in
The disclosure details implementations of apparatuses, methods, and systems to effectuate cross-border transaction payments; i.e., a cross-border Payment Facilitation Engine (or simply, “Engine”).
Unlike the Payment Facilitation Engine, current B2B portals do not offer an integrated online trade transaction and payment process; i.e., none of the B2B portals offer an end-to-end (E2E) electronic cross-border transaction mechanism that facilitates the navigation of intense import-export bureaucracies and financial payment processes. Furthermore, each country's various trade regulations and/or restrictions vary and may impact a transaction and/or associated payment(s) depending on the buyer's country with which the trade transaction is taking place. As such, each country-to-country transaction and payment will have a unique set of trade regulations and/or restrictions. This results in an unimaginable number of country-to-country trading pairs of trade regulations and/or restrictions with which trading partners must be familiar in order to complete a transaction and effectuate payment. As a result, even if a user finds a trading partner that offers goods in which they are interested, there is no easy way for that user to know what the actual cost of the transaction will be, as the transaction costs of the administrational, customs, duties and/or other related costs of the trade are difficult to discern and surmount, and effectuating payment in such an environment is particularly difficult. Even if the user can find out what trade restrictions apply to a particular country-to-country transaction, the labyrinth of procuring the right forms for the transaction and properly filing such forms is circuitous at best, and navigating foreign banking and payment processes is similarly difficult. As a result, global trading partners will engage in transactions with relatively few trading partners in relatively few regions; it is just too difficult for even sophisticated trading businesses to build a knowledge base and establish financial relationships in more than a relative few country-to-country pairings of trade processes, regulations and/or restrictions. As difficult as the import-export process is for large and sophisticated trading entities, it is all the more intimidating for small-to-mid-sized-enterprises (SMEs). As a result of such complexity, various consultants and trade intermediaries offer their services to facilitate a variety of segments of global trades, resulting in added costs, intermediary steps, inefficiencies, and/or delays. Furthermore, current B2B portals still require a high level of expert knowledge of the export-import processes, are not consistently and/or systematically integrated with third party service providers and are not integrated between the trading parties and/or their respective financial institutions. The Payment Facilitation Engine overcomes these failings, by helping a buyer through the transaction process, (e.g., by assisting the buyer address procurement issues, such as finding the right seller for a particular set of goods, logistic issues, such as generating the proper customs paperwork for a transaction between a manufacturer in country X and a buyer in country Y, and address payment issues, such as coordinating payment of each of the various entities involved in a particular transaction.
It is to be understood, that the Payment Facilitation Engine may be configured in a variety of implementations in order to meet the particular needs of any number of end users. For the purposes of illustration, aspects of Engine functionality will be described below in the context of a buyer's purchase of and payment for a group of widgets. However, it is to be understood that this example is for non-limiting, illustrative purposes only.
As illustrated in
In
The Engine 100 is configured to build a transaction record that adheres to local import/export regulations associated with a buyer's and/or a manufacturer's side of a transaction (e.g., export laws for a particular country, cargo carrier regulations, goods' inspection regulations). For example, in some implementations, the Engine may be configured to retrieve the correct documents for a particular transaction from the local official offices, for example a Ministry of Commerce 155. If local regulations require inspection of the goods prior to exporting, the Engine may coordinate inspection by an approved inspection firm 145, while the goods are stored at a distribution center 135 or with the Manufacturer 120.
In some implementations, the Engine may also facilitate one or more intermediate steps associated with transporting the goods from the Manufacturer 120 to the buyer 110, such as transferring the goods from distribution center 135 to a short-haul carrier 140 (e.g., by truck or rail service) for delivery to a long haul carrier (e.g., ocean cargo or air freight carrier) 104.
In addition to facilitating transport, the Engine may facilitate compliance with import/export regulations, and/or inspection of the goods involved in the transaction. The Engine 100 accesses the local regulations associated with purchased goods for import into the buyer's country, for example, from US Customs 160 as illustrated in
Once the buyer's goods have been transported to the buyer's country and have passed through customs, the Engine may again assist with coordinating intermediary transportation steps for delivery to the buyer 110 (or a Engine associated/buyer designated distribution center 165 until the buyer is prepared to receive the goods) from a long haul cargo carrier 104, via trucking or rail service 170.
The Engine's 100 components are configured to facilitate and coordinate payments to various entities involved in the transaction. Depending on the parameters of a transaction, the payment facilitation components provides significant flexibility and may be configured in a variety of implementations based on the needs/characteristics of a particular buyer/seller. For example, the Engine may coordinate a transfer of funds between a buyer's bank 178 (or in some implementations an Engine-affiliated bank) and a manufacturer's (seller's) bank 181 or a procurement agent 133 associated with the seller, as described in greater detail in
If the Buyer is an existing/registered user 114, they may enter their login (e.g., ID and password) 116, go to checkout 117 and select the preferred shipping method 118. The Payment Facilitation Engine may then generate a quote summary 119, which may be printed 121. The Buyer may then choose one of two options 122, the first option being to submit the quote for processing 123. The Payment Facilitation Engine may then provide the Buyer with an email confirmation of the processing 124. Alternately, the second option involves to saving the quote for 30 days 126 (or some other set time period) and receiving an email confirmation to that effect 127.
Although
Furthermore, in some implementations, the Engine facilitates transactions for goods that may not necessarily exist at the time the transaction record is created (or accessed). For example, a buyer may be submitting an order for tires to a manufacturer that will be produced and the manufacturer may forward a sample. In some transactions a large number of ordered goods may need to be manufactured in accordance with one or more buyer specifications (alternately, some transactions may also be based on existing goods). As such, a transaction record may have an effective lifespan that may span, days, weeks, months or in some instances, even years. Regardless of the exact duration, it is to be understood that the buyer may log onto the Engine at various points over the lifespan of a transaction record in order to check the status of a transaction record, as well as establish, update and/or effectuate certain aspects or elements of a transaction.
One of the first steps involved in creating and populating a transaction record 203 involves interaction with aspects of a procurement and/or logistics component of the Payment Facilitation Engine. For example, after a buyer logs onto the Engine and indicates that the transaction involves pursuing a new transaction. The Engine procurement components assist a buyer with searching for a particular type of good or service 205. In some implementations, the procurement component is configured to facilitate a variety of search functionality beyond basic searches for goods or services. For example, a buyer may search for a particular good and/or through a catalog of manufacturers, industries, specialty items or a variety of vertical product groupings within an industry (e.g., consumer electronics within a consumer goods industry). The Engine may be used to coordinate transactions between two manufacturers for manufacturing machinery, between a manufacturer and a vendor or middle-man, or any other number of buyer-seller configurations.
In the example illustrated in
However, this may not always be a feasible option based on any number of reasons, such as manufacturing constraints or goods' characteristics. As such, there may be a number of Engine affiliated quality assurance inspectors or other agencies that certify the quality of manufactured ordered goods. Quality assurance inspections may be effectuated at the manufacturer's location or at various points during the shipping process. If a sample is requested, the Engine transmits a sample request to the manufacturer 213 and save the transaction record for subsequent buyer action 215. In various implementations, the Engine may be configured to save a transaction record for a certain duration, during which the estimated transaction costs are held firm (e.g., 30 days). If the buyer has not accepted the quote (or created a purchase order) by the pendancy expiration date of the quote, the Engine deletes the expired quote. A buyer who logs onto the Engine after the expiration of a quote may have to go through the estimate creation process again so that shipping costs, currency exchanges and other transaction expenses can be re-established.
If the buyer is not able to order a sample and wishes to continue with the purchase, the Engine generates a quote or a purchase order 217. The purchase order is transmitted to the buyer for final approval 219. The buyer is provided with a final opportunity to revise order terms 220, before entering into a binding contract for the purchase of goods or services. Once the order terms for a new transaction are approved, the system may transition to a logistics effication stage 210-227 (described in greater detail below).
Depending on a variety of transaction parameters (e.g., the buyer's status, the buyer's credit, whether the buyer has repeatedly used the Engine, the manufacturer involved in the transaction and/or a number of other transaction parameters) the buyer may be provided with an opportunity to lock-in the transaction cost associated with the good faith estimate (or agree to a set cost variation percentage. +−5%). Alternately, the buyer may opt not to lock-in the good faith estimate price and accept the risks that the transaction costs might vary from the good faith estimate. Aspects of establishing the transaction parameters are discussed in greater detail in related applications “APPARATUSES, METHODS AND SYSTEMS FOR CROSS BORDER PROCUREMENT”, Armand Rousso, filed Sep. 28, 2007, Attorney Docket No. 17854-003PC, and “S
In accessing a previous transaction, a buyer may log back onto the Engine after the initial transaction parameters have been established. As in
If the buyer approves the purchase order 219 or if the approved transaction parameters from a retrieved transaction record are valid 206, a binding contract is created and the Engine transitions the transaction record to a Logistics effectuation mode 221. The Engine may be configured to verify that the initial logistics schedule is still viable 223. In an implementation, the Engine may be configured to generate a logistics milestone schedule. The milestone schedule may be incorporated as part of a transaction record and acts as a checklist of important checkpoints during transaction effication, such as when the manufacturer creates and ships the goods to the buyer or the goods pass through US customs (aspects of the milestone schedule will be discussed in greater detail in the LOGISTICS EFFICATION application). Aspects of the logistics verification process 223 involve confirming that various shipping, inspection, goods storage and/or a number of other services that comprise the logistics effication process are still available and in some instances are still available at the initial quoted prices. If the Engine logistics verification fails, the Engine accesses Engine contingency components 225 that facilitate identifying, presenting to a buyer, and in some implementations reserving alternate shipping, inspection and/or storage facilitates or other aspects of the logistics effication.
If the Engine is able to verify the logistics data, the Engine payment facilitation features are accessed 227. The Engine's flexibility is also demonstrated by the various implementations of Engine payment facilitation features or components. For example, the Engine presents available payment options to a buyer 229. The Engine 100 is configured to construct the payment parameters/characteristics to adhere to local financial regulations associated with a buyer's, manufacturer's, and/or associated financial institution's side of a transaction payment (e.g., laws/regulations requiring/forbidding certain types or amounts of payment and/or transactions).
The Engine also determines what, if any, regulations/restrictions are associated with the buyer 274. Restrictions may include currency restrictions, import/export restrictions, country to country bank payment restrictions and/or the like. The Payment Facilitation Engine then determines if any of the associated restrictions forbids one or more payment methods in the retrieved set of possible payment methods 275. If the set includes one or more forbidden payment methods 275, the forbidden payment methods are removed from the set 276. The Payment Facilitation Engine may then determine the costs/fees for the available payment methods 277. The costs and fees may be based on the payment amount, the locations/countries of the buyer and/or manufacturer, the buyer's credit history, the risk involved, the foreign exchange policy of the method, and/or the like. The Payment Facilitation Engine may then order the payment methods according to the determined costs/fees 278 and display some subset of the indicated payment methods to the buyer for selection.
Depending on the implementation, the listing of available payment methods may be customized based on processing the buyer's data, for example a buyer's verified credit rating. Alternately, the Engine may establish a buyer confidence metric based on a buyer's historic Engine use. Alternatively, the payment method(s) may be restricted to those methods to which the manufacturer is amenable. However, in some implementations, the Engine may provide additional options.
The Payment Facilitation Engine determines if the buyer's preferred payment method matches the manufacturer's preferred payment method 283, and if so, the Engine establishes necessary payment structures for effectuating payment from the buyer to the manufacturer 288. For example, if the buyer and manufacturer both indicate that their preferred payment method is a letter of credit, the Payment Facilitation Engine may set up a structure similar to that described in
In some implementations, the Engine may be configured to provide an Engine-driven payment facilitation model 231 (from
The manufacturer's financial institution 181 then confirms the letter of credit with the buyer's financial institution 178 and the Payment Facilitation Engine 100. The Payment Facilitation Engine 100 sends a letter of credit notification to the manufacturer 120 and confirms the manufacturing start date. The manufacturer 120 may then deliver the goods to the buyer 110. Upon receiving the goods, the buyer 110 may make a payment to their financial institution 178. The manufacturer 120 may transmit the appropriate letter of credit collection documents to their financial institution 181 which may forward the collection documents on to the buyer's financial institution 178. The buyer's financial institution may then verify the collection documents and process the buyer's payment.
In contrast to the Engine-driven model, the Engine may facilitate a buyer driven payment facilitation model 233 (from
As the Payment Facilitation Engine may be configured to mediate transactions that ranging from small-scale transactions to large-scale, international, and/or otherwise complex transactions, the Engine may be equipped to implement a purchase registration process comprising a buyer verification procedure.
Customer entered information may, in one embodiment, be analyzed and/or incorporated into marketing database for use in future marketing and targeted sales.
In some embodiments, the Payment Facilitation Engine may generate accounts receivable (A/R) entries for new purchases, as shown in
If the user inputs an invalid industry search term, the Engine may be configured to suggest that the user try again and/or suggest one or more registered alternative industry search term 323. In another implementation, the Engine may be configured to suggest that the user try a Manufacturer search 311 or a products search 308. The Engine may also be configured to suggest one or more search terms based on the underlying industry search term. If the user inputs a valid manufacturer search term 332 the Engine may provide access to a listing of one or more registered manufacturers 335. If the user selects a particular manufacturer from the listing, the Engine may generate an offered goods/services display listing associated with to a particular manufacturer 338. The user may select a specific good 349 in order to view product specification/pricing details 350.
The buyer may select a specific goods/services 308 search. The Engine determines if the buyer entered a valid goods search term 341. If the Engine determines that the search term is invalid, the Engine may generate a suggested manufacturer/industry search term based on the invalid goods search term. Alternately, the Engine may be configured to request the buyer enter a new search term 343. If the buyer has entered a valid product search term, the Engine may provide access to the product database 345 by generating and displaying a goods search result 347. For example, the Engine may display a search result listing that includes exact product search result matches and in some implementations Engine generated related product search results. The buyer may select a particular good 349 for inclusion as part of a purchase shopping cart, potential product catalog offering and/or simply to view product specification/pricing details 350. As part of the product display component, the buyer is presented with the option of conducting additional searches or starting the search over 348.
In one Engine implementation, the product characteristics display module coordinates with the logistics components to determine and display product specifications, as well as product pricing and shipping details. In another Engine implementation, the procurement component transfers a product identifier (e.g., a manufacturer's product SKU value) to Engine logistics components to generate product pricing and shipping details according to a registered buyer's preferences 355. The Engine may be configured to display these details based on a registered user's established preferences 361 or as an Engine default logistics solution 364.
By way of example only, a registered buyer may establish a preference that defaults product data display parameters to display shipping charges based on a least expensive shipping solution, a fastest shipping solution, a balanced shipping solution or a number of other registered buyer preference options 361. Alternately, for a non-registered buyer, the Engine may default to displaying a least expensive shipping 364 (or other type of default solution) and present additional shipping options as alternatives for the buyer to select (as shown as display widget 3C).
It is to be noted that as illustrated in the widget
The pricing data associated with the various shipping solutions are determined by the Engine logistics components, which may be populated based on current shipping rates/schedules, real-time quote requests and/or previous Engine transaction data associated with a number of carriers. After the transaction record is populated with the pricing data, the transaction record may be transferred by the procurement module 102 for display to the buyer 367.
Depending on the particular implementation, the procurement module 102 may be configured to display product transaction data in a number of ways based on the needs of a particular buyer or seller or the characteristics associated with a good/service 370. As such, the Engine may generate an interactive Graphical User Interface pricing widget 373 that displays shipping costs based on the buyer interacting with the widget to set values for the various pricing factors 364 (e.g. volume discounts, alternate shipping options). Alternately, the Engine may generate a product pricing matrix 375 that displays various text options available for a particular good or service.
For example, often a buyer working with a manufacturer may be interested in a significant volume of a particular good. Depending on the size and make-up of the particular good the buyer is interested in, the shipping costs may vary across a broad range. Ultimately, this information, in coordination with the packaging data may be used to derive one or more shipping pricing points based on several standardized or customized quantities of goods.
If the buyer requests a pricing widget 373 (illustrated in
In some implementations, the Engine is configured with a buyer's chat module, in which a buyer may attempt to negotiate additional buyer's discounts based on repeat business purchases, volume discounts or a number of other factors. If the product pricing terms are acceptable, the Engine may generate a good faith estimate and/or a product quote request 384. In some implementations, the buyer may be provided with the option to order a sample of the good (discussed in greater detail in
If the buyer is satisfied with the transaction details, the buyer may opt to generate a product order 390. Depending on the actual implementation, the buyer may print out, sign and date a product quote request. The signed/dated product quote request may then be transmitted back to the Engine via email (or in some instances fax the executed quote request to an Engine administrator). The Engine administrator may verify the buyer quote date, confirms the logistics information with the manufacturer, shipping carriers, inspectors, or other entities involved in the transaction and then can generate a purchase order—as a binding contract. However, before returning an executed the quote request, the buyer may be provided with an opportunity to pursue obtaining a sample 387.
The Engine also manages active pending orders and cull orders that have become stagnant. For example, most transactions have a transaction lifecycle. Accordingly, the Engine may include a stagnation date for each transaction as part of the transaction record. The stagnation date is a maximum transaction inactivity period (e.g., 30 days) after which the transaction record is transitioned to an inactive transaction queue for the buyer. In the inactive transition queue, the various product/shipping transaction parameters are saved, but the pricing points may have to be re-established. The transaction record may be saved on the inactive transaction queue without further update from the buyer for a predetermined period of time (e.g., 15 days) before the transaction record is deleted. The transaction inactivity period may be extended under certain circumstances. For example, the transaction inactivity period may be extended when a registered buyer orders a product sample and the transaction inactivity period may be extended by the number of days associated with shipping a sample to the buyer. In some instances, the transaction inactivity period may be further extended by a product sample evaluation period (e.g., 3 days). In the implementation of the Engine illustrated in
In contrast, if the ‘sample available’ parameter indicates that a sample is not available for the particular product. The Engine may present a manufacturer's specification warranty or an Engine certification for a particular manufacturer 410. In some implementations, the Engine may be configured to maintain a manufacturer rating system that allows buyers to provide feedback describing their experience with a particular manufacturer for a given transaction 410. As part of the offered services facilitated by the Engine, the Engine may provide a listing of Engine-affiliated or independent third party product inspectors 412. These inspectors may provide a variety of quality assurance services, including inspecting the specific products and/or the production facilities. The Engine may be configured to adjust the transaction inactivity period if a product/facility inspection is coordinated.
The buyer may access the transaction record after receiving the product sample or the quality assurance report 435 before the expiration of the transaction inactivity period. As the expiration date approaches 440, the Engine may generate and send an email to the buyer advising that the transaction period is about to expire and that the transaction may be shifted to the inactive transaction queue or in some implementations deleted 450. The buyer may access the transaction record and request addition time to evaluate whether to proceed with the transaction. Alternately, the buyer may initiate a final quote request, approving the initial terms associated with the transaction 445. Receiving a final quote request, the Engine initiates the quote verification discussed in
After the payment method is established, the buyer is provided an opportunity to give the quote a final review 524. If the buyer does not confirm the final quote, the Engine may present the buyer with the opportunity to select various parameters for modification 527, as well as update the selected parameters 530 and reconfirm the final quote. Once the quote request has been finalized and confirmed by the buyer 524, the Engine generates and transmits a copy of the finalized quote request to the buyer 531. The buyer, in turn, executes the finalized quote request and transmits the executed request back to the Engine. The Engine receives an indication that the executed request has been received, saves a copy of the executed/authorized order 532 and transmits the transaction record associated with the authorized order to the Engine logistics components to initiate logistics effication processes 533.
In one implementation, a PDF and/or other electronic copy of the sales order may be generated and supplied to the buyer, or a hard copy may be generated from the electronic copy and provided to the buyer. The printed copy of the sales order may, in one implementation, be printed, signed, and faxed to the Payment Facilitation Engine and/or a Payment Facilitation Engine administrator immediately by the buyer 548 or, in an alternate implementation, the buyer may be allowed a specified period of time (e.g., 7 days) in which to return the signed sales order 549. In addition to faxing, the sales order may be returned by a wide variety of other means in various alternative implementations, including postal mail, scanning and returning an electronic copy, and/or the like. Finally, when the signed sales order is received, the Payment Facilitation Engine may provide the customer with a set of terms and conditions for review 552, which the customer may then decide to accept in order to finalize the purchase. At this time the Engine saves a record of the binding purchase order and transfers a copy of the transaction record (which may include the binding purchase order) to logistics components associated with the Engine.
After an initial quote has been generated but before the purchase is finalized, a verification analysis may be performed in order to finalize the quote.
For a valid quote, the customer is provided with the opportunity to finalize and accept the quote 558, and an accepted quote may trigger the purchase registration process 559 and/or query information supplied by a previously completed purchase registration and/or buyer verification process. Buyer identification and/or verification information may be extracted from the purchase registration process information and used to perform a check of the buyer's reliability, credit worthiness, purchase history, business background, and/or the like. For example, in one implementation, the Payment Facilitation Engine may perform a Dun & Bradstreet check on the buyer based on buyer identification information 560. Subsequent to the check, Engine records are updated to reflect the buyer's status and/or their current interaction with the Engine 561, and a Payment Facilitation Engine validation process may be undertaken 562 to assess the outcome of the buyer check and/or to apply an Engine rule 563 (e.g. a rule that would determine whether a buyer has credit, what the buyer's credit is, below a certain threshold credit score, or would otherwise identify the buyer as a potential credit-risk the Engine may require collateral). As another example, a buyer credit score may be analyzed to determine whether it is sufficiently high to warrant a particular sale based on credit. For a good rating with respect to the Engine rule, the terms are set based on the quote and the transaction is allowed to proceed 564. Otherwise, for a low rating, an alternative set of terms may be generated to take into account the buyer's status and/or a message may be conveyed to the buyer to indicate the circumstances and determine an appropriate course of action thereafter 565.
In the event that the transaction record indicates the transaction is not a re-order, the logistics components are used to establish various aspects of the logistics data parameters 618. Depending on the implementation, the logistics data parameters may include a shipping carrier, product pick-up date, product delivery date, intermediary storage facilities, Engine affiliated or third party independent product inspection agencies, as well as customs data, such as product tariff category and expenses associated with the actual tariff. The logistics determination components coordinate providing a variety of pricing options for the buyer. In some implementations, a registered buyer may establish certain shipping preferences during the registration process (e.g., default to display least expensive shipping solution or another type of shipping solution). Accordingly, the logistics components determine whether the buyer is a registered with the Engine and has established logistics shipping preferences. If the buyer has not registered with the Engine, the Engine may transition to a buyer registration process.
As part of an implementation of the logistics (re-)establishment process, the Engine establishes (or re-establishes) the initial order parameters 618. If the buyer has established transaction parameters, the Engine may populate the initial transaction parameters optimizing the parameters for expedited delivery 621, optimizing for the least expensive parameters 624, and/or in some implementations generating a balanced set of parameters 627. The buyer may review the initial parameters and adjust a transaction parameter set (or in some instances, individual transaction parameters) 630. In some implementations, the Engine verifies that the seller's country and the buyer's country are viable trading partners 633. If the trading partners are determined to not be viable, the Engine may conduct an additional product search based on the buyer's initially requested product and suggest alternate sellers 651. Alternately, the Engine may conduct the verification during the procurement (products/manufacturer/search) search, wherein trading partners that are not viable may be excluded from the search results.
If the buyer and seller are determined to be viable trading partners, the Engine accesses a customs/tariff database and retrieves a tariff quote 636 for the buyer's requested product. Depending on the type of product or based on a buyer's request, the transaction may involve certain inspection costs 639. The logistics components update these elements of the transaction record and may transmit the record back to the procurement components for incorporation with a product pricing matrix (illustrated in
As part of the logistics effication, the system takes a finalized good faith estimate or a binding purchase order and places the actual order with the manufacturer, books the shipping carriers, coordinates inspections, and/or customs logistics and finalizes various aspects of the transaction. This process is described in greater detail in related application entitled “S
The Engine populates the logistics documents the corresponding transaction parameters from the transaction record 671. In some implementations, the Engine may require that the generated documents are reviewed by an Engine administrator or an Engine procurement agent 673. If the Engine does not receive a validity confirmation indicator that documents are valid, the Engine may update necessary parameters. If the Engine receives a validity confirmation indicator that the documents are valid, the Engine processes the transaction record associated with the transaction and generates a logistics watchdog milestone schedule 675. The logistics watchdog milestone is a checklist listing of the various steps involved with transitioning the goods from the manufacturer to the buyer. The execution of the Engine transaction milestone checklist involves monitoring the transaction status, generating alerts and trouble-shooting issues that arise from a defective performance. The buyer may be provided with an option to receive a system alert as various steps of the transaction are completed or log onto the system to view a current status update for a particular transaction.
In the event that the delays are not remedied 686, the Engine transitions to a default/contingency mode 687. Instead, if the delays are remedied the Engine updates the estimated milestone dates 688 for the remaining milestones within the milestone checklist. The Engine also transmits an alert(s) to the remaining logistics entities 689 to advise that the previous action dates (e.g., pickup of the goods from a shipping carrier) have been shifted. The Engine then transitions to the next checklist milestone event 690. In the example illustrated in
After the milestone checklist has been completed 695, the Engine updates the transaction record to indicate that the transaction has been completed 696. The Engine indexes and saves the completed transaction record 697, the logistics documentation 698, as well as the any watchdog exceptions that have occurred 699. The Engine can be configured to utilize the saved data in order to optimize the buyer's transaction experience. For example, if the transaction is a repeat order and the buyer approves the terms of the previous transaction, the buyer may pursue a one-click re-up, where the procurement process is streamlined and the buyer can simply select a “re-up” option.
The Engine retrieves the logistics data, establishes and effectuates the transaction based on the saved transaction data (product, shipping, inspection, and customs data) from the previous transaction. Another example of the Engine utilizing the saved transaction data involves categorizing the milestone exceptions into logistics entity performance metrics (e.g., rating for various manufacturers, shipping carriers, and/or product inspectors). The Engine may also incorporate a direct feedback component for a buyer to rate the various entities associated with executing a transaction.
The Engine verifies that the estimated transaction costs are within the buyer's available line of credit 721 (or the buyer selected payment option is a viable for the buyer, the Engine, and/or the manufacturer/vendor). Assuming the buyer's payment is viable, the Engine may be configured to update and/or credit the buyer's Engine account 727. In the Engine driven payment model, the Engine may determine whether an entity milestone action has been completed 728. If the action has not been completed, the Engine will not effectuate payment and will wait until the action is complete 729.
After the milestone action has been completed, the Engine effectuates payment to the entity 730. For example, the Engine may initiate funds transfer for payment of tariffs/customs duties 731, 3rd party logistics entities 734, the manufacturer and/or the manufacturer's payment agent 737, the cargo/shipping carriers involved in the transaction 740 and/or an Engine commission 743. After the funds transfer is initiated, the Engine determines whether there are remaining disbursements to be made 747. If the transaction is complete and there are no remaining there are remaining disbursements, the Engine finalizes the payment effication data and in some implementations prepares the data for an Engine data audit 749. If the Engine determines that there are additional disbursements, the Engine verifies that there are still sufficient funds for the remaining disbursements 748. The Engine transitions to a default/contingency state and generates a contingency alert 725 if sufficient funds do not exist. The Engine alert may be transmitted to a buyer, an Engine administrator and/or in some instances remaining transaction entities 724. If there are sufficient funds for subsequent disbursements, the Engine transitions to verify whether the next entity milestone has been completed 728.
Generally, the buyer is responsible for effectuating payment to the various transaction entities in the buyer-driven model. As such, the Engine may be configured to generate 759 and forward a series of payment invoices for each component of a given transaction to the buyer 761 (e.g., separate payment invoice(s) for the manufacturer, the short haul carrier, the long haul carrier, etc. . . . ). The buyer may receive a booklet of invoices and a corresponding payment schedule. In this implementation, the buyer then transmits payment to each transaction entity according to the payment schedule 764. As illustrated in
The Engine may be configured to verify that each transaction entity has received payment from the buyer 777 to fulfill assurance 750 responsibilities and/or maintain data auditing/reporting records 779. If the Engine confirms the transaction entity has been paid, the Engine updates the transaction record with a payment confirmation indicator 779. In contrast, if the Engine is not able to confirm that the buyer has effectuated the payment transfer, the Engine may determine whether the buyer has registered for payment assurance 782. If the buyer has registered for payment assurance and the payment transfer is due, the Engine may be configured to step in for the buyer and effectuate payment based on the buyer's Engine-associated line of credit 785. If the buyer has not registered for assurance, the Engine may generate and transmit an alert to the buyer indicating that the payment is due (or past due) 788. In some instances the Engine may transition to a default/contingency state, where subsequent transaction entities are alerted to a possible default condition 791. For example, if the manufacturer's payment has not been effectuated and the buyer has not registered for assurance, the Engine may generate and transmit an alert to the long haul carrier indicating that there may be transaction delays and/or default.
Once the Payment Facilitation Engine has determined the appropriate payment details 840, the Engine monitors the transaction record for achievement of fulfillment terms associated with outstanding required payments 850. Fulfillment terms may include triggering events, such as those shown in
If the Payment Facilitation Engine determines that one or more of the fulfillment terms are met 860, the Engine determines the payment facilitation parameters 865. While some transactions may be completely system driven or completely buyer (or other payor) driven, other transactions may include a mix of system driven payments along with buyer driven payments. If the payment facilitation parameters 865 indicate a system driven approach, the Payment Facilitation Engine manages payment collection/distribution for the corresponding required payment 870 and updates the transaction record 880. If the payment facilitation parameters 865 indicate a buyer driven approach, the Engine notifies the buyer that a payment is due 875, and may also provide the buyer with an invoice and/or payment coupon. Depending on the implementation, this notification may be made in a variety of ways, including email, postal mail, voice message, text message, SMS, pop-up notification, and/or the like. The Engine monitors the payment status 876, for example, by communicating with the payee and/or payor. If no payment is made, the Payment Facilitation Engine may then issue a reminder 878 and continues to monitor the payment status 876. Once the Engine determines that the payment has been made 877, the transaction record is updated 880. The Payment Facilitation Engine then determines if there are any remaining outstanding payments, and if so, continues to monitor the transaction record for achievement of the fulfillment terms associated with the remaining outstanding required payments 850.
In another implementation, the Engine may process transaction records to extract data for Engine usage. For example, the processed data may also be used to build service provider catalogs for a variety of service providers across a variety of industries, goods and/or geographic locations or countries, such as a listing of rail carriers that provide service for transporting goods from the port of New Orleans to areas in the Mid-West United States. As another example, the Engine may provide buyer(s) or seller(s) with the ability to rate the performance of one or more of the transaction entities involved in a particular transaction. Over time, this data may be aggregated to create a significant resource that may be used as another search metric to supplement the procurement processes (e.g., a buyer can conduct a search for wine glasses produced by 4-starr manufacturers). As yet another example, transaction data may also be utilized to build Engine derived transaction entity confidence metrics related to buyers, sellers, or other transaction entities (e.g., long/short haul carriers, 3rd party logistics entities, vendors, retailers or any other entity involved in transactions). In an example, the Engine may provide performance metrics that gives the buyer the opportunity to select between a particular long haul carrier that has a 97% on-time delivery performance rating or a 67% on-time delivery performance rating.
In order to determine these types of metrics, the Engine may be configured to conduct data auditing functionality at various points during a transaction. For example, the Engine may analyze how well particular entities perform, when compared to the transaction milestone schedule.
Accordingly, once the auditing parameters are extracted 1005, the Engine conducts product order diagnostics 1010 to determine whether exception flags have been generated. If the Engine identifies an exception flag, the invalid parameter is isolated and identified 1015. In some implementations, data auditing may be conducted dynamically throughout the transaction or after each stage of the transaction is complete. If the exception relates to a correctable informality, such as the manufacturer providing an inconsistent product shipping term, the Engine may be configured to identify correctable informalities 1020 and determines the appropriate steps to correct the informality 1030 and update/save the transaction record or notifies a Engine administrator 1025 who may be able to assist with saving a transaction from a default state. Similar processing may be run for logistics diagnostics data 1040, as well as payment facilitation data 1070. Regardless of whether the data is updated dynamically or when the transaction has been completed, the finalized transaction record 897 data may be used to the update stored entity performance metrics and/or buyer/seller entity ratings 899.
In a further embodiment, when the Engine is employed to facilitate the mechanics of payment, a payment matrix may be utilized. The payment matrix employs interrelated rules and data sets pertinent to the exchange of payments and transfer of financial instrument as between seller, buyer and any intermediary financial institutions; i.e., pertinent to payment. As such, the Engine employs the payment matrix to facilitate the identification of acceptable forms of monetary transfer, the connection of buyer/seller financial information (e.g., bank accounts, credit cards, native currency, etc.) to any intermediary financial vehicles, security of payments (e.g., through letters of credit, escrow accounts, security agreements, etc.), and/or the like based on intermediary financial information (e.g., cost of money, interest rates, availability, banks, etc.) and country regulations. In one embodiment, the payment matrix may be used by the Engine to determine and pre-populate the appropriate financial instruments for the goods in question and provide all the requisite invoicing information to the parties. In another embodiment, previous outside financial agents and/or institutions are employed. In yet another embodiment, the Engine discerns differences in currency as between buyers and sellers and automatically renders all financial transactions in the user's native currency.
The Engine may also be equipped to manage fluctuations in exchange rates. For example, at the time a purchase order is made, the exchange rate may be one U.S. Dollar to eight Chinese Yuan. However, over the course of the fulfillment and delivery of the order, the exchange rate may fluctuate (e.g., one U.S. Dollar to seven Chinese Yuan). Depending on the implementation, the Engine may lock in the exchange rate for the purchase at the rate at the time the purchase order was signed. However, as there may be multiple other parties (e.g., shippers, customs, third party service providers, etc.), the fluctuation in exchange rates may cause fluctuations in the cost to the buyer and/or manufacturer. In one embodiment, the Engine may overcome this issue by setting the amount to be paid for services rendered in the terms and conditions of the service agreement. Additionally, the Engine may adjust the fees/charges paid by the buyer to cover expected fluctuations, and in a further embodiment, the Engine may refund part of the fees/charges if the anticipated fluctuations in currency are not realized. In another embodiment, the Engine may utilize currency futures and/or other investments to mitigate risk associated with the transaction. The cost for such a strategy may be factored into the determination of fees/charges.
Payment Facilitation Engine Controller
Typically, users, which may be people and/or other systems, engage information technology systems (e.g., commonly computers) to facilitate information processing. In turn, computers employ processors to process information; such processors are often referred to as central processing units (CPU). A common form of processor is referred to as a microprocessor. CPUs use communicative signals to enable various operations. Such communicative signals may be stored and/or transmitted in batches as program and/or data components facilitate desired operations. These stored instruction code signals may engage the CPU circuit components to perform desired operations. A common type of program is a computer operating system, which, commonly, is executed by CPU on a computer; the operating system enables and facilitates users to access and operate computer information technology and resources. Common resources employed in information technology systems include: input and output mechanisms through which data may pass into and out of a computer; memory storage into which data may be saved; and processors by which information may be processed. Often information technology systems are used to collect data for later retrieval, analysis, and manipulation, commonly, which is facilitated through a database program. Information technology systems provide interfaces that allow users to access and operate various system components.
In one embodiment, the Payment Facilitation Engine controller 1101 may be connected to and/or communicate with entities such as, but not limited to: one or more users from user input devices 1111; peripheral devices 1112; a cryptographic processor device 1128; and/or a communications network 1113.
Networks are commonly thought to comprise the interconnection and interoperation of clients, servers, and intermediary nodes in a graph topology. It should be noted that the term “server” as used throughout this disclosure refers generally to a computer, other device, program, or combination thereof that processes and responds to the requests of remote users across a communications network. Servers serve their information to requesting “clients.” The term “client” as used herein refers generally to a computer, other device, program, or combination thereof that is capable of processing and making requests and obtaining and processing any responses from servers across a communications network. A computer, other device, program, or combination thereof that facilitates, processes information and requests, and/or furthers the passage of information from a source user to a destination user is commonly referred to as a “node.” Networks are generally thought to facilitate the transfer of information from source points to destinations. A node specifically tasked with furthering the passage of information from a source to a destination is commonly called a “router.” There are many forms of networks such as Local Area Networks (LANs), Pico networks, Wide Area Networks (WANs), Wireless Networks (WLANs), etc. For example, the Internet is generally accepted as being an interconnection of a multitude of networks whereby remote clients and servers may access and interoperate with one another.
The Payment Facilitation Engine controller 1101 may be based on common computer systems that may comprise, but are not limited to, components such as: a computer systemization 1102 connected to memory 1129.
Computer Systemization
A computer systemization 1102 may comprise a clock 1130, central processing unit (CPU) 1103, a read only memory (ROM) 1106, a random access memory (RAM) 1105, and/or an interface bus 1107, and most frequently, although not necessarily, are all interconnected and/or communicating through a system bus 1104. Optionally, the computer systemization may be connected to an internal power source 1186. Optionally, a cryptographic processor 1126 may be connected to the system bus. The system clock typically has a crystal oscillator and provides a base signal. The clock is typically coupled to the system bus and various clock multipliers that will increase or decrease the base operating frequency for other components interconnected in the computer systemization. The clock and various components in a computer systemization drive signals embodying information throughout the system. Such transmission and reception of signals embodying information throughout a computer systemization may be commonly referred to as communications. These communicative signals may further be transmitted, received, and the cause of return and/or reply signal communications beyond the instant computer systemization to: communications networks, input devices, other computer systemizations, peripheral devices, and/or the like. Of course, any of the above components may be connected directly to one another, connected to the CPU, and/or organized in numerous variations employed as exemplified by various computer systems.
The CPU comprises at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron and/or Opteron; IBM and/or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s). The CPU interacts with memory through signal passing through conductive conduits to execute stored signal program code according to conventional data processing techniques. Such signal passing facilitates communication within the Payment Facilitation Engine controller and beyond through various interfaces. Should processing requirements dictate a greater amount speed, parallel, mainframe and/or super-computer architectures may similarly be employed. Alternatively, should deployment requirements dictate greater portability, smaller Personal Digital Assistants (PDAs) may be employed.
Power Source
The power source 1186 may be of any standard form for powering small electronic circuit board devices such as the following power cells: alkaline, lithium hydride, lithium ion, lithium polymer, nickel cadmium, solar cells, and/or the like. Other types of AC or DC power sources may be used as well. In the case of solar cells, in one embodiment, the case provides an aperture through which the solar cell may capture photonic energy. The power cell 1186 is connected to at least one of the interconnected subsequent components of the Payment Facilitation Engine thereby providing an electric current to all subsequent components. In one example, the power source 1186 is connected to the system bus component 1104. In an alternative embodiment, an outside power source 1186 is provided through a connection across the I/O 1108 interface. For example, a USB and/or IEEE 1394 connection carries both data and power across the connection and is therefore a suitable source of power.
Interface Adapters
Interface bus(ses) 1107 may accept, connect, and/or communicate to a number of interface adapters, conventionally although not necessarily in the form of adapter cards, such as but not limited to: input output interfaces (I/O) 1108, storage interfaces 1109, network interfaces 1110, and/or the like. Optionally, cryptographic processor interfaces 1127 similarly may be connected to the interface bus. The interface bus provides for the communications of interface adapters with one another as well as with other components of the computer systemization. Interface adapters are adapted for a compatible interface bus. Interface adapters conventionally connect to the interface bus via a slot architecture. Conventional slot architectures may be employed, such as, but not limited to: Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and/or the like.
Storage interfaces 1109 may accept, communicate, and/or connect to a number of storage devices such as, but not limited to: storage devices 1114, removable disc devices, and/or the like. Storage interfaces may employ connection protocols such as, but not limited to: (Ultra) (Serial) Advanced Technology Attachment (Packet Interface) ((Ultra) (Serial) ATA(PI)), (Enhanced) Integrated Drive Electronics ((E)IDE), Institute of Electrical and Electronics Engineers (IEEE) 1394, fiber channel, Small Computer Systems Interface (SCSI), Universal Serial Bus (USB), and/or the like.
Network interfaces 1110 may accept, communicate, and/or connect to a communications network 1113. Through a communications network 150, the Payment Facilitation Engine controller is accessible through remote clients 1133b (e.g., computers with web browsers) by users 1133a. Network interfaces may employ connection protocols such as, but not limited to: direct connect, Ethernet (thick, thin, twisted pair 10/100/1000 Base T, and/or the like), Token Ring, wireless connection such as IEEE 802.11a-x, and/or the like. A communications network may be any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), I-mode, and/or the like); and/or the like. A network interface may be regarded as a specialized form of an input output interface. Further, multiple network interfaces 1110 may be used to engage with various communications network types 1113. For example, multiple network interfaces may be employed to allow for the communication over broadcast, multicast, and/or unicast networks.
Input Output interfaces (I/O) 1108 may accept, communicate, and/or connect to user input devices 1111, peripheral devices 1112, cryptographic processor devices 1128, and/or the like. I/O may employ connection protocols such as, but not limited to: Apple Desktop Bus (ADB); Apple Desktop Connector (ADC); audio: analog, digital, monaural, RCA, stereo, and/or the like; IEEE 1394a-b; infrared; joystick; keyboard; midi; optical; PC AT; PS/2; parallel; radio; serial; USB; video interface: BNC, coaxial, composite, digital, Digital Visual Interface (DVI), RCA, RF antennae, S-Video, VGA, and/or the like; wireless; and/or the like. A common output device is a television set, which accepts signals from a video interface. Also, a video display, which typically comprises a Cathode Ray Tube (CRT) or Liquid Crystal Display (LCD) based monitor with an interface (e.g., DVI circuitry and cable) that accepts signals from a video interface, may be used. The video interface composites information generated by a computer systemization and generates video signals based on the composited information in a video memory frame. Typically, the video interface provides the composited video information through a video connection interface that accepts a video display interface (e.g., an RCA composite video connector accepting an RCA composite video cable; a DVI connector accepting a DVI display cable, etc.).
User input devices 1111 may be card readers, dongles, finger print readers, gloves, graphics tablets, joysticks, keyboards, mouse (mice), remote controls, retina readers, trackballs, trackpads, and/or the like.
Peripheral devices 1112 may be connected and/or communicate to I/O and/or other facilities of the like such as network interfaces, storage interfaces, and/or the like. Peripheral devices may be audio devices, cameras, dongles (e.g., for copy protection, ensuring secure transactions with a digital signature, and/or the like), external processors (for added functionality), goggles, microphones, monitors, network interfaces, printers, scanners, storage devices, video devices, video sources, visors, and/or the like.
It should be noted that although user input devices and peripheral devices may be employed, the Payment Facilitation Engine controller may be embodied as an embedded, dedicated, and/or monitor-less (i.e., headless) device, wherein access would be provided over a network interface connection.
Cryptographic units such as, but not limited to, microcontrollers, processors 1126, interfaces 1127, and/or devices 1128 may be attached, and/or communicate with the Payment Facilitation Engine controller. A MC68HC16 microcontroller, commonly manufactured by Motorola Inc., may be used for and/or within cryptographic units. Equivalent microcontrollers and/or processors may also be used. The MC68HC16 microcontroller utilizes a 16-bit multiply-and-accumulate instruction in the 16 MHz configuration and requires less than one second to perform a 512-bit RSA private key operation. Cryptographic units support the authentication of communications from interacting agents, as well as allowing for anonymous transactions. Cryptographic units may also be configured as part of CPU. Other commercially available specialized cryptographic processors include VLSI Technology's 33 MHz 6868 or Semaphore Communications' 40 MHz Roadrunner.
Memory
Generally, any mechanization and/or embodiment allowing a processor to affect the storage and/or retrieval of information is regarded as memory 1129. However, memory is a fungible technology and resource, thus, any number of memory embodiments may be employed in lieu of or in concert with one another. It is to be understood that the Payment Facilitation Engine controller and/or a computer systemization may employ various forms of memory 1129. For example, a computer systemization may be configured wherein the functionality of on-chip CPU memory (e.g., registers), RAM, ROM, and any other storage devices are provided by a paper punch tape or paper punch card mechanism; of course such an embodiment would result in an extremely slow rate of operation. In a typical configuration, memory 1129 will include ROM 1106, RAM 1105, and a storage device 1114. A storage device 1114 may be any conventional computer system storage. Storage devices may include a drum; a (fixed and/or removable) magnetic disk drive; a magneto-optical drive; an optical drive (i.e., CD ROM/RAM/Recordable (R), ReWritable (RW), DVD R/RW, etc.); an array of devices (e.g., Redundant Array of Independent Disks (RAID)); and/or other devices of the like. Thus, a computer systemization generally requires and makes use of memory.
Component Collection
The memory 1129 may contain a collection of program and/or database components and/or data such as, but not limited to: operating system component(s) 1115 (operating system); information server component(s) 1116 (information server); user interface component(s) 1117 (user interface); Web browser component(s) 1118 (Web browser); database(s) 1119; mail server component(s) 1121; mail client component(s) 1122; cryptographic server component(s) 1120 (cryptographic server); the Payment Facilitation Engine component(s) 1135; and/or the like (i.e., collectively a component collection). These components may be stored and accessed from the storage devices and/or from storage devices accessible through an interface bus. Although non-conventional program components such as those in the component collection, typically, are stored in a local storage device 1114, they may also be loaded and/or stored in memory such as: peripheral devices, RAM, remote storage facilities through a communications network, ROM, various forms of memory, and/or the like.
Operating System
The operating system component 1115 is an executable program component facilitating the operation of the Payment Facilitation Engine controller. Typically, the operating system facilitates access of I/O, network interfaces, peripheral devices, storage devices, and/or the like. The operating system may be a highly fault tolerant, scalable, and secure system such as: Apple Macintosh OS X (Server); AT&T Plan 9; Be OS; Unix and Unix and Unix-like system distributions (such as AT&T's UNIX; Berkley Software Distribution (BSD) variations such as FreeBSD, NetBSD, OpenBSD, and/or the like; Linux distributions such as Red Hat, Ubuntu, and/or the like); and/or the like operating systems. However, more limited and/or less secure operating systems also may be employed such as Apple Macintosh OS, IBM OS/2, Microsoft DOS, Microsoft Windows 2000/2003/3.1/95/98/CE/Millennium/NT/Vista/XP (Server), Palm OS, and/or the like. An operating system may communicate to and/or with other components in a component collection, including itself, and/or the like. Most frequently, the operating system communicates with other program components, user interfaces, and/or the like. For example, the operating system may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. The operating system, once executed by the CPU, may enable the interaction with communications networks, data, I/O, peripheral devices, program components, memory, user input devices, and/or the like. The operating system may provide communications protocols that allow the Payment Facilitation Engine controller to communicate with other entities through a communications network 1113. Various communication protocols may be used by the Payment Facilitation Engine controller as a subcarrier transport mechanism for interaction, such as, but not limited to: multicast, TCP/IP, UDP, unicast, and/or the like.
Information Server
An information server component 1116 is a stored program component that is executed by a CPU. The information server may be a conventional Internet information server such as, but not limited to Apache Software Foundation's Apache, Microsoft's Internet Information Server, and/or the. The information server may allow for the execution of program components through facilities such as Active Server Page (ASP), ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, Common Gateway Interface (CGI) scripts, Java, JavaScript, Practical Extraction Report Language (PERL), Hypertext Pre-Processor (PHP), pipes, Python, WebObjects, and/or the like. The information server may support secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), messaging protocols (e.g., America Online (AOL) Instant Messenger (AIM), Application Exchange (APEX), ICQ, Internet Relay Chat (IRC), Microsoft Network (MSN) Messenger Service, Presence and Instant Messaging Protocol (PRIM), Internet Engineering Task Force's (IETF's) Session Initiation Protocol (SIP), SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE), open XML-based Extensible Messaging and Presence Protocol (XMPP) (i.e., Jabber or Open Mobile Alliance's (OMA's) Instant Messaging and Presence Service (IMPS)), Yahoo! Instant Messenger Service, and/or the like. The information server provides results in the form of Web pages to Web browsers, and allows for the manipulated generation of the Web pages through interaction with other program components. After a Domain Name System (DNS) resolution portion of an HTTP request is resolved to a particular information server, the information server resolves requests for information at specified locations on the Payment Facilitation Engine controller based on the remainder of the HTTP request. For example, a request such as http://123.124.125.126/myInformation.html might have the IP portion of the request “123.124.125.126” resolved by a DNS server to an information server at that IP address; that information server might in turn further parse the http request for the “/myInformation.html” portion of the request and resolve it to a location in memory containing the information “myInformation.html.” Additionally, other information serving protocols may be employed across various ports, e.g., FTP communications across port 21, and/or the like. An information server may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the information server communicates with the Payment Facilitation Engine database 1119, operating systems, other program components, user interfaces, Web browsers, and/or the like.
Access to the Payment Facilitation Engine database may be achieved through a number of database bridge mechanisms such as through scripting languages as enumerated below (e.g., CGI) and through inter-application communication channels as enumerated below (e.g., CORBA, WebObjects, etc.). Any data requests through a Web browser are parsed through the bridge mechanism into appropriate grammars as required by the Payment Facilitation Engine. In one embodiment, the information server would provide a Web form accessible by a Web browser. Entries made into supplied fields in the Web form are tagged as having been entered into the particular fields, and parsed as such. The entered terms are then passed along with the field tags, which act to instruct the parser to generate queries directed to appropriate tables and/or fields. In one embodiment, the parser may generate queries in standard SQL by instantiating a search string with the proper join/select commands based on the tagged text entries, wherein the resulting command is provided over the bridge mechanism to the Payment Facilitation Engine as a query. Upon generating query results from the query, the results are passed over the bridge mechanism, and may be parsed for formatting and generation of a new results Web page by the bridge mechanism. Such a new results Web page is then provided to the information server, which may supply it to the requesting Web browser.
Also, an information server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.
User Interface
The function of computer interfaces in some respects is similar to automobile operation interfaces. Automobile operation interface elements such as steering wheels, gearshifts, and speedometers facilitate the access, operation, and display of automobile resources, functionality, and status. Computer interaction interface elements such as check boxes, cursors, menus, scrollers, and windows (collectively and commonly referred to as widgets) similarly facilitate the access, operation, and display of data and computer hardware and operating system resources, functionality, and status. Operation interfaces are commonly called user interfaces. Graphical user interfaces (GUIs) such as the Apple Macintosh Operating System's Aqua, IBM's OS/2, Microsoft's Windows 2000/2003/3.1/95/98/CE/Millennium/NT/Vista (i.e., Aero)/XP, or Unix's X-Windows (e.g., which may include additional Unix graphic interface libraries and layers such as K Desktop Environment (KDE), mythTV and GNU Network Object Model Environment (GNOME)), provide a baseline and means of accessing and displaying information graphically to users.
A user interface component 1117 is a stored program component that is executed by a CPU. The user interface may be a conventional graphic user interface as provided by, with, and/or atop operating systems and/or operating environments such as already discussed. The user interface may allow for the display, execution, interaction, manipulation, and/or operation of program components and/or system facilities through textual and/or graphical facilities. The user interface provides a facility through which users may affect, interact, and/or operate a computer system. A user interface may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the user interface communicates with operating systems, other program components, and/or the like. The user interface may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.
Web Browser
A Web browser component 1118 is a stored program component that is executed by a CPU. The Web browser may be a conventional hypertext viewing application such as Microsoft Internet Explorer or Netscape Navigator. Secure Web browsing may be supplied with 128 bit (or greater) encryption by way of HTTPS, SSL, and/or the like. Some Web browsers allow for the execution of program components through facilities such as Java, JavaScript, ActiveX, web browser plug-in APIs (e.g., FireFox, Safari Plug-in, and/or the like APIs), and/or the like. Web browsers and like information access tools may be integrated into PDAs, cellular telephones, and/or other mobile devices. A Web browser may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the Web browser communicates with information servers, operating systems, integrated program components (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses. Of course, in place of a Web browser and information server, a combined application may be developed to perform similar functions of both. The combined application would similarly affect the obtaining and the provision of information to users, user agents, and/or the like from the Payment Facilitation Engine enabled nodes. The combined application may be nugatory on systems employing standard Web browsers.
Mail Server
A mail server component 1121 is a stored program component that is executed by a CPU 1103. The mail server may be a conventional Internet mail server such as, but not limited to sendmail, Microsoft Exchange, and/or the. The mail server may allow for the execution of program components through facilities such as ASP, ActiveX, (ANSI) (Objective-) C (++), C# and/or .NET, CGI scripts, Java, JavaScript, PERL, PHP, pipes, Python, WebObjects, and/or the like. The mail server may support communications protocols such as, but not limited to: Internet message access protocol (IMAP), Messaging Application Programming Interface (MAPI)/Microsoft Exchange, post office protocol (POP3), simple mail transfer protocol (SMTP), and/or the like. The mail server can route, forward, and process incoming and outgoing mail messages that have been sent, relayed and/or otherwise traversing through and/or to the Payment Facilitation Engine.
Access to the Payment Facilitation Engine mail may be achieved through a number of APIs offered by the individual Web server components and/or the operating system.
Also, a mail server may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses.
Mail Client
A mail client component 1122 is a stored program component that is executed by a CPU 1103. The mail client may be a conventional mail viewing application such as Apple Mail, Microsoft Entourage, Microsoft Outlook, Microsoft Outlook Express, Mozilla, Thunderbird, and/or the like. Mail clients may support a number of transfer protocols, such as: IMAP, Microsoft Exchange, POP3, SMTP, and/or the like. A mail client may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the mail client communicates with mail servers, operating systems, other mail clients, and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, information, and/or responses. Generally, the mail client provides a facility to compose and transmit electronic mail messages.
Cryptographic Server
A cryptographic server component 1120 is a stored program component that is executed by a CPU 1103, cryptographic processor 1126, cryptographic processor interface 1127, cryptographic processor device 1128, and/or the like. Cryptographic processor interfaces will allow for expedition of encryption and/or decryption requests by the cryptographic component; however, the cryptographic component, alternatively, may run on a conventional CPU. The cryptographic component allows for the encryption and/or decryption of provided data. The cryptographic component allows for both symmetric and asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/or decryption. The cryptographic component may employ cryptographic techniques such as, but not limited to: digital certificates (e.g., X.509 authentication framework), digital signatures, dual signatures, enveloping, password access protection, public key management, and/or the like. The cryptographic component will facilitate numerous (encryption and/or decryption) security protocols such as, but not limited to: checksum, Data Encryption Standard (DES), Elliptical Curve Encryption (ECC), International Data Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash function), passwords, Rivest Cipher (RC5), Rijndael, RSA (which is an Internet encryption and authentication system that uses an algorithm developed in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman), Secure Hash Algorithm (SHA), Secure Socket Layer (SSL), Secure Hypertext Transfer Protocol (HTTPS), and/or the like. Employing such encryption security protocols, the Payment Facilitation Engine may encrypt all incoming and/or outgoing communications and may serve as node within a virtual private network (VPN) with a wider communications network. The cryptographic component facilitates the process of “security authorization” whereby access to a resource is inhibited by a security protocol wherein the cryptographic component effects authorized access to the secured resource. In addition, the cryptographic component may provide unique identifiers of content, e.g., employing and MD5 hash to obtain a unique signature for a digital audio file. A cryptographic component may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. The cryptographic component supports encryption schemes allowing for the secure transmission of information across a communications network to enable the Payment Facilitation Engine component to engage in secure transactions if so desired. The cryptographic component facilitates the secure accessing of resources on the Payment Facilitation Engine and facilitates the access of secured resources on remote systems; i.e., it may act as a client and/or server of secured resources. Most frequently, the cryptographic component communicates with information servers, operating systems, other program components, and/or the like. The cryptographic component may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.
The Payment Facilitation Engine Database
The Payment Facilitation Engine database component 1119 may be embodied in a database and its stored data. The database is a stored program component, which is executed by the CPU; the stored program component portion configuring the CPU to process the stored data. The database may be a conventional, fault tolerant, relational, scalable, secure database such as Oracle or Sybase. Relational databases are an extension of a flat file. Relational databases consist of a series of related tables. The tables are interconnected via a key field. Use of the key field allows the combination of the tables by indexing against the key field; i.e., the key fields act as dimensional pivot points for combining information from various tables. Relationships generally identify links maintained between tables by matching primary keys. Primary keys represent fields that uniquely identify the rows of a table in a relational database. More precisely, they uniquely identify rows of a table on the “one” side of a one-to-many relationship.
Alternatively, the Payment Facilitation Engine database may be implemented using various standard data-structures, such as an array, hash, (linked) list, struct, structured text file (e.g., XML), table, and/or the like. Such data-structures may be stored in memory and/or in (structured) files. In another alternative, an object-oriented database may be used, such as Frontier, ObjectStore, Poet, Zope, and/or the like.
Object databases can include a number of object collections that are grouped and/or linked together by common attributes; they may be related to other object collections by some common attributes. Object-oriented databases perform similarly to relational databases with the exception that objects are not just pieces of data but may have other types of functionality encapsulated within a given object. If the Payment Facilitation Engine database is implemented as a data-structure, the use of the Payment Facilitation Engine database 1119 may be integrated into another component such as the Payment Facilitation Engine component 1135. Also, the database may be implemented as a mix of data structures, objects, and relational structures. Databases may be consolidated and/or distributed in countless variations through standard data processing techniques. Portions of databases, e.g., tables, may be exported and/or imported and thus decentralized and/or integrated.
In one embodiment, the database component 1119 includes several tables 1119a-c. A registered buyer data table 1119a includes fields such as, but not limited to: buyer credit data, buyer financial data, buyer transaction records, and/or the like. The buyer table may support and/or track multiple entity accounts on a Payment Facilitation Engine. An Engine product table 1119b includes fields such as, but not limited to: product description data, product pricing, and/or the like. An Engine-affiliated manufacturer table 1119c includes fields such as, but not limited to: product description data associated with a manufacturer, manufacturer affiliated shipping data, manufacturer financial data, and/or the like. An Engine payment information table 1119d includes fields such as, but not limited to: rules and data sets pertinent to the exchange of payments and transfer of financial instrument as between seller, buyer and any intermediary financial institutions, acceptable forms of monetary transfer, the connection of buyer/seller financial information (e.g., bank accounts, credit cards, native currency, etc.) to any intermediary financial vehicles, security of payments (e.g., through letters of credit, escrow accounts, security agreements, etc.), and/or the like based on intermediary financial information (e.g., cost of money, interest rates, availability, banks, etc.), country regulation data, and/or the like.
In one embodiment, user programs may contain various user interface primitives, which may serve to update the Payment Facilitation Engine. Also, various accounts may require custom database tables depending upon the environments and the types of clients the Payment Facilitation Engine may need to serve. It should be noted that any unique fields may be designated as a key field throughout. In an alternative embodiment, these tables have been decentralized into their own databases and their respective database controllers (i.e., individual database controllers for each of the above tables). Employing standard data processing techniques, one may further distribute the databases over several computer systemizations and/or storage devices. Similarly, configurations of the decentralized database controllers may be varied by consolidating and/or distributing the various database components 1119a-c. The Payment Facilitation Engine may be configured to keep track of various settings, inputs, and parameters via database controllers.
The Payment Facilitation Engine database may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the Payment Facilitation Engine database communicates with the Payment Facilitation Engine components (e.g., Payment Facilitation Engine system procurement components, logistics components and/or payment facilitation components, other program components, and/or the like. The database may contain, retain, and provide information regarding other nodes and data.
The Payment Facilitation Engines
The Payment Facilitation Engine component 1135 is a stored program component that is executed by a CPU. In one embodiment, the Payment Facilitation Engine component incorporates any and/or all combinations of the aspects of the Payment Facilitation Engine that was discussed in the previous Figures. As such, the Payment Facilitation Engine affects accessing, obtaining and the provision of information, services, transactions, and/or the like across various communications networks.
The Payment Facilitation Engine component enables the logistics, procurement, payment facilitation components and/or the like and use of the transaction facilitation system.
The Payment Facilitation Engine component enabling access of information between nodes may be developed by employing standard development tools and languages such as, but not limited to: Apache components, Assembly, ActiveX, binary executables, (ANSI) (Objective-) C (++), C# and/or .NET, database adapters, CGI scripts, Java, JavaScript, mapping tools, procedural and object oriented development tools, PERL, PHP, Python, shell scripts, SQL commands, web application server extensions, WebObjects, and/or the like. In one embodiment, the Payment Facilitation Engine server employs a cryptographic server to encrypt and decrypt communications. The Payment Facilitation Engine component may communicate to and/or with other components in a component collection, including itself, and/or facilities of the like. Most frequently, the Payment Facilitation Engine component communicates with the Payment Facilitation Engine database, operating systems, other program components, and/or the like. The Payment Facilitation Engine may contain, communicate, generate, obtain, and/or provide program component, system, user, and/or data communications, requests, and/or responses.
Distributed Payment Facilitation Engines
The structure and/or operation of any of the Payment Facilitation Engine node controller components may be combined, consolidated, and/or distributed in any number of ways to facilitate development and/or deployment. Similarly, the component collection may be combined in any number of ways to facilitate deployment and/or development. To accomplish this, one may integrate the components into a common code base or in a facility that can dynamically load the components on demand in an integrated fashion.
The component collection may be consolidated and/or distributed in countless variations through standard data processing and/or development techniques. Multiple instances of any one of the program components in the program component collection may be instantiated on a single node, and/or across numerous nodes to improve performance through load-balancing and/or data-processing techniques. Furthermore, single instances may also be distributed across multiple controllers and/or storage devices; e.g., databases. All program component instances and controllers working in concert may do so through standard data processing communication techniques.
The configuration of the Payment Facilitation Engine controller will depend on the context of system deployment. Factors such as, but not limited to, the budget, capacity, location, and/or use of the underlying hardware resources may affect deployment requirements and configuration. Regardless of if the configuration results in more consolidated and/or integrated program components, results in a more distributed series of program components, and/or results in some combination between a consolidated and distributed configuration, data may be communicated, obtained, and/or provided. Instances of components consolidated into a common code base from the program component collection may communicate, obtain, and/or provide data. This may be accomplished through intra-application data processing communication techniques such as, but not limited to: data referencing (e.g., pointers), internal messaging, object instance variable communication, shared memory space, variable passing, and/or the like.
If component collection components are discrete, separate, and/or external to one another, then communicating, obtaining, and/or providing data with and/or to other component components may be accomplished through inter-application data processing communication techniques such as, but not limited to: Application Program Interfaces (API) information passage; (distributed) Component Object Model ((D)COM), (Distributed) Object Linking and Embedding ((D)OLE), and/or the like), Common Object Request Broker Architecture (CORBA), local and remote application program interfaces Jini, Remote Method Invocation (RMI), process pipes, shared files, and/or the like. Messages sent between discrete component components for inter-application communication or within memory spaces of a singular component for intra-application communication may be facilitated through the creation and parsing of a grammar. A grammar may be developed by using standard development tools such as lex, yacc, XML, and/or the like, which allow for grammar generation and parsing functionality, which in turn may form the basis of communication messages within and between components. Again, the configuration will depend upon the context of system deployment.
The entirety of this disclosure (including the Cover Page, Title, Headings, Field, Background, Summary, Brief Description of the Drawings, Detailed Description, Claims, Abstract, Figures, and otherwise) shows by way of illustration various embodiments in which the claimed inventions may be practiced. The advantages and features of the disclosure are of a representative sample of embodiments only, and are not exhaustive and/or exclusive. They are presented only to assist in understanding and teach the claimed principles. It should be understood that they are not representative of all claimed inventions. As such, certain aspects of the disclosure have not been discussed herein. That alternate embodiments may not have been presented for a specific portion of the invention or that further undescribed alternate embodiments may be available for a portion is not to be considered a disclaimer of those alternate embodiments. It will be appreciated that many of those undescribed embodiments incorporate the same principles of the invention and others are equivalent. Thus, it is to be understood that other embodiments may be utilized and functional, logical, organizational, structural and/or topological modifications may be made without departing from the scope and/or spirit of the disclosure. As such, all examples and/or embodiments are deemed to be non-limiting throughout this disclosure. Also, no inference should be drawn regarding those embodiments discussed herein relative to those not discussed herein other than it is as such for purposes of reducing space and repetition. For instance, it is to be understood that the logical and/or topological structure of any combination of any program components (a component collection), other components and/or any present feature sets as described in the figures and/or throughout are not limited to a fixed operating order and/or arrangement, but rather, any disclosed order is exemplary and all equivalents, regardless of order, are contemplated by the disclosure. Furthermore, it is to be understood that such features are not limited to serial execution, but rather, any number of threads, processes, services, servers, and/or the like that may execute asynchronously, concurrently, in parallel, simultaneously, synchronously, and/or the like are contemplated by the disclosure. As such, some of these features may be mutually contradictory, in that they cannot be simultaneously present in a single embodiment. Similarly, some features are applicable to one aspect of the invention, and inapplicable to others. In addition, the disclosure includes other inventions not presently claimed. Applicant reserves all rights in those presently unclaimed inventions including the right to claim such inventions, file additional applications, continuations, continuations in part, divisions, and/or the like thereof. As such, it should be understood that advantages, embodiments, examples, functional, features, logical, organizational, structural, topological, and/or other aspects of the disclosure are not to be considered limitations on the disclosure as defined by the claims or limitations on equivalents to the claims.
This disclosure describes inventive aspects of at least two distinct inventions, including: a cross border transaction facilitator (with a suggested U.S. Class/Subclass of 705/20); a payment facilitation engine (with a suggested U.S. Class/Subclass of 705/40); The instant application details claims directed to a payment facilitation engine (suggested class/subclass: 705/40). However, in order to develop a reader's understanding of the invention(s), the descriptions of the other invention(s) have been compiled into a single disclosure to illustrate and clarify how aspects of these inventions operate independently, interoperate as between individual inventions, and/or cooperate collectively. The disclosure goes on to further describe the interrelations and synergies as between any of the various inventions within the context of an overarching inventive system; all of which is to further ensure compliance with 35 U.S.C. § 112. This disclosure claims priority to under 35 U.S.C. § 119 and incorporates by reference U.S. Provisional Patent Applications titled “Apparatuses, Methods and Systems to Effect Cross-Border Payments,” filed Sep. 29, 2006, Ser. No. 60/827,683, Attorney Docket No. 17854-005PV; titled “Apparatuses, Methods and Systems for Market Generation and Matches of Importation and Exportation Transactions,” filed Sep. 29, 2006, Ser. No. 60/827,687, Attorney Docket No. 17854-006PV; titled “Apparatuses, Methods and Systems for a Taxonomy Classifier,” filed Sep. 29, 2006, Ser. No. 60/827,684, Attorney Docket No. 17854-002PV; titled “Apparatuses, Methods and Systems for Market Generation and Matches of Importation and Exportation Transactions,” filed Dec. 18, 2006, Ser. No. 60/870,561, Attorney Docket No. 17854-006PV1; titled “Apparatuses, Methods and Systems for Cross-Border Logistical Fulfillment,” filed Sep. 29, 2006, Ser. No. 60/827,688, Attorney Docket No. 17854-004PV; titled “Apparatuses, Methods and Systems for Cross-Border Acquisition,” filed Sep. 29, 2006, Ser. No. 60/827,686, Attorney Docket No. 17854-003PV; titled “Apparatuses, Methods and Systems for a Trade Business Card,” filed Apr. 23, 2007, Ser. No. 60/913,521, Attorney Docket No. 17854-010PV. This disclosure is also related to co-pending Patent Cooperation Treaty patent application no. PCT/______ filed Sep. 28, 2007, entitled “APPARATUSES, METHODS AND SYSTEMS FOR CROSS BORDER PROCUREMENT,” attorney docket no. 17894-003PC; Patent Cooperation Treaty patent application no. PCT/______ filed Sep. 28, 2007, entitled “SYSTEMS, METHODS AND APPARATUSES FOR IMPORTATION AND EXPORTATION TRANSACTION LOGISTICS FACILITATION,” attorney docket no. 17894-004PC; Patent Cooperation Treaty patent application no. PCT/______ filed Sep. 28, 2007, entitled “SYSTEMS, METHODS AND APPARATUSES FOR A PAYMENT FACILITATION ENGINE,” attorney docket no. 17894-005PC; Patent Cooperation Treaty patent application no. PCT/______ filed Sep. 28, 2007, entitled “SYSTEMS, METHODS AND APPARATUSES FOR IMPORTATION AND EXPORTATION TRANSACTION FACILITATION,” attorney docket no. 17894-006PC; U.S. non-provisional patent application Ser. No. ______ filed Sep. 28, 2007, entitled “APPARATUSES, METHODS AND SYSTEMS FOR A TRANSACTIONAL FACILITATION PORTAL,” attorney docket no. 17894-003US1; U.S. non-provisional patent application Ser. No. ______ filed Sep. 28, 2007, entitled “APPARATUSES, METHODS AND SYSTEMS FOR A TRANSACTIONAL PARAMETER SELECTION INTERFACE,” attorney docket no. 17894-003US2; U.S. non-provisional patent application Ser. No. ______ filed Sep. 28, 2007, entitled “APPARATUSES, METHODS AND SYSTEMS FOR A PRODUCT MANIPULATION AND MODIFICATION INTERFACE,” attorney docket no. 17894-003US3; U.S. non-provisional patent application Ser. No. ______ filed Sep. 28, 2007, entitled “APPARATUSES, METHODS AND SYSTEMS FOR A PROJECT AND TRANSACTIONAL PARAMETER BASED SEARCH ENGINE,” attorney docket no. 17894-003US4; U.S. non-provisional patent application Ser. No. ______ filed Sep. 28, 2007, entitled “SYSTEMS, METHODS AND APPARATUSES FOR IMPORTATION AND EXPORTATION TRANSACTION LOGISTICS FACILITATION,” attorney docket no. 17894-004US1; U.S. non-provisional patent application Ser. No. ______ filed Sep. 28, 2007, entitled “SYSTEMS, METHODS AND APPARATUSES FOR IMPORTATION AND EXPORTATION TRANSACTION FACILITATION,” attorney docket no. 17894-006US1; and U.S. non-provisional patent application Ser. No. ______ filed Sep. 28, 2007, entitled “SYSTEMS, METHODS AND APPARATUSES FOR IMPORTATION AND EXPORTATION PROCUREMENT, LOGISTICS, AND PAYMENT TRANSACTION FACILITATION,” attorney docket no. 17894-006US2. The entire contents of the aforementioned applications are herein expressly incorporated by reference
| Number | Date | Country | |
|---|---|---|---|
| 60827683 | Sep 2006 | US | |
| 60827687 | Sep 2006 | US | |
| 60827684 | Sep 2006 | US | |
| 60870561 | Dec 2006 | US | |
| 60827688 | Sep 2006 | US | |
| 60827686 | Sep 2006 | US | |
| 60913521 | Apr 2007 | US |
