text:
In the preferred computer system, the user is provided with a separate Internet-accessible entity referred to here as the "personal page." A personal page, preferably, includes memory for storing information related to the user. For example, on his/her personal page the user indicates what he/she wishes to purchase, possibly along with other criteria associated with the purchase, such as, for example, a time that the purchase should take The user is provided with the ability to create personalized bidding rules that vendors that offer goods and services must respect. Vendors have the ability to specify similar criteria, which describe the goods and/or services they offer. Vendors can indicate, for example, the prices of their goods, times and places that their services are available, etc. Preferably, these specifications, called "vendor scripts," are embodied in active software/data entities (agents) that traverse sites on the Internet visiting sites hosting users' personal pages. Thus, preferably, vendor software/data agents (comprising vendor scripts) are the mobile, active elements in the system and purchasing requirements are stationary and more passive in comparison.
1. A computer-implemented method comprising:
storing at least one acquisition specification of a first user represented in a scripting language that specifies acquisition requirements;
parsing the acquisition specification into at least one purchase form comprising a plurality of attributes, at least one of which specifying a transactional action desired to be electronically completed by the first user;
receiving over the Internet and storing offering specification comprising at least one vendor form comprising a plurality of attributes, at least one of which specifying a transactional action desired to be electronically completed by a second user; and
electronically determining if the attributes in the purchase form are compatible with associated attributes in the vendor form by testing attributes in the purchase form against attributes in the vendor form for satisfiability using a compatibility dictionary, comprising a storage of sets of compatible terms associated with an automated completion of a transaction, wherein the step of testing comprises accessing the storage of the dictionary and determining whether the transactional action in the purchase form is compatible with the transactional action in the vendor form,
wherein the storing the at least one acquisition specification is on a personal page assigned to a user providing the acquisition specification and said personal page communicates with Global Positioning System.
2. The method of
3. The method of
4. The method of
5. The method of
6. The method of
The application claims the benefit of Provisional Application No. 60/202,908, filed May 10, 2000.
In traditional e-commerce, a user electronically attaches to a vendor's Internet Web site to make purchases. This most widely-used model is essentially an electronic catalog, in which goods and/or services are listed by vendors and purchasers actively peruse. Operators of these sites invest millions of dollars in advertising and brand building in order to encourage users to visit their sites, thereby increasing the costs of products since advertising costs must be passed on.
In traditional e-commerce, the user has limited power since he/she is forced by the structure of the marketplace to transact business with a specific site. There are, however, sites that "look for" the best deal. Here, the user has more flexibility and is more empowered, but still is at the mercy of the site doing the searching. There is still a manual element involved. Furthermore, the user may have to attach to another site to transact the purchase.
Another e-commerce technique is essentially a reverse auction, in which the user indicates a desired price and providers of goods and services vie to meet the price. Yet another model allows a user to requests an item on a web site and the site sends the request to vendors in order to obtain the desired product. Bidding on Internet sites is also well known, e.g., eBay.com. Also, some sites allow users to design a customized view (i.e., a Web page) of the site. Further, there are business-to-business sites where businesses buy and sell products and services. There are other e-commerce techniques (including business-to-business) as known in the art. What all these methods have in common is that they do not provide sufficient autonomy to users, who must visit sites to make purchases. In current electronic business, the user is not sufficiently empowered in the electronic world known as the Internet.
This invention applies to both commercial and consumer applications of computer technology. Thus, users of the described system can be either consumers purchasing goods and/or services for personal use or commercial enterprises obtaining business-related goods and/or services. (In some embodiments, the term "user" can refer to a human being and/or a machine, such as a computer. In some embodiments "user" can refer to a corporation or other group of human beings. Similarly, the term "vendor" can refer to a human being or corporation or other group of human beings, and/or a computer or set of computers.)
In the preferred system, the user is provided with a separate Internet-accessible entity referred to here as the "personal page." A personal page, preferably, includes memory for storing information related to its user. For example, on his/her personal page, the user indicates what he/she wishes to purchase, possibly along with other criteria associated with the purchase, such as, for example, a time that the purchase should take place. (In some implementations the personal page can be used to specify what the user wants to sell.) For example, a consumer wishing to purchase a service, such as a haircut, could indicate that he/she wishes to obtain the services of a barber at a particular time on a particular date, or more generally within a particular time interval over a succession of dates ("Between 3 pm and 5 pm Monday Or Wednesday next week"). Other criteria might include the place that the goods or services are to be delivered, for example. The user is provided with the ability to create personalized bidding rules that vendors that offer goods and services (collectively known as "items" for sale) must respect. For example, the user may indicate that he/she will accept the lowest price received within an hour, day, etc. Similarly, the user can also say that he/she will not accept a price that is greater than a specified amount, and/or the desired item should be delivered no later than a given date/time.
A user's purchasing or buying requirements ("B.R.") are stored on his/her personal page. The meaning of B.R. (purchasing/buying requirements) is not limited to purchasing or buying, and may relate to other requirements stored in connection with a personal page, for example, requests for service, information, advertisement, as well as other data.
Vendors have the ability to specify similar criteria, which describe the goods and/or services they offer. Vendors can indicate, for example, the prices of their goods, times and places that their services are available, etc. Vendors, preferably, do not have personal pages on which the specification is done. Preferably, these specifications, called "vendor scripts," are embodied in active software/data entities (agents) that traverse sites on the Internet visiting sites hosting users' personal pages. Thus, preferably, vendor software/data agents (comprising vendor scripts) are the mobile, active elements in the system and personal pages are stationary and more passive in comparison. Alternatively, vendor scripts may be stored on a personal page associated with a vendor. Also, alternatively, a personal page may contain both B.R.'s and vendor scripts. Though B.R.'s (vendor scripts) are preferably translated to lower level language equivalents and then stored on personal pages (vendor sites), we will continue to refer to the translated equivalents as B.R.'s (vendor scripts) for simplicity. Users and vendors are preferably given the capability of entering, editing, deleting, activating, deactivating, and reactivating B.R.'s and vendor scripts using techniques known in the art.
In the preferred embodiment, vendors of various items send electronic representatives (software agents, in the form of a script in an appropriate scripting language, for example) that visit personal pages. This electronic representative includes sufficient information to interface with the user's B.R. on the personal page so as to complete transactions if a compatible match is found. (Also, if permitted by the user, electronic representatives of the vendors may suggest alternative products.) In this implementation, instead of forcing a user to purchase items at vendors' sites, as is now mostly the case, the vendors "come" to the user and bid in accordance with the user's bidding rules.
A personal page can be hosted by an Internet server. It may also be hosted by the user's local computer, and, in some embodiments, can be made visible to the Internet similar to the way napster.com makes files residing on a user's local hard drive accessible to other users of the Internet. In yet other embodiments, it may be hosted by a computer or computers that are electronically positioned in the network between the user's local computer and an Internet server. In other embodiments, the personal page can be hosted on a computer or computers other than the user's local computer and mirrored on his/her local computer, i.e., the two copies are synchronized and kept current with each other. In other embodiments, the user's local computer hosts the personal page and another computer(s) contains a mirrored copy.
In a preferred embodiment, a personal page is comprised of computer memory, which, for example, stores B.R's. In this embodiment, a personal page has associated with it software as described below. This can include databases, executable code, libraries, application processes, and other such software known in the art for realizing Internet applications.
The Web page form presented to the user for the purpose of creating a B.R. (and similarly vendor script) is preferably a fixed length electronic form, as mentioned above, with fixed, labeled attributes. (Attributes are fields, like the "attribute" notion in the Relational Data Base Model.) Attributes are assigned values input by the user, or NULL, which may appear as a blank to the user if he/she does not enter a value. Optionally, some of the attributes may have values assigned to them by the user clicking a button near the field, with the user then choosing from among a list of possible allowed values. Also, certain information not entered by the user may be assigned default values. Such techniques are know in the art.
In what follows, the purchase forms and their processing are described, with vendor forms handled in a similar way. The user is required to provide values for certain attributes, such as "Action," and techniques for enforcing that he/she do so are well known in the art. Action (e.g., "purchase", "sell," "trade," "license," "reserve," "rent," "lease," etc.), Item Name, Item code, UPC code, Date (of delivery), Place, Supplier, Quantity, Quality, Size, and Price are examples of attributes in a purchase form, but in alternate embodiments purchase forms can contain other attributes as well and may omit some or all that are shown here. Some attributes may be automatically assigned a default value. In some embodiments, some or all of these attributes can have optional qualifiers such as "maximum" (<=), "minimum" (>=), "earliest" (>=), "latest" (<=), etc., for example, specified with them. Examples include:
The processing of the Web page input form completed by the user to create the purchase form (vendor form) involves the following. The system extracts the data from each attribute, checks that the value is in the domain of that attribute, and if so, stores the value in a corresponding field, with possible conversion, in the purchase form (vendor form). Illegal values cause the user to be sent the input form once again with a message indicating that an attribute value (or values) lie outside the defined domain(s). Once processing is complete, the purchase form (vendor form) is stored as the system's internal data structure used to represent the B.R. (vendor script). See
A purchase form is "satisfied" against a vendor form if all its attribute values are compatible with associated attribute values in the vendor form. In the preferred embodiment, compatibility of attributes is aided by a compatibility dictionary maintained by the system. The compatibility dictionary is preferably a database and associated program logic that indicates whether two or more values in certain attributes are deemed compatible. For example, if the value for the Action attribute in a purchase form is "purchase" and the value for the Action attribute in a vendor form is "sell," then the dictionary would indicate that these actions are compatible. Action values "buy" and "sell" would similarly be deemed compatible values for Action in the dictionary. But "trade" and "license" would not be deemed compatible Actions, nor would "buy" and "buy." Similarly, the values "100" and "<1000" would be deemed compatible in all attributes, since 100 is less than 1000 universally, and "anytime next week" and "next Wednesday" would also be deemed compatible universally. But "100" and "<50" would be deemed incompatible as would "anytime next week" and "in 6 weeks." Geographical attribute values "outside New York Metropolitan area" and "Boston" would be deemed compatible, while "New York Metropolitan area" and "Taiwan" would be considered incompatible. Preferably, the value NULL is compatible with all values, except the special value NOT NULL. Techniques for dealing with NULL values are known in the art and can be found in Data Base Management Systems (DBMS's) that support the SQL Relational Data Base query language, for example. In other embodiments, instead of, or in addition to, NULL, there may be a special value DON'T_CARE that indicates that any value is acceptable to the user in that attribute. In other embodiments there may be a value PROMPT that causes the prompting of the user for a value at the time the system is attempting to satisfy the purchase form against the vendor form. In some embodiments, the value indicated may be a location on the user's computer (e.g., hard drive) or a location on a Web page at an Internet site at which the value is to be obtained by the system automatically. In general, various techniques known in the art for obtaining a value can be used. Other embodiments may have other special values as dictated by the needs of the users. In some embodiments, the user may be given the ability to define his/her own special values with their own special meaning, thus providing an element of programmability to the user.
The compatibility dictionary technique can be used as an intelligent high-level macro feature allowing users to indicate a set or sequence of items and/or actions shorthand. For example, the user may create a B.R. that reads in part
In some embodiments, the user may be given the means of controlling the compatibility dictionary used by the system in satisfying purchase forms against vendor forms. For example, the user may indicate to the system which compatibility dictionary to use if more than one is available. He/she may even have the ability to edit the dictionary, or create a customized personal one. There may be separate compatibility dictionaries for each language: one for English, another for Spanish, a third for Russian, etc. Using techniques of Artificial Intelligence, the system may evolve a compatibility dictionary that is the result of "learning" what a user (or users in general, or a class of users) consider compatible and incompatible. Compatibility dictionaries may be supported that are particular to one industry or one class of industries, or to a class of individuals. Using techniques of Artificial Intelligence, the user may be given the choice of "teaching" the system which values he/she considers compatible and incompatible. A group of users may collectively agree to use a particular dictionary or dictionaries in some embodiments, or they may agree to refrain from using a particular dictionary or dictionaries. In some embodiments, a B.R. and/or a vendor script may have associated with it, as indicated by the user, a designation of which compatibility dictionary or dictionaries are to be used and which ones are excluded from use in that particular instance.
In some embodiments, the user's B.R. (vendor script) Web page input form described above may contain optional attributes that allow the user to indicate Boolean conditions. This is similar to the advanced search features found on Internet search engine sites, e.g. hotbot.com, that allow the user to specify conditions required of pages that are returned by the search. For example, the form may contain a "condition" attribute that allows the user to specify a B.R. such as
Action: purchase Item: airline ticket Place: Hawaii Condition: airline≠TWA.
Specifying and processing general boolean conditions are well known in the art and such known techniques may be used in various embodiments. The language for specifying conditions preferably includes the ability to express full Boolean logical expressions, as is known in the art. Thus, connectives such as, for example, AND, OR, and NOT are preferably available to the user, along with comparison operators, such as, for example, =, ≠, <, <=, >, >=, AT, BETWEEN, BEFORE, AFTER, etc. Preferably, wild characters, such as * for example, which are known in the art, are also included to allow the user the ability to compose more general conditions. The ability to compose "regular expressions," as is known in the art and found in systems such as the UNIX Operating System, for example, is preferably also included. Some embodiments may not choose to include regular expressions, however. Some embodiments may optionally include conditional AND (CAND) and/or conditional OR (COR) connectives, as is known in the art.
The purchase and vendor forms in an embodiment that includes condition(s) preferably have field(s) called "condition1," "condition2," etc., in which the specified condition(s) are stored. Satisfying a purchase form against a vendor form in such a case preferably involves evaluating the boolean condition(s) using well-known techniques for boolean evaluation. Preferably, values for items such as "airline" shown in the B.R. above come from attribute values in the vendor form against which it is being evaluated, in this case the value for attribute "Supplier."
In other embodiments, users are given the option of composing B.R.'s and vendor scripts in a scripting language reminiscent of a general purpose high-level programming language. This may be in addition to, or in place of, the electronic form technique discussed above, and may be combined with it.
Discussed here is the technique for specifying B.R.'s, with vendor scripts being specified and defined in an analogous way. The user wishing to specify a B.R. expresses it in an IF-THEN-ELSE control structure, exemplified by the following extended BNF (Backus-Naur Form) grammar fragment, with (preferably reserved) language keywords appearing in bold:
An example of such a B.R. might appear as
Since a B.R. and a vendor script might mutually depend on one another and since satisfying a B.R. against a vendor script may be possible in more than one way, IF-THEN-ELSE B.R. and vendor scripts are preferably evaluated against each other to determine satisfiability as follows. The B.R. is parsed using known parsing techniques in the field of compiler construction and based on an appropriately defined grammar. During the parse, each portion of the expression corresponding in the parse to the nonterminal <B.R.> is converted using the technique shown above to a separate purchase form, since the data contained there is much like what the user would enter in an input form described above. A vendor script is handled analogously, resulting in a similar collection of vendor forms. The purchase forms (vendor forms) are ordered according to their occurrence in the B.R. script, from top to bottom. This can be done, for example, at parsing time using an appropriately defined grammar and parsing technique. Preferably during the parse, each purchase form (vendor form) has associated with it a boolean condition that is the conjunction of all the IF conditions encountered on the path from the beginning of the B.R. (vendor script) to that purchase form (vendor form), with the proviso that ELSE results instead in the logical complement of its associated IF being used. Thus, in the previous example, associated with the three purchase forms in the order encountered in the parse are the conditions
Another embodiment adds a production of the form
to the grammar shown above, allowing B.R.'s (and/or vendor scripts) of the form
Another embodiment of the matching process is described as follows. A B.R., in whatever form it is input, is first translated (compiled) into a lower language equivalent using language compilation and translation techniques known in the art. (This is described in more detail below.) The lower level language statement into which a B.R. is translated is referred to as "alternative purchase statement," whose syntax and semantics are similar but not identical to the generalized if-statement called an "alternative command" known in the computer programming art and described in detail in the textbook The Science of Programming, by David Gries, SpringerVerlag, N.Y., 1981, pp. 131–137 (incorporated herein by reference). Other symbols or codes can be substituted for the ones shown here by an ordinary person skilled in the art.
Just as an alternative command is composed of "guarded commands" (see page 131 in Gries), an alternative purchase statement is composed of "guarded purchase statements," each of the form
The guard acts as a logical guard at the gate→, making sure that satisfaction of the associated purchase set is attempted only under the desired conditions, namely that the associated guard is true. Preferably, order of the pi's is irrelevant. In other embodiments, the purchase set may be contained within delimiters, and written {p1, p2, . . . , pm} for example. Other syntactic forms that indicate a set of items are also possible and known in the art. In some embodiments the order of the pi's may be significant.
Unlike the alternative command where execution is insensitive to the order of its constituent guarded commands because execution is nondeterministic (see page 111 in Gries), the order of the constituent guarded purchase statements in an alternative purchase statement is relevant to the matching process since the matching process is preferably deterministic. In some embodiments, however, the matching process may be nondeterministic. If the B.R. composition language is very high level and contains a nondeterministic OR connective, for example, then it is preferable that the matching process be nondeterministic as well. Some embodiments may include two types of alternative purchase statements: one in which the matching process is deterministic and another in which the matching process is nondeterministic. The description that follows describes the deterministic alternative purchase statement. Those skilled in the art can adapt and extend what is described here to the nondeterministic case.
An alternative purchase statement preferably takes the following syntactic form
[guard1→purchase-set1 □ guard2→purchase-set2 □ . . . □ guardn→purchase-setn]
where the □'s serve to syntactically separate the constituent guarded purchase statements. In other embodiments, the syntax may differ. Evaluating an alternative purchase statement is described further below.
For illustrative purposes, consider the IF-THEN-ELSE B.R. script shown above. It would be translated preferably into an alternative purchase statement such as
Translating an IF-THEN-ELSE B.R. into an alternative purchase statement is done using compiler and programming language techniques as known in the art. Preferably, the translation procedure is such that an IF keyword in the B.R. results in a guard being generated, and a THEN or ELSE (without an IF following it) in the B.R. results in a new purchase form being generated.
In some embodiments, the user may be given the ability to compose alternative purchasing statements him/herself directly, thus bypassing the process of composing a B.R. that is then translated to a lower level language equivalent. In other embodiments, the user may be given the ability to compose purchase forms directly.
Preferably, vendor scripts are also translated into lower level equivalents, similar to the way B.R.'s translate. In alternative embodiments, however, only B.R.'s are translated while vendor scripts are left untranslated. In other embodiments, only vendor scripts are translated while B.R.'s are left untranslated. In other embodiments, vendor scripts and B.R.'s translate into different lower level language equivalents. It is also possible using natural language processing techniques known in the art of Artificial Intelligence to do the matching of B.R.'s and vendor scripts in their raw, untranslated form. In other implementations, B.R.'s and/or vendor scripts can be translated into equivalents in languages that are lower level than the one illustrated above.
Satisfying a user's B.R. is done preferably by evaluating the alternative purchase statement that it translates into against a similarly translated vendor script. (For convenience, we will continue to refer to these translations as B.R.'s and vendor scripts, respectively. As noted above, a form is a lower representation than a script. Also as noted above, a script is provided as a result of user input and then it is translated into one or more forms.) We first describe the technique of trying to satisfy a B.R. against the simplest of vendor scripts, namely, one that translates into the equivalent of a single vendor form. The technique for dealing with more complex vendor scripts is described below. We will describe the technique for dealing with a single vendor script. The method can be extended by one skilled in the art to the situation of several vendor scripts. The technique preferably proceeds as follows. A (deterministic) alternative purchase statement is evaluated sequentially from top to bottom, i.e., from the first guarded purchase statement to the last. Evaluation terminates successfully when a guarded purchase statement is satisfied, and unsuccessfully if all guarded purchase statements cannot be satisfied. A guarded purchase statement is satisfied by a vendor script if its guard evaluates to true and all pi's in the associated purchase set can be satisfied against the vendor form. Evaluation of a guard may involve the querying of a vendor's Internet site, similar to the way guards in the concurrent programming language known as Communicating Sequential Processes (CSP) can contain interprocess communication commands. Satisfying a purchase set is might also involve accessing an Internet site. (This is analogous in CSP to the appearance of interprocess communication commands in the nonguard portion of a guarded command.).
We now describe the way of satisfying a B.R. against a more complex vendor script. (The technique can be extended to the case of several vendor scripts.) In this case, the B.R. and vendor script each translate, preferably, to alternative statements of the form
[u-guard1→purchase-set1 □ u-guard2→purchase-set2 □ . . . □ u-guardn→purchase-setn]and
[v-guard1→vendor-set1 □ v-guard2→vendor-set2 □ . . . □ v-guardm→vendor-setm]
respectively. The system then combines the two into a single alternative user-vendor statement
After a user's B.R. has been found to be satisfied by a vendor script, the processing moves to the next stage of deal closure. When a match has been identified as discussed herein, the deal can be closed in one of three ways: (1) it can close automatically; (2) it can be closed only after user confirmation; or (3) after additional verification by all parties regarding the terms of the deal. For example, the first case pertains to the purchase of simple consumer goods, e.g., groceries or staple articles of commerce. The second case may be used for more complex purchases, e.g., airline tickets. The user confirmation in this case can be provided by an electronic message from the user in textual or voice form (subsequently converted to data) or another form known in the art. The third one is typically used for transactions that are sufficiently complex that they require a formal agreement.
The server receives the electronic forms from the parties and stores this information in the database as a deal-in-process. Once the server has stored the forms from both parties as a deal-in-process, it compares the fields in the records identified by the same deal ID's. (See 65). If the fields in the records are compatible, the server marks the deal as closed. In the preferred embodiment, compatibility is defined by the fields being identical, but in other embodiments compatibility can be defined by looser criteria, such as, for example, selling price and buying price differing by less than a designated percentage, the term "12 months" being considered equivalent to the term "1 year," the "term 30 days" being equivalent to "1 month," etc. Such techniques for defining compatibility and implementing software accordingly are known to those skilled in the art. Alternatively, the compatibility dictionary technique described above can be used here as well. Once the deal is closed, the server sends confirmation messages, by email, for example, to both the buyer and the seller. It may also generate an electronic and/or non-electronic agreement and attach the electronic and/or non-electronic signatures provided with the forms when such signatures have been supplied. (See 78.). If at 65 the terms did not match, the system sends a message to both the buyer and the seller indicating the discrepancy. (See 80.) Alternatively, only one of the parties is notified that there is a discrepancy. (It may be the party initiating the transaction, or it may be the seller, for example.) In one embodiment, the user (or vendor) can also indicate requirements at a higher syntactic and semantic level, from which the system will translate to lower level equivalents using techniques found in the art. Thus, the user can specify, "I wish to get a haircut LIKE my haircut last month," and the system will retrieve the prior month haircut purchase and use it to compose the currents purchasing requirement. (Keywords such as LIKE shown here may be introduced into the requirements composition language to provide additional expressiveness.) A full macro capability may also be made available to the user, as well as language learning techniques adopted from the area of Artificial Intelligence so that the system may over time and possibly with training "learn" the semantics associated with the personal language style of the user. Automatic voice recognition techniques, as known in the art, may also be used to compose the B.R. data directly from user voice input. Graphical specification methods and devices as are known in the art may also be used, including but not limited to GUI techniques.
Various capabilities associated with general purpose procedural programming languages, such as, for example, variables, branching logic, and repetitive constructs, may be employed for constructing B.R.'s and vendor scripts. Functions found in general programming language environments may also available, such as MAXIMUM and MINIMUM, for example. Special keywords, preferably, may also included, such as LOWEST PRICE, MINIMUM DISCOUNT, SUPPLIER OF, and GRADE, for example. Further, features of nonprocedural programming languages, such as are found in PROLOG or parts of SQL (ANY, ALL, and SOME, for example), may also be included in the B.R.'s and vendor scripts.
Libraries of B.R.'s and vendor scripts can be made available to the user to aid in composition. Using the history of previous purchases made by a particular user, the system may be able to detect patterns of purchase, which the system can then use to automatically compose or translate purchasing requirements and bidding rules for him/her.
The system as a whole may also build a database of B.R.'s generated by the users of the system over time and evolve an understanding of patterns of language use that will enable more automatic translation of high level requirements into lower level equivalents. The user can also indicate default requirements that ought to apply in the absence of ones specified for a particular purchase. In addition, the user can designate certain bidding rules and purchasing requirements that must apply to all or some purchases even when not explicitly included for a particular purchase. (For example, the user may indicate that "All products must adhere to Milspec standards," or "All software must be Y2K compliant," or "All meat must meet USDA Grade A standards," or "All products must be manufactured in the United States," or "All consumer products evaluated by Consumer Reports must be rated 'A Best Buy'.") In some embodiments, the user can reference other users' purchasing requirements and bidding rules, and may even extend them. ("Use John Smith's bidding rules and requirements for all products except software.") Users can make some or all of their rules and requirements available to others, and the language for controlling visibility and adoption and extension of one's bidding rules or purchasing requirements by others can be similar to the way visibility and sharing is controlled in other areas of computing, for example, PRIVATE and PUBLIC scoping rules and CLASS extension in Object Oriented Programming languages.
Purchasing requirements can have conditional temporal components as well. ("In winter all oranges must originate from Florida and in summer all oranges must originate from South America," or "Purchase 1000 bushels of wheat before December 15."). Various trading rules and strategies may also be associated with the personal page, and the language for expressing them is, preferably, similar to the language used to express purchasing requirements as discussed above.
Items that can be purchased through the personal page can be selected from a searchable database of all available items. Preferably, a large fraction of items available commercially are included in the database. In the case that such a database is used, the user causes invocation of a conventional database search, locates the desired item that conforms to the user's requirements, selects it, and specifies delivery requirements. In some cases, the user can select a generic item, e.g., a computer with certain memory and storage characteristics, without specifying the brand. (The language may include a BRAND keyword to facilitate this.)
As noted, since the personal page is associated with a specific user (and perhaps his/her designees), it can include voice data for speaker dependent voice recognition, as described above, which can provide high quality recognition. Upon recognition of the voice command specifying the order, a confirmation can be displayed to the user. In addition, the user can provide such a voice order from his/her Internet enabled cellular phone, or even from a conventional noncellular phone. The user touches a button that automatically connects to his personal page and then speaks the order on the telephone. The order is voice-recognized and parsed. Optionally, then, the user is provided with a confirmation of the order that is read back to him/her on the phone. Various sequences of steps can be employed for providing voice input to a personal page. One example of voice input is shown in
Sites that host the personal pages of multiple users can provide the ability for collective bidding. That is, software at these sites may scan personal pages and identify common desired items and constraints associated with them. Then, common items with similar constraints can be pooled so that users are well positioned for volume purchasing. These aggregated items can be pooled to separate super-personal-pages ("virtual personal pages") which are also visited by vendors' electronic representatives. In yet another embodiment, software agents can "roam" users' personal pages on the network and organize buying pools by generating virtual personal pages.
Such an arrangement, where each user conducts electronic commerce using a personal page, provides enhanced privacy to the user. The user can specify whether he/she wants none, or some, or all the marketing information contained on his/her personal page to be visible to others and perhaps pooled and, if so, on what conditions. From the vendor side, marketing organizations have a very valuable commodity when they gather marketing data made visible by a user from his/her personal page, since all of a user's market activities are captured centrally on that page.
The user may also control advertisement using the personal page technique. A user could actively invite selective advertisements, which would then be provided to the user by vendors' electronic representatives. This feature could be implemented by the marketplace (described below in an alternative embodiment), where users' invitations for advertisements are matched with vendor electronic representatives. Alternatively, the system could allow electronic advertisement representatives, similar to vendor electronic representatives described above, to be sent to personal pages, which are then matched with users' invitations for advertisement. See
As noted, desired items on personal pages are not limited to specific goods but may also include services. Such requests for services may specify additional relevant parameters, such as a requested time for the service to be provided. In the preferred embodiment, the electronic representatives of service providers attempt to accommodate such service requests. Upon a match on price, time, location, etc., the service is scheduled accordingly and the user is notified. Service requests can be very general, such as "Provide a man's haircut<$45 in midtown Manhattan after 5 pm any day next week." Similarly, vendors' electronic representatives can have calendar features, such as "Fill 4 pm slot for man's haircut costing>$30 on West 45 Street in Manhattan at 6 pm next Tuesday." In the preferred embodiment, the marketplace will match service requests with vendor representatives in an optimized fashion using scheduling optimization techniques as is known in the art, thus creating a more efficient service economy.
Items can be delivered to the user physically, e.g., by a carrier to his home, or they may be delivered electronically, i.e., by downloading them (e.g., music and books) to the user's local computer. Physical delivery can also be provided from a center where a user would be able to review and exchange items.
A personal page may include banking information for making payments (e.g., credit card data) and obtaining banking services. Since the personal page may be where a user conducts business, adequate security, preferably, would be provided to assure protection. This information can be easily retrieved by a user with a cell phone or hand held mobile Internet appliance. Also, highly personal data, such as medicine prescriptions that must be periodically renewed, can be located on one's personal page.
Vendors may post information about items they offer on their Web sites. Preferably, then, the system would gather this published data and combine it into a list of available items. Thus, the system periodically updates the database of available items by visiting Web sites of vendors. Alternatively, vendors may submit information about the items they offer for inclusion in the system database.
Purchase strategies can be expressed in the B.R. (vendor script) at a high level. For illustrative purposes, consider the following simple high-level B.R.:
In some embodiments, the system can maintain a library of the most common high level B.R.'s (vendor scripts), which have been pre-translated—manually if necessary—into equivalents in lower level IF-THEN-ELSE scripts or alternative statements. These high level B.R.'s (vendor scripts) can be quite complex, and are preferably parametrically defined, with values for the parameters supplied by the user at the time of use. The user then chooses an appropriate B.R. (vendor script) from the library and supplies parameter values such as price, delivery date, etc. The user may even be given the ability to compose boolean conditions for particular parameter slots. The library can evolve over time using Artificial Intelligence techniques to include ever higher level B.R.'s (vendor scripts). Libraries of B.R.'s (vendor scripts) can be managed similar to the way compatibility dictionaries are managed as described above.
In addition to the attributes discussed above, many others can be used as well: credit rating, previous history, etc., for example. The B.R. (vendor script) language and its associated software can provide the capability of creating purchasing strategies whose evaluation logic is dynamically based on the offers (requests) they receive, i.e., dynamically determined at the time the B.R. is evaluated against the vendors' scripts. In addition, software may initiate searching databases of suppliers with a presence on the Web (but not necessarily combined on the same site) and retrieve all relevant data if the user has so indicated on his/her personal page.
Strategies can be defined that change dynamically based on external criteria. For example, if the purchaser is a manufacturer who buys various items required for its manufacturing process, its purchasing strategy may be dynamically determined by the number of outstanding orders it currently has for its products, and may involve, for example, asking for a bulk discount because it is making larger purchases. Similarly, vendor scripts can have similar dynamic features.
Also, several users can develop common, joint purchasing strategies, joining together to purchase items they both need. If, for example, one user's business is slow and another one's is doing well, the allocation between them of their common purchases can change. The adjustment can also be dynamic and automatic, based on the volume of orders appearing on their Internet sites, for example. Suppliers can also cooperate to meet the requirements of these strategies, subject of course to the relevant anti-monopoly and trust laws and regulations.
The personal page is generally useful, with application beyond what has been described thus far. It is preferably a programmable Web-page like electronic entity with partial or total visibility to other Internet participants. In the preferred embodiment, the user can access his/her personal page through means such as, for example, wireless handheld Internet devices, wireless is networks, voice recognized input devices, cable, cellular telephones, etc., as well as traditional Internet access devices such as the Personal Computer communicating with an Internet Service Provider (ISP) by telecommunications. In other embodiments, the user carries an electronic device such as a wireless Internet communicator (or is in a vehicle so equipped) that is in electronic contact with the Global Positioning System (GPS), and this electronic device is also in electronic communication with his/her personal page. Thus, the personal page software has access to the geographical location of its owner, and the personal page software logic executes in accordance with that current geographical location. For example, if such a user has programmed the personal page to notify him/her should he be within five highway miles of the home of his aunt, who is ill, and the user chances to enter the five mile distance, then the personal page software logic will notify him/her through his electronic communicator that he should visit his sick aunt. Similarly, for example, the user can program the personal page to be notified if he/she passes within two blocks of a supermarket to buy a quart of milk. The personal page may have electronic access also to other user appliances, such as his/her automobile, for example, and the user may be notified by personal page software logic that the fuel level is low and that he/she is now within one mile of a gas station. Or, for example, if there is a mechanical malfunction in the automobile, the personal page software may notify the user that he/she is within a certain mile distance of an authorized repair shop, and may even guide the user to that destination in accordance with GPS. See
The personal page, preferably, can be accessed by the user using voice recognized input techniques as are know in the art. The user speaks instructions into an electronic device connected to the personal page, which may be a suitably equipped cellular phone, for example, and issues instructions that cause the personal page to be appropriately programmed. Once programmed, the personal page can be visited by other Internet participants who interact with it. So a user, for example, might speak the instruction "Make an appointment with a dermatologist" into a cellular telephone and voice recognition software will, preferably, translate and it into an appropriate construct that is stored on the user's personal page, which then can be visited by software agents associated with dermatologists looking to fill their appointment calendars. See, e.g.,
Similarly, user's personal data can be stored on the personal page as well. Users' medicine and vision prescriptions and other medical history or conditions and data; dental records; personal dining habits (which restaurants, which kinds of restaurants); clothing and shoe sizes; cultural and social preferences; schools attended; financial history and credit data; domestic and foreign travels; criminal records; purchases made; photo and voice data; family data; etc., are all examples of things that can appear there. Personal historical data may also appear, such as service in the armed forces, jobs held, educational test scores, etc. Other embodiments may contain data and types of data not listed here. Personal page software can then use the stored data in its interaction with the Internet and/or with the page's owner. For example, in an embodiment where the personal page interfaces to GPS, as described above, the personal page software may notify the user that he/she is now three blocks away from a pharmacy where he/she should refill a medicine prescription that is running low. Similarly, personal page software may inform the user that he is two blocks from a shopping mall and next week is his/her mother's birthday. See, e.g.,
Other entities may also have access, albeit preferably in a limited way, to a user's personal page. A pharmacist filling a user's prescription may enter that fact along with relevant data onto the user's personal page. Similarly, all or some of a user's medical records could be stored on his/her personal page, thus providing easy and instant access to those records by any doctor treating the user. In alternative embodiments, all or part of the user's personal page could be stored in a nonvolatile, compact form, on a programmable mini-disk, for example, for immediate access. In some embodiments, special purpose electronic devices for interacting with a user's personal page could be available. When applying for a loan, for example, the user could insert his/her personal page mini-disk into a special reader located on the bank's premises, thus giving the loan officer instant access to the applicant's financial data and/or history and/or criminal record. In other embodiments, instead of presenting the bank with a mini-disk that is then read at the bank, the user may allow the bank software access to his/her personal page located on the Internet.
In some implementations, the user's personal page could be used as a passport when traveling, in lieu of the hard copy booklet now used for that purpose. The user could present a mini-disk passport when entering or leaving a country, which would be read and/or written onto by a special reader. In other embodiments, the user could make accessible his/her personal page located on the Internet to passport officials when entering or leaving a country. Using encryption techniques known in the art, such data could be made secure.
The personal page could be used as personal identification by the user in some embodiments. If the personal page contains photo images of the user, for example, then it could be used as a photo id. It could also contain user voice data, thus acting as a voice id as well. Law enforcement agencies could use a convicted criminal's personal page to keep track of the whereabouts and dealings of the user, for example, and government agencies could use the personal page as an electronic "license", say a drivers license or firearms license for instance. In that case, special readers, perhaps wireless and hand held, could be used by police officers in accessing the personal page. In other embodiments, the personal page license may be accessed on a mini-disk carried by the user.
In addition to the applications described thus far, the personal page has other uses as well. For example, it could be used by its owner to substantially optimize his/her purchases and acquisitions of goods and/or services. The user indicates on the personal page, for example, that he/she wishes to buy gifts for three friends, and that the total outlay should not exceed a certain cost, say $400. He/she can also indicate preferred categories of gifts, such as golfing equipment for the first friend, music CD's for the second friend, and books for the third. The user may have the opportunity of providing even finer purchasing requirements, such as indicating a category of CD's, say classical music, from which the purchase is to be made. Similarly, he/she can indicate that the cost of a particular gift is to be no less than a given amount, or between certain minimum and maximum amounts. Other possibilities that constrain the purchase as known in the art are also possible.
Once the purchasing requirements have been input, personal page software, preferably interacting with various sites on the Internet, compute various substantially optimal purchasing strategies using optimization techniques as are known in the art. (In alternative embodiments, interaction with the Internet may not be necessary. This would occur, for example, if the personal page software has locally available to it an appropriately extensive database of goods and services available for purchase.) The substantially optimal purchase decisions are presented to the user, who has the option of choosing among them. The user can then choose, if so desired, to purchase one or more of these items online, using purchase techniques as discussed above, such as B.R.'s.
The process can iterate. The user, having been presented with substantially optimal purchase recommendations based on the specified constraints, may choose to partially accept the system's recommendations. Having done that, the user can, optionally, change some or all requirements and ask the system to recompute the substantially optimal purchases for the remaining ones. Referring to the example cited above of a user wishing to purchase gifts for three friends, he/she may elect to accept the system's recommendation for gifts for one or two friends, for example, and then, optionally, change some or all requirements and ask the system to recompute optimal purchases for the remaining friend(s). See
Another application of the personal page involves programmable personalized telephone service. Preferably, this feature involves telephone company (and/or cellular telephone company and/or cable company, but for simplicity referred to here as "telephone company") interaction with the user's Internet personal page. (In other embodiments, the telephone company does not electronically interact with the user's page, but instead electronically accesses the user's telephone or cellular phone.) This feature allows the user to customize his phone service by programming telephone features on his/her personal page. The customization can be changed by the user by simply calling up the personal page and reprogramming or modifying the service logic. Programming, reprogramming, or modifying service logic is preferably done by accessing the Internet personal page using interactive means, but can also be done using voice input and voice recognition techniques as are known in the art. Preferably, the service logic is communicated to the personal page using a high level scripting language that is as close to natural language as possible, but lower-level interfaces, ones involving prompts and/or electronic forms that the user completes, are also possible in addition to or in place of higher level ones. Graphical languages as are known in the art for specifying service logic are also possible. Graphical methods, including but not limited to GUI techniques, may also be used. In general, all means of interacting with the personal page as known in the art can be used to program, reprogram, or modify the service logic contained there. A user can have many service logic scripts if he/she wishes, and they can be stored in service script libraries. Techniques of Artificial Intelligence as known in the art can be used to automatically construct service logic programs by monitoring the user as he/she interacts with the telephone over a period of time and "learning" the user's preferences.
The user's service logic specifies how he/she wishes telephone service to be governed. The user may, for example, specify that between the hours of midnight and 8 am all incoming calls are to be routed to another number, or certain incoming calls (based on the caller ID, for example) are to be blocked, or that the user wishes a wake-up call in 2 hours or at a certain hour. Similarly, the user can, for example, provide different outgoing messages based on the caller ID or class of caller ID's, or different outgoing messages for different time periods. For example, the user may have one message for all callers outside his local area, another one for specific caller ID's, another one for all caller's calling from a specific area code, etc. Call waiting features can be customized, with the user specifying which callers (based on caller ID, for example) he/she is willing to be interrupted for. The user can even elect to assign priorities to caller ID's, and specify in the service logic how to handle the situation of receiving a call from a caller of priority i while talking to a caller of priority j. (For example, "IF j<i THEN allow interruption ELSE play outgoing message 3.") The user may also, for example, choose to use different long distance carriers during different time periods (weekday, night, weekend for example) to take advantage of the best price available at the time a call is made. In this case, the user's local computer's memory and/or the user's Internet browser and/or personal page may have access to long distance carrier rates available on the Internet and can interface to service logic programming tools so that the best strategy for deciding which carrier to use during a particular period can be at least partially automated by the software. Optimization techniques known in the art for creating an optimal long distance carrier schedule (which carrier to use during which periods) can be used in constructing the service logic. In general, all techniques known in the art for specifying and generating telephone service can be used.
Whenever a user's service logic is programmed, reprogrammed, or modified on his/her personal page, the service logic is preferably downloaded to the telephone company's computer. This is preferably done using Internet communication and Internet communication protocols between the two computers, but can be through direct connection or through wireless transmission instead. In general, any and all means known in the art for communicating between computers can be used. Preferably, the service logic is translated to a lower level language equivalent so that its execution is as efficient as possible. Once the service logic is resident in the telephone company's computer, the logic is invoked whenever certain triggering events occur, such as, for example, the arrival of an incoming call, reaching a certain moment in time, going off-hook, going on-hook, etc. The user's service is handled appropriately in accordance with the dictates of the programmed service logic.
In an alternative embodiment, the service logic is resident in a device (or devices) at the user's location, such as the user's telephone set, telephone answering machine, computer (personal computer, for example), cellular phone, beeper, pager, television set, other hand held appliance, etc. The service logic executes locally, in the device that it is resident in, and is triggered by events such as, for example, the arrival of an incoming call, reaching a certain moment in time, etc. Examples shown above of the various ways service can be programmed by the user apply here as well.
If the user's local computer (personal computer, for example) contains the service logic handling the user's telephone service, then the user's Internet browser and/or personal page can interface to the service logic. In this fashion, the service logic can be kept up-to-date to adjust to changing circumstances. For example, the user's Internet browser and/or personal page can periodically download the latest long distance carrier rates and store them on the user's local computer so that the service logic can make its decisions based on the most recent data. In general, the service logic can use a locally stored database to aid it in its real-time execution decisions, and that database can be kept up-to-date automatically by the user's Internet browser and/or personal page. (For example, if personal page software detects over the Internet that one of the user's acquaintance's has just been elected to high office, then the software can upgrade the acquaintance's priority, as discussed above.) In some embodiments, the actual service logic itself can be modified by the Internet browser and/or personal page. For example, if the user is using a service logic program obtained from an outside source, over the Internet say, and the personal page has detected that an upgrade to the service logic program is now available, the personal page software can download the upgrade and apply it to the service logic program. Any and all techniques known in the art for automated management of software upgrades, preferably over the Internet, can be used to maintain service logic programs.
The user can also, in some embodiments, use buying request scripts described above to locate new service logic programs. The user creates a script such as, for example, the following on his personal page:
This technique of creating a buying request script on the user's personal page, which then locates a service logic program, preferably on the Internet, downloads it, and then installs it locally on the user's computer can be used to locate, download, and install other types of software and/or data as well, not only telephone service logic programs. For any appliance that contains software and/or data, such as, for example, a telephone, television, video camera, CD player, calculator, clock, electronic organizer, camera, automobile or other vehicle, microwave oven, washing machine, stove, medical machine, dental machine, automobile diagnostic machine, factory machine, farm machine, military weapon or machine, telephone switching system, etc., and that is connected to the user's computer (through wire or wireless means), a buying request script located preferably on the user's personal page can be used to locate, download, and install software and/or data on that appliance. In this case, the user's computer installs the downloaded software and/or data on the appliance preferably through the communication medium (wire of wireless) linking it to the appliance. The appliance need not be necessarily permanently connected to the user's computer to use the method just described. See
In other embodiments the appliance can be connected to the Internet directly, preferably through its own computer. In some embodiments the appliance can have it's own personal page. Appliances that are connected to the Internet, whether directly or through a user's computer, can be interacted with and controlled from elsewhere on the Internet. For example, if the appliance is a video camera (or collection of video cameras) in a house that is connected to the Internet, then the home owner on vacation, for example, in another location can connect to the Internet locally and access the camera's Internet page (preferably its personal page) and view real-time images of the interior of his house to see that everything is in order. He/she can, in some embodiments, control the camera (s) and reposition it (them), thereby improving the view, zooming in on a particular portion of a room, for example. The camera(s) may be on the exterior of his house as well. Other appliances, such as a stove, microwave oven, water heater, furnace, office machine, factory machine, etc., can be similarly remotely controlled if connected to the Internet. Thus, for example, a user on his/her way home from work can connect to the Internet through a wireless communication device as is known in the art, visit the Web page associated with his/her coffee machine at home, and issue a remote command that switches the machine on so that fresh coffee will be ready when he/she arrives home. The user can, in some embodiments, reprogram the appliance remotely through the Internet linking him/her to the appliance. This is preferably done by the user visiting his/her personal page, creating a purchase script (B.R.) as described above to locate an appropriate program for the appliance. Once found, the script downloads the appliance program to the appliance itself through the appliance's Internet connection (or through the user's computer to which the appliance is connected) for installation at the appliance.
Utility companies can use the technique just described to gain access to their meter devices remotely. The meter devices can be connected to the Internet and accessed by the utility company through the Internet for the purpose of taking readings, making adjustments, turning offservice, etc. Similarly, banks and financial institutions can connect their financial machines, ATM's for example, to the Internet and then remotely control and monitor them from central locations. In general, any electrical or electronic device for which remote monitoring and/or control is desired can be connected to the Internet and, preferably, be provided with a personal page, and thereby accessed remotely by authorized personnel. Password protection and/or encryption techniques as known in the art can be used to protect the integrity of such systems.
The user creating a buyer request script can, in some embodiments, send his/her buying request script out to the Internet in search of other, similar buying request scripts. The buying request script then "joins" together with other scripts to form collective buying groups, hoping to get a better deal by combining with other purchases into a single, larger purchase. Preferably, this is done as follows. The user creates a buyer request script as described above, which is then sent to an aggregation site on the Internet where the combining with similar scripts, if it is to occur, takes place. Software at the aggregation site scans and analyzes the scripts that have been sent there and, preferably, using Artificial Intelligence techniques identifies scripts that are compatible and that can be combined. The software then creates a "super" buying script from the aggregated ones that represents the combined purchase, once again preferably using Artificial Intelligence techniques. In alternative embodiments, the combining is not done at a central aggregation site, but instead software aggregation agents roaming the Internet and visiting users' personal pages locate and pool compatible scripts from which super scripts are created. Preferably, super scripts belong to virtual users, "super" users, which are software entities that represent the combined interests of the real users whose scripts have been combined. The super scripts then act like ordinary user scripts as described above. Once a super script finds a matching vendor script and the deal is closed, the aggregation software splits the purchase among the aggregated buyer request scripts and preferably sends electronic notification to the users whose scripts were combined notifying them that a match has been found. Vendor scripts can be combined in a similar way in some embodiments. In some embodiments, super scripts themselves can be combined to form "super super scripts," and so on.
Personal pages can also be used to support online "Requests For Proposals," (RFP's). The user wishing to solicit proposals creates an RFP, preferably using a high-level scripting language as described above, and puts it on his/her personal page. In other embodiments, it can be created by completing an electronic form. Alternatively, the RFP can be generated using voice input and/or graphical techniques, or any other technique known in the art for collecting data from users. Once on the personal page, the system uses the techniques for finding suitable matches for a user's bidding requirement described above to find appropriate proposals that are compatible with the RFP. Proposals play the role of vendor scripts described above. In the preferred embodiment, the RFP stays resident on the personal page while roaming vendor software agents traverse the Internet visiting personal pages looking for RFP's. A vendor software agent that locates a compatible RFP then submits an electronic proposal to the user, preferably by submitting it to the user's personal page. In other embodiments, RFP's roam the Internet and visit selected sites where they encounter vendors' software agents. In other embodiments, the RFP's and vendor agents are sent to central sites where the matching takes place. In yet other embodiments, the continuously circulating marketplace technique described below can be used. In general, any technique known in the art for rendezvousing software and/or data entities in a network can be used.
In the preferred embodiment, a central historical archive of RFP's and the proposals submitted in response to them is maintained on the Internet. (In other embodiments, the historical archive is not stored centrally, but is distributed across the network, and may even be stored locally on users' computers. They may even be contained on users' personal pages.) On creating an RFP, the user can, optionally, query the historical archive, retrieving similar RFP's along with the proposals submitted to them. The user can then use these retrieved proposals and contact the vendors that submitted them to solicit proposals for his/her RFP. In the preferred embodiment, the query, retrieval, and contacting of vendors for the solicitation of proposals is done automatically by software agents connected with the user's personal page. All techniques known in the art for gauging the similarity of scripts can be used to determine if two RFP's are similar, including but not limited to the compatibility dictionary technique described above.
Returning to B.R.'s and vendor scripts, in an alternative embodiment, the bidding, purchasing, and matching can be done at a network site or multiple sites, called here the "marketplace," which is neither the user's local computer nor the vendor's site. The marketplace acts as an electronic market matcher, matching vendors and users. The marketplace dynamically maintains a database of pending users' purchase requests (B.R.'s). Preferably, this database is segmented along item categories so that matching vendors and users can be done efficiently and quickly. Vendor electronic representatives are also transmitted to the marketplace.
The marketplace interprets (i.e., executes) each vendor script against each purchase request in the appropriate category (or categories) of the database. When a match is found, the marketplace may electronically enable the vendor's electronic software representative to contact the user. This is similar to the feature on dating/matchmaking sites where the user can ask the system to notify him/her when a suitable candidate registers with the site. Alternatively, the marketplace sends electronic messages to the matched user and vendor indicating that they have been matched. Also, vendor scripts can have trigger features, which ask the marketplace to store the script indefinitely or for a limited period of time and to enable the script (or the vendor) when a matching user request is sent to the marketplace. Similarly, the user request can be stored in the marketplace indefinitely or for a limited period of time, on command from the user, and can have triggering features.
An alternate implementation that enables various entities to conduct electronic transactions in a distributed environment is based on the object-oriented computation model. In this implementation, active intelligent software "agents" (objects) are instantiated by users, each agent the carrier of a purchasing requirement and bidding rule throughout the network. The agents represent the user in his/her quest to make purchases. We will call these agents "purchasing agents." Similarly, vendors instantiate intelligent software agents that carry scripts throughout the network. We will call these agents "vendor script agents." All agents can remain anonymous if their owners wish to remain anonymous.
On instantiation, a purchasing agent is released into the Internet, migrating to sites at which it will meet vendor script agents. On finding one another, the bidding rule agent and vendor script agent invoke methods (functions) within each other to determine if they are a compatible match. When a match is found, both agents report back to their owners (the user and the vendor) that a match has been found, and the deal can then be closed between the user and the vendor. The agents can then be destroyed as the deal is concluded.
The purchasing agents can be relatively passive compared with the vendor script agents. The purchasing agents can migrate to a marketplace site and passively wait for vendor script agents to "fly by" and visit them.
Yet another implementation is possible, this one based on a continually circulating marketplace. Here, all information on a global basis, or perhaps on an industry basis, is constantly and continually circulating throughout the Internet. All bidding rules and all vendor scripts are continuously being broadcast and rebroadcast to every server (or perhaps to every local computer) on the Internet. Alternatively, there can be two separate broadcast streams, one for purchasing requests and one for vendor scripts. Alternatively, only purchasing requests are broadcast. Alternatively, only vendor scripts are broadcast. So a user wishing to make a purchase inserts his purchasing request into the broadcast stream. Similarly, a vendor with goods and/or services to offer inserts his script into the circulating stream. A user with a purchase to make writes a request that "pulls down" (i.e. filters) from the circulating stream of scripts those scripts relevant to his purchase request. Similarly, or perhaps alternatively, the vendor wishing to sell goods and/or services writes a script that pulls down from the circulating stream of purchasing requests those requests that are relevant to what the vendor is marketing. The pulled down scripts (or purchasing requests) can then be examined by the user (or vendor) for a match. In general, any technique known in the art for rendezvousing software and/or data entities in a network can be used.
A continually circulating steam of information is a generally useful technique that applies beyond the confines of the application just described. An entire network, such as the Internet, for example, can be implemented using this technique. Preferably connected through high speed cable or, in other embodiments, through wireless microwave communication or through satellite transmissions, the entire information contained in the network is continually circulated to each user's local computer. Preferably, the information is grouped into page-like units, similar to the technique used in the Internet today where information is organized into Web pages. The user wishing to access information in the network composes a software filter that executes on his/her local computer and extracts from the circulating stream those pages containing information he/she is interested in. For example, if the user wishes to see all pages containing the phrase "American democracy," then he/she composes a filter in an appropriate scripting language indicating that only those pages containing the desired phrase are to be extracted. Alternatively, he/she completes an electronic form similar to the way Internet search engines operate and inserts the phrase "American democracy" into an appropriate field on the form, or uses voice input techniques as are known in the art. In general, any technique known in the art for collecting information from a user can be used. The user's local computer then extracts from the circulating stream the desired pages for presentation to the user. Alternatively, the continually circulating stream of information may not be broadcast to each user's local computer, but instead may be broadcast to computers to which user's local computer's are connected, e.g., servers. In such embodiments, the user composes filters that are sent to the server and execute there on the user's behalf. The extracted data is then sent by the server to the user's local computer. Should a user wish to communicate information from his/her local computer to another computer located on the network, the user inserts the information into the circulating stream with an electronic address indicating the destination. Alternatively, if the user's local computer does not have the circulating stream sent directly to it, but instead is connected to a server to which the stream is broadcast, then the user sends the information to the server for insertion into the circulating stream. All inter-computer communication (e.g., email, Instant Messages, etc.) can be done using this technique. A message destined for another computer is preferably removed from the circulating stream by the receiving computer as it extracts the received message. Alternatively or in addition, the transmitting computer can remove the message from the stream after a certain amount of time has elapsed or after the message has circulated through the network a certain number of times. Alternatively or in addition, garbage collecting "scavenger" nodes that prune the information stream and remove old and/or expired messages and/or pages may be included in the network. In some embodiments, encryption techniques as are known in the art can be used to shield unauthorized access and/or manipulation of information from the stream. In some embodiments, the network may include "police" nodes that monitor the network for undesired and/or illegal data, e.g., pornography.
In some embodiments, the circulating stream of information may be composed of several circulating substreams, not all of which would be necessarily broadcast to every computer on the network. For example, there may be a sports substream, a science substream, a financial substream, etc. The substreams may not necessarily be disjoint, i.e., some information may appear in several substreams. For example, an article about grapes may circulate in a wine connoisseurs substream and in an agricultural substream.
The present invention is not to be limited in scope by the specific embodiments described herein. Indeed, various modifications of the invention in addition to those described herein will become apparent to those skilled in the art from the foregoing description and accompanying figures. Such modifications are intended to fall within the scope of the appended claims. Doubtless numerous other embodiments can be conceived that would not depart from the teaching of the present invention whose scope is defined by the following claims.
Patent Citations
Non-Patent Citations
Referenced by
Legal Events
Original Image


text:
Thanks for redeeming.{{else}}
Success! Thanks for repurchasing.{{/if}} {{else}} {{#if Expired}}
Increase my visibility!{{else}} {{#if IsMultiPack}}
{{#if HasMultiPack}} You have {{MultiPackCount}} top spot(s) left. Now loading you into the search listings... {{else}} You have used all top spots. Now loading you into the search listings... {{/if}}{{else}}
We are loading you into the search listing pages...{{/if}} {{/if}} {{/if}} {{/if}}
{{Current}} just saw you!{{/if}} {{#if LastTopSpotPurchaseIsMulti }} {{#if HasAnyTopSpot}}
{{#if HasFreeTopSpot }} {{ UnclaimedTopSpotFree }} Free {{/if}} {{#if HasPaidTopSpot }} {{#if HasFreeTopSpot }} & {{/if}} {{ MultiPackCount }} {{/if}} Top Spot{{#if Plural}}s{{/if}} Left{{else}}
0 Top Spot{{#if Plural}}s{{/if}} Left{{/if}} {{else}} {{#if HasFreeTopSpot }}
{{ UnclaimedTopSpotFree }} Top Spot{{#if Plural}}s{{/if}} Left{{/if}} {{/if}} {{else}} {{#if HasResults}}
{{Current}} see you now!{{else}} {{/if}} {{/if}}
You can now invite anyone to meet at your favorite Starbucks.
Limited-time feature
26 year old man | Bronx, NY, USA | Seeking men 23-35 within 10 miles
Simply looking for someone to mesh with me, sorta like a great PB and Jelly sandwich. Hence my UserName.
My name is Casimar and a 24yo teacher from the South Bronx. I'm new to this so I have no idea what to write. About me? I'm an active guy, I like to maintain as healthy of a life style as I can have. I love to dance. I was actually a Latin Ballroom Dancer before I decided to be a teacher, so I'm definitely a big music and dance fan. I'm also a huge family guy and very ambitious, as I believe in "role models" and that I should aim to be as "cool" as possible. Who I'm looking for? Psh, I have no idea. Dating has proven to be extremely difficult. I tend to meet the "hidden motive" guy often, so I guess someone who is also looking to have fun and open to starting a relationship. I pretty much have everything else in my life in order; all thats missing is someone special to share moments with. I love to laugh and keep people in a great mood. I'm really just looking for that other half to enjoy life and really have a good time.
Camping , Coffee and conversation , Business networking , Cooking , Dining out , Movies/Videos , Music and concerts , Nightclubs/Dancing , Performing arts , Playing cards , Playing sports , Shopping/Antiques , Travel/Sightseeing , Volunteering
I exercise 3-4 times per week.
Currently wrapping up my masters so I consider the Library to be a Hot Spot.
For fun I enjoy a good night out dancing or a night in watching something "ratchet" on TV like those House Wives. And, although I'm not good at sports... I do enjoy playing them. Just don't put me on any teams. I'll GLADLY watch by the sidelines.
Z{{Cta}} {{#if HasMoreInfo}} ?{{CtaSecondary}} {{/if}}
|What he is looking for
|6'0" (182cms)
|5'11" (180cms) to 6'11" (210cms)
|Body type:
|Slender, Athletic and toned, Stocky
|No preference
|Dark brown
|No preference
|No Way
|No Way
|Social Drinker
|Never, Social Drinker
|Education / Teacher / Professor
|No preference
Teaching while working on my Masters Program
|$25,001 to $35,000
|No preference
|Never Married
|No preference
|Have kids:
|No preference
|Wants kids:
|No preference
|Latino / Hispanic
|No preference
Born in the Bronx, Family's from Puerto Rico.
|Spiritual but not religious
|No preference
|English, Spanish, Other
|Bachelors degree
|Associates degree, Bachelors degree, Graduate degree, PhD / Post Doctoral

subset: commoncrawl


text:
by MaDonna on 2015-06-22
by mwinaz3106 on 2015-06-21
by MaDonna on 2015-06-20
by RTG on 2015-06-20
by Antonio on 2014-01-23
by MaDonna on 2015-06-18
by rositza on 2015-06-19
by goart24 on 2015-06-21
by Tracee on 2015-06-14
by jannaverse on 2015-06-18
by RenataAc on 2010-10-01
by Shoreful Islam on 2015-06-08
by Jen on 2015-06-14
by nathan_ct on 2015-06-12
by Bátja ⃰ ⃰ ⃰ ® on 2015-01-10
by Jen on 2015-06-09
by RLC on 2015-06-17
by MaDonna on 2015-06-14
by MaDonna on 2015-06-16
by Crazy Psychiatrist ® on 2015-06-17
by Smoke_in_my_eyes on 2015-06-19
by MaDonna on 2015-06-08
by Fox_Naruto96 on 2009-05-13
by Lumio on 2015-06-17
by Christian on 2015-06-08
by xk1000ox on 2010-07-14
by Guitarzan on 2015-06-14
by Jen on 2015-06-17
Your browser, your style! Dress it up with a design of your own!
Submit a New Theme
Learn more
To create your own collections, you must have a Mozilla Add-ons account.
Create an Add-ons Account
or log in to your current account
Privacy Policy
Legal Notices
Report Trademark Abuse
| View Mobile Site
Except where otherwise noted, content on this site is licensed under the Creative Commons Attribution Share-Alike License v3.0 or any later version.


text:
The 5th Annual New York City Poetry Festival
- Performing & Visual Arts
- 10 South St, #7, New York, NY, 10004
Nickelodeon presents AOS2S Youth Step Tour @ Bronx, NY
Art of Stepping
Saturday, April 19, 2014 from 9:00 AM to 2:00 PM (EDT)
Art of Stepping™ (AOS) is excited to announce the partnership of AOS2S Youth Step Tour with Nickelodeon to get our kids active and fight childhood obesity!
AOS2S Youth Step Tour is a national campaign created by the Art of Stepping™ to help fight against childhood obesity and promote artistic expression. In partnership with former NBA Los Angeles Lakers Point-Guard Chris Duhon's Stand Tall Foundation, AOS launched the Sneakers 2 Succeed (S2S) campaign on July 16, 2011; the initiative is a year-long campaign to collect gently used/new sneakers and donate them to local charities.
In 2014, AOS expanded the campaign by offering our award winning step program that teaches dance through mathematical formulas for FREE. Starting February, we'll be hitting the road alongside Nickelodeon to get kids active as we near the largest kids party of the year WorldWide Day of Play!
The tour consist of hosting FREE one (1) day camps throughout the country where admission for each participant is a donation of a pair of gently used/new sneakers for a family in need. Without a donation, there will be a $20.00 fee per attendee. All registrants must be over the age of 6 to attend and must be escorted by a parental guardian that must be present throughout the event and registered.
Each tour stop runs as follows:
The next stop on our tour is: Bronx, New York in association with Soundview Academy for Culture and Scholarship!!!
Art of Stepping™ is also giving you a chance to perform LIVE at WorldWide Day of Play!!! Just submit a Youtube link of you and your friends (maximum 5 steppers per video) doing the step shown here! Winners will get two tickets to WorldWide Day of Play and an opportunity to perform on its stage! Show us what you've got!!! #WWDOP
Art of Stepping™ is a national recognized and accredited organization that provides interactive and exclusive curriculum based programs that teach stepping through mathematical formulas. The organization is owned and operated by Remo Production, Inc., a company founded by celebrity step choreographer, Jessica "REMO" Saul. AOS currently has operations in California, Florida, Indiana, Illinois, New York, New Jersey, Pennsylvania, and Tennessee and operates via its three divisions, AOS After-School, AOS PRO, and AOS Events. AOS' mission is the fight against childhood obesity. Art of Stepping is the proud recipient of the 2010 President's Council on Fitness, Sport and Nutrition Community Leadership Award. For more information visit: www.ArtofStepping.com Follow us on Twitter/Facebook/Instagram: ArtofStepping
Join millions of people on Eventbrite.
In order to purchase these tickets in installments, you'll need an Eventbrite account. Log in or sign up for a free account to continue.


text:
Key things you need to know aboutDr. Kassal:
Dr. Kassal's Experience
Research training, expertise and qualifications
Dr. Kassal's Specialties
- Neonatal Medicine
- View 1 specialty
More About Dr. Kassal's Background
Patient Satisfaction
Patients' feedback on their experience with Dr. Kassal
Likelihood of recommending Dr. Kassal to family and friends is 3.6 out of 5 5 1 12
See More Survey Results
8 Facts About Patient Satisfaction Surveys
Patient satisfaction surveys provide a standardized way of reporting about healthcare experiences. But there can be more than meets the eye when reviewing scores. Here's what you should know
Appointments & Offices
Check insurance plans, locations and make an appointment
- 127 W 3rd St
- Cameron, MO 64429
- Rajeev Kassal MD
- Rajeev Kassal MD
- 602 Lana Dr Ste D
- Cameron, MO 64429
7 Tips to Prepare for Your Appointment
The key to a successful appointment is communication. To get the most out of your visit, prepare ahead of time so you can lead the conversation with your doctor. These 7 tips will get you ready
Oops, you entered a bad link for Dr. Kassal!
The link you entered contains bad characters or identifiers. Please enter the link exactly as it appears in your email or text message.
Thank You
This confirms that we have received your survey about Dr. Kassal. Please note: it will take 24 hours for your survey results to show up on the doctor's profile.
Thank You
Our records show that you have already confirmed your survey for Dr. Kassal. Please note: it takes 24 hours for your survey results to show up on the doctor's profile.


text:
800 University WaySpartanburg, SC 293031-864-503-5000
Ryan CornfieldTeam: Men's Golf
Lexi Shubert - 44Team: Softball
"Surrounded by students on my level of intellect,
determination and integrity, I feel much more comfortable." - Hilary
Great things are always happening at Scholars Academy and we want our students and parents to stay informed. Below you will find a variety of information to keep you connected throughout the school year.
Summer Reading Assignments:
College Exam Schedule for Scholars
April 27 Last day of regular
schedule for all Scholars
No Scholars-only exams
See daily schedule.
Daily Schedule for Scholars
From April 28 through
May 27, Scholars should follow this modified schedule:
Wed., May 27
LAST DAY AT SA (continue classes at high school per their schedule)
The Scholars Academy headquarters is now located in Room 251 in the library building.
Newsletters 2012-2014March 2015
October 2014
March 2014
October 2013
February 2013
November 2012
September 2012
July 2012
Literary MagazineLiterary Magazine 2014Literary Magazine 2013
Literary Magazine 2012
Literary Magazine 2011
Quick LinksHandbook 2014-2015
Academic Honor Code of Conduct
Inclement Weather Policy
Useful Information & Frequently Asked Questions
Contact Us
Scholars Academy
School of Education
800 University Way
Spartanburg, SC 29303
Phone: 864-503-5506
Fax: 864-503-5183
Melissa DeLoach
Scholars Academy Director
Dr. Lee HurrenDean of the College of Education at USC Upstate
Faculty/Staff Directory
The University of South Carolina Upstate is accredited by the Southern Association of Colleges and Schools Commission on Colleges to award baccalaureate and masters degrees. Contact the Commission on Colleges at 1866 Southern Lane, Decatur, Georgia, 30033 or call 404-679-4500 for questions about the accreditation of USC Upstate. Comments or Complaints?


text:
Crime, courts and legal issues in Milwaukee and throughout Wisconsin
Inmate already serving life gets pass for May homicide of fellow inmate
Here's a bit of prosecutorial discretion that will no doubt be seen as either efficient or outrageous, wise or lazy.
The prosecutor in Alger County, in Michigan's Upper Peninsula, has decided its not worth charging Andre Adams with the May 31 strangulation of fellow inmate Carlos Marquis Love, WLUC-TV, Channel 6 reports.
Love, 39, of Detroit, was serving time at Alger Correctional Facility in Munising for armed robbery and having a weapon in prison.
Authorities believe Andres Adams killed Love, but the Alger County prosecutor told WLUC-TV "while it goes against every personal and professional instinct to do nothing about a chargeable murder, the fact remains that we cannot obtain additional consequences for the prospective defendant."
Adams is serving life without parole for a 2007 homicide.
Is it the right call?
A small county would save lots of money by not prosecuting a crime involving two state prisoners who otherwise have no ties to the community. Adams can get no more punishment, and in fact, would likely see a trial outside the prison as a welcome distraction from his current sentence.
But as one commenter on the TV station's website put it, "So he's free to kill as many inmates as he wants or gets hired to kill?"
Does it matter that the victim was a fellow inmate? What if it had been a guard or medical professional or some other visitor to the prison?
Comments »
Read and share your thoughts on this story.


text:
Corona Creekwood LLC filed as a Foreign Limited Liability in the State of Florida on Tuesday, March 18, 2008 and is approximately seven years old, according to public records filed with Florida Department of State. The filing is currently active as of the last data refresh which occured on Sunday, June 7, 2015. A corporate filing is called a foreign filing when an existing corporate entity files in a state other than the state they originally filed in. This does not necessarily mean that they are from outside the United States.
Christopher Mahowald serves as the Managing Member and has interests in other corporate entities including Young Presidents' Organization Inc. - Lone Star Dallas Chapter, Efo/Robroy, Inc. and twenty-seven more corporations. Christopher's past corporate affiliations include Efo/Liberty, Inc., Efo/Memorial Square, L.P. , and Corona Mission Ranch LLC .
Tony Koeijmans is the Managing Member of Corona Creekwood LLC. Tony's additional corporate interests include Dallas City Homes, Inc., The Mahowald Group III, L.L.C. and thirteen more corporations.
The Treasurer of Corona Creekwood LLC is Scott Harris.
The registered agent for the company is Corporation Service Company. Also known as a statutory or resident agent, the registered agent is responsible for receiving legal notifications regarding court summons, lawsuits, and other legal actions involving the corporate entity.
Key roles for Corona Creekwood LLC
Christopher W. Mahowald
Managing Member
Tony Koeijmans
Managing Member
Scott Harris
Rsf Partners
Managing Member
|Filing Type:
|Foreign Limited Liability
|State ID:
|Date Filed:
|Tuesday, March 18, 2008
Comprehensive Insight Plus Report
|Learn More
|The D&B Comprehensive Insight Plus Report for Corona Creekwood LLC combines D&B's proprietary statistical scoring with business, payment and financial information all in one report.
US Company Profile Report
|Learn More
|The D&B U.S. Company Profile contains basic information such as address and telephone number, executive names and titles, line of business and SIC codes, D-U-N-S Numbers, organization status, and year and location of incorporation for Corona Creekwood LLC.


text:
The Fillmore County Republican Party will be hosting its annual picnic and welcoming the Minnesota Republican Deputy Chair Chris Fields to Sylvan Park in Lanesboro on Thursday, July 16, beginning at 7 p.m.
"We got to fix a roof for a guy named Anthony. He was a Marine who served in Vietnam. He was an interesting guy who had a lot of vehicles," said Lanesboro United Methodist Church (LUMC) youth mission trip member James Kenyon, explaining for whom the 13 youth from LUMC and Wykoff United Methodist Church (WUMC) traveled to Mission, S.D., to assist in rebuilding his home.
"Dick DeLeo was a good friend of Forestville, and John Crippen, director of historic sites at the Minnesota Historical Society (MNHS), came for our Independence Day 1899 celebration to thank those who stepped up to Dick's challenge – we have a plaque that will go into our visitor's center recognizing those who donated toward the challenge," explained Historic Forestville site manager Sandy Scheevel, pleased to be able to survey the plaque displaying a long list of names of people whose generosity helped establish an endowment fund for southeastern Minnesota's only MNHS living history interpretive site.
After a brief hiatus for the Fourth of July holiday, Spring Valley's Music and Fun in the Park series will be returning in a big way on Friday, July 10.
Trustees of the Osterud-Winter Foundation recently met to approve the semi-annual distribution of proceeds from the $1 million trust established for the Spring Valley area by the late John N. Osterud, founder of Home Federal.
A Grand Meadow native and 2011 Stewartville graduate is building bridges and roads around the world as a member of the U.S. Navy's Naval Mobile Construction Battalion 1, based in Gulfport, Miss.
On Wednesday, June 29, two women, Lizzy Trickey and Haley Winkelman, from Oregon and their pet rat, Beefy, pedaled their way into Spring Valley, taking time to make a food run and explain their journey across the United States.
Believe it or not, it is July, and the Relay For Life is back this weekend. Fundraisers continue throughout the year for the Relay for Life and Liz Storlie of Greenleafton began a unique fundraiser last year, selling vegetables and other produce from her garden to support the cause.
As progress continues to be made at the state veterans cemetery, located on Highway 52 in Preston, many are wondering when it will be open and ready for the first veteran internments. Months ago, it was hoped the cemetery would open in the spring of this year, but for various reasons, it was postponed. However, the cemetery is nearing the final stretch of its construction.
"We're both authors and illustrators," said David LaRochelle, introducing himself and his "Moo!" book trunk show companion, Mike Wohnoutka, during the show's very special stop at the Spring Valley Public Library (SVPL) last Tuesday afternoon as part of the children's summer reading program, "and that means that as authors, we write the words for a book and as illustrators, we draw the pictures for a book."
It was a light agenda for the Spring Valley City Council during its June 22 meeting.
The 23rd annual Habitat 500 Bike Ride will soon be coming through the Spring Valley area as 120 cyclists and 33 volunteers begin the 500-mile journey through southern Minnesota on July 12.
The old saying, "Knee high by the Fourth of July," hasn't pertained to the stands of corn in southeast Minnesota for many years. During most of our recent growing seasons, the maxim is more like "head high by the Fourth of July."
Spring Valley resident Nevin Stender was recently presented a House of Representatives resolution from State Rep. Greg Davids.


text:
Out of Stock
© 2015 Replacements, Ltd. All rights reserved.
Quantity Available: 1
Piece Code: DEM
Piece Name: Demitasse Spoon
Size: 4 1/8 in
Our Price Each:
© 2015 Replacements, Ltd. All rights reserved
Piece Code: PLS
Piece Name: Place/Oval Soup Spoon
Size: 7 1/4 in
*This item is discounted 25% due to slight imperfections.
Piece Code: FRS
Piece Name: Fruit/Orange Spoon
Size: 5 5/8 in
*This item is discounted 50% due to noticeable imperfections.
With Our "Find This For Me" Service we notify you via email once we have stock!
Piece Code: TS
Piece Name: Teaspoon
Size: 6 in
Piece Code: CF
Piece Name: Cocktail/Seafood Fork


text:
Larry Eustachy bemoans new officiating emphasis on touch fouls
Even going back to his days at Iowa State, Larry Eustachy has won a lot of games because his teams have been physical. Basketball can be a fluid game, but it's also undoubtedly one that's rough on the muscles because of its laboring nature. Even though it's not the contact sport football or hockey are, hoops features plenty of battles of will and an innate corporal element, especially as play gets closer to the rim.
It's because the game has gotten so physical that many believe college basketball's aesthetic quality is at or near an all-time low. With fewer fouls being called, much more handchecking and play in the paint that's more aggressive/whistle-lenient than anything in the NBA, scoring averages have gone down and time of possession has gone up.
College basketball's higher-ups voted in the spring to make amendments to how blocks and charges were called, and to use monitor reviews to make the right decision. This will inevitably free up space and make the game less chaotic near the charge circle, but it's also not going to dim controversial calls, especially in the upcoming trial season.
At Mountain West's media day, Eustachy -- who won a school-record 26 games in his first season at Colorado State last year -- took to criticizing the looming foul fests that could compromise the composite talent on the court. From the Coloradoan:
"What are we thinking trying to put players in situations where they can be eliminated even more? We all witnessed it with Colton Iverson last year. It was a tragedy what the officiating did to him," Eustachy said. "If you pay to go see Celine Dion, she's not going to be fouled out at intermission. You pay to see Colton Iverson; you may only see four minutes of him. He may get two quick fouls and he has to sit the whole half."
"Louisville isn't going to have a team if we stick to this because they're going to all foul out in the first half, and I love the way they play," Eustachy said. "If you're going to call touch fouls, it'll be over in the first 10 minutes. (Rick) Pitino will have to play. It really is crazy."
Eustachy's philosophy runs in opposition to many other coaches', including John Beilein's. The Michigan coach who helped his team put on one of the best national title games of the past two decades wants more touch fouls to be called in order to nudge defenses away from the hacking, thus creating a smoother game. A smoother game equals a more appealing game, the way basketball was intended to be played, according to many.
This story is a harbinger of what's to come. College basketball will have to get uglier before it gets better. If scoring is to go up, there's going to be a learning curve with the block/charge rule. And if the critics are right, that the scoring and pace of college basketball is what's keeping it from being more nationally successful, then a change is in order, and this seems as sensible a place to start as any.