shervin
A posse ad esse. Aut viam inveniam aut faciam.
Welcome
Title
Newest Members
Recent Blog Entries
by anonymous | 36 comments
by anonymous | 42 comments
by anonymous | 11 comments
by anonymous | 17 comments
Patent Number 6,384,015: Selective lysis of malaria infected erythrocytes
| ( 1 of 1 ) |
| United States Patent | 6,384,015 |
| Pishevar | May 7, 2002 |
Selective lysis of malaria infected erythrocytes
The invention provides methods and compositions for inhibiting the development of intracellular parasites by treating such cells with an effective concentration of a magainin, PGLa or XPF peptide under conditions whereby the development of the parasite in the cell is inhibited. The targeted parasites have been found to increase in the accessibility of the plasma membrane of said cell to the peptide, and particularly, to effect an increase in the cytopathic, especially lytic, sensitivity of the cell to the peptide. In one application, the invention provides methods for treating blood infected with a Plasmodium species, by contacting the blood with magainin 2 under conditions whereby the development of the Plasmodium in the infected erythrocytes is inhibited and the infected erythrocytes evidence relatively increased cytolytic sensitivity to the magainin.
| Inventors: | Pishevar; Shervin K. (Oakland, CA) |
| Assignee: | The Regents of the University of California (Oakland, CA) |
| Appl. No.: | 831993 |
| Filed: | April 1, 1997 |
| Current U.S. Class: | 514/12 ; 514/2 |
| Current International Class: | A61K 38/17 (20060101) |
| Field of Search: | 514/2,12 |
Magowan et al. Blood, 86, 3196-3204, Oct. 1995.* . Gwadz, R. et al. Infection and Immunity, 57, 2628-2633, Sep. 1989.* . Matsuzaki et al., Biochemistry,34,6521-6526, 1995.* . Matsuzaki et al., Biochemistry,34,12553-12559, 1995.* . Matsuzaki et al., Biochemistry,34,3423-3429, 1995.* . Cabantchik et al. Blood Cells, 16, (2-3), 421-432, Feb. 1990.* . Pasvol, G. et al. Annals Tropical Medicine and Parasitology, 72, 87-88, Jan. 1978.. |
Primary Examiner: Borin; Michael
Attorney, Agent or Firm:
What is claimed is:
1. A method for inhibiting the development of a parasite in a erythrocyte, said method comprising the step of contacting the erythrocyte, infected with an intracellular parasite, with a magainin, PGLa or XPF peptide under conditions whereby the development of said parasite in said erythrocyte is inhibited.
2. A method according to claim 1, wherein said parasite increases the accessibility of the plasma membrane of said cell to said magainin, PGLa or XPF peptide.
3. A method according to claim 1, wherein said parasite increases the lytic sensitivity of said cell to said magainin, PGLa or XPF peptide.
4. A method according to claim 1, wherein said cell is a human erythrocyte.
5. A method according to claim 1, wherein said magainin, PGLa or XPF peptide is magainin 2.
6. A method according to claim 1, wherein said parasite is a Plasmodium species.
7. A method according to claim 1, wherein said conditions comprise an effective concentration of said peptide of between 5 and 100 .mu.M.
8. A method according to claim 1, wherein said parasite increases the lytic sensitivity of said cell to said magainin, PGLa or XPF peptide, said cell is a human erythrocyte, said parasite is a Plasmodium species, said magainin, PGLa or XPF peptide is magainin 2 and said conditions comprise an effective concentration of said magainin 2 of between 5 and 100 .mu.M.
9. A method according to claim 8, wherein said cell is a resident human erythrocyte.
10. A method for inhibiting the intracellular development of a parasite said method comprising the step of contacting blood comprising both infected erythrocytes having an intracellular parasite and uninfected erythrocytes, with a magainin, PGLa or XPF peptide under conditions whereby the development of said parasite in said infected erythrocytes is inhibited and said infected erythrocytes evidence relatively increased cytopathology.
11. A method according to claim 10, wherein said parasite increases the accessibility of the plasma membrane of said cell to said magainin, PGLa or XPF peptide.
12. A method according to claim 10, wherein said parasite increases the lytic sensitivity of said cell to said magainin, PGLa or XPF peptide.
13. A method according to claim 10, wherein said cell is a human erythrocyte.
14. A method according to claim 10, wherein said magainin, PGLa or XPF peptide is magainin 2.
15. A method according to claim 10, wherein said parasite is a Plasmodium species.
16. A method according to claim 10, wherein said conditions comprise an effective concentration of said magainin, PGLa or XPF peptide of between 5 and 100 .mu.M.
17. A method according to claim 10, wherein said parasite increases the lytic sensitivity of said cell to said magainin, PGLa or XPF peptide, said cell is a human erythrocyte, said parasite is a Plasmodium species, said magainin, PGLa or XPF peptide is magainin 2 and said conditions comprise an effective concentration of said magainin of between 5 and 100 .mu.M.
18. A method according to claim 10, wherein said cell is a resident human erythrocyte.
FIELD OF THE INVENTION
The field of the invention is the use of magainins and related peptides to selectively lyse malaria infected erythrocytes.
BACKGROUND OF THE INVENTION
Intracellular pathogens comprise a particularly intractable source of pathogenic infections. Notorious clinical examples include Rickettsia, Chlamydia, Plasmodia species. Malaria-causing Plasmodia species in particular are the most devastating sources of infectious human morbidity and mortality on earth, with approximately 250 million to 500 million new cases each year, malaria is the direct cause of 1 million to 1.5 million deaths per year. By seeking refuge inside host cells, intracellular pathogens such as Plasmodia are able to evade many traditional host defenses. Instead, the host must resort to immune mechanisms capable of distinguishing infected from uninfected cells.
Magainins, PGLa and XPF comprise a class of linear, amphipathic cationic peptides originally found in the skin of Xenopus laevis and shown to have broad-spectrum antimicrobial activity. These peptides have been reported to exhibit cidal activity against many infectious agents including bacteria, fungi, protozoa and viruses. In particular, magainins have been reported to disrupt extracellular stages of Plasmodia parasites. Unfortunately, the life cycles of the Plasmodia, like many intracellular pathogens, comprise only brief extracellular stages and the magainins were reported to have no effect on their intracellular development.
Relevant Literature
Gwadz et al. (1989) Infection and Immunity 57, 2628-2633 report that magainins had no effect on the intracellular development of Plasmodium species.
Zasloff (1989) U.S. Pat. No. 4,810,777 discloses a class of antibiotic polypeptides termed magainins.
Zasloff(1996) U.S. Pat. No. 5,567,681 discloses a antibiotic properties of polypeptides termed PGLa and XPF.
Huang et al. (1990) Antimicrobial Agents and Chemotherapy 34, 1824-1826 report the effect of magainins against pathogenic protozoa.
Aboudy et al. (1994) Int. J. Peptide Protein Res. 43, 573-582 report the effect of magainins against herpes simplex virus types 1 and 2.
Jacob and Zasloff (1994) Antimicrobial Peptides. While, Chichester (Ciba Foundation Symposium 186), p197-223 review the potential therapuetic applications of magainins.
Matsuzaki et al. (1995) Biochemistry 34, 3432-3429, report on the molecular basis for membrane selectivity of magainin 2.
Matsuzaki et al. (1994) Biochemistry 34, 3342-3349, report on the structural orientation of magainin 2 in phospholipid bilayers.
Tytler et al. (1995) Biochemistry 34, 4395-4401, report on the molecular basis for prokaryotic specificity of magainin-induced lysis.
SUMMARY OF THE INVENTION
The invention provides methods and compositions for inhibiting the development of intracellular parasites by treating such cells with an effective concentration of a magainin, PGLa or XPF peptide under conditions whereby the development of the parasite in said cell is inhibited. The targeted parasites have been found to increase in the accessibility of the plasma membrane of the cell to the peptide and effect an increase in the cytopathic, especially lytic, sensitivity of the cell to the peptide.
In one application, the invention provides methods for treating infected blood comprising both infected erythrocytes having an intracellular parasite and uninfected erythrocytes, by contacting the blood with a magainin, PGLa or XPF peptide under conditions whereby the development of the parasite in the infected erythrocytes is inhibited and the infected erythrocytes evidence relatively increased cytopathology relative to the uninfected cells.
In preferred embodiments of the disclosed methods, the infected cell is a resident erythrocyte, the parasite is a Plasmodium species, the peptide is magainin 2 and the conditions comprise a localized concentration of the peptide of between 5 and 100 .mu.M.
BRIEF DESCRIPTION OF THE FIGURES
FIG. 1 shows the inhibition of parasitemia in P. falciparum infected human erythrocytes.
FIG. 2 shows an digitized image of a immunofluorescent micrograph of a P. falciparum infected human erythrocyte.
DETAILED DESCRIPTION OF PARTICULAR EMBODIMENTS OF THE INVENTION
In one embodiment, the invention provides methods and compositions for inhibiting the development of intracellular parasites which cause an enhanced accessibility of the plasma membrane of the cell to a magainin, PGLa or XPF peptide, an enhanced sensitivity of the cell to peptide-induced cytopathology, or both. The enhanced accessibility may be assayed by peptide transfer into, across, or through the membrane, by, for example, immunofluorescent labeling. In a preferred embodiment, the enhanced accessibility results in an increase in plasma membrane permeability to the peptide of at least 50%, preferably at least 10-fold, preferably as measured by intracellular peptide, over uninfected cells. Enhanced sensitivity may be assayed by indicia of cytopathology such a changes in membrane potential (e.g. vital dye excludability), cellular dysfunction (e.g. structural deformations), etc.; especially, increased lytic sensitivity to one or more such peptides, over uninfected cells. Lytic sensitivity to the peptides may be measured by lysis as a function of peptide concentration, time, osmotic stress, etc.
Intracellular parasites which induce the requisite enhanced accessibility or sensitivity are readily determined empirically by screening in assays based on the requisite function, e.g. cell lysis assays. A wide variety of such intracellular parasites are amenable to screening, e.g. prokaryotes such as mycobacteria and Rickettsia, fungi such as Chlamydia and, especially, pathogenic protozoa such Plasmodium species, especially P. vivax, P. malariae, P. ovale and especially, P. falciparum.
In a preferred embodiment, the infected cells are blood cells, especially erythrocytes or red blood cells. The cells may be in culture or resident, i.e. in their native environment, for example, erythrocytes in the host, preferably mammalian host, blood stream. The route of administration to the cells depends on the nature and context of the cells. For example, the peptide may be solublized in a physiological buffer and added to culture media bathing cells in vitro or delivered to resident blood cells by direct injection into the animal host, ingestion by the host, etc., so long as the peptide achieves an effective localized concentration at the infected cell effective to inhibit development of a parasite therein.
In a particular embodiment, the peptide is administered in conjunction with an adjuvant or other antimicrobial therapeutic. For example, in the case of Plasmodia infections, the peptide may be administered in conjunction with a tissue schizonticide such as primaquine, or with a blood schizonticide such as chloroquine or for chloroquine-resistant Plasmodia, mefloquine, quinine, quinidine, pyrimethamine-sulfadoxine, doxycycline, halofantrine, artemisinin, etc.
Effective concentrations of the peptide are determined empirically, though a localized (e.g. proximal to the infected cell) concentrations between 1 and 500 .mu.M, preferably between 5 and 100 .mu.M, more preferably between 10 and 50 .mu.M are shown to be effective in numerous applications, including P. falciparum infected blood-borne human erythrocytes. Inhibition may be measured by conventional assays for parasitemia, host physiology, etc.
The selection of a particular peptide for use in the subject method is determined by the targeted infected cell and parasite. As used herein, the magainin, PGLa and XPF peptides comprise a structurally related class of linear, amphipathic cationic peptides which may be naturally derived from epithelia of amphibians. Exemplary such peptides derivable from Xenopus laevis are known in the art (e.g. U.S. Pat. No. 4,810,777, supra, for exemplary magainins, and U.S. Pat. No. 5,567,681, supra, for exemplary PGLa and XPF peptides). Other magainin, PGLa and XPF peptides natural are readily identified by screening amphibian epithelia, preferably frog epithelia, more preferably Xenopus laevis epithelia, using extraction procedures and antimicrobial assays known in the art, e.g. Zasloff et al. (1987) Proc. Natl. Acad. Sci. USA 84, 5449-5453, or described herein. Such natural magainin, PGLa and XPF peptides are identical in sequence at at least 12, preferably at least 16, more preferably at least 20 positions of and/or share at least 8, preferably at least 12, more preferably at least 16 contiguous residues with a magainin, PGLa or XPF peptide as described in U.S. Pat. Nos. 4,810,777 or 5,567,681. For example, as described in Examples 1 and 2 below, Xenopus laevis-derived magainin 2 was found to be particular effective at selectively lysing P. falciparum infected blood-borne human erythrocytes as compared with non-infected cells.
The following examples are offered by way of illustration and not by way of limitation.
EXAMPLES OF THE INVENTION
Example 1
P. falciparum (New Guinean isolate D10) cultures were grown and maintained substantially as described in Trager et al. (1976) Science 193, 673-675. Human type O+ blood was obtained from healthy donors. Magainin 2 (Matsuzaki et al., 1995, supra) was made by solid phase peptide synthesis. Parasitemia assays were performed substantially as described in Pasvol et al (1978) Ann Trop Med Parasitol 72, 87-92 and Magowan et al. (1995) Blood 86, 3196-3204. The parasitemia assays were performed at 1, 24 and 48 hrs post-treatment at three magainin concentrations: 10, 25 and 50 uM final conc. magainin. Each group was done in triplicate and 7,500 erythrocytes were counted for each data point. Table 1 shows the resultant data. Table 1.
TABLE 1 Magainin 2 Day 1 Day 2 Day 3 Day 4 0 uM 1.39 2.59 2.96 6.09 10 uM 0.92 1.88 2.40 4.52 25 uM 0.41 1.88 1.61 3.68 50 uM 0.52 1.43 1.96 2.87
FIG. 1 provides a graphical representation of the data showing the inhibition of parasitemia in infected human erythrocytes over the foregoing time courses and concentrations. In the figure, .circle-solid. represents data points for the untreated cells, .box-solid. represents data points for cells treated at 10 uM, .tangle-solidup. at 25 uM, and .tangle-soliddn. at 50 uM. The data demonstrate dose and time dependent inhibitions of parasitemia by the magainin peptide.
Example 2
Immunofluorescent assays were carried out using a primary rabbit antibody generated against magainin 2 and a fluoresceine-goat anti-rabbit secondary antibody conjugate. The parasitemia assays were performed as described in Example 1 at 1, 24 and 48 hrs post-treatment at three magainin concentrations: 10, 25 and 50 uM final conc. magainin. Immunofluorescent. confocal microscopy was performed substantially as described in Magowan et al. (1995) Blood 86, 3196-3204. At each time point at each magainin concentration, the antibody was visualized exclusively within the parasite inside infected erythrocytes. No reaction was seen in any of the untreated or uninfected erythrocytes. FIG. 2 shows an immunofluorescent micrograph of an exemplary P. falciparum double-infected human erythrocyte after treatment with the magainin peptide at a 25 uM concentration.
All publications and patent applications cited in this specification are herein incorporated by reference as if each individual publication or patent application were specifically and individually indicated to be incorporated by reference. Although the foregoing invention has been described in some detail by way of illustration and example for purposes of clarity of understanding, it will be readily apparent to those of ordinary skill in the art in light of the teachings of this invention that certain changes and modifications may be made thereto without departing from the spirit or scope of the appended claims.
Collective procurement management system
|
| United States Patent | 7,124,107 |
| Pishevar , et al. | October 17, 2006 |
Collective procurement management system
A collective procurement management system which permits multiple potential purchasers of a specific item or service to submit orders for the item or service on an ongoing basis. As orders enter the system, they are grouped such that potential purchasers are may "cooperate" in generating a collective bulk order so that all participants may obtain discount/volume pricing. Once a threshold level of order volume is obtained as a result of multiple orders, the grouped order is submitted to the supplier for fulfillment. The order is then fulfilled at a volume pricing level although individual portions of the collective order are routed to a plurality of purchasers. The present invention also includes a Reverse Auction Process (RAP) which, in one embodiment, operates to allow potential purchasers to select a product or service and set a maximum price that they are willing to pay for the same. Following submission of this information to the system, possibly including orders for the same item from other potential buyers, potential vendors bid to supply the item to the relevant buyers requesting the item.
| Inventors: | Pishevar; Shervin (Gaithersburg, MD), Morris; Drew E. (Alpine, NJ) |
| Assignee: | Freewebs Corporation (Silver Spring, MD) |
| Appl. No.: | 09/326,646 |
| Filed: | June 7, 1999 |
| Current U.S. Class: | 705/37 ; 705/26 |
| Current International Class: | G06Q 40/00 (20060101) |
| Field of Search: | 705/37 |
| 6260024 | July 2001 | Shkedy | |||
| 6260025 | July 2001 | Silverman et al. | |||
| 6269343 | July 2001 | Pallakoff | |||
| 6466919 | October 2002 | Walker et al. | |||
| 6606608 | August 2003 | Bezos et al. | |||
| 7013290 | March 2006 | Ananian | |||
| 2002/0143692 | October 2002 | Heimermann et al. | |||
| 2004/0083156 | April 2004 | Schulze | |||
| 2004/0177026 | September 2004 | Balabon | |||
| 2004/0204987 | October 2004 | Hill et al. | |||
| 2005/0010521 | January 2005 | Muelier et al. | |||
| 2005/0234808 | October 2005 | Goto et al. | |||
| 10269374 | Oct., 1998 | JP | |||
Parity Trademark History, Aug. 1992, 31 pages. cited by examiner. |
Primary Examiner: Kyle; Charles R.
Attorney, Agent or Firm:
We claim:
1. A collective procurement management system comprising: a processor; and a memory in communication with the processor, the memory storing a plurality of processing instructions that enable the processor to: generate a profile for each of a plurality of purchasers based on their purchasing characteristics over a period of time, the profile characteristics including types of items ordered, quantities of items ordered, location and shipping needs; generate a profile for each of a plurality of sellers based on types of items provided, industry type, payment methods used, order shipment time and credit rating; provide to each of the plurality of sellers a macro for automatically uploading a catalog of items available for purchase, including a minimum price and a minimum order size of each of the items; provide the minimum price and the minimum order size to the plurality of purchasers prior to a submission of a purchase request; receive a purchase request from each of the plurality of purchasers for an item, each purchase request including at least one separate purchase price for the item, a separate quantity of the item, and a separate delivery condition for the item; receive, from each of a plurality of sellers, a bid for a supply commitment for the item, each bid including a plurality of supply prices for the item, each supply price corresponding to a quantity of the item to be included in an order; group said plurality of purchase requests, based on the item and the purchase price, into a collective procurement order; identify at least one of the plurality of sellers for supplying the item for the collective procurement order based on the received bids; identify a final supply price for the collective procurement order based on the ordered quantity of the item in the collective procurement order and the received bids; and fulfill said collective procurement order by matching at least one of the identified suppliers to at least one of said plurality of purchasers, based on a comparison of the profile of each purchaser with the profile of each identified supplier, and further based on each requested purchase price and received delivery condition compared to the supply commitment received for each identified supplier, at least one of said purchase requests being fulfilled at the final supply price when the final supply price is lower than the purchase price included in said purchase request.
2. The system of claim 1, said memory further comprising an inventory database including a listing of at least one item available for purchase by the plurality of purchasers.
3. The system of claim 1 wherein the processor groups each purchase request based on a similar item requested by the plurality of purchasers.
4. The system of claim 1 wherein the processor groups each purchase request only if the purchase requests specify the same item.
5. The system of claim 1 wherein the processor fulfills the collective procurement order if the plurality of purchase requests satisfy at least one threshold condition.
6. The system of claim 5, said threshold condition including a minimum number of purchasers in the collective procurement order.
7. The system of claim 5, said threshold condition including a minimum quantity of requested items in the collective procurement order.
8. The system of claim 5, said threshold condition including a minimum total order price for the collective procurement order, the total order price based on the plurality of purchase prices and a number of requested items in the collective procurement order.
9. A method for fulfilling a collective procurement order between at least one supplier and a plurality of purchasers, the method comprising: generating a profile for each of a plurality of purchasers based on their purchasing characteristics over a period of time, the profile characteristics including types of items ordered, quantities of items ordered, location and shipping needs; generating a profile for each of a plurality of sellers based on types of items provided, industry type, payment methods used, order shipment time and credit rating; providing to each of the plurality of sellers a macro for automatically uploading a catalog of items available for purchase, including a minimum price and a minimum order size of each of the items; providing the minimum price and the minimum order size to the plurality of purchasers prior to a submission of a purchase request; receiving a purchase request from each of a plurality of purchasers for an identified item, the purchase request including at least one separate purchase price, a separate quantity of the identified item, and a separate delivery condition for the identified item; receiving from each of a plurality of sellers, a bid for a supply commitment for the identified item, each bid including a plurality of supply prices for the identified item, each supply price corresponding to a quantity of the identified item to be included in an order; grouping said plurality of purchase requests, based on the identified item and the purchase price, into a collective procurement order; identifying at least one of the plurality of sellers for supplying the identified item for the collective procurement order, based on the received bids; identifying a final supply price for the collective procurement order based on the quantity of the identified item in the collective procurement order and the received bids; and fulfilling said collective procurement order by matching at least one of the identified suppliers to at least one of said plurality of purchasers, based on a comparison of the profile of each purchaser with the profile of each identified supplier, and further based on each requested purchase price and received delivery condition compared to the supply commitment received for each identified supplier, at least one of said purchase requests being fulfilled at the final supply price when the final supply price is lower than the purchase price included in said purchase request.
10. The method of claim 9 wherein each of said suppliers fulfill at least a portion of each purchase request.
11. The method of claim 9, said fulfilling further comprising: fulfilling the collective procurement order only if a minimum total quantity of the identified item is ordered from the plurality of purchase requests.
12. The method of claim 9, said fulfilling further comprising: fulfilling said collective procurement order only if a minimum number of purchasers are grouped.
13. The method of claim 9, said fulfilling further comprising: fulfilling the collective procurement order only if a minimum total order price is established for the collective procurement order, based on the plurality of purchase requests.
14. The method of claim 9 wherein said purchase price received from each of said purchasers includes a plurality of prices, each price corresponding to different quantities of the identified item in the purchase request.
15. The method of claim 9, further comprising receiving at least one acceptable price from the at least one supplier, each acceptable price corresponding to a total quantity of the identified item in the collective procurement order.
16. The method of claim 9, each said purchase request specifying at least one additional purchase condition in connection with the identified item.
17. An apparatus for completing collective procurement management orders, comprising: means for generating a profile for each of a plurality of purchasers based on their purchasing characteristics over a period of time, the profile characteristics including types of items ordered, quantities of items ordered, location and shipping needs; means for generating a profile for each of a plurality of sellers based on types of items provided, industry type, payment methods used, order shipment time and credit rating; means for providing to each of the plurality of sellers a macro for automatically uploading a catalog of items available for purchase, including a minimum price and a minimum order size of each of the items; means for providing the minimum price and the minimum order size to the plurality of purchasers prior to a submission of a purchase request; means for receiving a purchase request from each of a plurality of purchasers for an identified item, the purchase request including at least one separate purchase price, a separate quantity of the identified item, and a separate delivery condition for the identified item; means for receiving, from each of a plurality of sellers, a bid for a supply commitment for the identified item, each bid including a plurality of supply prices for the identified item, each supply price corresponding to a quantity of the identified item to be included in an order; means for grouping said plurality of purchase requests, based on the identified item and the purchase price, into a collective procurement order; means for identifying at least one of the plurality of sellers for supplying the identified item for the collective procurement order, based on the received bids; means for identifying a final supply price for the collective procurement order based on the quantity of the identified item in the collective procurement order and the received bids; and means for fulfilling said collective procurement order by matching at least one of the identified suppliers to at least one of said plurality of purchasers, based on a comparison of the profile of each purchaser with the profile of each identified supplier, and further based on each requested purchase price and received delivery condition compared to the supply commitment received for each identified supplier, at least one of said purchase requests being fulfilled at the final supply price when the final supply price is lower than the purchase price included in said purchase request.
18. The apparatus of claim 17, said purchase request including at least one additional purchase criteria.
19. The apparatus of claim 17, further comprising: means for notifying at least one purchaser of a pending collective procurement order based upon profile information of the purchaser.
20. The apparatus of claim 17, further comprising: means for identifying, to the at least one supplier, a number of purchase requests forming said collective procurement order, wherein said supply price is based on the number of purchase requests.
21. The apparatus of claim 17, further comprising: means for notifying the plurality of purchasers of an amount of time remaining prior to a closing of the collective procurement order.
22. The system of claim 1, said plurality of purchasers comprising at least two purchasers providing different purchase prices.
23. The method of claim 9, said plurality of purchasers comprising at least two purchasers providing different purchase prices.
FIELD OF THE INVENTION
The present invention relates generally to automated systems and methods for transaction processing and more particularly to systems and methods for efficiently and optimally processing purchase and sale orders for goods and services.
BACKGROUND OF THE INVENTION
Business is all about commercial transactions. These transactions result in the critical revenue streams necessary for businesses to survive. In some cases, businesses purchase goods or services which are helpful or necessary for the company to operate. Goods and services may be purchased as "overhead" (e.g. pencils and pens for employees) or for redistribution to the ultimate consumer (e.g. software to be distributed by a PC seller in connection with the sale of PCs).
While commercial transactions between parties have occurred practically since the beginning of time, the methodology by which they are conducted has evolved rapidly. This is especially true in recent years with the advent of the computer, the internet and other communications technologies.
One recent development has been so called "on-line commerce". This umbrella term generally refers to the conduct of business and the consummation of business transactions through an electronic medium available to both parties through which orders may be communicated and processed. For example, consumers may purchase various goods through on-line stores available on the internet. In this case, the age old requirement of a face to face transaction in, for example, a retail brick and mortar store is unnecessary. Instead, a consumer reviews available offerings on the internet, selects one for purchase and orders it. The consumer may pay for the purchase by credit card and receive the item in the mail a few days later.
In addition to the above described business to consumer transactions, business to business transactions which occur via computers and various communications systems have also become commonplace. For example, electronic commerce ("e-commerce") systems, services and software exist whereby companies may enter into purchase and sale transactions on an automatic or semiautomatic basis. Through the use of these e-commerce systems, purchasing entities may, for example, be set up to automatically receive re-orders of consumable supplies on a rolling basis from a predetermined supplier. In some cases, the price and quantity may be pre-negotiated or at least known ahead of time by the purchaser. In other cases, the purchasing entity may agree that it will accept a certain quantity on a rolling basis at the then current market price, whatever it may be. Communication in these systems between buyers and sellers may occur through various communication channels such as the internet, private local or wide area network or dialup access.
While these systems are extremely successful, they do suffer drawbacks. In particular, these systems generally operate under the restriction that the supplier-purchaser relationship is predefined and relatively inflexible. By way of example, existing e-commerce systems and services generally require the purchaser to preselect its supplier with respect to specific goods and/or services. After selection, these goods and services are provided exclusively by the preselected supplier regardless of price or terms. As mentioned above, in many cases where rolling orders are used, the purchasing entity is required to accept goods/services at a future price which is likely unknown at the time of the initial order or when the relationship is set up. This can be disadvantageous to the purchaser not only in terms of pricing but also in terms of product/service quality and fitness for purpose. In other words, the purchaser may, due to a prior commitment made to a supplier, be stuck with an inferior product/service or one that does not meet its needs as well as another product/service which would otherwise be available to the purchaser.
SUMMARY OF THE INVENTION
It is therefore an object of the present invention to overcome the disadvantages and drawbacks of prior art systems and methods.
It is another object of the present invention to provide a flexible and efficient system which provides a buyer with the opportunity to obtain desired goods and services at prices which would otherwise be unavailable to such a buyer.
It is yet another object of the present invention to provide a system which automatically and systematically groups potential buyers of products and services with each other in order to obtain optimal pricing on such products and services.
It is a still further object of the present invention to provide a method by which potential buyers may be automatically placed into a buying cooperative with other potential buyers of the same item or items so that volume pricing may be obtained by all buyers in the cooperative.
It is another object of the present invention to provide a transaction system and methodology through which suppliers and buyers may be matched in an online environment.
It is another object of the present invention to provide a system which provides automatic ordering capabilities for potential purchasers wherein the delegation level of order control may be automatically adjusted over time and/or as a result of various events.
It is another object of the present invention to provide an ordering system and method through which purchasers may specify multiple price points for purchase of a particular item whereby selective fulfillment of the order is dependent upon the time since the order as well as other orders submitted by other potential purchasing entities.
It is a still further object of the present invention to provide a reverse auction process whereby potential suppliers may bid against one another to satisfy a collective order according to required prices and terms dictated by multiple potential purchasers.
The above and other objects are achieved through the novel transaction management system of the present invention. In one embodiment of the present invention, multiple potential purchasers of a specific item or service submit orders for the item or service on an ongoing basis. As orders enter the transaction system, they are grouped such that potential purchasers are automatically set up to "cooperate" in order to obtain discount/volume pricing. Once a threshold level of order volume is obtained as a result of multiple orders, the grouped order is submitted to the supplier for fulfillment. The order is then fulfilled at a volume pricing level although portions of the collective order are routed individually to a plurality of purchasers.
As may be seen, the system of the present invention produces significant advantages for both the supplier and the individual potential purchasing entities. The suppliers benefit by receiving large orders for specific products/services at one time and the potential purchasers benefit by obtaining pricing discounts that would otherwise be unobtainable. In one embodiment of the present invention, potential purchasers specify orders in the form of multiple "fulfillment level" at different price points. In this case, a potential purchaser may submit an order ("primary fulfillment level") through which they agree to pay a specific price if the order is filled within a certain time frame. Whether or not the order is filled at this price is dependent upon the amount and timing of other orders for the same item made by other parties. Additionally, in this embodiment, the potential purchaser may specify additional fulfillment levels ("secondary fulfillment levels") through which the potential purchaser agrees that if the primary fulfillment level is not met and the order not filled at the specified primary price, the potential purchaser would be willing to accept the product at a different (higher or lower) price during a different time frame.
An additional feature of the present invention is the method by which potential purchasers may automate their purchasing process through a continuing and evolving relationship with its suppliers. For example, rather than submitting purchase orders to the transaction processing system of the present invention on an ongoing basis each time the purchaser requires the same item over time, the purchaser may submit one or more "rolling orders" to the system. In this case, the purchaser may not initially delegate significant authority to the potential supplier with respect to control over the purchaser's orders. However, with the passage of time or as a result of specified events, additional authority may be delegated to the supplier with respect to the purchaser's purchase of either a specific item, a set of items or all items available through the particular supplier.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a high level block diagram illustrating the major components of the transaction processing system of the present invention.
FIG. 2 is a block diagram illustrating, at a more detailed level, the major components of the transaction processing system of the present invention.
FIG. 3 is a flowchart illustrating the process through which a potential purchaser may enter a purchase order using the system of the present invention and the way in which such an order is processed in the system.
FIG. 4 is a flowchart illustrating the process through which a potential supplier may enter a supply commitment using the system of the present invention and the way in which such a commitment is processed in the system.
FIG. 5 is a representation of an exemplary screen through which a purchaser may enter an order into the transaction processing system of the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
An overview of the system of the present invention is now provided in connection with FIG. 1. Following this overview, the particular components of the system are discussed in detail as are the methods employed to achieve the objects of the present invention.
System Overview and Capabilities
FIG. 1 illustrates the transaction processing system (TPS) 20 of the present invention as well as various components with which it is in communication in order to accomplish the objectives of the present invention. The overall "system" of the present invention is referred to herein as the system and referenced for purposes of this description as "system 10".
TPS 20 is comprised of various components which are discussed in detail below. In a preferred embodiment of the present invention TPS 20 includes a set of computer programs which collectively perform the transaction processing tasks to be discussed in detail below. These computer programs preferably reside on a server having the necessary processing power and storage capability to accomplish the objectives without subjecting users to unreasonable delays, downtime or failure of results. The server running TPS 20 is deployed so as to have the capacity to communicate with other processing resources and users via the internet. Alternatively or in addition to internet communication, TPS 20 may communicate with other processing resources through private communication networks or through point to point dial up access or according to other communication protocols and networks.
One set of processing resources in communication with TPS 20 are purchaser terminals 15. The system 10 of the present invention may provide for communication of TPS 20 with an unlimited number of purchaser terminals via various communication channels subject to provision of the necessary processing power and communication bandwidth to provide satisfactory response time and system performance in general. Purchaser terminals 15 may be personal computers, dedicated terminals or any other device capable of displaying menus, accepting input from a user, receiving and transmitting information and otherwise communicating with TPS 20. In a preferred embodiment of the invention, purchaser terminals 15 comprise personal computers running an internet browser such as Netscape Navigator or Microsoft Internet Explorer and communicating with TPS 20 over the internet. In this embodiment, menus may be provided to the user as, for example, Java applets (or some other dynamic resource) or as static HTML pages.
TPS 20 further communicates with one or more supplier terminals 25. Again, it is preferable that supplier terminals 25 be personal computers or some other processing resource running a browser or browser like application that permits the display of menus, accepts input from the user and communicates with TPS 20 through the internet. It is also conceivable that a user of the system 10 of the present invention may be both a supplier and a purchaser. In this case, a single terminal may serve both purposes. The primary differences between a supplier terminal 25 and a purchaser terminal 15 from an operational standpoint are the menus displayed and the types of transactions which may be processed and submitted.
In addition to the previously described components, the system 10 of the present invention may also include a separate inventory database 50. Inventory database 50 stores the "inventory" available for purchase or sale through system 10. Thus, each time an order for a particular item or service is requested by a purchaser for the first time, information such as the item description and the assigned item number will be entered into inventory database 50. Following this, the specific item will be available via pull down menus or search screens for order by other purchasers or sale by various suppliers. Conversely, a supplier, upon affiliating with the purchase management service ("PMS"), may load some or all of its catalog of available items through TPS 20 for ultimate storage in inventory database 50. At this point each of the stored items becomes available for purchase by potential purchasers having access to the system 10.
TPS Components
FIG. 2 illustrates additional details and components of TPS 20 which we now described in conjunction with that Figure. Turning now to FIG. 2, it may be seen that in a preferred embodiment of the present invention, TPS 20 comprises various components for accomplishing the functions of system 10. In a preferred embodiment, each of these components is implemented as one or more software modules and/or physical processing devices for processing data as required.
System control 110 is the central controller of TPS 20. In this respect, system control 110 initiates, controls, terminates, and monitors all processes occurring in TPS 20. In addition to system control 110, TPS 20 includes various components for accomplishing particular tasks associated with receiving orders, receiving commitments to fill orders, matching orders and fulfilling orders. For example, order matching process 130 functions to group orders for particular items and services as they are submitted to system 10. In this way, individual orders for the same or similar items and service which are submitted by purchasers may be grouped together. In order to accomplish this grouping function, order matching process communicates with inventory database 50. Inventory database 50 stores and provides data respecting all available products and services which are available for purchase through system 10. Additionally, incoming order storage database 160 is provided for the purpose of storing incoming orders as they are pending and up until the time that they may be matched with a supplier commitment for the same product or service.
Similarly, commitment matching process 170 functions to match commitments made by suppliers to supply products and services under specified terms and at specified prices. In most cases, a collective buy order resulting from multiple individual orders will be fulfilled by a single supplier. However, commitment matching process 170 may, in some cases, function to group supply commitments from multiple suppliers so that these multiple suppliers may collectively fill a collective procurement order. For purposes of this description, such a situation is referred to as a co-sell arrangement. Incoming supplier commitment database 150, in a manner similar to incoming order storage database 160, stores supply commitment transactions as they are entered into system 10 by potential suppliers. Storage of commitment transactions is under the direction and control of commitment matching process 170 regardless of whether a co-sell arrangement is called for or fulfillment is to be accomplished by a single supplier.
Fulfillment processing processor 140 is invoked at the time a collective procurement order can be matched by a co-sell arrangement or, more likely, when a single supplier commitment matches a collective procurement order. Fulfillment processing processor 140, at such time, accomplishes the tasks which are associated with order fulfillment when a group of buyers can be matched with one or more sellers with respect to a particular transaction. Such tasks may include, for example, notification to supplier(s) of the transaction match, notification to buyers that their order has been filled and notification to a third party fulfillment company indicating that it should fulfill the consummated transaction. Of course, additional information may be provided in each case, including, for example, the names of the buyers, the names of the supplier(s), the shipping addresses, the pricing and terms information, etc.
Delegation control 120 is a process that controls the amount of delegation afforded to suppliers in supplier first enter into a relationship under which supplier supplies goods or services to the purchaser, delegation may be minimal. In such a case, purchaser may specify that all orders must be pre-approved by purchaser prior to fulfillment by supplier. As the relationship matures, purchaser may be willing to allow supplier to exert more control over the supply of goods and services to the purchaser. For example, in the case of consumable goods, once a good estimate of purchaser's needs for such goods over time can be obtained, purchaser may be willing to allow supplier to fulfill orders on a periodic basis without consulting purchaser prior to every fulfillment event. Perhaps, purchaser may place a limit on the price that purchaser is willing to pay under this rolling automatic supply arrangement. In this case, if supplier were to raise its price a certain threshold above the previous price, it may require purchaser's specific consent prior to fulfillment. This process of assigning a delegation level for each purchaser/supplier pair is controlled and executed by delegation control 120.
Purchase Order Submission
FIG. 3 is a flowchart illustrating the overall process of submitting purchase orders, matching them with supply commitments and fulfilling the order according to the methods of the present invention (purchaser point of view). FIG. 4 is a flowchart illustrating the overall process of submitting supply commitments, matching them with purchaser orders and fulfilling the orders (supplier point of view). A description of both processes and how they work together is now provided in conjunction with FIGS. 3 and 4.
In FIG. 3 and from the point of view of the purchasing entity, the process begins when the purchaser locates the item he or she desires. Various search screens and methodologies as are well known in the art may be used to search for and locate desired products and services. Note that as suppliers enter supply commitments into system 10, each item or service is stored in inventory database 50 along with a description and a predefined or then specified identification/stock code. With this in mind, inventory database 50 may be queried by a potential purchaser as is known in the art in order to locate the desired item. In an internet embodiment, various images and descriptions of the products may be displayed through the browser application during the product/service search phase.
Assuming a purchaser locates a product or service he or she desires, the potential purchaser may know specify the maximum price that he or she is willing to pay for the item with respect to the desired quantity. The desired quantity is specified at the next step. As will be discussed in further detail below, an alternate embodiment of the present invention provides the purchaser with the ability to customize the purchase order in many ways. For example, the purchaser may specify that he would be willing to buy an additional quantity if a specific reduction in price was offered. Further, the purchaser might specify that he would be willing to pay the specified price for a certain period of time after which, if his order is not filled, he might be willing to pay a higher price or accept a lesser or greater quantity. The specific custom options alluded to here are described in greater detail below.
Once the quantity and price have been specified by the potential purchaser, the potential purchaser is given the opportunity to specify additional terms and conditions that may apply to the order. Examples of this might be shipping included, insurance included, specific color only, ship to multiple destinations, must ship by specific date, etc. As will be discussed in further detail below, specific terms and conditions available for selection may be demonstrated to the potential purchaser via pull down menus or the like. System 10 operates so as to prevent inconsistent terms or orders with missing information from being submitted to TPS 20. Such "order checking" may, in one embodiment, be accomplished through the use of a Java applet or other dynamic program which is download to the purchaser terminal 15 via the internet.
Once the order has been completed to the potential purchaser's liking and subject to the order checking process, the user may submit the purchaser order to TPS 20 by clicking on a "submit" button. The user may be queried to ensure that he or she truly wishes to submit the order prior to actual submission. Additionally, order checking may occur at TPS 20 upon receipt of the order either as a sole check or in addition to real time order checking occurring at purchaser terminal 15.
Once submitted, the purchase order is received by TPS 20 under the direction of system control 110. System control 110 invokes order matching process 130 which first stores the new order in incoming order storage database 160. Next, order matching process 130 matches the order with any other orders that exist for the same product or service. The check for other matching orders which are qualified to group to form a collective procurement is accomplished through a check of the incoming order storage database 160 which contains information about all previously submitted but yet unfulfilled orders. If there are other orders for the same product or service, they must be qualified further by order matching process 130 to determine if the orders can be grouped. Qualification for grouping is discussed in further detail below but generally requires a check of the requested quantity (vis a vis other potential grouped orders and commitments made by potential suppliers), a check of special terms and conditions which may apply and a check of compatible purchase prices.
If the submission of the current order is determined to be the order that completes the grouping such that a supplier commitment is met, then the order is fulfilled under the direction of system control 110 and fulfillment processor 140 and the process ends. Otherwise, if additional orders are required to meet the terms and conditions of a supplier commitment, then system 10 awaits additional purchase orders through the above-described process until a collection of orders does meet the terms and conditions of a supplier commitment.
Supply Commitment Submission
From the point of view of the supplier and in connection with FIG. 4, the methodology through which a supplier may enter a commitment to supply goods or services using system 10 is now described. Upon initiating the process, the supplier specifies the particular item or service which it wishes to make available to purchasers through system 10. The supplier may also provide various details about the product or service including providing an image which may be viewed by potential purchasers at purchase terminal 15. Macros may be provided to allow a supplier to enter its whole catalog or a large portion thereof into system 10 without having to individually enter each one. In addition to providing product/service details, the supplier may also enter an identification number (e.g. SKU) or one may be assigned by system 10 or both. The supplier also enters the minimum price he or she will accept for a particular item given a specific quantity. In most cases, a supplier might be willing to accept a lower price in return for a large order. This represents the significance of collecting and combining purchase orders to create a collective procurement on the purchaser end. Supplier also preferably enters the quantity of the product which it has available and which it is willing to supply through system 10 as well as the minimum volume it will accept at each particular price point.
As is the case with the purchasers, the supplier may customize the supply commitment with various conditions and terms under which it is willing to supply the product or service. For example, the supplier may specify that it will accept a collective procurement but only one with a maximum of 10 individual purchasers or less. Various additional conditions can be attached to the supply commitment as will be discussed in greater detail below.
Once all terms have specified and a real time order checking process similar to one that has been used with the purchaser order process has ensured that all required terms are present and that there are no inconsistent terms, the supply commitment may be submitted to TPS 20 via supplier terminal 25. Again, upon submission, additional order checking may be performed by TPS 20 in addition to or instead of the checks performed at supplier terminal 25.
Once a supply commitment has been submitted and accepted, the commitment is placed in the incoming supplier commitment storage database 150 under the direction and control of system control 110 and commitment matching process 170. If the submission of this particular commitment can be matched successfully against a pending collective procurement order, the commitment matching process 170 (possibly in combination with order matching process 130) can cause the order to be fulfilled under the direction of fulfillment processor 140.
Example of Purchase Order Submission
A description of an exemplary purchase order submission is now provided in conjunction with FIG. 5. FIG. 5 represents a sample order entry screen which may be provided to a purchaser at purchaser terminal 15 to allow such a purchaser to enter data associated with a purchase order to be submitted. Of course, this is only one example of such a data entry screen and others with the same or different data inputs may be readily substituted.
Item Description input field 510 permits a purchaser to enter an item description. Field 510 may also include a pull down menu for selecting among various items available through system 10. Manufacture input field 520 allows the purchaser to specify a manufacturer of the item desired. In the case of a service, this would typically be the service provider. System 10 may be configured to function such that upon selection of a manufacturer via a pull down menu, item description field 510 pull-down is loaded with all of the selected manufacturer's products/services available within system 10. Alternatively or in addition, a purchaser may specify an item stock number in input field 560. The stock number may be located, for example, through an online search or through a hard copy catalog. In field 570, the user may specify a desired supplier for the item or service.
Additional fields may also be provided to allow the purchaser to more full refine the purchase request. In particular, the purchaser may enter the maximum price he or she is willing to pay for the item in field 530. Additionally, the purchaser may enter the quantity of items that he or she desires for the aforementioned price. In the case of a service, field 550 and/or additional fields may be used to specify particular characteristics of the service desired.
In one embodiment of the invention (not shown in FIG. 5), additional price and quantity data entry fields may be provided in order to allow a purchaser to specify additional fulfillment levels (secondary fulfillment levels) in addition to the already specified initial level. For example, a purchaser might specify a price of $9 and a quantity of 100 for the primary fulfillment level. At the same time, the purchaser might specify a first secondary fulfillment level of $8.75/200. This means that if the supplier is not willing to provide 100 units at $9 per unit, then the purchaser would be willing to accept 200 units at $8 per unit. System 10 and in particular order matching process 130 may be configured to automatically determine the supplier's preference as to the two offers and fill the offer most desirable to the supplier. Additionally, order matching process may make the determination based upon existing orders contained in incoming order storage 160. For example, the specified secondary fulfillment level might be selected if a 200 unit purchase would complete a collective procurement whereas a 100 unit purchase would not.
Additional fields may also be provided on the purchase order submission screen. For example, the purchaser may specify the latest acceptable shipping date in field 540. This is particularly important in the case where orders are pending to generate a minimum order quantity acceptable to the supplier. For example, a potential purchaser may desire that his offer expire at some date certain rather than waiting, however long it takes, for enough orders to satisfy a minimum quantity for a collective procurement.
Field 590 permits a potential purchaser to specify the maximum shipping cost he is willing to pay. Alternatively, system 10 may use this field to automatically display a non-negotiable shipping cost associated with the requested quantity of items. In field 550, the purchaser can supply shipping address information and in field 525 the purchaser can select a link to provide a separate billing information screen (not shown). After all information has been provided, the purchaser may submit the purchase order by clicking on submit button.
Once the purchaser submits the purchase order via purchaser terminal 15, it is transmitted to transaction processing system 20. As orders are submitted by multiple purchasers they are stored in incoming order storage database 160 under the direction of system control 110 and order matching process 130. Each time an order is received, a collective procurement matching process is initiated by order matching process 130. Order matching process queries both the incoming storage database 160 and the incoming supplier commitment storage database 150 in order to determine if a collective procurement order can be processed as a result of supplier commitments and the collective orders contained in incoming storage 160 as well as the present order at the time it is submitted. In determining whether a collective procurement order can be fulfilled, both primary fulfillment levels and secondary fulfillment levels are checked.
Collective Buy Example
The next portion of the description provides an example of how a collective procurement order may be fulfilled according to one embodiment of the present invention. The following is merely one example based upon hypothetical data. As will be apparent to one of skill in the art, other algorithms and matching procedures may be employed according to the present invention without departing from the scope or spirit thereof.
Assume the incoming supplier commitment storage database includes the following data:
TABLE-US-00001 Minimum Minimum Price at SUPPLIER ID # PRODUCT ID # Quantity Quantity 5T76R 76-65A 350 $7.95 7R56A 76-65A 175 $8.25 7R56A 76-65A 250 $7.85 4G79F 54-99Z 450 $4.25
Example 1
Assume there are no orders in incoming order storage 160. Assume also that a new order comes in for a quantity of 150 at a purchaser price of $9.00 of item 76-65A. In this case the collective procurement could not yet be fulfilled since no supplier (as reflected by incoming supplier commitment storage database 150) is willing to supply a quantity of this item which is below 175. As a result, the order would be stored in incoming order storage awaiting another order which would serve to satisfy the minimum collective procurement requirement.
Assume that a second order comes in wherein a second purchaser requests 200 of item 76-65A. For simplicity, also assume that this second purchaser has also submitted a purchase order indicating that this purchaser is also willing to pay $9.00 per item. Order matching process 130 will now determine, through a query of both incoming order storage 160 and incoming supplier commitment storage 150, that a request for a total of 350 of item number 76-65A is outstanding. Order matching process 130 may now complete a collective procurement match by processing the order with supplier number 5T76R as the sole source of the item. As a result, a collective procurement match will be processed whereby the first purchaser receives the requested 150 at $9.00 per item and the second purchaser receives the requested 200 also at $9.00 per item. Both orders will be supplied by vendor number 5T76R.
Note that even though the minimum purchase price specified by vendors for the item was below $9.00, the order was fulfilled at the price offered by the purchasers ($9.00). In one embodiment of the present invention, potential purchasers are not aware of the minimum acceptable prices acceptable to the participating suppliers. Alternatively, the system of the present invention may be configured so as to permit potential purchaser to effectively obtain access to the data in incoming supplier commitment storage prior to submitting purchase orders. In the latter case, potential purchaser can know the minimum acceptable pricing for items and/or minimum quantities. If the potential purchaser can not or will not meet the minimum quantity for the item, they can nonetheless offer the requested price and wait until other order come in sufficient to collectively meet the minimum quantity necessary to receive the price. It is also possible to configure the system of the present invention such that the purchaser receive the lower price specified by the suppliers even though they "bid" a higher price.
An alternative result based upon the same order submissions may be that the order is filled by a combination of vendor 5T76R and vendor 7R56A. However, since the total requested quantity is 350 and vendor 5T76R has indicated a minimum quantity of 350 at the specified price, the order would most likely not be split to provide that vendor with a lower quantity than it minimum specified. In the event, the collective order was, for example, a total of 500 items, vendor 5T76R may supply its 350 and the other vendor(s) (in this case 7R56A) would supply the balance. Allocation is, of course, based upon how the system is configured but may be based upon, for example, time of commitment, amount of commitment, vendor status and price offered.
Example 2
The following example demonstrates supplier side fulfillment levels. Just as purchasers can submit orders which vary by time, price and quantity, suppliers can agree to supply goods or services according to different fulfillment levels. As is apparent in the table above, vendor 7R56A has agreed to supply item 75-65A in a quantity of 175 at a price of $8.25. However, if a commitment to purchase a quantity of 250 is obtained (either by a single purchaser or as a collective buy) the vendor is willing to accept a lower price of $7.85 per item. Thus, if an order for 150 came in with a purchase price of $8.00, based upon the data in the table, it would clearly remain unfulfilled. Now suppose a second order for 175 came in from a second purchaser, also specifying a price of $8.00. In this case, a collective order total of 325 exists. This is sufficient to obtain the lower price from vendor 7R56A so the order would be fulfilled for the two purchasers at a price of $8.00 since this is less than the $8.25 minimum at the lower quantity level. Alternatively, since the collective quantity is sufficient for the two purchasers to obtain the $7.85 price, they may receive this price even though they were willing to pay the higher $8.00 price.
As will be apparent to one of skill in the art, the above examples are intended merely to provide information on the system and its operation according to one embodiment. A practically limitless set of configurations and associated algorithms may be employed by the system of the present invention without departing from the scope and spirit thereof.
Reverse Auction Process (RAP)
The present invention may include, either independently or in connection with the collective procurement process described above, a Reverse Auction Process (RAP) capability. The RAP allows potential buyers to specify a maximum price that they are willing to pay for a product or service. But even more importantly, the RAP provides these potential buyers with the possibility of obtaining a price which may be significantly more attractive then the buyer specifies as the maximum price.
This is accomplished through a multiple step reverse auction procedure. According to a preferred embodiment, a potential buyer specifies product/service information (including possibly particular constraints to be associated with the purchase as required by the potential buyer) as well as the maximum price the buyer is willing to pay for the desired product or service. The pricing determination may, in some cases, reflect the quantity desired and/or particular constraints to be attached to the purchase request.
Once the above information is submitted via the system of the present invention, the next step calls for the potential suppliers to take steps to "bid" for the proferred purchase order. This portion of the overall process may occur according to various embodiments. In one embodiment, suppliers, once notified of the purchase request, submit their best price under the maximum price agreed to be paid by the potential buyer. Further, in this embodiment, none of the suppliers are aware of other "bids" made by other suppliers in meeting the purchaser request. Preferably, a deadline is imposed either by the potential purchaser or the system, or both, by which suppliers must submit their bids. Following the deadline, the supplier that has offered to supply the goods/services at the lowest price and meeting all of the potential buyer's requirements, will be automatically selected to fulfill the order. In the event of a tie, the system may either divide the order between the tying suppliers according to a predetermined scheme or use a predetermined algorithm for deciding which supplier shall fulfill the order.
In addition to the "blind" auction process above, the RAP of the present invention may be implemented according to at least one alternative embodiment. One such alternative embodiment calls for bidding suppliers to be made aware of other bids by other suppliers during the reverse auction process. According to this embodiment, one supplier may offer an opening bid and then each other supplier which can meet the requirements can be sequentially offered the opportunity to beat the previous bid. This may be accomplished through the automatic generation of email messages to subscribing suppliers with such suppliers being offered the opportunity to bid through a predetermined deadline. Again, as in the previous embodiment, the supplier offering the best bid will be selected to fulfill the order.
As may be understood by one of skill in the art, the above RAP works best with "commodity" items and services in that potential purchasers will not be as concerned with the supplier as they are with the product or service. Further, the potential purchaser, in this case, can expect that the product or service provided through one supplier will be virtually indistinguishable from the equivalent product or service supplied by another supplier.
Notwithstanding the above, the RAP process (and the collective procurement process in general) may also be applied to "non-commodity" products and services as well. In this case, it is preferable that potential purchasers specify the general class of product or service that they desire as well as the maximum price that they are willing to pay for such product or service. Then, according to one embodiment, potential suppliers that can offer a product or service, as applicable, within the specified class are invited to bid for the opportunity to supply the potential purchaser. As before, the lowest price bid offered by a supplier is presented to the potential purchaser. However, in this case, it is preferable that descriptive details about the specific product or service to be supplied is also presented to the potential purchaser. Once presented with this information and the supply price offer, the potential purchaser may be offered the opportunity to accept or reject the specific bid presented by the system. This is in contrast to the case where a commodity item is desired. In the latter case, it is preferable that the buyer be bound so long as a supply commitment at a price below the maximum price specified by the purchaser is presented.
In addition to the above described embodiments of the RAP, there are a number of alternative embodiments for implementing the system and the process of the present invention. Examples of such alternative embodiments are now discussed. With respect to the initiation of the RAP, rather than the potential purchaser setting a maximum price that he or she is willing to pay, other possibilities exist.
One such possibility is a case wherein a group of potential buyers seeking to obtain the same product or service simply enter their desired quantity without entering a maximum price. In this case, potential sellers may bid through the RAP process to supply the desired product or service at the lowest price possible without regard to any particular constraints set by the potential purchasers. In this case, the lowest bidding supplier than can offer the collectively desired quantity will be the supplier. The system of the present invention may function such that once the grouped buyers all submit requests to purchase, they are bound to accept the lowest offered price despite the fact that no maximum price was set. However, a more reasonable approach is to allow the potential purchasers to collectively or individually accept or reject the lowest bidding seller's offer.
Another possibility also does not require the potential purchaser(s) to specify a maximum price that they are willing to pay but instead, the maximum price for the particular item is specified by the system. Thus, the service operator may develop and maintain a database of pricing information for all items available in the system. In the event no supplier offers the specified price (or a better one) through the RAP, the potential buyers are preferably informed that the item is not currently available at the "recommended maximum price". Potential purchasers, in this case, may be permitted to set their own maximum price above the recommended price reflecting the price they would be willing to pay. At that point, vendors may be invited to attempt to match that price.
Yet another possibility for conducting the RAP process from the potential buyer point of view is to average maximum/target prices set by individual potential purchasers to arrive at a collective maximum price for a collective procurement group purchase request. In addition to a simple average, other algorithms may be employed to determine the ultimate price which must be met on the vendor side for a transaction to be completed.
Service Provider and Supplier-Side Process Initiation
Additional variations exist whereby the RAP process may be initiated by, for example, a service provider operating the system of the present invention. In such a case, a particular product or service or package of products or services may be selected to be "bid out" to subscribing suppliers. These suppliers may then bid to supply the items to prospective purchasers which are to be grouped at a later time. The suppliers and/or the service provider may specify particular constraints which are to be associated with the potential transaction.
By way of example and not limitation, the suppliers or the service provider may specify that the price to be offered will be dependent upon constraints such as buyers geography, shipping date, date of service, quantity, number of buyers and repetitive purchases as well as others.
Profiling and Matching Engine
The present invention may include a profiling engine which operates to determine the needs, requirements and conditions associated with both buyers and sellers using the system of the present invention. The profiling engine functions in connection with various database with the goal of generating and maintaining such databases so that they contain data which may be used by transaction processing system 20 to more effectively match buyers and sellers.
As time goes on and specific buyers and sellers enter more and more purchase orders and supply commitments, respectively, the databases are updated to include a better and better reflection of particular characteristics of both buyers and sellers. This, in turn, allows TPS 20 to more effectively match buyers and sellers both on an ongoing basis and with respect to particular transactions.
In the typical course of business, a seller may manufacture a quantity of goods based upon assumed or estimated demand for those goods. Unfortunately, this often leads to inefficiencies including inventory costs and the need for middlemen and third party distribution channels. The system of the present invention offers the opportunity to eliminate or greatly reduce such inefficiencies by allowing a seller to custom manufacture based upon real demand rather than estimates thereof or assumptions relating thereto. The present invention is most effective in reducing the previous inefficiencies with respect to orders for products and services which are cyclical, predictable and prepaid.
Thus, in one embodiment of the present invention, the profiling engine interacts with buyers and sellers to effectively place both buyers and sellers in particular classes and categories of interest to these buyers and sellers. For example, one such class may be a custom manufacturing class whereby a seller states that it is willing to receive and accept collective orders from large groups of buyers far enough in advance that they can custom manufacture such an order. A buyer may also elect to participate in a custom manufacturing program whereby such a buyer would be grouped with other similarly interested buyers for a product or service. As a result, for example, a paper manufacturer may then be able to custom manufacture 100,000 reams of paper for a custom manufacturing order with the knowledge that once manufactured, the goods will ship directly to specific buyer without the need for specialized (and expensive) distribution channels. Custom orders can also be set up to be provided on a recurring schedule. For example, a group of buyers may be organized so that such group, through the system of the present invention, is set up to pay for and receive one or more particular items and/or services on a regular basis. Additionally, the supplier meeting the need may permit the number of buyers in the group and/or the purchase quantity to increase over time or the supplier may require the volume and/or number of purchasers to be constant.
One of the purposes of the Profiling and Matching Engine is to establish a rules-based system that profiles buyers and sellers at the point of initial registration and over time and learns their buying and selling characteristics. These characteristics will in turn be used to match and aggregate groups of similar buyers into collective buying groups. These collective buying groups will then be matched to groups of sellers whose profiles match the characteristics that the buyers require which may include but not be limited to the types of products or services, quantity, geography, time and shipping needs.
The characteristics used in profiling and matching buyers and sellers include but are not limited to the following list of discrete data points: Geography Quantity Pricing Time (time between re-supply, time to shipping, time to purchase . . . ) Types of Products or Services Industry Type Approval Process/Permissions Payment Methods/Account Information Credit Rating
These data points will be continuously cross-correlated between each other and across buyers to find, match and aggregate buyers with similar buying patterns and needs and present them to groups of sellers. These discrete data points make up in the whole a user's buying patterns that help the profiling and matching engine to collect similar buyers together.
A similar model of profiling is used to profile sellers and their selling patterns over time to determine which sellers match a buying groups needs in terms of products, services, pricing, time and any other relevant or material profiling criteria. In the case of sellers, particular characteristics such as inventory, capacity, manufacturing capabilities, production cycle times, industry ratings, product specifications and ratings as well as others may be included within the seller profile.
As time goes on and specific buyers and sellers enter more and more purchase orders and supply commitments, respectively, the databases are updated to include a better and better reflection of particular characteristics of both buyers and sellers. This, in turn, allows TPS 20 to more effectively match buyers and sellers both on an ongoing basis and with respect to particular transactions. Thus, the profiling system becomes more and more intelligent over time about users buying and selling patterns and becomes more efficient about matching them together.
Internet Browser Application
The present invention may be practiced in connection with a client or server based Internet application. According to this embodiment, software resident on a server, on the client or via a dynamic download such as Java or some other similar executable, functions to permit buyers to select products and services which they are interested in for purchase. In this embodiment, an icon, logo or other identifying characteristic is displayed somewhere on the screen viewable by the user as the user "surfs the net". By way of example, an icon may be displayed at the bottom right hand corner of the browser window. By selecting the icon the user may be directed to an internet page or set of pages whereby they can order products and services through system 20 and the processes associated therewith.
The icon may also allow buyers to join groups for upcoming product purchases while surfing the web. In this model, a user browses the web to find a specific product or service that he/she would like to buy and then clicks an icon that resides on the desktop (either in the systems tray, on a separate button bar, or in the start menu) or even within a web page or an Internet browser. In one embodiment, the user clicking the icon initiates a program residing on the desktop to record the current web page and, using a search technique known in the art, locates a product or service identifier (i.e.--an ISBN number, SKU number, or another public assigned reference number given by a third party), and automatically adds the user to the respective group of aggregate buyers. The user may have the option to enter additional purchase-specific data fields such as pricing requirements, purchase timeline/needs, etc. Once added, the program notifies the user that he/she has been successfully added to the group and reports on the groups current number of aggregated users and status of order. The button may also provide access to all of the users current groups and pending purchases so he/she may modify or delete them at any time (pre-purchase).
The icon may also be used as a simple buyer aggregation tool whereby the user directly enters purchase information about the product without using search process described above. In the event that the user's profile indicates an interest in a pending purchase group, the user may be notified via a "pop-up" window that is triggered by clicking the icon. Additional method for buyer aggregation include using the telephone to join groups by leaving a voice message, using voice recognition software, or using a menu-driven phone system or by traditional mail delivery (postal, FedEx, UPS, etc.). In each of these scenarios, the user may access/refer to his/her profile, request the ability to join a product-purchasing group, and receive a confirmation and group status report.
An additional embodiment of this invention is an alerting or metering functionality that alerts buyers regarding how many buyers have joined a group buy and much time is left before the group order is closed. Such an alerting or metering functionality is important to allow buyers and sellers know how many more buyers are needed before a collective sell is closed and submitted to the Reverse Auction Process.
Another embodiment of this invention is a self-organizing community function that allows similarly interested buyers to join self-organized communities dedicated to a specific interest, industry, product or service. Such communities of buyers can in turn alert one another regarding buy and sell orders and help members of their communities join a collective buy.
Pre-paid and Post-paid Collective Procurement Identification System
Groups of buyers may join to buy or commit to buy a service or product in advance of use or delivery. This method is especially effective for non-time sensitive, location-specific, continuous use, sporadic use or non-deliverable items. In this case, buyers will use some form of identification at the point of use to identify them as belonging to the collective group of buyers. Identification may be in the form of a driver's license, identification number or some form of membership card recording the collective procurement order. These identification cards or numbers allow groups of buyers to buy items well in advance of use and then be able to purchase the item or service at a discount when they actually need the said item or service. In one example, a group of buyers would commit to buying $1000 of shipping from Federal Express. The group of buyers may then each receive some form of identification in the shape of a number, card or data that they can then use whenever they use Federal Express. That identification allows them to receive the group discount they received from the collective purchase of shipping services from Federal Express. In this embodiment the payment may be in the form of a pre-paid or post-paid arrangement where the buyers either make payment prior to using the service or at the point of use or after the point of use of the service. Pre-paid or post-paid arrangements may be in the form of a one time lump payment or periodic payments with or without interest.
While various preferred embodiments of the present invention have been illustrated and described, it will be apparent that various modifications and alterations may be made thereto without departing from the spirit of the invention or the scope of the appended claims. By way of example only, the present invention may be practiced in various environments and on various platforms including handheld PCs, personal digital assistants and wireless and wired telecommunications products and networks.
Apparatus, method and system for improving application performance across a communications network
| United States Patent | 7,085,825 |
| Pishevar , et al. | August 1, 2006 |
Apparatus, method and system for improving application performance across a communications network
An apparatus, method and system to enable dynamic replication of Web servers across a wide area in response to access patterns by Web clients as well as in response to customer requests. The method for dynamically replicating one or more parent nodes on a network in response to a user request by a policy manager. The policy manager transmits the user request to an event module. The event module transmits the user request to a data consistency module, wherein the data consistency module maintains integrity of the data on the parent node. The event system communicates with a resource management module to ensure proper utilization of network resources, and transmits the routing request to a request routing module for appropriately balancing the network load. The request routing module is capable of providing optimal routing based on the network resources.
| Current U.S. Class: | 709/221 ; 709/204; 709/220; 709/222; 709/226; 709/238; 709/241; 718/100; 718/101; 718/102; 718/103; 718/104; 718/105; 718/106 |
| Current International Class: | G06F 15/177 (20060101) |
| Field of Search: | 709/204,238,241,220-222,226 718/100-106 |
|
| 6078943 | June 2000 | Yu | ||
|
| 6195680 | February 2001 | Goldszmidt et al. | ||
|
| 6424992 | July 2002 | Devarakonda et al. | ||
|
| 6587866 | July 2003 | Modi et al. | ||
|
| 2002/0078263 | June 2002 | Darling et al. | ||
|
| 2002/0194251 | December 2002 | Richter et al. | ||
|
| 2002/0199014 | December 2002 | Yang et al. | ||
|
| 2003/0126200 | July 2003 | Wolff | ||
|
| 2005/0010653 | January 2005 | McCanne | ||
|
|
Assistant Examiner: Patel; Niketa I.
Attorney, Agent or Firm:
Priority is claimed under 35 U.S.C. .sctn.119(e) for: Provisional Application No. 60/278,876, filed Mar. 26, 2001.
What is claimed is:
1. A method for event routing in a network comprising more than one node, the method comprising: assigning a node to a user; storing user data only on the node assigned to the user; receiving a request from the user; parsing the request to obtain values therefrom; determining whether the node can handle an event corresponding to the request based on the values, and when the node can not handle the event: identifying a plurality of nodes capable of handling the event based on the values; determining node usage of the plurality of nodes; selecting an appropriate node from the plurality of nodes for handling the event, based on the node usage; and copying applications and the user data from the node assigned to the user to the appropriate node, after which the appropriate node handles the request.
2. The method of claim 1, wherein the plurality of nodes capable of handling the event are identified by comparing a module type value in the request to a node lookup table located on the network.
3. The method of claim 2, wherein the node usage is determined by ranking the plurality of nodes in accordance with usage statistics in a resource usage list.
4. The method of claim 3, wherein the appropriate node for performing the event thereon is selected based on a least-used node algorithm.
5. The method of claim 3, wherein the appropriate node for performing the event thereon is selected based on an algorithm for determining a least-used node for an anticipated time of use.
6. The method of claim 3, wherein the appropriate node for performing the event thereon is selected based on an algorithm for determining a node most capable of performing the event.
7. The method of claim 6, wherein the request is parsed to obtain values of a plurality of fields for making comparison to data stored in the node lookup table and the resource usage list.
FIELD
The present invention relates generally to computer systems and server software, and more particularly to an apparatus, method, and system for creating, managing and positioning application instances in strategic locations to increase utility and performance across a communications network.
BACKGROUND
Information Technology Systems
Typically, users, which may be people or other systems, engage computers to facilitate information processing. A computer operating system enables and facilitates users to access and operate computer information technology. Information technology systems provide interfaces that allow users to access and operate the various systems.
User Interface
The function of computer interfaces such as cursors, menus, and window components are, in many respects, similar to automobile operation interfaces. Automobile operation interfaces such as steering wheels, gearshifts, and speedometers facilitate the access, operation, and display of automobile resources, functionality, and status. Computer interaction interfaces such as cursors, menus, and windows similarly facilitate the access, operation, and display of 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 or Microsoft's Windows provide a baseline and means of accessing and displaying information.
Networks
Networks are commonly thought to consist of the interconnection and interoperation of clients, servers, and intermediary nodes in a graph topology. It should be noted that the term "server" as used herein refers generally to a computer, other device, software, or combination thereof that processes and responds to the requests of remote users across a communications network. Servers serve their information to requesting "clients." A computer, other device, software, 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.
Transmission Control Protocol-Internet Protocol (TCP/IP)
The proliferation and expansion of computer systems, databases, and networks of computers has been facilitated by an interconnection of such systems and networks in an extraterritorial communications network commonly referred to as the Internet. The Internet has developed and largely employs the Transmission Control Protocol-Internet Protocol (TCP/IP). TCP/IP was developed by a Department of Defense (DoD) research project to interconnect networks made by various and varying network vendors as a foundation for a network of networks, i.e., the Internet. The development of TCP/IP was in part driven by a requirement by the DoD to have a network that will continue to operate even if damaged during battle, thus allowing for information to be routed around damaged portions of the communications network to destination addresses. Of course, if the destination address itself is rendered inoperable, such routing will not be possible.
The Internet is a packet-switched network and thus, information on the Internet is broken up into pieces, called packets, and transmitted in packet form. The packets contain IP addressing information called headers, which are used by routers to facilitate the delivery of the packets from a source to a destination across intermediary nodes on the Internet.
The IP component of the protocol is responsible for routing packets of information based on a four byte addressing mechanism; the address is written as four numbers separated by dots, each number ranging from 0 to 255, e.g., "123.255.0.123". IP addresses are assigned by Internet authorities and registration agencies, and are unique.
The TCP portion of the protocol is used for verifying that packets of information are correctly received by the destination computer from the source, and if not, to retransmit corrupt packets. Other transmission control protocols are also commonly used that do not guarantee delivery, such as User Datagram Protocol (UDP).
World Wide Web
The proliferation and expansion of computer systems, databases, the Internet, and particularly the World Wide Web (the web), have resulted in a vast and diverse collection of information. Various user interfaces that facilitate the interaction of users with information technology systems (i.e., people using computers) are currently in use. An information navigation interface called WorldWideWeb.app (the web) was developed in late 1990. Subsequently, information navigation interfaces such as web browsers have become widely available on almost every computer operating system platform.
Generally, the web is the manifestation and result of a synergetic interoperation between user interfaces (e.g., web browsers), servers, distributed information, protocols, and specifications. Web browsers were designed to facilitate navigation and access to information, while information servers were designed to facilitate provision of information. Typically, web browsers and information servers are disposed in communication with one another through a communications network. As such, information servers typically provide information to users employing web browsers for navigating and accessing information about the web. Microsoft's Internet Explorer and Netscape Navigator are examples of web browsers. In addition, navigation user interface devices such as WebTV have also been implemented to facilitate web navigation. Microsoft's Information Server and Apache are examples of information servers, i.e., their function is to serve information to users that typically access the information by way of web browsers.
Distributed Information Technology
The proliferation and expansion of computer information systems coincides with an increase in demand on network applications. The increased use of various applications across communications networks has resulted in increased network traffic. Furthermore, new network applications increasingly involve larger sized transmissions, which has resulted in increased bandwidth problems. The growing use of applications across communications network has resulted in an overall problem with regard to network application transactions and transmission delivery speeds. Such network speed problems in many instances frustrate users.
SUMMARY
One embodiment of the present invention solves many of the above network bandwidth, speed, and traffic problems by employing dynamic application replication and resource allocation. In a nutshell, application replication is a mechanism for allowing users/subscribers of the present invention to dynamically create copies of software on different servers (i.e., computer hardware nodes) and enabling the applications in new environments, while maintaining consistency of their datasets on the different nodes.
In one embodiment of the present invention, the system comprises Web servers that are capable of dynamically replicating themselves across the wide area in response to access patterns by Web clients. The present system enables scaling across temporal and geographic spikes in client demand for particular Web services. According to this embodiment, the system allows a server to shed its load onto other idle servers within the network. The other idle servers are able to satisfy the same requests as the original server, including requests for both static as well as dynamically generated objects.
According to another embodiment of the present invention, the system is capable of dynamically (i.e., without human intervention) receiving a customers' request for nodal activity on one or more servers at different geographical locations within the network. The nodal activity by the customer may comprise a request for a new node(s) to use, removal of existing node(s) from use, changing the usage pattern with respect to existing node(s). In response, the present system automatically, and on the fly, creates, deletes and/or modifies nodes to accommodate the users' requests.
The present invention is capable of replicating an existing node by replicating applications and/or data from an existing node to a new node in response to a user request. Replicating existing nodes requires that the system ensure data and application between the different nodes belonging to a given user, process and/or a process, as well as to the new node being created. On the other hand, where existing nodes are to be deleted, processes on nodes are to be turned on and/or off, and/or operational policies of the nodes reprogrammed, the present system ensures that the integrity and consistency of the existing applications and/or data is maintained.
The above advantages and features are of representative embodiments only, and are not exhaustive and/or exclusive. They are presented only to assist in understanding the invention. It should be understood that they are not representative of all the inventions defined by the claims, to be considered limitations on the invention as defined by the claims, or limitations on equivalents to the claims. For instance, some of these advantages may be mutually contradictory, in that they cannot be simultaneously present in a single embodiment. Similarly, some advantages are applicable to one aspect of the invention, and inapplicable to others. Furthermore, certain aspects of the claimed invention have not been discussed herein. However, no inference should be drawn regarding those discussed herein relative to those not discussed herein other than for purposes of space and reducing repetition. Thus, this summary of features and advantages should not be considered dispositive in determining equivalence. Additional features and advantages of the invention will become apparent in the following description, from the drawings, and from the claims.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings illustrate certain embodiments of the present invention.
FIG. 1 illustrates a centralized controller according to one embodiment;
FIG. 2 illustrates another embodiment in the form of a distributed system through a communications network;
FIG. 3 illustrates another embodiment of a Application Replicator Server (ARS) and various user system interactions;
FIG. 4 illustrates one embodiment of an ARS and module components;
FIG. 5 illustrates one embodiment of the ARS system in accordance with the present invention;
FIG. 6 provides a flow diagram of the different steps taken by the policy manager;
FIG. 7 illustrates the flow for creating a new application node in response to the user request;
FIG. 8 illustrates the flow for maintaining and determining the resource usage during the creation, deletion and/or modification of new application nodes;
FIG. 9 provides an overview of the creation of the bill of materials on the Application Resource Module (ARM);
FIG. 10 provides a flow diagram for the deletion of an application node on the ARM;
FIG. 11 illustrates the flow for turning off an existing turned-on application node on the ARM;
FIG. 12 provides a flow diagram of the process of turning on an application node on the ARM;
FIG. 13 illustrates the flow necessary for changing the consistency and/or the priority of the node under operation;
FIG. 14 illustrates the message parsing routine that the event system module 503 must undertake;
FIG. 15 provides an overview of the flow for the event system routing mechanism; and
FIG. 16 provides an overview of the request routing server of the present invention.
DETAILED DESCRIPTION
Actors and Resources
The present invention involves various actors and/or resources. Generally, the actors take on three forms: (1) accessers such as a user and/or commuter, (2) providers, and (3) facilitators such as an Application Replicator Server (ARS) 125. An accesser may be a human and/or system embodying the role of a buyer, client, customer, user, and/or the like. Accessers and providers may affect the access of a resource. A provider may be a human, entity, seller, system, and/or user that engages in the purveying of goods, information, services, and/or the like. Typically a provider engages in commerce. A facilitator facilitates in matching the wants and/or requests of accessers with the provisions of providers. In the context of electronic commerce (E-commerce) one or more computer systemizations executing software (such as information server software) may embody the purveying role of the facilitator.
A typical resource is an information server, which may be a computer systemization 102. An information server module 116 is software that executes on an information server and/or centralized controller 101 of FIG. 1. An ARS facilitates communications between accessers and providers. The ARS 425 is another resource, which may be employed by accessers such as buyers, through a facilitator so as to affect and/or obtain information from the provider. Resources may also be controllers, conventional computer systems and software, associated enabling systems and/or software, and/or the like.
With reference to the figures, various embodiments of the present invention will now be described in greater detail. It is to be understood that the tasks shown in the figures and described in this description can be sequenced in many different orders to achieve the desired result. The order or sequence of tasks illustrated in the figures is merely intended to be exemplary of the concepts defined herein.
Centralized Controller
FIG. 1 illustrates one embodiment incorporated into a centralized controller. In this embodiment, the centralized controller 101 may be connected to and/or communicate with entities such as, but not limited to: one or more users from user input devices 111; peripheral devices 112; base units 131, and/or a communications network 113. The centralized controller may even be connected to and/or communicate with a cryptographic processor device 128.
A typical centralized controller 101 may be based on common computer systems that may comprise, but are not limited to, components such as: a computer systemization 102 connected to a storage device 114. Storage devices may be a fixed hard disk drive, and/or other devices of the like.
A computer systemization 102 may comprise a clock 130, central processing unit (CPU) 103, a read only memory (ROM) 106, a random access memory (RAM) 105, and/or an interface bus 107, and conventionally, although not necessarily, are all interconnected and/or communicating through a system bus 104. The system clock typically has a crystal oscillator and provides a base signal. The clock is typically coupled to the system bus and various means known to those skilled in the art 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. Optionally, a cryptographic processor 126 may similarly be connected to the system bus. 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 conventional computer systems.
A centralized controller and/or a computer systemization may employ various forms of memory 129. In a typical configuration, the memory 129 may include ROM, RAM, and a storage device. Non-conventional software modules such as an ARS Module 125, may be loaded into memory.
The CPU comprises at least one high-speed data processor adequate to execute program modules for executing user and/or system-generated requests. The CPU is a conventional microprocessor such as the Intel Pentium Processor and/or the like. The CPU interacts memory to execute stored program code according to conventional data processing techniques.
Interface bus(ses) 107 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) 108, storage interfaces 109, network interfaces 110, and/or the like. Optionally, cryptographic processor interfaces 127 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 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 (PCI), Personal Computer Memory Card International Association (PCMCIA), and/or the like.
Storage interfaces 109 may accept, communicate, and/or connect to a number of storage devices such as, but not limited to: storage devices 114, removable disc devices, and/or the like. Storage interfaces may employ connection protocols such as, but not limited to: (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 110 may accept, communicate, and/or connect to a communications network 113. 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), IEEE 802.11b, Token Ring, wireless connection, and/or the like. A communications network may be: a direct connection; the Internet; a Local Area Network (LAN); 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, etc.); and/or the like. A network interface may be regarded as a specialized form of an input/output interface. Base unit interfaces 133 may be conventional network interface 110 and/or variants thereof that are connected to base units 131. An example of a base unit interface 133 is a T1/E1 connection.
I/O interfaces 108 may accept, communicate, and/or connect to user input devices 111, peripheral devices 112, cryptographic processor devices 128, 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 1394; infrared; joystick; keyboard; midi; optical; PC AT; PS/2; parallel; radio; serial; USB; video: BNC, composite, digital, RCA, S-Video, VGA, and/or the like; wireless; and/or the like. A common output device is a video display, which typically comprises a CRT with an interface (e.g., VGA circuitry and cable) that accepts signals from a video interface. The video interface composites information generated by a computer systemization and generates video signals based on the composited information. Typically, the video interface provides the composited video information through a video connection interface that accepts a video display interface (e.g., a VGA connector accepting a VGA display cable).
User input devices 111 may be card readers, dongles, finger print readers, gloves, graphics pads, joysticks, keyboards, mouse (mice), trackballs, trackpads, retina readers, and/or the like.
Peripheral devices 112 may be connected and/or communicate with or to I/O and/or with or to other facilities of the like such as network interfaces, storage interfaces, and/or the like). Peripheral devices may be cameras, dongles (for copy protection, ensuring secure transactions as a digital signature, and/or the like), external processors (for added functionality), goggles, microphones, monitors, network interfaces, printers, scanners, storage devices, visors, and/or the like.
Cryptographic units such as, but not limited to, microcontrollers, processors 126, interfaces 127, and/or devices 128 may be attached, and/or communicate with the centralized controller. In one embodiment, a MC68HC16 microcontroller, commonly manufactured by Motorola Inc., may be used for and/or within cryptographic units. The MC68HC 16 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 Roadrunner284.
A storage device 114 may be any conventional computer system storage. Commonly a storage device is a fixed hard disk. However, it is to be understood that a computer systemization may be configured to employ many types of memory 129. 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 is not preferred and would result in an extremely slow rate of operation. Generally, any mechanization and/or embodiment allowing a processor to affect the storage and/or retrieval of information is memory 129. Thus, a computer systemization generally requires and makes use of memory. 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.
The storage devices 114 may contain a collection of program and/or database modules and/or data such as, but not limited to: an operating system module 115 (operating system); an information server module 116 (information server); a user interface module 117 (user interface); a web browser module 118 (web browser); databases 119 including tables such as but not limited to a user table 119a, provider table 119b, Bill of Materials (BOM) table 119c (tracking requests, advertisements, and/or the like), Module-type table 119d, advertisements table 119e, and/or the like; a cryptographic server module 120 (cryptographic server); ARS module 125, and/or the like (i.e., collectively a module collection). These modules may be stored and accessed from the storage devices and/or from storage devices accessible through an interface bus. Although these modules typically and preferably are stored in a local storage device, they may also be stored in peripheral devices, RAM, remote storage facilities through a communications network, ROM, and/or the like.
The operating system 115 is executable program code facilitating the operation of a centralized controller. Typically, the operating system facilitates access of I/O, network interfaces, peripheral devices, storage devices, and/or the like. The operating system preferably is a conventional product such as a Microsoft Windows NT Server and/or Unix operating systems. Preferably, the operating system is highly fault tolerant, scalable, and secure. An operating system may communicate to and/or with other modules in a module collection, including itself, and/or facilities of the like. Conventionally, the operating system communicates with other program modules, user interfaces, and/or the like. For example, the operating system may contain, communicate, generate, obtain, and/or provide program module, system, user, and/or data communications, requests, and/or responses. The operating system, once executed by the CPU, may interact with base units, communications networks, data, I/O, peripheral devices, program modules, memory, user input devices, and/or the like. Preferably, the operating system provides communications protocols that allow the centralized controller to communicate with other entities through a communications network 113. The preferred protocol for communicating a communications network is transmission control protocol Internet protocol (TCP/IP). Protocols for communicating with base units 131 may include TCP/IP, X.25, SNA, and/or the like; the preferred embodiment will depend on the base unit to which an ARS is attached and/or other deployment factors.
Decentralized Controllers
FIG. 2 illustrates another embodiment of a system incorporating the present disclosure. In this embodiment, the centralized controller 101 embodiment of FIG. 1 has been decentralized into components such as, but not limited to: an information server controller 201; user interface controller 202a and/or alternatively a user interface device 202b; a web browser controller 203; database controllers such as, but not limited to accesser database controllers 204a, provider database controllers 204b, transaction database controllers (not shown in the Figure), Time & Place database controllers (not show in the Figure), advertisements database controllers, and/or the like; a cryptographic controller 205; a ARS controller 206; and a predictive cache controller 207, and/or the like (i.e., collectively decentralized server controllers). The aforementioned controllers of FIG. 2 may be attached, coupled, interconnected, and/or communicate through the communications network 113 and/or like facility.
An information server controller 201 is comprised similarly to the centralized controller of FIG. 1 except it does not require an entire module collection other than an information server module. An information server module 116 is stored program code that is executed by the CPU. The information server may be a conventional Internet information server such as, but not limited to, Microsoft's Internet Information Server and/or the Apache Software Foundation's Apache. Preferably, the information server allows for the execution of program modules through facilities such as C++, Java, JavaScript, ActiveX, Common Gateway Interface (CGI) scripts, Active Server Page (ASP), and/or the like. Preferably the information server supports secure communications protocols such as, but not limited to, Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), and/or the like. Conventionally, an 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 modules. An information server may communicate to and/or with other modules in a module collection, including itself, and/or facilities of the like. Most frequently, the information server communicates with operating systems, other program modules, user interfaces, web browsers, and/or the like. An information server may contain, communicate, generate, obtain, and/or provide program module, system, user, and/or data communications, requests, and/or responses.
In an alternative embodiment, the information server controller 201 may itself be further distributed across several computer systemizations. The information server modules 116, may itself run partially on the various computer systemizations such that part of the information server module 116 runs on the numerous systemizations to increase both fault tolerance and load balancing. It is to be understood that any single and/or multiple program modules may similarly be distributed across several computer systemizations for similar and/or varying reasons.
A user interface controller 202a is comprised similarly to the centralized controller of FIG. 1 except it does not require an entire module collection other than an user interface module 117. A user interface is stored program code that is executed by the CPU. Preferably, the user interface is a conventional user interface as provided by, with, and/or atop operating systems and/or operating environments such as Apple Macintosh OS, e.g., Aqua, Microsoft Windows (NT), Unix X Windows (KDE, Gnome, and/or the like), and/or the like. The user interface may allow for the display, execution, interaction, manipulation, and/or operation of program modules and/or system facilities through 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 modules in a module collection, including itself, and/or facilities of the like. Most frequently, the user interface communicates with operating systems, other program modules, and/or the like. The user interface may contain, communicate, generate, obtain, and/or provide program module, system, user, and/or data communications, requests, and/or responses.
In alternative embodiments, a user interface device 202b may take the place of and/or be used in conjunction with a user interface controller. The user interface device may be a consumer electronics online access device (e.g., Philips Magnavox Inc.'s WebTV), personal digital assistant (PDA), pager, cellular telephone, a terminal, and/or the like.
A web browser controller 203 is comprised similarly to the centralized controller of FIG. 1 except it does not require an entire module collection other than web browser module 118. A web browser is stored program code that is executed by the CPU. Preferably, the web browser is a conventional hypertext viewing application such as Microsoft Internet Explorer or Netscape Navigator (preferably with 128 bit encryption by way of HTTPS, SSL, and/or the like). Some web browsers allow for the execution of program modules through facilities such as Java, JavaScript, ActiveX, 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 modules in a module collection, including itself, and/or facilities of the like. Most frequently, the web browser communicates with information servers, operating systems, integrated program modules (e.g., plug-ins), and/or the like; e.g., it may contain, communicate, generate, obtain, and/or provide program module, system, user, and/or data communications, requests, and/or responses. Of course, in place of a web browser a proprietary accesser controller may be developed to perform similar functions. An accesser module would similarly affect the obtaining and the provision of information to accessers, providers, providers' agents, and facilitators from an ARS and/or any proprietary facilitator systems. The accesser module may be nugatory on systems employing standard web browsers. For added security, such an accesser module, and consequently any resulting accesser controllers, could be configured to communicate directly with the ARS without an intermediary information server to further enhance security.
The database controllers 204 are comprised similarly to the centralized controller of FIG. 1 except it does not require an entire module collection other than database modules 119. A database is stored program code that is executed by the CPU and it is stored data; the stored program code portion configuring the CPU to process the stored data. Preferably, the database is 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. A database may communicate to and/or with other modules in a module collection, including itself, and/or facilities of the like. Most frequently, the database communicates with information servers, operating systems, other program modules, and/or the like. The database may contain, communicate, generate, obtain, and/or provide program module, system, user, and/or data communications, requests, and/or responses.
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, a predictive cache database 119 of FIG. 1 may be implemented to include accesser 119a, provider 119b, Bill of Materials 119c, modules 119d, and advertisements 119e tables. In an alternative embodiment, these tables have been decentralized into their own databases and their respective database controllers (i.e., accesser database controller 204a, provider database controller 204b, transaction database controller 204c, time and place database controller 204d, and advertisements database controller 204e). Of course, employing standard data processing techniques, one may further distribute the databases over several computer systemizations and/or storage devices. Similarly, configurations of the database controllers 204 may be varied by consolidating and/or distributing the various database modules 119a e. The ARS system may be configured to keep track of accesser requests and various transactions tracking via database controllers 204a e.
An accesser database controller 204a is a specialized controller designed to facilitate accesser-related transactions. A facilitator may maintain an accesser database to keep track of accessers' accounts and/or transactions. The accesser database controller employs an accesser database module 119a.
A provider database controller 204b is a specialized controller designed to facilitate provider-related transactions. The provider database may store information such as, but not limited to advertisements, locations of data to cache, data to cache, and/or the like.
A transaction database controller 204c is a specialized controller designed to facilitate both accesser and provider transactions. The transaction database may store information relating to a transaction such as, but not limited to accesser requests, and provider replies, requested data, and/or the like.
A time and place database controller 204d is a specialized controller designed to facilitate transactions. The time and place database may store information relating to the whereabouts of various base units, providers, accessers, and/or the like. Furthermore, the database may store availability and demand levels at certain times for those base units, providers, accessers, and/or the like.
An advertisement database controller 204e is a specialized controller designed to facilitate advertising. The advertisements database may store advertisement, targeting criteria for the advertisement, and/or the like.
A cryptographic server controller 205 is comprised similarly to the centralized controller of FIG. 1 except it does not require an entire module collection other than cryptographic server module 220. A cryptographic server module is stored program code that is executed by the CPU 103 of FIG. 1, cryptographic processor 126 of FIG. 1, cryptographic processor interface 127 of FIG. 1, cryptographic processor device 128 of FIG. 1, and/or the like. The cryptographic processor interfaces may allow for expedition of encryption and/or decryption requests by the cryptographic server; however, the cryptographic server, alternatively, may run on a conventional CPU. The cryptographic server may allow for the encryption and/or decryption of provided data. The cryptographic server may also allow for both symmetric and asymmetric (e.g., Pretty Good Protection (PGP)) encryption and/or decryption. The cryptographic server may further allow conventional cryptographic techniques such as, but not limited to digital certificates (e.g., X.509 authentication framework), digital signatures, dual signatures, enveloping, public key management, and/or the like. In addition, the cryptographic server may facilitate numerous encryption and/or decryption protocols such as, but not limited to: Data Encryption Standard (DES), Elliptical Curve Encryption (ECC), International Data Encryption Algorithm (IDEA), Message Digest 5 (MD5, which is a one way hash function), RC5 (Rivest Cipher), 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.
A cryptographic server may communicate to and/or with other modules in a module collection, including itself, and/or facilities of the like. The cryptographic server may support encryption schemes allowing for the secure transmission of information across a communications network. Often, the cryptographic server communicates with information servers, operating systems, other program modules, and/or the like. The cryptographic server may contain, communicate, generate, obtain, and/or provide program module, system, user, and/or data communications, requests, and/or responses.
An ARS server controller 206 is comprised similarly to the centralized controller of FIG. 1 except it does not require an entire module collection other than an ARS module 125. As noted above, the ARS module 125 is stored program code that is executed by the CPU. Generally, the ARS 125 affects obtaining and the provision of communication, information, transactions, and/or the like between facilitator modules for accessers. The ARS 125 adds the ability to anticipate, predict, prefetch and ready information for subsequent accesser requests before the accessers make any such requests. Generally, the ARS 125 acts as an interface to accessers requesting data and the data providers. The ARS 125 coordinates with the various database controllers to predict data requests and provide the predicted data to accessers by prefetching the anticipated requests into a predictive cache. The ARS that enables communications between a provider and a facilitator's commerce systems maybe be developed by employing standard development tools such as, but not limited to: C, shell scripts, Java, Javascript, SQL commands, web application server extensions, Apache modules, Perl scripts, binary executables, and/or other mapping tools, and/or the like. Some embodiments may also and/or alternatively employ a mix of program modules such as, but not limited to modules discussed in FIG. 4, and/or the like. According to one embodiment, the ARS server employs a cryptographic server to encrypt and decrypt communications. The ARS may store requests, store requested data, anticipate and prefetch data, provide predictive advertising, retrieve accesser requests, and much more. The ARS server may communicate to and/or with other modules in a module collection, including itself, and/or facilities of the like. Most frequently, the ARS server communicates with databases, information servers, operating systems, other program modules, and/or the like. The ARS server may contain, communicate, generate, obtain, and/or provide program module, system, user, and/or data communications, requests, and/or responses.
The predictive cache controller 207 is comprised similarly to the centralized controller of FIG. 1 except it does not require an entire module collection other than the RS module 125. A predictive cache is a repository where data cached by an ARS is stored. The predictive cache itself may simply be a file system for storing cached data into a storage device 114, or in an alternative embodiment, the predictive cache may be a database and/or database table that stores data as instructed by the ARS. A cache is stored data; the stored data is typically a copy of requested data from a provider, which typically, is more remote from an accesser. The cached data may be accessed in lieu of a more remote source of the data, thereby improving overall processing speed. The predictive cache is the reservoir of data flow being controlled by an ARS. In one non-limiting embodiment, the ARS fills the predictive cache with common search requests made between accessers and providers. However, a predictive cache may act as an accelerating buffer between any number of systems and databases. The predictive cache may store transactions. A cache may be a communications medium facilitating communication between modules in a module collection, including itself, and/or facilities of the like. Most frequently, the predictive cache communications with a ARS, information server(s), operating system(s), other program module(s), and/or the like; e.g. it may contain, communicate, generate, obtain, and/or provide program module, system, user, and/or data communication(s), request(s), and/or response(s).
The functionality of any of the distributed server controllers may be combined, consolidated, and/or distributed in any number of ways to facilitate development and/or deployment. To accomplish recombining the functionality of the distributed server controllers, one may simply copy the executable program module code from the module collection and/or with other program modules, first ensuring the executable program module code has been compiled for the appropriate CPU of the controller for which it is destined, and/or data onto a local storage device of any of the various controllers. Similarly, the module collection may be combined in any number of ways to facilitate deployment and/or development. To accomplish this, one must simply 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 module 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 modules in the program module collection may be instantiated on a single controller, and/or across numerous controllers to improve performance through standard load balancing data processing techniques. Furthermore, single instances may also be distributed across multiple controllers and/or storage devices; e.g., databases.
All program module instances and controllers working in concert may do so through standard data processing communication techniques.
The preferred centralized and/or distributed controller configuration will depend on the context of system deployment. Factors such as, but not limited to, the capacity and/or location of the underlying hardware resources may affect deployment requirements and configuration. Regardless of if the configuration results in more consolidated and/or integrated program modules, results in a more distributed series of program modules, and/or results in some combination between a consolidated and/or distributed configuration, communication of data may be communicated, obtained, and/or provided. Instances of modules (from the module collection) consolidated into a common code base from the program module collection may communicate, obtain, and/or provide data. This may be accomplished through standard data processing 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 (intra-application communication).
If module collection components are discrete, separate, and/or external to one another, then communicating, obtaining, and/or providing data with and/or to other module components may be accomplished through standard data processing 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 Provider Architecture (CORBA), process pipes, shared files, and/or the like (inter-application communication). Messages sent between discrete module components 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, and or the like, which allow for the inclusion of message generation and parsing functionality within and between modules. Again, the preferable embodiment will depend upon the context of system deployment.
User Interaction Systems
FIG. 3 illustrates an overview of various ARS user systems interactions. Information servers 116 act as an in-between for ARS module components 125 and user interfaces 117, user interface devices 301, web browsers 118, and/or the like. Generally, the information servers take requests. The information server can make further requests of ARS server modules components 125. ARS module components comprise modules from the module collection, modules detailed in FIG. 4, and/or the like, except it does not include and/or require a web browser module, user interface module, and/or information server module. Both the information server and ARS module components may service multiple instances of any of the user interfaces, user interface device, and/or the like, such as user interface components. However, it is preferable for the information server to act as a proxy for ARS module components rather than them directly interfacing with user interface components. Also, there may be one or more instances of the information server and/or ARS module components that may severally or jointly interact with one another.
Generally, ARS module component service information servers, which in turn service user interface components, i.e., the information servers accept requests from accessers. FIG. 3 illustrates that components may be numerously instantiated and may service multiple and various components. For example, the user interface 117 may make numerous communications. In one embodiment, the user interface 117a makes two communication with an information server 116a while also making two communications with another information server 116b; all while another instance of a user interface 117b also communicates with the information servers 116a b. Similarly in another example, a user interface device(s) 301a b may make numerous communications. In this example, the user interface device 301a makes two communications, one with an information server 116a, and a second with another information server 116b; all while another instance of the user interface device 301b also makes two communications, also one with an information server 116a, and a second with the other information server 116b. Similarly, the web browser 118a communicates with an information server 116a while another instance of a web browser 118b also communicates another instance of the information server 116b.
Similarly, information server modules 116 and ARS module components 125 may make multiple communications and may be instantiated multiple times. For example, ARS module components 125 may make numerous communications. In this example, the ARS module component 125a makes three communications with an information server 116a, another information server 116b, and with another instance of a ARS module component 125b (also, the ARS module component 125a may communicate with itself). Similarly, the ARS module components 125b makes three communications with an information server 116a, another information server 116b, and with the first instance of ARS module components 125a (also, the ARS module components 125b may communicate with itself). It should be noted, all the communications taking place as illustrated in FIG. 3 by lines may take place over and/or through a communications network 113 of FIG. 1.
Application Replicator Server
FIG. 4 illustrates one embodiment of the ARS 425 and its module components. In one embodiment, users, e.g., providers, engage the ARS 425 through user interface interactions as discussed in FIG. 3 that are fed through an information server module 116 running on an information server controller 201 of FIG. 2, commonly called an "information server" or a "web server." As will be discussed in further detail in FIG. 5, the information server 416 acts as a gateway between a base unit 131 and a communications network 113, that are each in turn disposed in communication with accesser devices 411 and providers 417, respectively. Upon the user's traversal of the appropriate navigation location hosted by a particular information server module 116, the information server module will obtain data (e.g., HTML or any text based markup language; streaming audio, video, data; Wireless Markup Language (WML) data, and/or the like) from the ARS 425 to relay to the requesting user.
Information servers act as a gateway for users to access the ARS. Information servers obtain information to serve requests over communications networks in ways, and employ protocols, well known to those skilled in the art. Note that Information Servers servicing the ARS may act as a gateway to base units 131 and/or a communications network 113 through various network interfaces 110, 133 as discussed in FIG. 1.
As noted above, the ARS 425 enables the users to create new nodes in different servers for load-balancing and or other efficiency reasons, without any manual intervention by the hosts of the service providers. In other words, the ARS 25 of the present invention is capable of creating, modifying, deleting and/or the like new nodes on the fly, upon user/subscriber request. The ARS 425 comprises a plurality of different modules to enable the creation of new nodes for replicating new and/or existing applications, which communicate with the database 119, as described in more detail below.
The ARS 425 comprises an application replication module 401 that is responsible for replicating the applications in the new nodes being created, upon request from the user. The data consistency module (such as Tunable Availability and Consistency Tradeoffs (TACT)) 402 ensures that the data being replicated along with the applications remains consistent at the new nodes. The data consistency module 402 is generally a library layer between the database replica and the applications being used. The data consistency module 402 may comprise of toolkits that allow Internet services to flexibly and dynamically choose their own availability/consistency tradeoffs, enabling differentiated availability/consistency quality of service. In one embodiment, the system may be typically defined as a switch, wherein the system either provides strong consistency with reduced availability of the systems' resources, or vice versa. According to another embodiment, the data consistency module 402 may be a more complex system where the system may allow the specification of a consistency level metric that results in probabilistic guarantees about system availability. One of the features of the data consistency module 402 is the ability to dynamically trade consistency for availability and performance in response to current system, network and client characteristics.
The event system module 403 receives requests from users and automatically executes commands in accordance therewith as well as with pre-determined and pre-programmed logic therein.
The ARS 425 further comprises a configuration management module 405 which adds the appropriate values to the applications' configuration files. In a nutshell, the configuration management module 405 manages the modules created along with their configuration to ensure that the different modules and/or different nodes being created on the different servers have similar configuration and are compatible with other.
There exists a request routing module 404 which is responsible for dynamically routing user requests for services and application appropriately to for appropriate load balancing and optimal usage of user resources throughout. According to one embodiment, the request routing system 404 is capable of dynamically ensuring that user requests are evenly spread out geographically and temporarily over the entire network of servers in the present system. According to another embodiment, the request routing system 404 provides customers using the present system with optimal routing facilities based on real-time load balancing.
The ARS 425 further comprises a network monitoring module 406 which is responsible for ensuring that the network performance remains optimal and for reporting network status changes to the policy manager periodically. The network monitoring system 406 continues to monitor network performance over a period of time. The present system also comprises a policy manager module 407 which fires off events such as crating new replications of software on different computer hardware nodes, tearing down old replications, turning off replications for customers who have not paid for their services or for customers who do not wish to pay for new nodes being created. The policy manager module 407 is able to change consistency patterns and/or change resource constraints in response to user demands. The policy manger 407 is also responsible for activating different events in the network. For example, the policy manager, in response to user demands, is able to initiate the starting of a new replication, the ending of old replications, creation of new nodes or stopping the use of older nodes when necessary, when an appropriate user request is made.
The ARS 425 further comprises a customer configuration utility 408 which is really a Graphical User Interface (GUI) tool for users. The GUI is structured in such a way that it provides a user-friendly screen in which the users can decide the resources needed in accordance with their needs. The GUI configuration tool sets policies, such as the number of replications that a particular user needs in total, or needs to have live at any given time, the different status locations and the maximum payment policy that the user must abide by.
The present system further comprises a resource management module 409 which monitors the bandwidth of the network, the memory being utilized by the processes running in the network, the CPU regulators as well as it monitors all different parameters being effected by the running processes in the network.
Finally, the ARS 425 also comprises a billing module 410 which tracks the payment bills for the customers of the present system. The billing module comprises of logic which determines when users need to pay their bills, what their payment periods are, whether users will be automatically billed.
FIG. 5 provides an overall system-level view of the present invention, wherein the different modules in the ARS interact therebetween to make the replication mechanism work efficiently. It should be noted, that the different modules are capable of interacting therebetween in many different ways, and the scope of the present invention should not limited by some of the exemplary configurations shown and discussed hereinafter.
As noted above, the present system comprises an event system 503 which receives event requests and executes commands by messages passing, remote procedure calls and/or the like. The event requests are received from the users and are passed on to the different modules that comprise the present system and will be discussed in more detail below. For example, the event system may send a message to the data consistency module 502 to change the consistency settings of the data being used and stored in the present system. The Data consistency module 502 uses the TACT system to ensure an efficient balance between the consistency and availability levels of the data in the present system.
The event system 503 also interacts with the application replication module 501 which is responsible for replicating applications/software between different nodes. According to one embodiment, a user may decide to utilize a plurality of different nodes to better balance the load of their processes. As a result, the application replication module 501 will copy application files and/or software to the new replicated node ("child node") that is similar to the node being replicated ("parent node"). The application replication module 501 sets up the necessary databases and directories in that the new node being created or an older existing nodes being modified so that the replicated node has applications/software and/or necessary data that is the mirror image of the older nodes, which is important for ensuring that the data and the applications being run are consistent between all the nodes.
The application replication module 501 triggers events in the configuration management module 505. The configuration management module 505 provides the appropriate values to the configuration files of the applications. The configuration management module 505 also registers applications with the servers being used, the daemons, the ports and/or the like. The configuration management module 505 comprises programs that runs continuously and exist for the purpose of handling periodic service requests that the network expects to receive, and forwards the requests to other programs, processes, modules, and/or servers as appropriate.
The application management module 505 also interacts with the data consistency module 502, which is also known as the TACT system. The data consistency module 502 ensures the data being used, generated, altered are amended remains consistent between the different servers being used by the user. As noted above, the data consistency module 402 is generally a library layer between the database replica and the applications being used, which may comprise of toolkits that allow Internet services to flexibly and dynamically choose their own availability/consistency tradeoffs, enabling differentiated availability/consistency quality of service.
In accordance with the present invention, the event system 503 also causes the request routing system 504 to modify the appropriate settings. The request routing system 504 is responsible for routing the new replications being made. The request routing system 504 is also responsible for wide-area load balancing. As a result, the request routing system 504 is capable for maintaining an efficient load balance throughout the network. The request routing system 504 is also responsible for providing optimal routing of process and resource requests based on the real-time network conditions and available replications for particular users/customers. In accordance with one embodiment of the present invention, the request routing system 504 is provided with logic that allows it to dynamically decide the optimal routing based on existing highway conditions and users desired by user.
The request routing system 504 queries the network monitoring system 506 to receive information for properly handling routing requests. The network monitoring system 506 monitors the network performance and reports network status to the policy manager 507 as well as the request routing system 504. Once the request routing system 504 has made a routing decision, the decision is provided to the network monitoring system 506 for updating the list of processes, resources and/or nodes being monitored. The network monitoring system 506 reports the networks status, and/or any changes thereto to the policy manager 507. The reporting may be done periodically, intermittently or as defined by the various algorithms that may be utilized in accordance with user demands.
The policy manager 507 dynamically and in real-time fires off events in response to user demands, customer needs as well as in response to utilization of the network at any given point. The policy manager 507 creates new replications, tears down old replications, turns off replications that are already being made or are in existence. The policy manager 507 is also capable of changing the consistency levels of the data desired by particular users. In addition, the policy manager 507 changes the resource constraints to ensure efficient usage of the resources that exist. For example, according to one embodiment, the more constraints that are put on the resources being used, the less easy and frequent it is to change the state of the underlying resources. In accordance with the present invention, the policy manager 507 is also capable of dynamically adjusting the consistency in accordance with the availability of the data and/or applications desired by the user(s).
In accordance with the present invention, a customer configuration utility 508 configures policies for the policy manager 507. The customer configuration utility may be provided in a graphical user interface (GUI) which enables the user to set the appropriate policies, such as the number of live replications being performed at any given time, the desired number of static locations, the maximum payment policy and/or the like. The resources granted to any given user might be dependent on the payment policy chosen by that user. Since the present invention allows dynamic replication of nodes without any manual intervention, the customer configuration utility is capable of dynamically firing off requests for creating new nodes or removing existing nodes in response to user requests/demands.
The policy manger also interacts with the resource management modules 509 by configuring the parameters that are used and/or monitored by the resource management module. The resource management module monitors the network to ensure that the bandwidth, memory, the CPU, and/or the other resources are being utilized in the most efficient manner. Depending on the usage by a particular user, the resource management modules 509 reports information to the billing module 510.
The billing module 510 is responsible for using information provide by the resource management module 509 to bill the customers for their usage of the network. As noted above, the billing module 510 is capable of billing automatically on a periodic basis or on an intermittent basis depending on the user preference.
According to the invention, the various modules illustrated in FIG. 5 may interact with each other to ensure a dynamic, seamless, and scalable network. Thus, while a few exemplary embodiments have been described herein, the scope of the present invention is not to be limited by the discussed examples, but must be considered to include a variety of connections between the different modules.
FIG. 6 provides a flow diagram showing the different steps that are taken by the policy manager and its effect at the model node being created, altered and/or deleted by the present application by the system of the present invention.
In step 601, the policy manager 507 obtains a user request. The user request may comprise of the applications/software needed, the user identification, the maximum or minimum payment that the user is willing to pay, and/or the like. The policy manager 507 is able to determine dynamically, and in real-time, based on predetermined algorithms the different number of nodes that the user must be granted. The system may also be provided an indication of the geographical locations in the network where the user/customer wishes to create, alter and/or delete applications/software in accordance with their needs. In step 602, the policy manager 507 requests the resources that are needed and/or that will be used by the user for its needs. For example, the policy manager 507 may need to know the amount of usage of the TACT system that the users will require. The policy manger 507 may also need to know the amount of resources the user used prior to the new request made in steps 601.
Based on the user request, the present system determines the resources that are required for the user, in step 603. For example, according to one embodiment, the present system determines the applications and the data that the user will need. The present system also determined based on the user request, the application and data size that must be stored on the new nodes being created, old nodes being deleted and/or the existing nodes being modified. The model node that is being acted upon may also maintain activity logs in response to the request resource usage. Once the fixed resources are determined in step 603, the results are provided to the policy manager 507 in step 604.
In step 605, the policy manager 507 parses the request that was provided thereto. As a result of the parsing of the request, the policy manager 507 determines the amount of CPU resources that are needed, the hard drive size that is required and must be set aside, the load usage by the users, the usage frequency for the different times of usage of the server, the nodes being created, the locations of the users, peak times for usage, and/or the like. The policy manager 507 determines the peak times of the users' usage so that it can efficiently allocate the necessary resources for allowing efficient usage of the nodes being created, deleted and/or modified.
In step 606, the parsed result is compared to the current settings for the underlying user. In other words, if the user is already an existing subscriber of the current system, its current usage and pattern settings are compared to the new input provided in step 601. In step 607, the policy manager 507 determines the action(s) that need to be taken in response to the user request. Some of the actions that may be performed include adding a new node, removing an old node, turning off an existing turned-on existing node, turning on an existing turned-off node, changing the consistency levels of existing nodes, changing the constrains on the nodes, and/or the like.
As a result of determining the action that needs to be taken, new nodes may be created in step 608, an existing node may be deleted in step 609, an existing application node may be turned on in step 610, an existing application node may be turned off in step 611, and/or the consistency and/or priority of existing nodes may be changed in step 612.
In accordance with the present invention, an existing customer of the present server network may have certain nodes that are assigned thereto but are turned off in response to the users earlier requests. As a result, in step 610 an existing node that was initially assigned to the user but turned off may be turned back on in response to the usage change requested by the user. Similarly, an existing node that is in current usage by the user may be turned off in response to the user's new request in step 611. Once an action in response to user's request has been performed on the application nodes in steps 608 612, the system proceeds to step 613. In step 614, the policy manager 507 checks to determine whether the event must be terminated. In other words, the policy manager decides if it should end its activity that was initiated in step 601 in response to the user request. If the policy manager 507 determines that it must continue acting and receive new user requests, then the control is taken back to step 601 and the new user request is obtained from the same or some other user. On the other hand, where the policy manager 507 determines that its current activity flow must end, the process proceeds to step 615.
FIG. 7 provides an overview of the flow for creating a new application node in response to the user request. The flow for creating a new node starts at step 701, where, in response to the users request to create a new node in step 608 of FIG. 6, the policy manager initiates the process that will result in a new application node at the end of the present flow.
In step 702, the user's parsed request is compared to the resources usage list. The resource usage list maintains a listing of all the load availability, the sizes of the different usage by different users, the resources required to accomplish different tasks and/or the like. As a result, in step 703 the policy manager determines whether sufficient resources exist to support the user's request for adding a new node. To ensure that sufficient resources exist to support the user's request, the existing load usage of the network, and/or the sizes of the different tasks being run on the various different servers of the network are looked at. The existing resources are compared to the resources required for the user's processes/applications. In step 704, if the system does not have sufficient resources, then error handling is initiated in accordance with a predetermined mechanism. On the other hand, if sufficient resources exist to provide a new application node to the user, then, in step 705, the present system initiates the resource request.
In step 706, the application replication module determines the fixed resource requirements for accomplishing the user request. As a result, the application replication module obtains/determines the application and the data sizes. In step 707, the ARM checks to determine if sufficient resources exist to create the necessary node for the user. As a result, the ARM looks at the existing load availability based on other nodes being used as well as other tasks/processes being run on the system. In addition, the ARM checks the sizes of the various processes being run and the resources required therefor. If the load availability is greater than the required resources for creating the new node, then the system proceeds to create a new node. On the other hand, if the required resources are more than the available resources, then the present system aborts the process of creating the new node and initiates error handling in step 708.
In step 709, the system checks to determine if an application's bill of material (BOM) exists. If the bill of material does not exist, then the ARM creates a new installation bill of materials in accordance with its existing algorithms. On the other hand, if the bill of material exists, then in step 710 the ARM proceeds to use that existing bill of material for installation the necessary software/applications during creation of the new node.
After creating a bill of material in step 711 and or determining that the appropriate bill of material exists in step 710, the flow proceeds to step 712. In step 712, the ARM generates a user account if necessary. Next, in step 713, the ARM allocates the necessary space for installing the bill of material in accordance with the present invention.
In step 714, the ARM copies application files for each install bill of material and applies a special attribute needed at the space allocated in step 713. In step 715, the replicated node obtains local replacement for all the tokens in the bill of material, such as its IP address, the different paths need for accessing the local files and directories, and/or the like.
Once the local replacement for tokens in the bill of material have been obtained/created, the flow proceeds to the configuration management module, as shown in box 716. In step 717, the files for the local nodes are configured in accordance with other nodes that are being used by the underlying user. In step 718, the ARM reports completion of the creation of the new node, and the in step 719 the flow proceeds back to step 720. In step 719, once completion of creation of the new node has been reported, the flow proceeds to the requesting node. The creation of the new application node is reported to the event system module 503, the request routing system 504, optional peer-to-peer messaging system and/or any other module that may need this information.
In step 720, the policy manager 507 checks to determine if an application node was successfully created. If the application node was not created properly, an error is signaled and the system initiates the error handling procedures in accordance with predetermined policies set by the providers of the present system. On other hand, if the application node was successfully created then the system returns back to the procedure that invoked the application creation procedure.
FIG. 8 shows the flow necessary for maintaining and determining the resource usage during the creation, deletion and/or modification of new application nodes in accordance with the present invention. At noted in box 801, the resource usage that is determined is CPU usage, size of memory needed, load, and/or the like.
The flow starts at step 802 where the user requests resource usage, which may be for the TACT system when data already exists, or for a new application. The resource being requested is checked against existing resources in the present system. For example, the resource usage request is checked against the applications being used, current loads, free space available on the servers by examining the activity logs and/or the like in step 803. The results of the resource checking being performed are provided in step 804, as a result of which the resource usage list is updated in step 805.
In step 806, the network monitor module checks to determine whether the requesting events should be terminated. If the network monitor system decides that the event should be terminated, the flow proceeds to step 807. On other hand, if the event need not be terminated, the flow is returned back to step 802, and new users and/or existing users are allowed to make usage request in accordance with the flow described herewith.
FIG. 9 provides an overview of the creation of the bill of materials on the ARM. In step 901, the present system initiates the process of determining the directory in which the application is stored and/or should be stored. The application directory may be determined by a simple selection procedure and/or by searching the existing directories, which may include looking at existing known system directories and/or registry entries in the system. In step 902, a bill of materials is generated. In step 903, the present system obtains the machine specifics. The machine specifics may include the Internet protocol address (also known as the IP address), the devices used or to be used and the current as well as the top level directories in the machine being used.
In step 904, the present system initiates the process of creating an application bill of materials for each file and/or directory. The file type and/or creator is parsed to obtain the individual fields, in step 905.
In step 906, the system checks to see if the type and/or the creator is known to the system. If the type and/or the creator of the file is known to the system, a lookup is performed to extract the specifics for the type from the existing tables and/or lists in the system. An existing type might be, for example, a MP3 tag and/or the like. On other hand, if the type or the creator of the file being created in the bill of material is not known, the contents for the machine specific entries are parsed in step 908.
In step 909, the locations are noted by the present system and/or replace the machine specific entries with the appropriate tokens. The custom entries are appended in the bill of material. This process is repeated numerous times for each file and/or directory being installed in the bill of material. Once the system creates a specific entry for each file and/or directory in the bill of material, the process ends and the created bill of material is returned back to the procedure that invoked the bill-of-material-creation-procedure, in step 910.
FIG. 10 provides a flow diagram for the deletion of an application node on the ARM. The deletion of the application node is initiated in step 1001.
In step 1002, the system checks to see if an application node is running on the ARM. If the application node is running on the ARM, it is turned off in step 1003, and the flow proceeds to step 1006 where the application node is checked for checking if it is safe to be deleted. On other hand, if the application node is not running, a TACT update is performed on the node that is to be propagated (or replicated) to see if the data has been replicated consistently. In step 1005, a report is made if the node is not available for update and also for examining the TACT and/or resource management modules. Next, the flow proceeds to step 1006 where the system checks to determine if the application node is safe for deletion. If the application node is not safe for deletion, which would be the case where a TACT update has not been performed, the system initiates error handling in step 1007. On other hand, if the application node is safe for deletion, the bill of materials is read in step 1008.
After the bill of materials has been read, the files are deleted in step 1009. In step 1010, the present system checks to ensure that all the necessary files have been deleted. If all the files have not been deleted, error handling is initiated in step 1011. On the other hand, if all the necessary files have been deleted, unavailability of the node is reported in step 1012 to TACT, the resource management modules and/or any other modules that may in the future look for data from the node that was just deleted.
FIG. 11 illustrates the flow for turning off an existing turned-on application node on the ARM. The process of turning off the existing application node is initiated in step 1101.
In step 1102, the present system initiates a TACT update from the node that is to be propagated/replicated. In step 1103, as a result of the TACT update in process, the unavailability of the node is reported to the TACT module and to the resource management module. In step 1104, the system checks to see if the node that is to be turned off is running and/or has any live processes thereon. If the node is not running, then an error handling is initiated in step 1107, because there the underlying node is already turned-off. On the other hand, if the node is running, then the present system sends out a signal indicating that it is safe to deactivate the application node.
In step 1106, the present system checks to determine if the application node is safe for deactivation. If the application node is not safe for deactivation then an error handling is initiated by sending the control back to step 1107. On the other hand, if it is safe to deactivate the application node, then a kill process is initiated in step 1108.
In step 1109, the system checks to see if the process has been terminated as well as if the application node has been deactivated. If the process has not been terminated and/or the application node has not been deactivated then error handling is initiated in step 1110. On the other hand, if the process was successfully terminated then unavailability of the turned-off application node is reported in step 1111 back to the TACT module, to the resource management module, as well as to any other module that would look for data and/or application from the turned off application node.
FIG. 12 provides a flow diagram of the process of turning on an application node on the ARM. The process starts with step 1201 in which the user initiates or provides an indication of its desire to turn on an existing application node.
In step 1202, the present system checks to see if the application node is running. If the application node is currently running, it means it has an existing process that must be turned off. If the application is running, error handling is initiated in step 1203. On the other hand, if no existing application is running on the application node (i.e., the application node that is to be turned on is idle), then the present system checks to see if it is safe to turn on the application node and/or activate it, in step 1204. If it is not safe to activate the application node then error handling is initiated in step 1206. If, however, it is safe to activate the application node then error handling is initiated in step 1206.
Where it is safe to activate the application node, the system checks to see if the node is available and/or desirable for the application that is to be propagated/replicated thereon, in step 1205. It should be noted that step 1205 is optional and is merely one exemplary embodiment that may be performed or added to the flow in accordance with the present invention. If the node is not available and/or desirable for the application that is to be performed thereon then error handling is initiated in step 1206. On the other hand, if the node is desirable, the prior settings are obtained in step 1206. According to one embodiment, the prior settings may be performed by the network monitoring system of the present invention in step 1207.
In step 1208, the process is instantiated with the prior settings. In step 1209, the present system checks to see if the process was instantiated properly. If the process was not instantiated properly, error handling takes place in step 1210. On the other hand, if the process was properly instantiated, it is reported to the system that the node is available for updates in step 1211. According to one embodiment of the present invention, the report informs that the node is available for updates and may be provided to the TACT module, the resource management module and/or any other module that may need the information.
Finally, in step 1212, availability of the data on the node being turned on is a reported to the TACT module, the resource management module, and/or any other module that may need to use the data being stored, created, updated, and/or appended the node.
FIG. 13 illustrates the flow necessary for changing the consistency and/or the priority of the node under operation. The changing of the consistency and/or the priorities is initiated in step 1301. The request message is parsed to obtain the values of the various fields included in the request. In step 1302, the system checks to see if the parsed request is less than the current settings. If the parsed request is less than the current settings then a message with the new consistency and/or priority parameters is sent to the event system module 503 to reduce the data consistency module priority, in step 1303, and the procedure terminates.
On the other hand if the parsed request is not less than the current settings (i.e., the parsed request is greater than or equal to the current settings) then a message is sent with the new consistency priority parameters to the event system module 503 to increase the DMS priority in step 1304.
FIG. 14 illustrates the message parsing routine that the event system module 503 must undertake. In step 1401, a message is received from the user. In step 1402, the received request is parsed to obtain the parameters being passed and/or entered by the user and the flow proceeds to box 1403.
Box 1403 provides an overview of the procedure for determining the destination of the message being parsed. In step 1404, the system checks to determine if a message target is required. If a message target is required, the flow proceeds to step 1405 to determine if the message target has been identified. If the message target is not identified then error handling is initiated and the process terminates. On the other hand, if a message target was identified then the process proceeds to send the message to the appropriately identified node, as shown in box 1416.
However, if the message target is not required then the flow proceeds to step 1408. In step 1408, actions are initiated for each module type in the module list. The different modules that may be called upon to perform an action are policy manager module, event system module, the resource routing system module, network monitoring system module and/or the like. In step 1409, the system checks to see if the command provided is of the proper module type. As shown in block 1410, the command in the parsed message is compared to the command module lookup list that exists in the system. If the command in the module type is recognized by the system, the flow passes to step 1411 where the module type for passing the request to the resource routing system 504 is selected.
In step 1412, the system checks to determine if the nodes have been appropriately selected. If the nodes have not been appropriately selected, error handling is initiated in step 1413. On the other hand, if the nodes were appropriately selected then the event system requests selection of the node. In other words, a node is requested based on the selected module type. There are various different algorithms that may be used to pick a selected node. For example, according to one embodiment, the node may be selected by the least used node algorithm after examining the usage entries for the selected nodes. According to another embodiment, the system may select nodes based on the shortest geographical distances to the node being used. According to yet another embodiment, the system may pick a node by checking to see if the user already has any process running on the node to be selected.
In step 1415, the results for the selection of the node are obtained and in step 1416 the system sends the message to the appropriately selected node in accordance with the results obtained.
FIG. 15 provides an overview of the flow for the event system routing mechanism. In step 1502, a node selection request is received by the event system routing module with the necessary module type. In step 1503, the received message is parsed to get the different parameters that are necessary to perform further action.
In step 1504, the system checks to see if the nodes capable of performing the events have been identified. If the nodes have not been identified then error handling is initiated in step 1505. On the other hand, if the nodes capable of performing the events have been identified then node usage is determined in step 1507. According to the present invention to identify the capable node, the system checks to see the node lookup table and obtains the module type by making comparisons between the parsed message and the information stored about the various modules in the lookup table. To determine the node usage, the present system ranks the identified nodes by user statistics in the resources usage list, as shown in block 1508.
In step 1509, user selection algorithms are used to select the appropriate node. According to one embodiment, one of the algorithms used to select the node may be based on the least used node. According to another embodiment, the algorithms may be based on the least used node for an anticipated time of the use. According to yet another algorithm, the node that is capable for the most amount of usage during expected used time may be used.
Finally, in step 1511, the appropriate node is returned to the system for performing further actions thereon.
FIG. 16 provides an overview of the request routing server of the present invention. In step 1602, a service request is received by the resource routing server. The request may be similar to receiving a Web address, wherein the system automatically goes and performs the action at the appropriate Web address. In step 1603, the received message is parsed.
In step 1604, the system checks to determine whether the identified nodes are capable of performing the request made by the user. To determine whether the nodes are capable of performing in accordance with the user's request, the system compares the requested location with the application node lookup list that is already in existence within the system, as identified by block 606. If the identified node is not capable of performing the request then error handling is initiated in step 1605. On the other hand, if the node is available of performing the request, then the appropriate node usage is determined in 1607.
Identified nodes are ranked by user statistics in the resource usage list, as indicated by step 1608. The flow proceeds from step 1607 to step 1609 where a selection algorithm is utilized to select the appropriate node for usage. Some of the algorithms, as noted above, may be based on the least used node for an anticipated piece of time, and/or nodes currently being used that are capable of the maximum expected use during the use by the user. Once the node that is most appropriate for usage is selected, the system proceeds to step 1611 where the request routing server returns the appropriate node to the system for further action thereon.
It is to be understood that the above description is only representative of illustrative examples of embodiments and implementations. For the reader's convenience, the above description has focused on a representative sample of all possible embodiments, a sample that teaches the principles of the invention. Other embodiments may result from a different combination of portions of different embodiments. The description has not attempted to exhaustively enumerate all possible variations.
It should be recognized that the method and system of the present invention has many applications, and that the present invention is not limited to the representative examples disclosed herein. Alternate embodiments may not have been presented for a specific portion of the invention. Some alternate embodiments may result from a different combination of described portions, or other undescribed alternate embodiments may be available for a portion. This is not to be considered a disclaimer of those alternate embodiments, because many of those undescribed embodiments are within the literal scope of the following claims, and others are equivalent.
It is to be further understood that the tasks described in the following claims can be sequenced in many different orders to achieve the desired result. Thus, the scope of the present invention covers conventionally known variations and modifications to the system components and the method steps described herein, as would be known by those skilled in the art.
Unleashing Human Potential: A New Form of Financing for Children and Teenagers Based on Future Earnings Potential
Unleashing Human Potential: A New Form of Financing for Children and Teenagers Based on Future Earnings Potential
Human Capital Saatchi.doc
Shervin Pishevar
Judd McManus
Dr. Sarah Pishevar Haynes, Ph.D. (Licensed Child Psychologist)
We propose a new form of financing that we believe has the potential to accelerate the rate and capacity of human achievement. We are building predictive models based on a child's future earning potential based on grades, parental education, behavioral patterns and records, intelligence and standardized test scores, personality tests and activities and begin human capital loans at childhood to invest in that a chosen child's potential. We believe that this will create a virtuous circle that will boost that child's ultimate earnings potential and impact on their community and society at large
Human capital financing fits best at the Pre-K to the 12th grade arena. If you invest after someone is already out of college you are reducing your ROI's compared to the ROI's of investing in children and teenagers. The model works better since there is a complete black hole in the financing of children's training and potential.
Now this will truly change our world as we now it. Our current system is bankrupting our youth. Financial loans come too late after most young peoples potential have been scrubbed by 12 years of reiteration and boredom. These very college loans then saddle these deflated youth with the shackles of debt that they can't really pay off with their now reduced earnings potential commiserate with their lower quality training.
Human Capital Financing will make educated bets on youth from all demographic strata starting as early as birth based on our proprietary algorithms. We will perfect the art of predictive potential earnings and achievement analysis over time and real life investments in youth. Think of how many undiscovered Mozarts and Einsteins this idea could help find and support.
Unlike ever before, individuals can now unlock the power of their future potential at an earlier age to assist them in achieving higher realized earnings over the course of a lifetime.
With longer expected life spans reaching averages into 80 and 90 years of age and beyond, increased earnings at earlier ages will lead to larger retirement accounts to support retirement eras that will begin stretching from the current decade into decades of active retirement.
Our investment program will consist of financing the optimal educational, cultural, societal training based on each child's specific personality and profile. A child with great musical ability will for example be financed to receive the very best musical training money can buy, attend musical concerts around the world, meet great musicians, acquire the very best musical instruments. A child with great scientific capability and interest will be funded to receive additional advanced scientific training, attend scientific conferences, intern at top research labs and fund independent research. In this virtuous circle the child's initial potential will be further magnified and their future earnings potential will be enlarged and their maximum positive societal affect will be reached. A child with uncommon athletic talent in soccer, for example, could be supported to receive advanced sports training and conditioning and tutoring as well as visiting and interacting with professional athletes and attending sports events.
Human Capital Finance Corporation's (HCFC) business model revolves around an intricate frame agreement with the child's parents and later the child at the age of 18 when their college education and graduate training if required will be funded by HCFC. If the child does not choose to continue the program then the parents will be obligated to pay back the loans. After the child becomes an earning adult that child's earning potential will offset the financing. All earnings contributed back to HCFC will be the put into a pooled pension fund for all members of the program. It is assumed that the child's earning potential will be significantly higher than the norm. The model will be a scaled percentage of earnings will be paid to HCFC for the life of that person with the percentage going from low single digits in the beginning of their career to a cap of 10%, for example, at the end of their career.
The selection step of the invented method is based on the identification of children and teenagers with skills, accomplishments, etcÂ… that may lead them to achieve a high degree of future earnings and the estimation of those potential earnings.
After a child or teenager is selected a capital payment schedule is devised based on age and the financial requirements needed to assist the selected child or teenager to receive training, education, access to advanced equipment etcÂ… so that they may improve their skills; thus increasing their future earnings potential.
The funds would have to be rolled out by age groups since the first graduating class of students funded by HCFC would be the first to contribute to the pooled retirement funds. This step approach would result in a shorter time to wait for the first earners. HCFC will encourage a proper work ethic by promoting opportunities for members to work jobs related to their fields of interest at the youngest legal age (usually 14 years of age) in order to make them more exposed to work and to begin contributing to their retirement funds at an earlier age so the returns on their earnings will benefit from 40 to 50 years of investment cycles. Our ultimate goal should be to give our HCFC funded clients the ability to retire at younger ages say 50 or 55 so that they may be free to dedicate time to charitable endeavors. Based on our initial financial models a pension fund for only 500,000 high achievers over a 40 year time span leads to hundreds of billions of dollars under management.
The other reality is that longer life spans into the 90s and higher is likely for our clients so the peoples retirement funds now must stretch decades rather then the current decade or so. This means HCFC will hit a bulls eye in a market most do not have the foresight to predict. High potential earners will flock to HCFC to maximize their human potential and earnings potential at earlier ages iin order to fund their decades long retirements in the 2050 to 2100 timeframe and beyond.
Are you ready to change the world? Human Capital Finance Corporation can take us there.
Note: We believe that Saatchi & Saatchi could greatly assist in launching HCFC in a proper way to the world. We would appreciate that if we are lucky and blessed enough for this idea to be chosen as a winner that this not be publicly announced until we have the benefit of Saatchi & Saatchi assisting in having a proper brand, PR and website in order to properly take in nominations for candidates from around the world for children and teenagers seeking to be funded by HCFC. We will also seek to build a Board of Directors of amazing human achievers such as Bill Gates, Bill Clinton, Oprah Winfrey, Sergei Brin, Larry Page, Maya Angelou and a Board of Experts from different fields will be assist in identifying young achievers as well as proscribing the proper training and education for those selected.
Patents Pending
Human Capital Saatchi.doc
Shervin Pishevar
Judd McManus
Dr. Sarah Pishevar Haynes, Ph.D. (Licensed Child Psychologist)
We propose a new form of financing that we believe has the potential to accelerate the rate and capacity of human achievement. We are building predictive models based on a child's future earning potential based on grades, parental education, behavioral patterns and records, intelligence and standardized test scores, personality tests and activities and begin human capital loans at childhood to invest in that a chosen child's potential. We believe that this will create a virtuous circle that will boost that child's ultimate earnings potential and impact on their community and society at large
Human capital financing fits best at the Pre-K to the 12th grade arena. If you invest after someone is already out of college you are reducing your ROI's compared to the ROI's of investing in children and teenagers. The model works better since there is a complete black hole in the financing of children's training and potential.
Now this will truly change our world as we now it. Our current system is bankrupting our youth. Financial loans come too late after most young peoples potential have been scrubbed by 12 years of reiteration and boredom. These very college loans then saddle these deflated youth with the shackles of debt that they can't really pay off with their now reduced earnings potential commiserate with their lower quality training.
Human Capital Financing will make educated bets on youth from all demographic strata starting as early as birth based on our proprietary algorithms. We will perfect the art of predictive potential earnings and achievement analysis over time and real life investments in youth. Think of how many undiscovered Mozarts and Einsteins this idea could help find and support.
Unlike ever before, individuals can now unlock the power of their future potential at an earlier age to assist them in achieving higher realized earnings over the course of a lifetime.
With longer expected life spans reaching averages into 80 and 90 years of age and beyond, increased earnings at earlier ages will lead to larger retirement accounts to support retirement eras that will begin stretching from the current decade into decades of active retirement.
Our investment program will consist of financing the optimal educational, cultural, societal training based on each child's specific personality and profile. A child with great musical ability will for example be financed to receive the very best musical training money can buy, attend musical concerts around the world, meet great musicians, acquire the very best musical instruments. A child with great scientific capability and interest will be funded to receive additional advanced scientific training, attend scientific conferences, intern at top research labs and fund independent research. In this virtuous circle the child's initial potential will be further magnified and their future earnings potential will be enlarged and their maximum positive societal affect will be reached. A child with uncommon athletic talent in soccer, for example, could be supported to receive advanced sports training and conditioning and tutoring as well as visiting and interacting with professional athletes and attending sports events.
Human Capital Finance Corporation's (HCFC) business model revolves around an intricate frame agreement with the child's parents and later the child at the age of 18 when their college education and graduate training if required will be funded by HCFC. If the child does not choose to continue the program then the parents will be obligated to pay back the loans. After the child becomes an earning adult that child's earning potential will offset the financing. All earnings contributed back to HCFC will be the put into a pooled pension fund for all members of the program. It is assumed that the child's earning potential will be significantly higher than the norm. The model will be a scaled percentage of earnings will be paid to HCFC for the life of that person with the percentage going from low single digits in the beginning of their career to a cap of 10%, for example, at the end of their career.
The selection step of the invented method is based on the identification of children and teenagers with skills, accomplishments, etcÂ… that may lead them to achieve a high degree of future earnings and the estimation of those potential earnings.
After a child or teenager is selected a capital payment schedule is devised based on age and the financial requirements needed to assist the selected child or teenager to receive training, education, access to advanced equipment etcÂ… so that they may improve their skills; thus increasing their future earnings potential.
The funds would have to be rolled out by age groups since the first graduating class of students funded by HCFC would be the first to contribute to the pooled retirement funds. This step approach would result in a shorter time to wait for the first earners. HCFC will encourage a proper work ethic by promoting opportunities for members to work jobs related to their fields of interest at the youngest legal age (usually 14 years of age) in order to make them more exposed to work and to begin contributing to their retirement funds at an earlier age so the returns on their earnings will benefit from 40 to 50 years of investment cycles. Our ultimate goal should be to give our HCFC funded clients the ability to retire at younger ages say 50 or 55 so that they may be free to dedicate time to charitable endeavors. Based on our initial financial models a pension fund for only 500,000 high achievers over a 40 year time span leads to hundreds of billions of dollars under management.
The other reality is that longer life spans into the 90s and higher is likely for our clients so the peoples retirement funds now must stretch decades rather then the current decade or so. This means HCFC will hit a bulls eye in a market most do not have the foresight to predict. High potential earners will flock to HCFC to maximize their human potential and earnings potential at earlier ages iin order to fund their decades long retirements in the 2050 to 2100 timeframe and beyond.
Are you ready to change the world? Human Capital Finance Corporation can take us there.
Note: We believe that Saatchi & Saatchi could greatly assist in launching HCFC in a proper way to the world. We would appreciate that if we are lucky and blessed enough for this idea to be chosen as a winner that this not be publicly announced until we have the benefit of Saatchi & Saatchi assisting in having a proper brand, PR and website in order to properly take in nominations for candidates from around the world for children and teenagers seeking to be funded by HCFC. We will also seek to build a Board of Directors of amazing human achievers such as Bill Gates, Bill Clinton, Oprah Winfrey, Sergei Brin, Larry Page, Maya Angelou and a Board of Experts from different fields will be assist in identifying young achievers as well as proscribing the proper training and education for those selected.
Patents Pending
Hyperion Slipstream: Using Electromagnetic Forces for Hyper Travel
Get the Word Document with Pictures and Diagrams:
The Hyperion Spaceship.doc
The Hyperion Slipstream: A Slippery Path Out of Our Solar System
Shervin Pishevar
Cyrus Pishevar
Hyperion \Hy*pe"ri*on\, n. [L., fr. Gr. ?.] (Class Myth.)
The god of the sun; in the later mythology identified with
Apollo, and distinguished for his beauty.
[1913 Webster]
Space is far from a vacuum. It is teeming with plasma. It is this very plasma that will allow humans to travel out of our solar system by the year 2100. Hyperion Technology and the Slipstream effect will take us there.
The key to the Hyperion design is a combination of the hallow hull design and the use of a phenomenon we dub the Slipstream effect.
The Hyperion hallow hull forces super dense, charged plasma to flow through the hallow hull and around the outer hull where oppositely charged microunits will be attracted to the negatively charged plasma. This attraction will be the accelerant pulling the space through the space time continuum at increasingly alarming speeds.
You have to imagine the creation of a supercharged tunnel or jet of plasma immediately at the bow of the spaceship (before the spaceship comes into contact with the plasma). Such supercharged tunnels or jets of plasma and the Hyperion's design allowing it to slip through the plasma is called the "SlipStream" effect. Such supercharged plasma are already in existence in well known flows within space (see charts below) and can serve as spaceways or highways for the Hyperion Spaceship to take advantage of. A supercharged charge by means of a laser and later any device better suited to the task in the future will be aimed at the forward space plasma before the ship and ionize and super charge the forward medium prior to being in contact with the microunits in the outer hull and inside the hallow cores. Additional zappers could be fitted around the
Hyperion Slipstream Basic Contructs:
SEE IMAGE IN DOCUMENT
Hull and inside the hallow cores and would be calibrated in the future experiments for optimum propulsion.
However, it is imagined that a laser of some sort that zaps the plasma prior to contact with the Hyperion Hallow Hull will further alter the membrane potential between the hull and the plasma and lead to increased attraction.
The Hyperion hallow hull will be made of micro units comprised of small electrode and a large electrode to take advantage of the Biefeld-Brown effect. Electrohydrodynamics will be what helps this design work by stripping off the electrons from the surrounding space plasma. The electrons will then move to the micro units and are driven by the negative electrode in the voltage. This will create a cloud of positively charged ions in the medium, which are then attracted to the electrode. This will drag along some of the surrounding plasma, which is the will create a sort of a superfast plasma ion wind. The movement will be of considerably greater magnitude then the ions themselves account for and will be propel the ship at extreme speeds through space.
Similar to NASA's scram jet the Hyperion Slipstream technology makes use of the speed of travel to compress the space plasma in take, which then uses a combination of the speed of travel and the distortion of the continuum to generate a space/time torque which will position the charged particles to propel the ship and generates a plasma exhaust that creates the charged particles which in turn begins the cycle of acceleration again.
The key is to create the charge far enough in advance of the position of the hull to create the slipstream effect. This is where some kind of folding of the space-time continuum might be useful e.g if the forcefield effect could be created by the exhaust of the engines and then warped through space/time so that became positioned/displaced in front of the hull.
The Hyperion theorem predicts that the space time continuum will bend due to the density and speed of the supercharged hallow core of space plasma traveling through the ship. The delta between the (1) slower speed, (2) density and (3) charge of the plasma before and after touching the forward hull should be enough to bend the continuum allowing further acceleration through time and space.
The use of well defined solar winds (see chart below) should provide pathways or spaceways for the ship to reach known destinations. I believe that worm holes are only supercharged, superdense space plasma "falling" from point A to B without the limitations afflicted their lesser charged and lightweight cousins. My theory is that the Slipstream designed ship could create its own approximate worm holes by supercharging a forward, reverse and inner dense core of plasma traveling through its hallow cores and outer hull.
Of course there would need to be a fuel source, as an initial starter and to counter entropy. It is proposed that longlasting nuclear fuel technology used in new U.S. submarines be used until an alternative fuel can be generated. It is also proposed that the membrane potential differences between the ship's hull and plasma be utilized in generated and recharging electric fuel cells as well as harnessing the power of any starlight that can be efficiently harvested.
The aforementioned pulling affect of the Hyperion SlipStream when combined with the propulsion of the nuclear-powered jets designed in rings around the hallow cores will both pull and propel the spaceship closer to the speed desired: 300,000 km per second (although, even speeds nearing 1,000 km/second would suffice). However, such measurements are futile at that point since neither time nor distance will quite matter.
The Hyperion Spaceship.doc
The Hyperion Slipstream: A Slippery Path Out of Our Solar System
Shervin Pishevar
Cyrus Pishevar
Hyperion \Hy*pe"ri*on\, n. [L., fr. Gr. ?.] (Class Myth.)
The god of the sun; in the later mythology identified with
Apollo, and distinguished for his beauty.
[1913 Webster]
Space is far from a vacuum. It is teeming with plasma. It is this very plasma that will allow humans to travel out of our solar system by the year 2100. Hyperion Technology and the Slipstream effect will take us there.
The key to the Hyperion design is a combination of the hallow hull design and the use of a phenomenon we dub the Slipstream effect.
The Hyperion hallow hull forces super dense, charged plasma to flow through the hallow hull and around the outer hull where oppositely charged microunits will be attracted to the negatively charged plasma. This attraction will be the accelerant pulling the space through the space time continuum at increasingly alarming speeds.
You have to imagine the creation of a supercharged tunnel or jet of plasma immediately at the bow of the spaceship (before the spaceship comes into contact with the plasma). Such supercharged tunnels or jets of plasma and the Hyperion's design allowing it to slip through the plasma is called the "SlipStream" effect. Such supercharged plasma are already in existence in well known flows within space (see charts below) and can serve as spaceways or highways for the Hyperion Spaceship to take advantage of. A supercharged charge by means of a laser and later any device better suited to the task in the future will be aimed at the forward space plasma before the ship and ionize and super charge the forward medium prior to being in contact with the microunits in the outer hull and inside the hallow cores. Additional zappers could be fitted around the
Hyperion Slipstream Basic Contructs:
SEE IMAGE IN DOCUMENT
Hull and inside the hallow cores and would be calibrated in the future experiments for optimum propulsion.
However, it is imagined that a laser of some sort that zaps the plasma prior to contact with the Hyperion Hallow Hull will further alter the membrane potential between the hull and the plasma and lead to increased attraction.
The Hyperion hallow hull will be made of micro units comprised of small electrode and a large electrode to take advantage of the Biefeld-Brown effect. Electrohydrodynamics will be what helps this design work by stripping off the electrons from the surrounding space plasma. The electrons will then move to the micro units and are driven by the negative electrode in the voltage. This will create a cloud of positively charged ions in the medium, which are then attracted to the electrode. This will drag along some of the surrounding plasma, which is the will create a sort of a superfast plasma ion wind. The movement will be of considerably greater magnitude then the ions themselves account for and will be propel the ship at extreme speeds through space.
Similar to NASA's scram jet the Hyperion Slipstream technology makes use of the speed of travel to compress the space plasma in take, which then uses a combination of the speed of travel and the distortion of the continuum to generate a space/time torque which will position the charged particles to propel the ship and generates a plasma exhaust that creates the charged particles which in turn begins the cycle of acceleration again.
The key is to create the charge far enough in advance of the position of the hull to create the slipstream effect. This is where some kind of folding of the space-time continuum might be useful e.g if the forcefield effect could be created by the exhaust of the engines and then warped through space/time so that became positioned/displaced in front of the hull.
The Hyperion theorem predicts that the space time continuum will bend due to the density and speed of the supercharged hallow core of space plasma traveling through the ship. The delta between the (1) slower speed, (2) density and (3) charge of the plasma before and after touching the forward hull should be enough to bend the continuum allowing further acceleration through time and space.
The use of well defined solar winds (see chart below) should provide pathways or spaceways for the ship to reach known destinations. I believe that worm holes are only supercharged, superdense space plasma "falling" from point A to B without the limitations afflicted their lesser charged and lightweight cousins. My theory is that the Slipstream designed ship could create its own approximate worm holes by supercharging a forward, reverse and inner dense core of plasma traveling through its hallow cores and outer hull.
Of course there would need to be a fuel source, as an initial starter and to counter entropy. It is proposed that longlasting nuclear fuel technology used in new U.S. submarines be used until an alternative fuel can be generated. It is also proposed that the membrane potential differences between the ship's hull and plasma be utilized in generated and recharging electric fuel cells as well as harnessing the power of any starlight that can be efficiently harvested.
The aforementioned pulling affect of the Hyperion SlipStream when combined with the propulsion of the nuclear-powered jets designed in rings around the hallow cores will both pull and propel the spaceship closer to the speed desired: 300,000 km per second (although, even speeds nearing 1,000 km/second would suffice). However, such measurements are futile at that point since neither time nor distance will quite matter.
title
add text, images, video, widgets, etc...
