https://cyber.harvard.edu/projectvrm/api.php?action=feedcontributions&user=Bbenz&feedformat=atomProject VRM - User contributions [en]2024-03-19T01:04:03ZUser contributionsMediaWiki 1.39.5https://cyber.harvard.edu/projectvrm/?title=Talk:Privacy_issues&diff=1541Talk:Privacy issues2007-01-05T08:01:06Z<p>Bbenz: /* The third party doesn't usually have to define the Taxonomy */</p>
<hr />
<div>The hashing approach, while it brings some interesting benefits, makes me a bit nervous on a couple of fronts. My main concern is the limitations that it seems to impose on the RFP: as Bbenz notes, because hashing requires that both seeker vendor hash the exact same string it works well for something like a specific product code, but far less well for more abstract requests. <br />
<br />
Taking the examples from the [[Taxonomy_issues |taxonomy page]], hashing might manage a request for a Blackberry 7130c relatively easily, but requesting a cell phone based on features (must have bluetooth and EDGE support), or price (must cost $250 or less) becomes non-trivial very quickly...the data dictionary required just for cell phones would be pretty hairy. Hashing also makes RFP-offer matching absolutely binary: either a vendor has an exact match for the RFP or not, no possibility of a vendor offering a good deal on something very close to, but not exactly, what is defined in the RFP. [This "all or nothing" model may be desirable for some; in my head, though, VRM allows vendors some latitude in what they offer, with a combination of seeker-side offer evaluation and a reputation system combatting the potential for abuse.]<br />
<br />
I also worry about the increased importance of a third-party authority that I think I see coming from this model. If we're hashing, there needs to be a single, authoritative source defining the language and grammar of every term that can be used in an RFP; returning to the taxonomy examples, until that source provides or confirms the definitive way to say "I want a cell phone that costs less than $50 and is AIM-capable," it's effectively impossible to make that request. The central authority becomes absolutely critical to the VRM process, which scares me a bit. <br />
<br />
[Note: I'll happily agree that defining a data format for RFPs/offers that is structured enough to be easily parseable but open enough to allow making all (or most) of the necessary kinds of statements isn't all that much more appealing an option. I just think that it's a much more forgiving approach for when the inevitable typos/errors creep in, and that it would require less maintenance and overhead.]<br />
<br />
Looking forward to hearing what others think...<br />
--[[User:Whitneymcn|whitneymcn]] 02:56, 4 January 2007 (EST)<br />
<br />
== The third party doesn't usually have to define the Taxonomy ==<br />
<br />
In my experience, there is usually already a way to define items that are the focus of transactions within an industry, be it products or services, and many of those formats are already in sharable forms, such as XML. A third party (or parties) could be part of this solution, but I see them more as facilitators providing the common method by which the data is hashed by the customer and the vendor, not determining the format of the data itself. <br />
<br />
One possibile example: The customer part of the system (not that I'm purposely avoiding defining these too much at this point...) could find the data format of the product or service request from the vendor part of the system to define what they want (could be a format registry, etc.), in my example, cell phone service. The customer part of the system would use this format as part of the RFP, which would be enclosed in a standard transport format when hashed (I want to say XML doc segment here but I'm resisting pinning down the format just yet). Only vendors offering that type of service as identified in the format of the request could query and respond to those requests.<br />
<br />
On the subject of third parties, (if there is a need for third parties in VRM), IMHO, the most important function would be vendor control. Without some way to identify real vendors, I could see "agencies" popping up to handle queries, claiming to be in every business in the universe, then reselling the quotes to whoever pays for them. The result would be basically a faster, electronic form of the advertisement model we have now; getting lots of offers for lots of stuff you don't need or want, not related to what you asked for in the first place. Or getting 30 offers for the same 1 thing, with a margin tacked on by middlemen (for example, 30 offers for cell phone service from retail storefronts, offshore cyber sweatshops and moonlighting day-traders in their home offices, all of which are actually just reselling the same cingular plan)....But maybe I'm wrong here, I'd definitely like to hear thoughts on how VRM vendors could be controlled without third party policing.<br />
<br />
As for RFPs containing really vague items, now wer'e talking customer control.....In any RFP scenario I've ever been involved in (and this is bitter experience talking here :) ), one of the few responsibilities of the customer is to have a fairly clear idea of what they want before they send out an RFP. IMHO the same would be true for VRM RFPs....In order to submit a lucid VRM RFP, basic product and service decisions would have to be made by the customer before the RFP is submitted. That way the vendor can provide appropriate responses to the RFP. As there will be minimal contact between the customer and the vendor befor a VRM-based purchase is made, IMHO, this is as critical as vendor control....And the customer part of the VRM system would definitely have to manage this. This definitely needs more discussion too....</div>Bbenzhttps://cyber.harvard.edu/projectvrm/?title=Talk:Privacy_issues&diff=1540Talk:Privacy issues2007-01-05T08:00:01Z<p>Bbenz: /* The third party doesn't usually have to define the data dictionary */</p>
<hr />
<div>The hashing approach, while it brings some interesting benefits, makes me a bit nervous on a couple of fronts. My main concern is the limitations that it seems to impose on the RFP: as Bbenz notes, because hashing requires that both seeker vendor hash the exact same string it works well for something like a specific product code, but far less well for more abstract requests. <br />
<br />
Taking the examples from the [[Taxonomy_issues |taxonomy page]], hashing might manage a request for a Blackberry 7130c relatively easily, but requesting a cell phone based on features (must have bluetooth and EDGE support), or price (must cost $250 or less) becomes non-trivial very quickly...the data dictionary required just for cell phones would be pretty hairy. Hashing also makes RFP-offer matching absolutely binary: either a vendor has an exact match for the RFP or not, no possibility of a vendor offering a good deal on something very close to, but not exactly, what is defined in the RFP. [This "all or nothing" model may be desirable for some; in my head, though, VRM allows vendors some latitude in what they offer, with a combination of seeker-side offer evaluation and a reputation system combatting the potential for abuse.]<br />
<br />
I also worry about the increased importance of a third-party authority that I think I see coming from this model. If we're hashing, there needs to be a single, authoritative source defining the language and grammar of every term that can be used in an RFP; returning to the taxonomy examples, until that source provides or confirms the definitive way to say "I want a cell phone that costs less than $50 and is AIM-capable," it's effectively impossible to make that request. The central authority becomes absolutely critical to the VRM process, which scares me a bit. <br />
<br />
[Note: I'll happily agree that defining a data format for RFPs/offers that is structured enough to be easily parseable but open enough to allow making all (or most) of the necessary kinds of statements isn't all that much more appealing an option. I just think that it's a much more forgiving approach for when the inevitable typos/errors creep in, and that it would require less maintenance and overhead.]<br />
<br />
Looking forward to hearing what others think...<br />
--[[User:Whitneymcn|whitneymcn]] 02:56, 4 January 2007 (EST)<br />
<br />
== The third party doesn't usually have to define the Taxonomy ==<br />
<br />
In my experience, there is usually already a way to define items that are the focus of transactions within an industry, be it products or services, and many of those formats ae already in sharable forms, such as XML. A third party (or parties) could be part of this solution, but I see them more as facilitators providing the common method by which the data is hashed by the customer and the vendor, not determining the format of the data itself. <br />
<br />
One possibile example: The customer part of the system (not that I'm purposely avoiding defining these too much at this point...) could find the data format of the product or service request from the vendor part of the system to define what they want (could be a format registry, etc.), in my example, cell phone service. The customer part of the system would use this format as part of the RFP, which would be enclosed in a standard transport format when hashed (I want to say XML doc segment here but I'm resisting pinning down the format just yet). Only vendors offering that type of service as identified in the format of the request could query and respond to those requests.<br />
<br />
On the subject of third parties, (if there is a need for third parties in VRM), IMHO, the most important function would be vendor control. Without some way to identify real vendors, I could see "agencies" popping up to handle queries, claiming to be in every business in the universe, then reselling the quotes to whoever pays for them. The result would be basically a faster, electronic form of the advertisement model we have now; getting lots of offers for lots of stuff you don't need or want, not related to what you asked for in the first place. Or getting 30 offers for the same 1 thing, with a margin tacked on by middlemen (for example, 30 offers for cell phone service from retail storefronts, offshore cyber sweatshops and moonlighting day-traders in their home offices, all of which are actually just reselling the same cingular plan)....But maybe I'm wrong here, I'd definitely like to hear thoughts on how VRM vendors could be controlled without third party policing.<br />
<br />
As for RFPs containing really vague items, now wer'e talking customer control.....In any RFP scenario I've ever been involved in (and this is bitter experience talking here :) ), one of the few responsibilities of the customer is to have a fairly clear idea of what they want before they send out an RFP. IMHO the same would be true for VRM RFPs....In order to submit a lucid VRM RFP, basic product and service decisions would have to be made by the customer before the RFP is submitted. That way the vendor can provide appropriate responses to the RFP. As there will be minimal contact between the customer and the vendor befor a VRM-based purchase is made, IMHO, this is as critical as vendor control....And the customer part of the VRM system would definitely have to manage this. This definitely needs more discussion too....</div>Bbenzhttps://cyber.harvard.edu/projectvrm/?title=Talk:Privacy_issues&diff=1539Talk:Privacy issues2007-01-05T07:42:04Z<p>Bbenz: The third party doesn't usually have to define the data dictionary</p>
<hr />
<div>The hashing approach, while it brings some interesting benefits, makes me a bit nervous on a couple of fronts. My main concern is the limitations that it seems to impose on the RFP: as Bbenz notes, because hashing requires that both seeker vendor hash the exact same string it works well for something like a specific product code, but far less well for more abstract requests. <br />
<br />
Taking the examples from the [[Taxonomy_issues |taxonomy page]], hashing might manage a request for a Blackberry 7130c relatively easily, but requesting a cell phone based on features (must have bluetooth and EDGE support), or price (must cost $250 or less) becomes non-trivial very quickly...the data dictionary required just for cell phones would be pretty hairy. Hashing also makes RFP-offer matching absolutely binary: either a vendor has an exact match for the RFP or not, no possibility of a vendor offering a good deal on something very close to, but not exactly, what is defined in the RFP. [This "all or nothing" model may be desirable for some; in my head, though, VRM allows vendors some latitude in what they offer, with a combination of seeker-side offer evaluation and a reputation system combatting the potential for abuse.]<br />
<br />
I also worry about the increased importance of a third-party authority that I think I see coming from this model. If we're hashing, there needs to be a single, authoritative source defining the language and grammar of every term that can be used in an RFP; returning to the taxonomy examples, until that source provides or confirms the definitive way to say "I want a cell phone that costs less than $50 and is AIM-capable," it's effectively impossible to make that request. The central authority becomes absolutely critical to the VRM process, which scares me a bit. <br />
<br />
[Note: I'll happily agree that defining a data format for RFPs/offers that is structured enough to be easily parseable but open enough to allow making all (or most) of the necessary kinds of statements isn't all that much more appealing an option. I just think that it's a much more forgiving approach for when the inevitable typos/errors creep in, and that it would require less maintenance and overhead.]<br />
<br />
Looking forward to hearing what others think...<br />
--[[User:Whitneymcn|whitneymcn]] 02:56, 4 January 2007 (EST)<br />
<br />
== The third party doesn't usually have to define the data dictionary ==<br />
<br />
In my experience, there is usually already a way to define items that are the focus of transactions within an industry, be it products or services, and many of those formats ae already in sharable forms, such as XML. A third party (or parties) could be part of this solution, but I see them more as facilitators providing the common method by which the data is hashed by the customer and the vendor, not determining the format of the data itself. <br />
<br />
One possibile example: The customer part of the system (not that I'm purposely avoiding defining these too much at this point...) could find the data format of the product or service request from the vendor part of the system to define what they want (could be a format registry, etc.), in my example, cell phone service. The customer part of the system would use this format as part of the RFP, which would be enclosed in a standard transport format when hashed (I want to say XML doc segment here but I'm resisting pinning down the format just yet). Only vendors offering that type of service as identified in the format of the request could query and respond to those requests.<br />
<br />
On the subject of third parties, (if there is a need for third parties in VRM), IMHO, the most important function would be vendor control. Without some way to identify real vendors, I could see "agencies" popping up to handle queries, claiming to be in every business in the universe, then reselling the quotes to whoever pays for them. The result would be basically a faster, electronic form of the advertisement model we have now; getting lots of offers for lots of stuff you don't need or want, not related to what you asked for in the first place. Or getting 30 offers for the same 1 thing, with a margin tacked on by middlemen (for example, 30 offers for cell phone service from retail storefronts, offshore cyber sweatshops and moonlighting day-traders in their home offices, all of which are actually just reselling the same cingular plan)....But maybe I'm wrong here, I'd definitely like to hear thoughts on how VRM vendors could be controlled without third party policing.<br />
<br />
As for RFPs containing really vague items, now wer'e talking customer control.....In any RFP scenario I've ever been involved in (and this is bitter experience talking here :) ), one of the few responsibilities of the customer is to have a fairly clear idea of what they want before they send out an RFP. IMHO the same would be true for VRM RFPs....In order to submit a lucid VRM RFP, basic product and service decisions would have to be made by the customer before the RFP is submitted. That way the vendor can provide appropriate responses to the RFP. As there will be minimal contact between the customer and the vendor befor a VRM-based purchase is made, IMHO, this is as critical as vendor control....And the customer part of the VRM system would definitely have to manage this. This definitely needs more discussion too....</div>Bbenzhttps://cyber.harvard.edu/projectvrm/?title=Privacy_issues&diff=1531Privacy issues2007-01-03T21:06:19Z<p>Bbenz: VRM Privacy Model for Discussion</p>
<hr />
<div>Hereâs a possible VRM privacy model for discussion, based on [http://www-306.ibm.com/software/data/db2/eas/anonymous/ existing tools that I work with at IBM]<br />
<br />
As a real-world example, Iâm planning on switching cell-phone carriers in February this year, and I also need a new cell phone. In this case, I could enter my needs into a VRM system, which would anonymously store them (in a centralized database via a Web site/Web service, or locally to some kind of P2P client.). <br />
<br />
As for how to store the info and identify needsâ¦. Somehow we have to be able to identify the cell phone needed. I suppose that UPC codes could be used or some other identifier, translated from a master list of products offered. The cell phone plan entry is a little more nebulous. Not sure how that one would be identified, other than needs based on a customer formâ¦.minutes needed, family plan, coverage, etcâ¦.(Iâll just skip over this little part for nowâ¦..:)<br />
<br />
After the needs are recorded, they would be anonymized via a one-way hash (we currently use the [http://en.wikipedia.org/wiki/SHA-1 SHA-1] algorithm). The original data is still in its original state, but only accessible to the person who created it. Other customers can not see any data but their own.<br />
<br />
Hashed entries are stored separately and available for querying by Vendors. Vendors would have to register to receive a shared hash key. That key would allow Vendors to query customer needs, but only for products that they provide, via unique, shared codes. <br />
<br />
Vendors can not see customer data. They can only query data with products that they have on offer, via a unique shared ID. The VRM system notifies the customer when a match is found, not the Vendor.<br />
<br />
The VRM system could optionally notify the vendor when a match is found, for statistical purposes (comparing hits to products sold, for example), but this binary hit/no hit value is all the vendor would have. The customer remains anonymous until they choose to purchase a product or service. <br />
<br />
Customers that are notified when a match is found would be anonymously directed to a Web page or Web Service with an offer for the specific product that they are looking for. It is then up to the customer to decide if they want to pursue the product with that vendor (take the relationship to the next level).<br />
<br />
If the offers are all Web Service based, tools could be built to aggregate and compare offers that are returned when needs are recorded. Going even further, the tools could be built to link to product and service reviews, and complete the transaction once a decision is made. <br />
<br />
In my real-world example, I would shop for a cell phone and service options online, anonymously, and decide on one or more products that Iâm interested in, pretty much the same way I do now. I would then record my cell phone preferences and service needs in the VRM system. My needs would be hashed and added to the hash values that are accessible to Vendors (via a centralized or P2P-style decentralized system). Registered cell phone vendor A can query the hashed data using the same unique IDs (UPCs or other value) that I entered when I recorded my need. If thereâs a match, I would be notified of an offer from that Vendor by the VRM system. At the same time, Cell phone service provider B could query my plan needs via shared plan IDs or via plan parameters, and offer me a cell phone and cell phone service bundle in conjunction with a cell phone provider. <br />
<br />
I would review these offers anonymously and decide which is best for me. Once I have made a decision, I would contact the vendor (via the VRM system, or directly) and proceed with the purchase. The purchase would be my first direct, non-anonymous contact with the vendor.<br />
<br />
Once a decision is reached and a purchase has been made, I would remove the record of my needs from the VRM system, and no longer receive offers for that specific product or service.<br />
<br />
Things that need more thought, more discussion:<br />
This model only works assuming multiple vendors are trying to sell you the same, somewhat easily identified product or service. For vague items that donât easily fit into this model (video service providers, holiday travel, catering, many other services), more thought is neededâ¦</div>Bbenzhttps://cyber.harvard.edu/projectvrm/?title=Interesting_Links&diff=1530Interesting Links2007-01-03T21:05:00Z<p>Bbenz: /* People's Blogs */</p>
<hr />
<div>[http://cyber.law.harvard.edu/ The Berkman Center for Internet & Society at Harvard Law School]<br />
<br />
[http://www.windley.com/events/iiw2006b/ The Internet Identity Workshop]<br />
<br />
Link to another take on a [[vrm diagram]]<br />
<br />
== People's Blogs ==<br />
<br />
[http://doc.weblogs.com Doc Searls]<br />
<br />
[http://blog.joeandrieu.com Joe Andrieu]<br />
<br />
[http://gesturelab.com Steve Gillmor]<br />
<br />
[http://www.blackmailr.com/smr Whitney McNamara]<br />
<br />
[http://aqualung.typepad.com/aqualung Ric Hayman]<br />
<br />
[http://bbenz.typepad.com/softwaresoapbox Brian Benz]<br />
<br />
*If you are interested in the VRM conversation, please add your blog...</div>Bbenzhttps://cyber.harvard.edu/projectvrm/?title=Interesting_Links&diff=1529Interesting Links2007-01-03T21:04:19Z<p>Bbenz: /* People's Blogs */</p>
<hr />
<div>[http://cyber.law.harvard.edu/ The Berkman Center for Internet & Society at Harvard Law School]<br />
<br />
[http://www.windley.com/events/iiw2006b/ The Internet Identity Workshop]<br />
<br />
Link to another take on a [[vrm diagram]]<br />
<br />
== People's Blogs ==<br />
<br />
[http://doc.weblogs.com Doc Searls]<br />
<br />
[http://blog.joeandrieu.com Joe Andrieu]<br />
<br />
[http://gesturelab.com Steve Gillmor]<br />
<br />
[http://www.blackmailr.com/smr Whitney McNamara]<br />
<br />
[http://aqualung.typepad.com/aqualung Ric Hayman]<br />
<br />
[http://http://bbenz.typepad.com/softwaresoapbox Brian Benz]<br />
<br />
*If you are interested in the VRM conversation, please add your blog...</div>Bbenzhttps://cyber.harvard.edu/projectvrm/?title=Privacy_issues&diff=1528Privacy issues2007-01-03T21:00:44Z<p>Bbenz: </p>
<hr />
<div>Hereâs a possible VRM privacy model for discussion, based on [http://http://www-306.ibm.com/software/data/db2/eas/anonymous/ existing tools that I work with at IBM]<br />
<br />
As a real-world example, Iâm planning on switching cell-phone carriers in February this year, and I also need a new cell phone. In this case, I could enter my needs into a VRM system, which would anonymously store them (in a centralized database via a Web site/Web service, or locally to some kind of P2P client.). <br />
<br />
As for how to store the info and identify needsâ¦. Somehow we have to be able to identify the cell phone needed. I suppose that UPC codes could be used or some other identifier, translated from a master list of products offered. The cell phone plan entry is a little more nebulous. Not sure how that one would be identified, other than needs based on a customer formâ¦.minutes needed, family plan, coverage, etcâ¦.(Iâll just skip over this little part for nowâ¦..:)<br />
<br />
After the needs are recorded, they would be anonymized via a one-way hash (we currently use the [http://en.wikipedia.org/wiki/SHA-1 SHA-1] algorithm). The original data is still in its original state, but only accessible to the person who created it. Other customers can not see any data but their own.<br />
<br />
Hashed entries are stored separately and available for querying by Vendors. Vendors would have to register to receive a shared hash key. That key would allow Vendors to query customer needs, but only for products that they provide, via unique, shared codes. <br />
<br />
Vendors can not see customer data. They can only query data with products that they have on offer, via a unique shared ID. The VRM system notifies the customer when a match is found, not the Vendor.<br />
<br />
The VRM system could optionally notify the vendor when a match is found, for statistical purposes (comparing hits to products sold, for example), but this binary hit/no hit value is all the vendor would have. The customer remains anonymous until they choose to purchase a product or service. <br />
<br />
Customers that are notified when a match is found would be anonymously directed to a Web page or Web Service with an offer for the specific product that they are looking for. It is then up to the customer to decide if they want to pursue the product with that vendor (take the relationship to the next level).<br />
<br />
If the offers are all Web Service based, tools could be built to aggregate and compare offers that are returned when needs are recorded. Going even further, the tools could be built to link to product and service reviews, and complete the transaction once a decision is made. <br />
<br />
In my real-world example, I would shop for a cell phone and service options online, anonymously, and decide on one or more products that Iâm interested in, pretty much the same way I do now. I would then record my cell phone preferences and service needs in the VRM system. My needs would be hashed and added to the hash values that are accessible to Vendors (via a centralized or P2P-style decentralized system). Registered cell phone vendor A can query the hashed data using the same unique IDs (UPCs or other value) that I entered when I recorded my need. If thereâs a match, I would be notified of an offer from that Vendor by the VRM system. At the same time, Cell phone service provider B could query my plan needs via shared plan IDs or via plan parameters, and offer me a cell phone and cell phone service bundle in conjunction with a cell phone provider. <br />
<br />
I would review these offers anonymously and decide which is best for me. Once I have made a decision, I would contact the vendor (via the VRM system, or directly) and proceed with the purchase. The purchase would be my first direct, non-anonymous contact with the vendor.<br />
<br />
Once a decision is reached and a purchase has been made, I would remove the record of my needs from the VRM system, and no longer receive offers for that specific product or service.<br />
<br />
Things that need more thought, more discussion:<br />
This model only works assuming multiple vendors are trying to sell you the same, somewhat easily identified product or service. For vague items that donât easily fit into this model (video service providers, holiday travel, catering, many other services), more thought is neededâ¦</div>Bbenzhttps://cyber.harvard.edu/projectvrm/?title=Privacy_issues&diff=1527Privacy issues2007-01-03T21:00:16Z<p>Bbenz: VRM privacy model for discussion</p>
<hr />
<div>Hereâs a possible VRM privacy model for discussion, based on [http://http://www-306.ibm.com/software/data/db2/eas/anonymous/ existing tools that I work with at IBM]<br />
<br />
As a real-world example, Iâm planning on switching cell-phone carriers in February this year, and I also need a new cell phone. In this case, I could enter my needs into a VRM system, which would anonymously store them (in a centralized database via a Web site/Web service, or locally to some kind of P2P client.). <br />
<br />
As for now to store the info and identify needsâ¦. Somehow we have to be able to identify the cell phone needed. I suppose that UPC codes could be used or some other identifier, translated from a master list of products offered. The cell phone plan entry is a little more nebulous. Not sure how that one would be identified, other than needs based on a customer formâ¦.minutes needed, family plan, coverage, etcâ¦.(Iâll just skip over this little part for nowâ¦..:)<br />
<br />
After the needs are recorded, they would be anonymized via a one-way hash (we currently use the [http://en.wikipedia.org/wiki/SHA-1 SHA-1] algorithm). The original data is still in its original state, but only accessible to the person who created it. Other customers can not see any data but their own.<br />
<br />
Hashed entries are stored separately and available for querying by Vendors. Vendors would have to register to receive a shared hash key. That key would allow Vendors to query customer needs, but only for products that they provide, via unique, shared codes. <br />
<br />
Vendors can not see customer data. They can only query data with products that they have on offer, via a unique shared ID. The VRM system notifies the customer when a match is found, not the Vendor.<br />
<br />
The VRM system could optionally notify the vendor when a match is found, for statistical purposes (comparing hits to products sold, for example), but this binary hit/no hit value is all the vendor would have. The customer remains anonymous until they choose to purchase a product or service. <br />
<br />
Customers that are notified when a match is found would be anonymously directed to a Web page or Web Service with an offer for the specific product that they are looking for. It is then up to the customer to decide if they want to pursue the product with that vendor (take the relationship to the next level).<br />
<br />
If the offers are all Web Service based, tools could be built to aggregate and compare offers that are returned when needs are recorded. Going even further, the tools could be built to link to product and service reviews, and complete the transaction once a decision is made. <br />
<br />
In my real-world example, I would shop for a cell phone and service options online, anonymously, and decide on one or more products that Iâm interested in, pretty much the same way I do now. I would then record my cell phone preferences and service needs in the VRM system. My needs would be hashed and added to the hash values that are accessible to Vendors (via a centralized or P2P-style decentralized system). Registered cell phone vendor A can query the hashed data using the same unique IDs (UPCs or other value) that I entered when I recorded my need. If thereâs a match, I would be notified of an offer from that Vendor by the VRM system. At the same time, Cell phone service provider B could query my plan needs via shared plan IDs or via plan parameters, and offer me a cell phone and cell phone service bundle in conjunction with a cell phone provider. <br />
<br />
I would review these offers anonymously and decide which is best for me. Once I have made a decision, I would contact the vendor (via the VRM system, or directly) and proceed with the purchase. The purchase would be my first direct, non-anonymous contact with the vendor.<br />
<br />
Once a decision is reached and a purchase has been made, I would remove the record of my needs from the VRM system, and no longer receive offers for that specific product or service.<br />
<br />
Things that need more thought, more discussion:<br />
This model only works assuming multiple vendors are trying to sell you the same, somewhat easily identified product or service. For vague items that donât easily fit into this model (video service providers, holiday travel, catering, many other services), more thought is neededâ¦</div>Bbenz