Method and apparatus for facilitating peer-to-peer electronic commerce

One embodiment of the present invention provides a system for determining a list of providers of a commodity. During operation, the system receives a description of the commodity from a customer at a server. Then, the system uses the description to identify a list of providers of the commodity. Next, the system receives a specification of a set of desired provider-traits from the customer. The system then filters the list of providers of the commodity based on the desired provider-traits to obtain a filtered list of providers of the commodity. Finally, the system presents the filtered list of providers to the customer.

BACKGROUND

Related Art

The increasing popularity of the Internet has led to an increase in the number of users conducting commerce online. In response to this increase in electronic commerce, organizations have created a number of web-sites that provide a centralized “marketplace” for peer-to-peer electronic commerce.

Although convenient, peer-to-peer commerce web-sites rely significantly on users trusting one another. For example, a customer who purchases a commodity trusts that the provider of the commodity will send the commodity after receiving the customer's payment. Some peer-to-peer commerce web-sites employ strategies to reduce the level of trust required by customers who use these “safer” web-sites. However, to offset the costs involved in implementing these strategies, the “safer” web-sites typically charge commodity providers a fee for listing and selling commodities. Often, these fees discourage commodity providers from listing their commodities on the “safer” web-sites. Consequently, a customer who wants to use a peer-to-peer commerce web-site typically has to choose between obtaining a commodity from commodity providers who use “less-safe” free web-sites, or obtaining a commodity from a smaller number of commodity providers who use “safer” web-sites to sell commodities.

SUMMARY

One embodiment of the present invention provides a system for determining a list of providers of a commodity. During operation, the system receives a description of the commodity from a customer at a server. Then, the system uses the description to identify a list of providers of the commodity. Next, the system receives a specification of a set of desired provider-traits from the customer. The system then filters the list of providers of the commodity based on the desired provider-traits to obtain a filtered list of providers of the commodity. Finally, the system presents the filtered list of providers to the customer.

In a variation on this embodiment, the commodity can include a physical item, a piece of software, or a service.

In a variation on this embodiment, the provider-traits for a given provider can include: a group affiliation of the given provider; a hobby of the given provider; a degree of association with the customer; and a number of prior interactions with the customer.

In a variation on this embodiment, the desired provider-traits can include: required provider-traits, which the customer requires of a provider of the commodity; and preferred provider-traits, which the customer desires of the provider of the commodity, but does not require.

In a further variation, filtering the list of providers involves adding each provider who has the required provider-traits to the filtered list of providers. The system then sorts the filtered list of providers based on the preferred provider-traits associated with each provider.

In a variation on this embodiment, the system receives a set of customer-traits associated with the customer from the customer at the server.

In a further variation, filtering the list of providers of the commodity involves determining the set of customer-traits associated with the customer. Then, for each provider, the system determines a set of desired customer-traits, which the provider desires for customers who purchase the commodity. Next, the system determines if the set of desired customer-traits matches the set of customer-traits. If not, the system removes the provider from the list of providers of the commodity.

One embodiment of the present invention provides a system for selecting a customer of a commodity. During operation, the system receives at a server a set of preferred customer-traits from a provider of a commodity, wherein the set of preferred customer-traits are traits the provider desires of the customer of the commodity, but does not require. Then, the system retrieves customer-traits for potential customers of the commodity. Next, the system ranks the potential customers by comparing the customer-traits with the set of preferred customer-traits to obtain a ranked list of potential customers. Finally, the system presents the ranked list to the provider.

In a variation on this embodiment, the system selects a customer of the commodity from the ranked list based on the customer-traits and the set of preferred customer-traits.

DETAILED DESCRIPTION

The data structures and code described in this detailed description are typically stored on a computer-readable storage medium, which may be any device or medium that can store code and/or data for use by a computer system. This includes, but is not limited to, volatile memory, non-volatile memory, magnetic and optical storage devices such as disk drives, magnetic tape, CDs (compact discs), DVDs (digital versatile discs or digital video discs), or other media capable of storing computer readable media now known or later developed.

Overview

One embodiment of the present invention provides a peer-to-peer electronic commerce server that enables users to enter personal traits. For example, customers can enter personal traits that they require and/or prefer of a provider of a commodity. Similarly, providers can enter personal traits that they require and/or prefer of a customer. Note that personal traits can include any information that can be associated with a user. For example, personal traits can include: a location of the user, which can be a general location such as a county, or a very specific location, such as a neighborhood; a group affiliation; a hobby; and any other personal trait that can distinguish a user from a second user, or associate a user with a second user. Group affiliations can include any private or public group, such as users belonging to a specific church, users from a specific town, users who served in the Vietnam War, or any other definable group. Moreover, note that the state of being a customer or a provider is not an exclusive role—it is possible to be both a customer and a provider.

In one embodiment of the present invention, before including a group affiliation as a personal trait, a user authenticates with a group administrator who controls which users can affiliate with a group.

In one embodiment of the present invention, the peer-to-peer electronic commerce server can be the group administrator. In this embodiment, the group creator specifies the conditions that a user is required to meet to join the group. The peer-to-peer electronic commerce server then authenticates the user to ensure that the user meets the conditions that the group creator specified.

In one embodiment of the present invention, a commodity can include: a physical item, such as a car or a book; a piece of software, such as an operating system; a service, such as landscaping or babysitting; or information.

In one embodiment of the present invention, a customer can search for a provider of a commodity by searching for personal traits that the customer requires or prefers of the provider. Similarly, a provider can select a customer from a set of potential customers who have expressed interest in purchasing the commodity based on the personal traits that are associated with the potential customers. For example, suppose that a customer lives in town X and that the customer wants to purchase a used car. Furthermore, suppose that the customer only trusts providers who reside in town X, or who have attended university Y, the customer's alma mater. Using the peer-to-peer electronic commerce server, the customer can search for providers of cars who possess the personal traits of living in town X, or having attended university Y.

As a second example, suppose that a provider is selling a car, but the provider, empathizing with poor college students, only wishes to sell the car to a college student. Using the peer-to-peer electronic commerce server, the provider can specify that for a potential customer to be eligible to purchase the car the potential customer is required to be a college-student. The peer-to-peer electronic commerce server will not present the listing of the provider's car to any potential customers who have not identified themselves as college students. Now, suppose that although the provider wants to sell the car to a college student, the provider would prefer to sell the car to a college student who attends the provider's alma mater. The provider can specify being a student at the provider's alma mater as a preferred customer-trait and request that the peer-to-peer electronic commerce server sort the list of potential customers based on this preferred customer-trait.

In one embodiment of the present invention, the peer-to-peer electronic commerce server can complete a sales transaction on behalf of the provider according to conditions specified by the provider.

In one embodiment of the present invention, the peer-to-peer electronic commerce server can use the personal traits supplied by users for targeted advertising. Note that this embodiment does not require a third-party user to view the personal traits; an organization can configure the peer-to-peer electronic commerce server to perform the targeted advertising without user-intervention.

Note that the present invention is not restricted to commerce applications. Any peer-to-peer application can use the present invention to influence search-results. For example, an employer can use the present invention to pre-filter resumes of job-candidates who provided personal traits when registering for an online job-search service.

Computing Environment

FIG. 1illustrates a computing environment100in accordance with an embodiment of the present invention. Computing environment100includes a number of computer systems. These computer systems can generally include any type of computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a personal organizer, a device controller, or a computational engine within an appliance. More specifically, computing environment100includes client110, client120, network130, server140, and database150.

Clients110and120can generally include any node on a network including computational capability and including a mechanism for communicating across the network.

Network130can generally include any type of wired or wireless communication channel capable of coupling together computing nodes. This includes, but is not limited to, a local area network, a wide area network, or a combination of networks. In one embodiment of the present invention, network130comprises the Internet.

Server140can generally include any computational node including a mechanism for servicing requests from a client for computational and/or data storage resources. In one embodiment of the present invention, server140can include a web-server, or a commodity-server, which facilitates commerce-transactions.

In one embodiment of the present invention, server140is configured to facilitate peer-to-peer electronic commerce.

Database150can generally include any type of system for storing data in non-volatile storage. This includes, but is not limited to, systems based upon magnetic, optical, and magneto-optical storage devices, as well as storage devices based on flash memory and/or battery-backed up memory.

Suppose that customer112wants to purchase a commodity. (Note that a commodity can include a physical item, a piece of software, or a service, such as landscaping.) To find an instance of the commodity to purchase, customer112accesses a web-site hosted by server140that facilitates peer-to-peer electronic commerce. Before searching for the commodity, customer112registers with the web-site. This involves customer112providing the web-site with a set of customer-traits which describe customer112(such as customer112's hobbies or town of birth). At this point, customer112also provides the web-site with a set of desired provider-traits. Note that the desired provider-traits can include required provider-traits, which customer112requires of the providers of the commodity, and preferred provider-traits, which customer112desires of the providers, but does not require of the providers.

After registering with the web-site, customer112can search for the commodity from providers who have the desired provider-traits. Note that the web-site only shows customer112a given provider if customer112has the required customer-traits as requested by the given provider. Upon finding the commodity, the web-site presents customer112with a list of the providers of the commodity who have the required provider-traits. Note that the list can be sorted based on a score that server140calculates for each provider on the list and that is based on preferred provider-traits that customer112desires of the providers of the commodity. In calculating the score, server140can assign weighted values to preferred provider-traits to account for how much importance customer112gives to a specific preferred provider-trait.

In one embodiment of the present invention, suppose that provider122is selling a commodity via a web-site hosted by server140that facilitates peer-to-peer commerce. Prior to listing the commodity on the web-site, provider122registers with the web-site. This involves provider122sending provider-traits which describe provider122(such as provider122's place of worship) to the web-site. At this point, provider122also sends to the web-site a list of desired customer-traits that provider122requires of a customer of the commodity. Note that the desired customer-traits can include both required customer-traits and preferred customer-traits.

After registering with the web-site, provider122lists the commodity on the web-site. Next, server140retrieves customer-traits from potential customers of the commodity. Server140then ranks the potential customers by comparing the customer-traits with the preferred customer-traits that provider122desires of the customer of the commodity. Note that the potential customers can be ranked based on a score that server140calculates for each potential customer. This score is based on preferred customer-traits that provider122desires of the customers of the commodity.

In calculating the score, server140can assign weighted values to preferred customer-traits to account for how much importance provider122gives to a specific preferred customer-trait. Note that the preferred customer-trait is a trait that provider122desires of the potential customers, but does not require of the potential customers. The next time provider122accesses the web-site, the web-site presents provider122with a ranked list of potential customers. Note that server140is not required to filter the potential customers of the commodity because server140filters the providers of the commodity before presenting the list of providers to the potential customers. Thus, the filter process has already occurred prior to a customer indicating interest in purchasing the commodity from provider122.

In one embodiment of the present invention, provider122specifies conditions required to complete a transaction with a potential customer, including the desired customer-traits. In this embodiment, server140can complete the transaction with a customer from the ranked list of potential customers on behalf of provider122without provider122explicitly selecting a customer from the ranked list of potential customers.

In one embodiment of the present invention, customer112can avoid registering with the web-site. In this embodiment, customer112can only view commodities offered by providers who do not specify any required customer-traits.

In one embodiment of the present invention, customer112can specify desired provider-traits without registering with the web-site. In this embodiment, the desired provider-traits are only used for the current session and are not saved by the web-site for future use.

In one embodiment of the present invention, customer112can specify customer-traits without registering with the web-site. In this embodiment of the present invention, the customer-traits are only valid for the current sessions and are not saved by the web-site for future use.

In one embodiment of the present invention, provider122can avoid registering with the web-site. In this embodiment, provider122can search a commodities-wanted section of the web-site for potential customers who want to purchase commodities that provider122can provide. Note that the commodities-wanted section lists commodities that customer112and other customers desire and have specified as such on the web-site. Furthermore, note that without registering with the web-site, provider122is limited to listings on the commodities-wanted section posted by customers who have not specified any required provider-traits.

In one embodiment of the present invention, server140is not restricted to a server that facilitates electronic commerce, but can facilitate any peer-to-peer service (such as a resume service, a dating service, or a donation service). For example, suppose that customer112is seeking a job and provider122is an employer. Using server140, customer112can pre-filter employers so that server140only presents job descriptions for employers who provide day-care. Similarly, provider122can pre-filter potential job-applicants so that server140only presents resumes of potential job-applicants who attended provider122's alma mater.

Registering a User

FIG. 2presents a flow chart illustrating the process of registering a user in accordance with an embodiment of the present invention. The process begins when server140receives registration information from a user, such as customer112or provider122(step202). Server140then determines if the account is for customer112or provider122(step204). If the account is for customer112, server140receives desired provider-traits from customer112(step206). Then, server140receives customer-traits from customer112(step208). If the account is for provider122, server140receives desired customer-traits from provider122(step210). Then, server140receives provider-traits from provider122(step212).

In one embodiment of the present invention, desired provider-traits can include required provider-traits, which customer112requires of a provider, and preferred provider-traits, which customer112desires of the provider, but does not require.

In one embodiment of the present invention, desired customer-traits can include required customer-traits, which provider122requires of a customer, and preferred customer-traits, which provider122desires of the customer, but does not require.

In one embodiment of the present invention, provider-traits, desired provider-traits (both required and preferred), customer-traits, and desired customer-traits (both required and preferred) can include: a location of provider122or customer112; a group affiliation of provider122or customer112; a hobby of provider122or customer112; a provider/customer-feedback level for provider122or customer112; a degree of association with provider122or customer112; a number of prior interactions with provider122or customer112; and any other trait that can describe provider122or customer112.

In one embodiment of the present invention, the location of provider122or customer112can be as general or as specific as provider122or customer112desire.

In one embodiment of the present invention, the group affiliation can include any public or private group created by a user. This can include groups based on: place of worship, town of birth, town of residence, university attended, distinguishing physical-characteristics, and any other trait that can define a group of customers/providers. Note that server140or the creator of the private group authenticates customer112or provider122before customer112or provider122can join the private group. Furthermore, customer112and provider122can create their own public or private groups. If customer112or provider122creates a private group, then customer112or provider122can decide who is eligible to join the private group.

In one embodiment of the present invention, provider-traits, desired provider-traits (both required and preferred), customer-traits, and desired customer-traits (both required and preferred) can include personal-traits that server140determines based on customer112or provider122's use of server140and information that customer112or provider122sends to server140. For example, these personal-traits can include: customer112or provider122's degree of association with a second user; customer112's buyer-rating; provider122's seller-rating; the number of transactions between customer112and provider122; and any other personal-traits that server140can determine and associate with customer112or provider122. Note that by determining the degree of association of a second user, server140enables customer112to select a provider to purchase a commodity from based on, for example, whether an associate of customer112knows or trusts the provider. Furthermore, by determining the degree of association of a second user, server140enables provider122to sell a commodity to a customer based on whether an associate of provider122knows or trusts the customer.

Next, server140determines if the customer-traits or the provider-traits include private group affiliations (step214). If not, server140associates the customer-traits or the provider-traits with customer112or provider122respectively (step218). If so, server140determines if a group administrator has approved customer112or provider122joining the specified private groups (step216). If so, server140associates the customer-traits or provider-traits with customer112or provider122respectively (step218). If not, server140rejects customer112or provider122's registration (step220).

In one embodiment of the present invention, customer112can create a provider account.

In one embodiment of the present invention, customer112can create an account that is both a provider account and a customer account.

In one embodiment of the present invention, server140stores customer112's registration information, customer-traits, and desired provider traits on database150.

Determining a List of Providers

FIG. 3presents a flow chart illustrating the process of determining a list of providers of a commodity in accordance with an embodiment of the present invention. The process begins when server140receives a description of a commodity (step302). This can involve customer112providing a search-term specifying the commodity, or clicking on a link associated with the commodity. Next, server140identifies a list of providers of the commodity (step304). Then, server140receives a specification of a set of desired provider-traits (306). Note that if customer112provided the specification of the set of desired provider-traits when customer112registered, then server140can retrieve the specification of the set of desired provider-traits from database150. Furthermore, note that customer112can amend the desired provider-traits and the customer-traits.

Next, server140uses the desired provider-traits to filter the list of providers of the commodity (step308). Note that this is a multi-step process, which is described in more detail below with reference toFIG. 4.

After filtering the list of providers, server140presents the filtered list to customer112(step310).

In one embodiment of the present invention, the filtered list includes for each provider the specification of the provider-traits that match customer112's desired provider-traits. In this embodiment, the filtered list does not include any additional provider-traits that were not included in customer112's specification of desired provider-traits.

In one embodiment of the present invention, server140stores the filtered list of providers on database150. This enables server140to identify possible providers of a commodity without re-comparing provider-traits with desired provider-traits during subsequent commodity searches. Note that if customer112changes the desired provider-traits, or if a provider changes the provider-traits associated with the provider, server140re-compares the provider-traits to the desired provider-traits. This embodiment also facilitates identifying possible customers for provider122without re-comparing customer-traits with desired customer-traits. Note that if provider122changes the desired customer-traits, or if a customer changes the customer-traits associated with the customer, server140re-compares the customer-traits to the desired customer-traits. Furthermore, note that this embodiment does not facilitate identifying new providers or new potential customers.

In one embodiment of the present invention, server140stores a list of providers on database150that server140has previously identified as lacking the desired provider-traits. This enables server140to identify future commodity-searches providers who lack the desired provider-traits without re-comparing provider-traits with desired provider-traits. Note that if customer112changes the desired provider-traits, or if a provider changes the provider-traits associated with the provider, server140re-compares the provider-traits with the desired provider-traits.

This embodiment also facilitates identifying customers who lack desired customer-traits without re-comparing customer-traits with desired customer-traits. Note that if provider122changes the desired customer-traits, or if a customer changes the customer-traits associated with the customer, server140re-compares the customer-traits with the desired customer-traits. Furthermore, note that this embodiment does not facilitate identifying new providers or new potential customers.

Filtering a List of Providers

FIG. 4presents a flow chart illustrating the process of filtering a list of providers of a commodity in accordance with an embodiment of the present invention. The process begins when server140determines a set of customer-traits associated with customer112(step402). Note that this may involve receiving customer-traits from customer112.

In one embodiment of the present invention, determining the set of customer-traits can involve retrieving the set of customer-traits from database150.

Next, server140determines a set of desired customer-traits for a given provider on the list of providers (step404). Note that this can involve retrieving the set of desired customer-traits from database150. Server140then determines if the customer-traits match the desired customer-traits (step406). Note that this can involve determining if the customer-traits match both the required customer-traits and the preferred customer-traits.

In one embodiment of the present invention, determining if the customer-traits match the desired customer-traits is limited to determining if customer-traits match the required customer-traits. In this embodiment, server140does not determine if the customer-traits match the preferred customer-traits.

If the customer-traits match the desired customer-traits, server140determines if the given provider has the required provider-traits (step410). If so, server140adds the provider to the filtered list of providers (step412). If the customer traits do not match the desired customer-traits, or if the given provider does not have the required provider-traits, server140removes the given provider from the list of providers (step408). After removing the given provider from the list of providers, or after adding the given provider to the filtered list of providers, server140determines if there are more providers on the list of providers (step414). If so, server140proceeds to step404. If not, server140sorts the filtered list of providers (step416).

Note that sorting the filtered list of providers may involve comparing the preferred provider-traits for a given provider on the filtered list to the preferred provider-traits of the remaining providers specified by the filtered list. Furthermore, note that sorting the filtered list can involve server140calculating a score for each provider on the filtered list based on the preferred provider-traits associated with each provider on the filtered list. In calculating the score, server140can assign different weighted values to the different preferred provider-traits to account for the level of importance customer112places on each preferred provider-trait. Server140then proceeds to step310.

Selecting a Customer of a Commodity

FIG. 5presents a flow chart illustrating the process of selecting a customer of a commodity in accordance with an embodiment of the present invention. Note that this process occurs after server140has presented a filtered list of providers to customer112. Because creating the filtered list involves comparing customer traits to required customer-traits, using required customer-traits to select a customer of a commodity is unnecessary. Therefore, this process is described herein with reference toFIG. 5in terms of preferred customer-traits. However, note that this process can involve both preferred customer-traits and required customer-traits.

The process begins when server140receives a set of preferred customer-traits from provider122(step502). Server140then retrieves customer-traits for potential customers from database150(step504). Note that potential customers are customers who have indicated a willingness to purchase a commodity from provider122. Furthermore, potential customers are customers who have required customer-traits as specified by provider122. Server140then compares the customer-traits to the preferred customer-traits (step506). Using the result of this comparison, server140ranks the potential customers to obtain a ranked list of potential customers (step508). Server140then presents the ranked list to provider122(step510).

In one embodiment of the present invention, ranking the potential customers can involve server140calculating a weighted score based on the importance the provider122places on each preferred customer-trait. Server140can then use the weighted score to rank the potential customers.

In one embodiment of the present invention, server140selects a customer from the list of potential customers to purchase the commodity. In this embodiment, server140may or may not present the ranked list to provider122. Note that server140can select the customer based on the ranked list, or based on any other criteria specified by provider122.

In one embodiment of the present invention, provider122can specify a different purchase price based on the preferred customer-traits associated with the potential customers. This embodiment enables provider122to give discounts to specific customers, such as repeat customers or students.

In one embodiment of the present invention, the ranked list includes for each customer the customer-traits that match provider122's desired customer-traits. In this embodiment, the ranked list does not include any additional customer-traits that were not included in provider122's specification of desired customer-traits.