For this third and final blog in my “contextual services” series, I’ll look at the actual higher-level software requirements for the concept. Remember that my goal in the series is to frame a set of facilitating services or features that would be exposed via APIs and provide operators with a means of wholesaling capabilities to OTTs in order to support higher-level “retail” services. Of course, operators could also exploit these APIs themselves, subject to regulatory policies.
Let’s start by saying that contextualization, in software/processing terms, is the intersection of events and policies. The events are signals of conditions of interest/value to a user, and the policies define how the user would like his contextual applications to respond to those signals. My assumption (from my last blog) is that the policy storage would be on a user device, within a blockchain like Ethereum’s, but I also assume that contextualization could involve enough signals and reactions that the overhead and cost of blockchain use might be prohibitive. I also think that we should assume that a user would have to enter a state of “contextual sensitivity” that would render the user’s technology sensitive to contextual aid. With these assumptions, I think we can lay out a sequence of processing, in two pieces. The first is the policy side and the second the signal side.
The policy side is initiated when a user sets themselves in a contextual sensitivity state, meaning they open or activate an app on their device that indicates they want contextual help. I assume that any given user would have a number of what I’ll call contextual states, representing activities where contextual help is valuable. For work-oriented states, these would be aligned with work activities, and for personal/recreational there would be other states, such as “shopping”, “looking for a friend”, “sightseeing”, etc. A state would be linked to a service and parameter set. When a user activates one, the policies from that state in the user’s blockchain would be transferred to a context agent that could be resident in the device or in the cloud, or even split between the two. There, these policies would be used to respond to signals.
Which we’ll now introduce. A “signal” is a process event triggered by the analysis of local conditions based on those stored policies, conducted by a context agent. The assumption I make is that “local conditions” are represented by what I’ve characterized in past blogs as “information fields”, where the term “field” means “area of impact”. For example, if it’s raining in New York City north of 41st street, there would be a “raining” information field associated with that geography. If there is a sale on at Macy’s, there would be a field centered on the store location that would represent the things on sale. My conception was that information fields would be stored in a database, indexed by the locations within the field.
When the user’s location is identified, or when it changes by what’s deemed a significant amount (as defined in the context state, but a block, for example), the user’s context agent would query the information field database and obtain those fields to which the user’s policies indicated sensitivity or interest. Each information field would then be processed according to the context state data provided by the user, and when there was a match between information field and context state, the identified process would be activated.
If we generalize this, we could say that the user’s context state would identify the conditions that signaled a query of the information field database. For example, a work task like changing a fuse might trigger a query explicitly, meaning that the user might be told “open the fuse box and click NEXT when done.” Any condition that could be sensed by the user’s device, by a device like an IoT sensor, or signaled explicitly could be used to initiate an information field query.
In summary, what happens is that when a “context signal event” occurs, the context agent would query the information fields database to determine which of the conditions user policies said were interesting were actually present. For each such information field, the context agent would match its parameters against the user policies, and when a match was found would activate the process indicated. That process could be a device notification or some on-device or externally run software element. To make this work, then, what do we need?
A lot of what’s needed is data models. First, we need a standardized structure and coding for our information fields. We have to be able to create that database I talked about, and allow any context agent to access it to process events against it and against user policies. Second, we need a standard for coding policies in blockchain identity records, and in the form that would be passed to context agents. This might take the form of a policy language specification. Third, we need a standard signal event coding so we can activate the context agent properly.
Then there’s the APIs. We need to be able to submit information fields to the database, and to access the database, and both those mechanisms should be in the form of an API. We also need to be able to activate processes from the intersection of policies, information fields, and signal events, which is also an API.
Operators, in my view, would host this, and could contribute (directly or through their users) information fields and signals or triggers. Where regulations allowed, they could offer the services retail (directly or through a subsidiary, again depending on regulations). The bulk of the data and the applications (context agents, processes associated with the handling of signal events, etc.) would likely be created by third parties as part of a retail service.
Regulations are the last point here. There are multiple levels of regulations that could apply here. One is the question of whether a regulated entity can offer an “information service”; this is the dominant issue in the US. The general answer is either “Yes” or that the entity has to do so through a fully separate subsidiary. Another level is the privacy protections associated with customer data. In most cases, this applies to data acquired through the operation of the regulated service. Finally, there’s the question of “custodial” behavior; if the operator stores third-party data, would that data be subject to privacy regulations even though the operator didn’t own it. All this is murky to say the least, so I asked operators for their views.
I’m told by operators globally that there would be no regulatory barrier to their providing standards for data structures or mechanisms for creating contextual services. In some geographies, there may be barriers to operators supplying personal data, but my proposal is that the users’ personal data is stored in a blockchain, and is supplied parametrically to the context agent on user command. Most operators think that wouldn’t violate regulations in their market because the user is sharing the information and there is no persistent storage of the policies and parameters extracted by the user from the blockchains.
About a third of operators believe they could actually provide the complete service as long as they used a separate subsidiary, but there are some questions regarding how that subsidiary would be able to access the network or real estate owned by the regulated operator entity. Most operators, both in this group and overall, were less interested in being the contextual service provider and more interested in contributing wholesale data or being a repository, with both options falling into my “facilitating services” category.
That raises the final point. I do not believe that there are any significant opportunities for new service revenues for operators that don’t fall into either contextual-services or would be based on a similar model of facilitation. I also think that regulators are beginning to realize that they either have to give operators more latitude in creating return on infrastructure, or we end up in nationalization or subsidization. You can’t wish away financial realities, and even governments are (reluctantly) accepting that.