We’re building an intentcasting scenario to demonstrate the power of personal clouds linked using personal channels as a vehicle for enabling near-future commerce scenarios. The specific scenario we’re working on involves a woman buying a motorcycle.

Players

The following describes the players in the initial scenario along with the initial configuration of the personal clouds and channels:

• Allison is in the market for a new motorcycle. She uses a personal cloud and has already established channels to her bank, insurance company, and the DMV (since she already owns a car). Allison’s personal cloud contains data about her including employment, income, FICO score, driving record, and so on
• Ben is selling his motorcycle. Allison doesn’t know it yet, but it’s just what she’s looking for. Ben also has a personal cloud with channels to his motorcycle, the DMV, and his bank.
• The motorcycle is a BWM S1000. The bike has a personal cloud and is linked to Ben, its owner, as well as the DMV. In our vision, things like motorcycles are active participants in the scenario since they have personal clouds of their own. The motorcycle’s personal cloud has all of the relevant details of the bike’s manufacture, sale, maintenance history, riding history, and any other relevant information. In short, the motorcycle is a spime. See my earlier blog post about a smart bike for more detail on how things can be active participants on the Live Web.
• FastStuff is a brokerage service that supports intentcasting around high value items like motorcycles. The broker supports publishing intents and subscribing to filtered intent streams. The broker also provides discovery and reputation services.
• Other sellers are also selling motorcycles. They may or may not be using personal clouds, but they are capable of understanding and responding to messages over personal channels. Channels can interact with other communications networks, albeit with limited capabilities relative to those connected through personal clouds.
• Other players such as Allison and Ben’s respective banks, the DMV, and the insurance company are all using systems that are capable of interacting with personal clouds via channels.

The initial setup is shown in the following diagram.

The solid lines represent channels between personal clouds. The dotted line represents an channel with restricted permissions (we call these attenuated channels).

Phase 1: Finding the Bike

Allison has decided to buy a new motorcycle and has selected FastStuff as her intentcasting broker (a 4th party in the four party nomenclature of VRM). She has activated FastStuff’s app in her personal cloud and this has established a channel between her personal cloud and FastStuff. Allison’s intent-to-buy along with relevant information about what she’s looking for are published to FastStuff.

Ben has also activated the FastStuff app in his personal cloud and used it to list his S1000. As part of that listing process Ben established a channel between his personal cloud and FastStuff—he has subscribed to relevant intentions to buy from buyers such as Allison. He has also established a channel between the motorcycle’s personal cloud and FastStuff. The motorcycle, in essence, lists itself since it knows all its own relevant details and even has pictures and video that can become part of the listing.

Other sellers have also subscribed to intentions from FastStuff. They may do this in a variety of ways, including through another service, as long as they understand the semantics of the messages that are sent to them. This semantics constitutes a protocol for intentcasting. The semantics is available via a data dictionary that software can use to flexibly and quickly adapt to messaging from various players.

FastStuff, as a broker, uses a reputation service that allows it to provide guarantees about the various players in the scenario. For example, FastStuff can warrant to sellers that Allison will be able to secure the credit necessary to complete the purchase because they have access to reputation information about her.

As a result of publishing an intent-to-buy, Allison receives various information and offers from qualified sellers through the channel she has established with FastStuff. The FastStuff app in her personal cloud, acts in concert with other apps she uses, appropriately filters offers, and even automatically replies to sellers.

The links between the players in this phase is shown in the following diagram.

Notice that in this phase FastStuff is acting as the broker for the communication. The FastStuff business model is to serve as a market and bring buyers and sellers together for a fee.

Phase 2: Linking to the Seller

After reviewing the offers she received from various sellers, Allison decides she’d like to take a closer look at Ben’s bike. FastStuff facilitates establishing direct channel between Allison and Ben.

In addition, Ben facilitates an attenuated channel between Allison and the motorcycle’s personal cloud. Because it’s attenuated, Allison can see certain information, such as maintenance history, but not other information, like trip history. If she decides she needs more access, she negotiates this with Ben, who as the motorcycle’s owner is in control of the motorcycle’s personal cloud.

Using information from the direct channels, Allison determines that she’d like to test drive the bike. Since the price is right, she’s fairly sure this is a bike she’d like to buy if the test drive goes well. She uses a banking app in her personal cloud to pre-approve the financing. Her bank confirms that the motorcycle loan is ready to fund.

The Address Book app in Allison’s personal cloud uses the channel to Ben to negotiate a time to meet and to get Ben’s address.

The links in this phase are shown in the following diagram.

In this diagram, Allison and Ben are now linked. Allison has an attenuated channel to the bike. The channels to FastStuff and other buyers are no longer needed for purposes of our demonstration, so we’ll ignore them from here on out.

Phase 3: Buying the Bike

Allison’s friend drives her over to test drive the bike and it’s everything she wants and more. After finalizing the price with Ben, Allison buys the bike.

Because she has pre-approved the loan with bank, Allison has an approval code on her phone. The code is available either using the NFC system on her phone or as a QR code. Ben’s older-model phone doesn’t support NFC, so he scans the code with his phone. The phones are acting as trusted agents of their respective owner’s personal clouds and the apps that have been activated therein.

Scanning the code creates a new channel between Allison and Ben for purposes of completing the financial transaction. The channel is new because it has a different purpose as well as more sophisticated permissions and capabilities than the channel that had already been established. Allison and Ben use the new channel to confirm the purchase. Allison’s bank also calls her to confirm the transaction.

An out of band transfer of funds is completed between Allison’s bank and Ben’s bank and they both receive a confirmation that the funds have been transferred. At the same time, Ben’s personal cloud initiates a transfer of ownership. This means that the DMV is notified so that the title can be updated as well as the motorcycle itself being told of it’s new owner. This creates a channel between Allison and the bike that identifies her as the owner and gives her ownership permissions in the motorcycle’s personal cloud.

Allison uses the channel to her insurance company to inform them about the purchase and gives them an restricted channel to the new bike so that they can issue a policy. The DMV also registers the motorcycle and returns information about the registration to Allison and the bike.

The links in this phase are shown in the following diagram.

This diagram attempts to show the out-of-band funds transfer between bikes. Note that the ownership link to Ben’s personal cloud from the bike is gone and a new ownership link has been established to Allison.

Notes

A few notes about the preceding scenario:

• You might ask “Why do the bank and other companies have ‘personal’ clouds?” While “personal” is the word that best describes the concept it doesn’t just mean “person.” Rather the more correct term would be “entity-specific” but that’s unwieldy. Every entity can have a personal cloud. In fact, some entities like people or corporations might be in control of thousands of them.
• The personal clouds and channels create a sophisticated relationship network that includes people, institutions, and even things. The relationships in that network are rich and varied—just like relationships in the real world.
• The personal cloud infrastructure might be hosted by a third party provider or self-hosted. There’s nothing in this scenario that requires all the clouds to be hosted in the same place or even that they all use the same technology as long as they adhere to standards like EXP and XDI.
• We’ve largely ignored the problem of discovery in Phase 1. We’re assuming that the various players all connect to the broker or use another broker that networks with FastStuff. This isn’t because we don’t think discovery is important, but because we are ignoring it here to keep the moving parts down to less than a couple dozen.
• There’s lots of data floating around this scenario that I’ve failed to highlight. Building the scenario out will require that the personal data and data about the bike be worked out. For example, I blithely mention Allison’s FICO score being in her cloud, but in fact there’s probably a third party providing that and Allison is merely referencing it to her bank who ultimately retrieves it.
• The centerpiece of the build-out is the module that manages channels and understands ownership. As this matures more and more of it will be built into the core system for security and performance reasons, but to start we’ll build it as a KRL module for flexibility.

More to Come

In the coming weeks we’ll be building different parts of this and defining the event protocols and apps that make this work.