The present invention relates to an online item and product management system associated with a related transaction processing system. In particular, the present invention relates to a product management system wherein users can provide information about items and users are associated with items and categories.
The Internet has provided some amazing opportunities to connect people and provide information. However, sometimes is it difficult to obtain all of the information people need, especially where the domain of the information is quite large. For example, where the domain is products, there are a great many products that users might be interested in. Additionally, different users may be searching for different pieces of information about a product. For example, some users may want to buy or sell a product, while other user may want to value products they already have. Yet other users may simply wish to learn more about a product.
Many resources on the Internet can help solve aspects of this problem. For example, search engines can be used to find web pages with relevant content. Discussion boards, newsgroups, and blogs on the Internet can also be used to find information. However, all of these sources of information can at times be incomplete, untrustworthy, or difficult to find for one reason or another.
It would be desirable to have a centralized location where information on a variety of products could be easily found and where those products can be easily exchanged between users of this centralized community. Additionally, it would be desirable to have a mechanism to give incentives to users to not only use the community to obtain information, but also to contribute complete and accurate information to the community.
In an embodiment of the present invention, a computer system is provided that maintains information about products and provides for transactions between users buying and selling those products as well as providing a public exchange for valuing those products. The system also tracks the users who set up products in the system as well as maintain product categories. That tracking can be used for sharing revenue related to those products with the users, controlling which users become “experts” for a category of products or specific products, allowing for user-to-user interactions, etc.
One embodiment of an apparatus for tracking user contributions and distributing revenue associated with the user contributions is comprised of an item database, an item server coupled to the item database, a transaction database, and a transaction server coupled to the transaction database. The item server is capable of reading and modifying the item database, and the transaction server is capable of reading and modifying the transaction database. The item database comprises a table of associations. The table of associations associates an owner with an item record. An owner is a user that contributed to the item database by requesting the item record to be added to the item database or by perfecting an existing item record. The transaction database comprises a table of transactions that associates revenue with item records.
Another embodiment for distributing revenue associated with user contributions to a community of users begins by registering a user with a community of users. Next, the user is associated with a referral chain if the user was referred to the community of users by a referral user. A referral chain associates the user with a chain of users who have each referred each other to the community of users. Following the referral chain association, one or more pages are assigned to the user. Revenue from the community of users is then associated with one or more pages. Finally, at least a portion of the revenue associated with one or more pages is shared with the user assigned to the page and with up to N additional users in the referral chain of the user.
a is a simplified block diagram of a referral database structure which an embodiment of the present invention may use.
b is a diagram showing how one embodiment represents the data underlying revenue and payouts.
a is a diagram illustrating revenue sharing and payout flow which an embodiment of the present invention may use.
b is a diagram illustrating revenue sharing and payout flow which an embodiment of the present invention may use.
An improved product management, transaction and presentation system is described herein.
In one embodiment, computer system 200 typically includes a monitor 210, a computer 220, user output devices 230, user input devices 240, communications interface 250, and the like.
As shown in
User input devices 230 can include various possible types of devices and mechanisms for inputting information to a computer 220. These may include a keyboard, a keypad, a touch screen incorporated into the display, audio input devices such as voice recognition systems, microphones, and other types of input devices. In various embodiments, user input devices 230 are typically embodied as a computer mouse, a trackball, a track pad, a joystick, wireless remote, drawing tablet, voice command system, eye tracking system, and the like. User input devices 230 typically allow a user to select objects, icons, text and the like that appear on the monitor 210 via a command such as a click of a button or the like.
User output devices 240 can include various possible types of devices and mechanisms for outputting information from computer 220. These may include a display (e.g., monitor 210), non-visual displays such as audio output devices, etc.
Communications interface 250 provides an interface to other communication networks and devices. Communications interface 250 may serve as an interface for receiving data from and transmitting data to other systems. Embodiments of communications interface 250 typically include an Ethernet card, a modem (telephone, satellite, cable, ISDN), (asynchronous) digital subscriber line (DSL) unit, FireWire interface, USB interface, and the like. For example, communications interface 250 may be coupled to a computer network, to a FireWire bus, or the like. In other embodiments, communications interfaces 250 may be physically integrated on the motherboard of computer 220, and may be a software program, such as soft DSL, or the like.
In various embodiments, computer system 200 may also include software that enables communications over a network such as the HTTP, TCP/IP, RTP/RTSP protocols, and the like. In alternative embodiments of the present invention, other communications software and transfer protocols may also be used, for example IPX, UDP or the like.
In some embodiment, computer 220 includes one or more Xeon microprocessors from Intel as processor(s) 260. Further, one embodiment, computer 220 includes a UNIX-based operating system.
RAM 270 and disk drive 280 are examples of tangible media configured to store data such as embodiments of the present invention, including executable computer code, human readable code, or the like. Other types of tangible media include floppy disks, removable hard disks, optical storage media such as CD-ROMS, DVDs and bar codes, semiconductor memories such as flash memories, read-only-memories (ROMS), battery-backed volatile memories, networked storage devices, and the like. RAM 270 and disk drive 280 may be configured to store the basic programming and data constructs that provide the functionality of the present invention.
Software code modules and instructions that provide the functionality of the present invention may be stored in RAM 270 and disk drive 280. These software modules may be executed by processor(s) 260. RAM 270 and disk drive 280 may also provide a repository for storing data used in accordance with the present invention.
RAM 270 and disk drive 280 may include a number of memories including a main random access memory (RAM) for storage of instructions and data during program execution and a read only memory (ROM) in which fixed instructions are stored. RAM 270 and disk drive 280 may include a file storage subsystem providing persistent (non-volatile) storage for program and data files. RAM 270 and disk drive 280 may also include removable storage systems, such as removable flash memory.
Bus subsystem 290 provides a mechanism for letting the various components and subsystems of computer 220 communicate with each other as intended. Although bus subsystem 290 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple busses.
The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims. In addition, the technique and system of the present invention is suitable for use with a wide variety of methodologies for programming a device. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
Item database 304 contains a table of item records 305. Item records can further be organized into categories in the item database. Item record 306 represents one item record or one page from item records 305. Each item record in item database 304 is associated with a SKU (Stock Keeping Unit) number. As used herein, the “term item record” and “SKU” are interchangeable. The term “SKU” may also be used for the item the SKU refers to. Often times, the item the SKU refers to is presented to the user, along with other information, in the form of a web page or other similar presentation means. The term “page” is often used in place of the term “SKU” from an end-user's perspective, and the terms have the same definition as used herein.
At a high level, each SKU within item database 304 is homesteaded by a user of the invention. When a SKU is homesteaded by a user, the SKU is claimed by the user, and an ownership interest in the SKU is given to the user. As used herein, the terms homesteaded, claimed, owned, or variants thereof all refer to this concept. A SKU owned by the user can be referred to as a homesteaded item. When a user homesteads a SKU, the user gains the potential for earning revenue off of that SKU. There are many different ways that a user can gain an ownership interest in a SKU. There are also many different ways that a SKU can generate revenue. Additionally, the means used to determine the how revenue is shared between users with an interest in a SKU can vary between embodiments. All of these variations are discussed in more detail below.
Another method for a user to acquire an financial interest is to become a category expert. A category expert is much like a securities analyst in the stock market or a subject matter expert in the technology world. The category experts may write reports on the categories they cover to provide analysis and guidance to help users make informed decisions whether to buy, sell, or hold some specific items. The report may contain a product review, valuation opinion, and/or answers to questions posted by users. A portion of the category revenue may be allocated to the experts for sharing knowledge, driving traffic, and/or raising the performance of a category that satisfies the needs of the community.
Other users who don't own a particular SKU can add it to their user profiles in item database 304. Although these users don't own the item record in the item record database, they may physically own the item at their home, workplace, etc. By adding items to user profiles, the user can use item server 303 as an online inventory system or an asset management tool for organizing and recording details of personal belongings and tracking the associated monetary value. It can also be a marketplace for buying and selling goods, thereby creating liquidity for non-financial assets, for example, watches and cell phones.
The process begins when users, represented by people 410, register with the community. This registration process can take place using a client workstation 301 connected to a registration server or the process can take place using any other suitable means.
At step 440, the user registration process determines whether the user is registering using a standard single-user registration 442 or through a referral program 441. Single-user registration 442 is one means through which a user can join the community. During this process, the user discloses some basic information about themselves, such as contact information, along with other pieces of information. Once the single-user registration is complete, the newly created user is ready to participate in the community.
Another means for joining the community is through the referral program 442. When a new user joins the community as a result of a referral made by an existing user of the community, a referral chain between the users is created. In one embodiment, when the new user becomes a homesteader and the associated homesteaded item generates revenue, not only does the homesteader receive a portion of the revenue generated, but the existing user who referred the homesteader into the community receives a portion of the revenue generated from the new user's homesteaded item. A referral chain can be used to define this relationship between users. Users who qualify for financial incentive through the referral chain are called “stakeholders”. As used herein, a stakeholder can also be called a referrer or a sponsor. The new user who was referred into the system can also be called a referred user, a recruited user or recruit, or a sponsored user.
After the user registration 440 is complete, the user becomes a registered user 420. As a registered user 420, the user can now participate in the community by acquiring SKUs, becoming a category expert, conducting transactions in the community, or participating in the community in other ways.
A user can acquire a SKU ownership interest, and thus a financial interest, in a SKU in a variety of ways. One such way is for a user to add an item that is not currently listed in item database 304. This is shown as SKU submission 451. Another way is for a user to correct, improve, enhance or otherwise perfect an existing item, thereby laying claim to it. This is shown as SKU perfection 452. Other ways for a user to obtain a SKU ownership interest can also be implemented in step 450. For example, in some embodiments a user can acquire a SKU ownership interest by trading for the interest from another user.
SKU submission 451 may begin by the user entering a series of required product attributes into a form. The user may also be required to submit a picture of the item referred to by the SKU. Once the user has finished entering these attributes, item server 303 may attempt to locate an existing SKU with similar attributes, to see if the submitting SKU might already exist. If it finds some potential matches, the matches can be presented to the user and the user can be prompted to verify that the SKU should still be submitted. If the user indicates that the SKU should still be submitted, or if the system finds no matches, then the item server may display a page preview and/or confirmation page.
Another way in which a user can claim ownership of a SKU is by “perfecting” an existing SKU in item database 304. This step is shown at step 452. At any given time there can be a number of existing SKUs within item database 304 with incomplete or missing information, and these SKUs can be marked as requiring “perfecting”. For this purpose, item database 304 tracks which items are candidates for perfection. A user can search through the catalog looking for SKUs requiring perfecting. The user may then supply the missing or incorrect information.
In one embodiment, after the user confirms the information entered during the SKU submission 451 or SKU perfection 452 process, the SKU may be placed into a “pending” table for review and approval/rejection. This pending table may be periodically reviewed by a category expert, catalog administrator, other reviewing entity who can review that submission and either approve or reject it. This step is shown at step 460. If approved, the user can be notified, and at that point the user will officially own the SKU and can start deriving future revenue from it. It is at this point the user becomes a homesteader for that particular item. If the submission is rejected, then the user may or may not receive an opportunity to resubmit the SKU depending on the quality of the initial submission.
Once a user becomes a SKU Owner 430, that SKU and its revenue generating activity (including, but not limited to, transactional and advertising revenue) can be closely tracked and associated with that user in order to provide accurate accounting and revenue payout. In one embodiment, the relationship between a SKU Owner and a SKU can be stored in the Item Database 304 in a table of associations.
In some embodiments, once a user becomes a SKU Owner 430, the user can sell, trade, or otherwise transfer their ownership interest in the SKU to another user. The ownership interest can thus become a tradable commodity in the community that can be valued based at least in part on the current or future revenue that the SKU is able to generate for the owner of the SKU. Some embodiments may even setup a marketplace or exchange to facilitate transactions involving the SKU ownership interests.
A user can be a homesteader, a stakeholder, and a category expert all at the same time, and as a result, there are many different incentives given to a user to become an active, productive, participating member of the community.
Block 610 represents the SKU itself. Each SKU entry contains a list of attributes that describe the SKU in detail. For example, information about the manufacturer, model number or name, color, price, etc., of the SKU may be stored.
Additionally, each SKU entry contains information that links the SKU to a variety of other pieces of information. For example, the SKU can contain a reference linking the SKU to the SKUOwner 620. Advertising 630 and transaction 640 tables can also link to the SKU so that revenue generated by this SKU can be uniquely tracked. SKUs may also belong to a category 650 and these categories may be subordinate to one or more “parent” categories as well. This category information can be stored in a category table. The category table may be stored in the item database 304 or in another database. The branch within the category tree which a SKU belongs to may determine the specific attributes that are required for that SKU. The category may also have one or more category experts associated with the category.
At step 720 the transaction server 307 may send an introductory e-mail inviting these referrals to join as registered members of transaction server 307. In other embodiments, other components of the system may send the invitation email.
At step 730, the referred user receives the invitation. This invitation will often introduce the referred user to the community, explain some of the benefits of joining the community, and also contain a reference to the registered user who referred the referred user to the community.
The referred user can complete a registration form at step 740. To qualify for financial incentive, the referred user may need to provide their social security number, mailing address, date of birth, and an active credit card and/or bank account for identification purpose. The referrer may be responsible for ensuring his immediate downline referrals provide such information to qualify for financial incentive. Otherwise, the referrer himself/herself may be disqualified from receiving a payout too. If such requisite information is not provided, payment due to a delinquent stakeholder or homesteader for that particular payment cycle may be skipped and moved upline to the next qualifying referrer.
As an example, assume that A refers B, B refers C, and C refers D, and all of them have provided the requisite information except D. In this case, if there is a payout due to D, only B and A will receive his or her portion of the income. C is disqualified from receiving an income for failing to ensure that D provide the requisite information. If a referral becomes a homesteader, transaction server 307 may assign an identifier, identifying this registered member as a homesteader who may be eligible for a share of the transaction and advertisement revenues. Eligibility may depend on whether the homesteader provides the requisite information to qualify for financial incentive. In summary, transaction server 307 can verify the following information before a cash disbursement is made payable to a registered member.
Once the referred user complete the registration form and is sent to the system, some embodiments may send a follow-up confirmation email as shown in step 750. This email is often used to validate the new user before they join the community.
After a prospective new user confirms his registration in step 750, the relationship between the newly registered member and the user who referred the new member can be established. This is shown in step 760. The transaction database 308 may assign an identifier to the referrer, identifying him/her as a stakeholder for the immediate and subsequent referral relationships. Likewise, transaction server 307 may assign a unique identifier to each referred registered member, identifying and associating him/her to a particular referral level or layer within the tiered compensation scheme.
In one embodiment, the financial relationship between users terminates once a user is more than three layers removed from another user in the referral chain. For example, if A is the first referrer and his referral chain consists of A>B>C>D>E>F>G, A will have no financial relationship with E, F and G because the chain ends at the 3rd downline layer.
If there is a limit on how deep a referral chain for a particular user can reach, the referral model may need to be updated accordingly at step 760. For example, if the referral limit is 3 levels deep and the referral structure grows beyond that limit, the top level referrers may be eliminated progressively 1 level at a time so that at all times, the referral structure will consistently not have more than 3 levels of referral memberships. By the same token, a referred registered member can also be a referrer.
Once the referral model is updated, the updated relationships between users can be stored in a referral model for future use.
The referral model, which stores referral tree that maps referrers to referees, can be generated and maintained by transaction server 307. Some assumptions regarding the structure and functionality of the referral tree may exist in various embodiments of the system. For example, it may be assumed that no circular referral relationship exists between sponsor and recruit, and that a recruit has one and only one direct sponsor. In other embodiments, a user could have more than one sponsor, including a direct one and indirect ones. Other possible assumptions are: users map to nodes in one tree wherein the root node is assigned to the system operator, users' IDs on the tree are positive integers with a root id equal to 0, and updates on tree happens in real time and concurrently.
In the example referral tree shown in
The performance is determined by parameter N and SQL execution speed. For the speed of SQL statements, all operations listed above depend on database performance for statements with condition LIKE ‘<prefix>%’ where <prefix>does not contain ‘%’. Most relational databases can execute this kind of SQL statement efficiently with an index built on that field. If the database is a MySQL database, it can run fast with low cost. It is possible to return a query in 1,000,000 record table in only 2 ms. Pseudocode representing processes that a computer system might execute to implement the methods described herein are listed in Appendix A. An analysis conclusion for how many SQL executions are needed in the operations follows below.
Using a data structure such as the one presented in this example embodiment, various operations on the referral tree require a different number of SQL executions to be run against the database.
For example, some operations, including adding a single user or finding the sibling of a user, only need 1 or 2 SQL executions to complete the operation no matter what the size of N is.
Other operations, including deleting a user without deleting the user's recruits and adding a referral sub-tree to the referral tree, require approximately N SQL executions to complete the operation.
Still other operations, including querying or counting the sponsors of a user, determining if two nodes have a referrer/referee relationship, determining the distance between two nodes, or determining the distance from the top node to a lower node in the referral tree, require N SQL executions. Normally, if the number of queried levels is less than N, the operation can be done with a single SQL statement. Even if the number of queried levels is greater than N, fewer than N SQL statements can be used if the example data structure is leveraged properly.
For some other operations, including querying or counting the recruits of a user, the number of queries required depends on shape of tree. Normally, if N is greater than the queried levels, the number of SQL executions required will be less than N.
The most expensive operations are typically deleting a single user with his recruits and initializing/reinitializing the entire tree. However, these operations are rarely needed in practice and can often be executed at times when the system does not have a high load.
a is a diagram illustrating a revenue sharing engine and payout system design structure that an embodiment may use. Revenue in the illustration typically comes from one of two sources: buying/selling transactions between users involving a SKU, highlighted by 1010, and advertising revenue received from third-party accounts, highlighted by 1020. This revenue can be collected in a central location, such as a revenue account 1030. The revenue sharing engine, which can be a part of the revenue account 1030, can then analyze the collected revenue and distribute payouts to sponsors 1040 and 1050 or SKU owners 1060. The logic used by the revenue sharing engine to distribute the money can use the relationships described above according to the methods disclosed below.
b shows how one embodiment might represent the data underlying revenue 1070 as it enters the system and the corresponding payout 1080 as the revenue is distributed to users.
Assumptions regarding the revenue sharing and payout flow may exist and can be reflected in the data structure. Such assumption can include, but are not limited to, assumptions about where the fee comes from and how the fee is identified. For example, revenue might accrue from fees collected from buyers for a transaction, fees collected from sellers for a transaction, or fees paid by advertisers. Some source information might be used to match revenue to particular SKUs. For example, when payment occurs via an online payment system, such as “PayPal”, the payment may include a payer identifier and a transaction identifier. The transaction identifier may directly specify a SKU, and if so, this information can be used to help allocate the revenue to the proper parties. If the SKU cannot be directly identified, then other heuristics might be used to properly handle the revenue.
Initially at step 1130, revenue is entered into a revenue sharing and payout system. In one embodiment, the transaction server 307 can be the device receiving this revenue information. The information entered into the system will generally include data such as the value of the revenue received, SKU identifiers, and other relevant information. Revenue associated with a transaction 1110 will generally have a SKU identified from data in the transaction. Typically the SKU is the item of transaction. Revenue from an advertisement 1120 can be divided to each related SKU according to clicks received from that SKU over some period of time. Other mechanisms can also be used to associate SKU's with received revenue. The revenue's status will generally be set to ‘New’ when it is entered into the system.
Revenue calculations can be done in daily batches, weekly, or monthly, i.e. the revenue-sharing engine is triggered to start its calculation daily, weekly, or monthly. This is shown at step 1140. As a result of the batching process, there might be some time delay between the time when a transaction happens and the money associated with the transaction goes into the user's account. One skilled in the art will recognize that other mechanisms can determine the timing of revenue payouts.
Once a revenue calculation is triggered, the first step of the calculation generally identifies the SKU owner and the owner's N-level sponsors for a given piece of revenue. This is shown at step 1150. As described earlier, the relationships between a SKU owner and any sponsors can be determined from a referral tree that is stored in the referral model 1155.
Once the SKU owner and the owner's sponsors have been identified, an appropriate payout policy 1165 is selected at step 1160. Payout policies determine what percentage of the revenue a user can receive based on the user's relationship to the SKU and the SKU owner. Payout policies can also determine if an otherwise eligible user is to be excluded from receiving a payout. Example payout policies are disclosed in more detail below.
After the payout policy has been selected, the revenue each identified SKU owner and sponsor is entitled to receive is calculated at step 1170. After the calculation, the status of revenue can change to ‘calculated’.
In one embodiment, the revenue is then divided to users in the form of payout record whose status is marked as ‘ready’ according to the payout policy. Finally, the payout can be added to user's balance, and payout status can be changed to ‘balanced’. These actions are shown at step 1180.
The percentages listed in 1220 would also apply in a similar fashion to other users represented in the pyramid based on the relationship between users. For example, assume that A refers B1, B1 refers C1, C1 refers D1, and D1 refers E1 in a linear referral chain. If D1 is a homesteader for an item and this item is traded through transaction server 307 resulting in a transaction fee of $20 and an advertisement revenue of $80, D1 will be entitled to 5% ($5), C1 4% ($4), B1 2% ($2), and A 1% ($1) of the gross homesteading receipts of $100.
Assume in another referral chain A refers B2, B2 refers C3, C3 refers D4, and D4 refers E5. Suppose A, B2, D4, and E5 are homesteaders, but not C3, and all their items are traded through transaction server 307 resulting in the gross homesteading receipts shown in
In addition to the income earned by each user in this referral chain for their homesteading activities,
Aside from the percentage of revenue a given user is entitled to receive based on the user's relationship to SKUs and other users, a payout policy may go through the following steps to implement one example payout policy:
1) Is the registered member a homesteader?
2) If yes, is there transaction and/or advertisement revenue associated with the homesteaded items. If not, no payout occurs.
3) If yes, has the homesteader provided the requisite information? If not, no payout occurs.
4) If yes, allocate a percentage of the gross homesteading receipts to him or her.
5) Does the homesteader have upline stakeholder(s)? If no, no further payout.
6) If yes, has the stakeholder provided the requisite information? If no, no payout and disqualify the immediate upline stakeholder from receiving a payout too. Move to the next upline stakeholder and ask if he or she has provided the requisite information.
7) If yes, allocate the appropriate percentage payout to the upline stakeholder and move up to the next level stakeholder and ask if he or she has provided the requisite information.
8) Lastly, verify if the referral structure has more than 3 levels of referral. If no, confirm payout. If yes, trigger a red flag for administrator to check payment process.
Alternative payout policies may look at additional factors when determining if a user is entitled to a percentage of revenue generated. For example, category experts may receive a percentage of revenue generated from any SKUs for which they are an expert.
The Calculation table 1350 describes a process with information including payout policy used, status which is one of ‘started’, ‘proceeding’ or ‘finished’ and start/finish timestamp. These status are displayed by state diagram 1360.
The Revenue 1370 and Revenue_Status 1380 tables are used to record revenue information and status which is one of ‘new’ or ‘calculated’ as described above. The Payout 1392 and Payout_Status 1391 tables are used to record payout information and status which is one of ‘ready’ or ‘balanced’ as described above. These states are depicted in state diagram 1390.
Payouts can be linked to the member table 1393 that stores additional information about users.
Further embodiments can be envisioned to one of ordinary skill in the art after reading this disclosure. In other embodiments, combinations or sub-combinations of the above disclosed invention can be advantageously made. The example arrangements of components are shown for purposes of illustration and it should be understood that combinations, additions, re-arrangements, and the like are contemplated in alternative embodiments of the present invention. Thus, while the invention has been described with respect to exemplary embodiments, one skilled in the art will recognize that numerous modifications are possible.
For example, the processes described herein may be implemented using hardware components, software components, and/or any combination thereof. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims and that the invention is intended to cover all modifications and equivalents within the scope of the following claims.
This application claims priority to U.S. Provisional Application No. 60/954,716 entitled “Client-Server System For Managing an Item Database and Item Transactions with User-Item Associations” filed on Aug. 8, 2007, which is hereby incorporated in its entirety.
Number | Date | Country | |
---|---|---|---|
60954716 | Aug 2007 | US |