Patent Application
20050004865
The present invention relates generally to computer data and information systems, and more particularly to the control and monetization of networking transactions based on relational patterns between users.
The development of technology and the explosion of users connected to the Internet has permanently changed the way people communicate with each other. Networking databases can provide a user access to direct contacts to those family, friends and acquaintances the user has successfully added. A direct contact may be described as a contact separated from the user by one degree of freedom. Today it is possible to imagine a scenario where that user can access not just direct contacts, but contacts of direct contacts, i.e., other Internet users who are separated by more than one degree of freedom.
Tools exist for establishing relational or contact paths enabling a user to connect to other parties separated by more than one degree of freedom. In certain cases, these teachings provide the user a specific indication of the relational path that connects the user to the party. Some of these tools have even provided unsophisticated techniques for monetizing transactions between users.
Existing technology fails to fully take advantage of the wealth of information available or potentially available through a properly populated and managed networking database. For example, in prior art schemes where relational connections are established between users, all relational connections are treated equally without reference to the degree of separation and other characteristics of the relational pattern. Likewise, there is no teaching for monetizing transactions between two users as a function of their degree of separation. What are needed are networking techniques and systems which fully utilize the relational data to implement sophisticated monetization and control strategies.
The accompanying figures illustrate embodiments of the claimed invention. In the figures:
Any headings used herein are for convenience only and do not affect the scope or meaning of the claimed invention.
The present invention teaches a variety of techniques and mechanisms for controlling and monetizing networking transactions among users of a computer network. At least some of these techniques and mechanisms come about as a result of several new paradigms contemplated by the present invention. One paradigm of the present invention involves monetizing user transactions as a function of relational patterns and connections between different users. Another paradigm of the present invention introduces a “virtual network” as a set of user having some predefined relational pattern. Once virtual networks are defined for a plurality of users, decisions regarding transactions can then be made based on the characteristics of the virtual network.
The present invention teaches a variety of techniques and mechanisms for controlling and monetizing networking transactions among users of a computer network. At least some of these techniques and mechanisms come about as a result of several new paradigms contemplated by the present invention. One paradigm of the present invention involves monetizing user transactions as a function of relational patterns and connections between different users. Another paradigm of the present invention introduces a “virtual network” as a set of user having some predefined relational pattern. Once virtual networks are defined for a plurality of users, decisions regarding transactions can then be made based on the characteristics of the virtual network.
The present invention defines a “networking transaction” broadly as any interaction which a unique computer user might contemplate performing. Thus networking transactions include communications of all types with other computer users, joining a networking database, inviting others to join a networking database, adding other users or parties to a users set of friends or contacts database, forming relational connections with other users, joining a community of other computer users having some common characteristic, creating a community open to other computer users having some common characteristic, inviting other users into a community, etc.
The computer network contemplated by the present invention can be a closed network, a wide area network, a local area network, a World Wide Web such as the Internet, etc. The present invention also teaches the use of networking databases populated with users and supporting viral growth. Such networking database are well suited for providing a structure wherein the control and monetization techniques of the present invention are implemented. However, the control and monetization techniques of the present invention can be accomplished with direct use of a networking database, as will be described below.
With further reference to
Turning to
Referring to
Those skilled in the art will readily understand how certain relational connections can be viewed as a degree of separation between two users. By way of example, users 4 and 5 have two degrees of separation as they are connected by two relational connections 202 through user 1. In preferred embodiments, the relational path used to connect two users will be selected as the relational path with the least degrees of separation. Those users that have no connecting relational path have an undefined degree of separation.
In certain embodiments, the relational connections 202 are direct one degree of freedom relational connections between two users. However, those skilled in the art will appreciate that the relational connections 202 can take a variety of suitable forms. It is contemplated that a relational connection may correspond to a one way communication channel. For example, a first user may grant email access to all users in the networking database, however the first user could only send an email to those users that have granted the first user this right, either directly or indirectly through a series of suitable relational connections 202. Furthermore, the present invention contemplates supporting different types of relational connections within the same networking database 100.
With further reference to
The virtual networks A, B, and C shown in
In an initial step 301, any necessary initialization and set up procedures are performed. The initialization process may involve instantiating a database manager process upon a database server. The initialization process may involve creating and initializing a template for a networking database, or invoking for use a pre-existing networking database. As will be appreciated, the networking database may be a distributed database, and the initial step would then involve establishing any necessary communications links between the distributed portions of the database.
In a step 302, a networking database is populated with a plurality of users. Populating the networking database with users may involve porting in a pre-existing database of users and inserting such data into the database template, updating the pre-existing database, inviting parties to join the networking database and then including received data as desired, responding to a party's request to be added to the networking database, creating a networking database from scratch, etc. Each user provides or is assigned a unique identifier, and a minimum amount of profile data is required. One suitable method 302′ for adding a party to the networking database in response to a user request is described below in more detail with respect to
A step 304 defines relational patterns among the users populating the networking database. Step 304 may include generating a connection table such as connection data structure 104 illustrated in
Step 304 may acquire the data necessary to define and generate the relational patterns through any suitable mechansim or technique. For example, step 304 may mine through existing data found in sources such as contact databases, history of previous email traffic, etc. Step 304 may also include users entering email address information for contacts they have a relationship with.
A next step 306 defines one or more virtual networks from the plurality of users populating the networking database. This step 306 is optional, and may be performed initially through examination of each user populating the networking database, or may be performed on a case by case basis as required to execute a transaction.
A step 308 defines a set of transaction rules for performing transactions. The present invention contemplates making a wide variety of transactions available to users in the networking database. These transactions include email, instant messaging, calendaring, data sharing, searching, auctioning, psychological profiling, dating services, community services. The set of transaction rules may include pre-existing rules taken from an outside source or invoked at initiation, or the transaction rules may be determined on the fly, and may depend upon the character of the networking database as populated. In certain embodiments, the transaction rules define how to monetize any transaction, and how to respond to requests originating from parties not found in the networking database, or transactions directed outside of the networking database.
A step 310 receives a transaction request. The received transaction request may originate from a user found in the networking database, or in certain embodiments a non-member party. The present invention also contemplates absolutely closed networking databases that do not accept transaction requests whatsoever from outside the networking database.
A next step 312 processes the transaction request in a manner consistent with the transaction rules and the relational patterns of the networking database. Processing a transaction request may include determining whether the requested transaction is allowed and under what circumstances, determining the presence of required circumstances such as an existing relational connection which supports the requested transaction, requiring successful monetization prior to execution or initiation of such transaction, and/or attempting to change the circumstances in order to effectuate the transaction. One possible set of rules is illustrated below within the description of method 400 of
A step 314 performs any necessary record keeping resulting from the transaction request such as updating the networking database and virtual networks, as well as notifiying a database manager of certain events.
The method 300 of FIG.8 is a suitable and generic approach to implement certain aspects of the present invention. However, those skilled in the art will readily be able to adapt the principles set forth in method 300 to more narrow applications as well as to broader embodiments.
Allowing database users to add parties to their set of friends enables viral growth of the networking database. This viral growth in turn improves opportunity for transactions, and creates more opportunities for monetization of such transactions. Of course, certain embodiments of the present invention which require stricter control and privacy within the networking database will not enable or will strictly limit viral growth.
The method 302′, as with any method for allowing a user to add members to the networking database, may result from the network database managing process proactively inviting the user to add to the networking database, say for example during an initial population phase of the networking database, or when the user has recently joined the networking database. The method 302′ may be prompted by a determination that a requested transaction is not available until certain relational connections are established. Of course, the user may initiate a method 302′ during the course of updating user contacts. Those skilled in the art will recognize that these are only a few of the ways and reasons a user may attempt to add a party to their set of friends.
Turning directly to the method 302′ of
When step 354 determines that the party either denies permission or is not entitled to become a member of the user's set of friends, a step 368 rejects the user's request. The rejection of step 368 often includes providing some type of feedback to the requesting user regarding the failure. In certain embodiments, step 368 includes a determination of whether the requesting user can accomplish the request by taking some other action such as adding another party to the database, and then prompting the user to take such action first and then resubmit the request. For example, the party may only grant permission if the user has a relational connection to another user found in the party's set of friends. In this case, the user may be prompted to add another user with such a connection thereby enabling addition of the desired party.
When step 354 determines that the party grants permission and is entitled, a step 356 monetizes the transaction. Monetization may include charging the requesting user for adding the party to the user's set of friends, or determining if the requesting user has a subscription level allowing the transaction (e.g., nonpaying users cannot add, paying users can). The present invention contemplates embodiments that involve sharing the benefit of the monetization with the added party, and/or allowing the added party to set the cost of the transaction. Alternatively, monetization may include giving credit to the requesting user, or may simply determine that the cost to the user and the party is nothing (i.e., free!).
When monetization step 356 fails, a step 368 rejects the user's request. When monetization failure causes the rejection, step 368 often includes providing feedback regarding the nature of failure. In certain embodiments, step 368 includes a determination of whether the requesting user can accomplish the request by taking some other action such as updating credit card information or providing another valid form of payment, taking an action which results in credit being added to the user's account, etc. Step 368 may prompt the user to attend to these and resubmit the request to add the party to the user's set of friends.
When monetization step 356 succeeds, a step 358 adds the party to the user's set of friends by taking an action such as updating the connections data structure. Then a step 360 provides feedback to the requesting user regarding the success of the transaction.
Turning back to an earlier part of the flow chart not yet covered, when step 352 determines that the party is not a member of the networking database, a step 362 determines whether the party can be added to the networking database. Step 362 can be based on a variety of factors such as the identity of the party (known spammer?), whether a suitable connection can be made with the party, etc.
When step 362 determines that the party is not allowed in the database, a step 368 rejects the user's request, typically providing feedback in the process. When step 362 determines that the party is eligible to join the networking database, a step 364 invites the party to join the networking database. The process of joining typically involves obtaining data such as that necessary to populate the networking database with the party, assigning a unique user identity, monetizing the transaction as desired, etc. When the party successfully joins the networking database, control passes to monetization step 356, and on to steps 358 and 360 as described above. When the party does not join the networking database, control passes to step 368 that rejects the user's request and provides feedback to the user as desired.
A step 402 receives a transaction request from a specific user. The present invention contemplates a wide variety of available transactions such as email, instant messaging, video conferencing, database searching, modifying the database, dating services, job finding services, people finding services, contact lookup, etc. A step 404 determines the nature of the requested transaction. A step 406 determines whether the transaction is feasible based on a set of predefined rules. For example, the first user may request communication with a second user, in which case it must first be determined whether there is a relational connection between the first and second user sufficient to support the requested communication. Perhaps the transaction request corresponds to a search on a particular type of user profile data, and step 406 must determine whether the first user has access to such data.
In certain embodiments, when step 406 determines the requested transaction is not feasible, the method 400 proceeds to a step 418 that performs any necessary updates to the database. For example, it may be useful in certain contexts to monitor failed transactions. Then a step 420 responds to the specific user indicating that the requested transaction failed, and if desired, the response can indicate the nature of the failure.
In other embodiments, when step 406 determines that the requested transaction is not feasible, the method 400 may continue in step 406 to attempt to change the situation so that the transaction is feasible. For example, email may only be permitted among users that are members of the same virtual network. Thus a request for communication to a user outside of the specific user's network is not immediately feasible, but would be feasible should the specific user add a relational connection that includes the outside user into the same virtual network. Step 406 may prompt the specific user to take action to accomplish this, and then hold the transaction request for a period of time if during which the user succeeds in adding the outside user to the specific user's virtual network, the transaction becomes feasible and the method 400 continues rather than terminating the transaction request.
In any event, when step 406 determines that the transaction is feasible, a step 408 then determines whether the transaction is free. When the transaction is free, control passes to a step 416 which initiates the requested transaction, then a step 418 performs any necessary database updates, and then step 420 provides a response to the specific user regarding the successful initiation of the transaction. The present invention contemplates that the user may be compensated for successfully initiating certain types of transactions. For example, the specific user may be compensated for transactions resulting in another paying user joining the networking database, and/or transactions such as completing surveys, or joining another networking database, or joining a given virtual network. This compensation may take a variety of forms such as direct payment, credit for future transactions within the networking database, credit toward the purchase of goods sold by the operator of the networking database, airline miles, etc.
When step 408 determines that the transaction is not free, a step 410 determines whether the specific user is eligible to have the requested transaction completed based on a subscription level or some other characteristic of the specific user. An example rule might instruct us that email communication between users having one degree of separation is free and becomes progressively more expensive as the degree of separation between users increases. When step 410 determines that the specific user is eligible, process control passes along to step 416 that initiates execution of the requested transaction and proceeds as described above.
When step 410 determines that payment is required, a step 412 requests payment from the specific user. It will be appreciated that payment can be accomplished through a variety of mechanisms. For example, the specific user may have an account with the networking database, and step 412 debits the transaction cost from that account if funds are available. The specific user's account may have both a cash reserve, credit from past monetize transactions, or both. Certain transactions may be payable only from a cash reserve, while others may be payable from cash reserve or credit. As another example, the specific user may have a credit card on file that is automatically debited or the user may be prompted to select a credit card to pay the transactions cost.
A step 414 determines whether the transaction cost was successfully paid, and if so control passes to transaction execution step 416 and proceeds as described above with reference to initiating and executing the transaction, else the transaction request is rejected and the method 400 proceeds as described above with reference to failure.
A first step 502 receives a request from a first user to perform a transaction that is dependent upon a second user. The requested transaction can be any of a variety of suitable transactions such as communication (email, etc.) with the second user, a search upon data related to the second user, etc. A next step 504 determines a relational connection between the first and second users. Step 504 contemplates both real time determination and retrieval of the relational connection information from a networking or other type of database.
After the relational connection is determined in step 504, a step 506 determines a cost of executing the transaction, the execution cost being a function of the relational connection. The method 500 does not limit how this cost is determined except that it must in some way be related to the relational connection between the two users. For example, it may that transactions between users having a one degree of separation relational connection are free. The transaction cost may increase as a function o the degrees of freedom of the relational connection. Or perhaps all email transactions are free between users that have a relational connection, but video conferencing transactions and searches are monetized as a function of the relational connection between the two users.
In any event, once the cost has been determined, the method 500 continues as a step 508 performs initiation or execution of the transaction if and when the costs are met. As described above, the cost may be met in a variety of ways, and the benefit may be shared with the second user. Certain transaction may result in benefit flowing to the first user, which benefit may take on any suitable form.
The description herein of illustrated embodiments of the invention is not intended to be exhaustive or to limit the invention to the precise form disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.
Access to the different forms of databases and virtual networks can be controlled by any means. For example, access to a virtual network may be controlled such that only members of the virtual network may search on certain profile data associated with members of the virtual network. Alternatively, access to a virtual network may be controlled so that non-members may search or view certain profile data associated with members of the virtual network, but non-members are not allowed to engage in transactions with the members of the virtual network.
Regardless of any serial execution of the flow chart steps implied by their visual placement, those skilled in the art will recognize when such steps may be performed in parallel or in a different order, sometimes without effecting the outcome and other times in order to implement a different but related embodiment.
All of the references and U.S. patents and applications referenced herein are incorporated herein by reference. Aspects of the invention can be modified, if necessary, to employ the systems, functions and concepts of the various patents and applications described herein to provide yet further embodiments of the invention.
These and other changes can be made to the invention in light of the detailed description herein. In general, in the following claims, the terms used should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims. Accordingly, the invention is not limited by the disclosure, but instead the scope of the invention is to be determined entirely by the claims.
While certain aspects of the invention are presented below in certain claim forms, the inventors contemplate the various aspects of the invention in any number of claim forms. Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the invention.
This application claims the benefit under 35 U.S.C. sec. 119(e) of Chudnovky's U.S. Provisional Patent Application No. ______, filed Jul. 1, 2003, which application is incorporated herein by reference.
| Number | Date | Country | |
|---|---|---|---|
| 60484040 | Jul 2003 | US |
