1 / 54 V8. 2 Semi Automated Bartering of Digital Goods and Services in Pervasive Environments Olga Ratsimor Doctoral Research Proposal October 25 2005.

1 / 54

V8

2

Semi Automated Bartering of

Digital Goods and Services in Pervasive Environments

Olga RatsimorDoctoral Research ProposalOctober 25 2005

3 / 54

Presentation Outline

• Introduction• Thesis Statement• Motivation • Proposed Approach• Research Contributions• Research Plan & TimeLine• Preliminary Work • Related Work • Summary and Q&A

INTRO

4 / 54

Pervasive Computing Vision

INTRO

5 / 54

Issues Affecting Collaboration

• No incentive for collaborations • Self-interested personal mobile devices have limited

resources

• Free Rider Problems in Pervasive Environments • In attempt to conserve its computing resources and

power, device drops service requests and other communications from other devices while sending out service discovery requests for its own benefit.

• Information Noise Makers and Spammers:• Spamming and other heavy communication services. • Devices must be capable of filtering out “noise“ still

being able to collect useful information and discover needed services.

INTRO

6 / 54

Environmental Limitations

• Quality of Services is Unpredictable:• Received goods and services may not be what originally was

expected.• Utility function various on perceived context, time, location, etc.

• Inefficient Storage of Context Specific Services: • Many of the services are very context specific and are used only

during a particular context. • When the user changes context, unused services continue to

take up space and resources on the devices.

INTRO

7 / 54

Hypothesis Statement

The Question :Considering the diversity and the personal nature of devices

participating in pervasive environments, is the current model of altruistic ad hoc collaborations still the most effective model to motivate collaborations?

The Hypothesis:

Bartering can be an effective mechanism to incentivize devices to collaborate and improve the quality of collaborations.

The Proposed Approach:• Incentive driven collaboration mechanisms • Communication model based on bartering• Value based view of electronic goods and services

HS

8 / 54


• Introduction• Thesis Statement• Motivation • Proposed Approach• Research Contributions• Research Plan & TimeLine• Preliminary Work • Related Work• Summary and Q&A

MOTIV

9 / 54

Basic Scenario - 1

Has: Map-A, RingTone-A,CWants: RingTone-B

D4

Has: ScreenSaver-A, BWants: RingTone-A

D5

Has: Map-A, Song-AWants: RingTone-B

D3

D1

Has: RingTone-B, C, DWants: Song-A

D2

Has: Wallpaper-A, Song-A RingTone-B,CWants: ScreenSaver-A Wallpaper-B

MOTIV

10 / 54

Counter Proposal Scenario - 2


D4


D5


D3

D1


D2


MOTIV

11 / 54

Relationship Scenario - 3


D4


D3

D1


D2



D5

MOTIV

12 / 54

Investment Scenario - 4

Has: Song-AWants: RingTone-A, B

Has: RingTone-BWants: Song-A

D2D1

D3D2

Later

Has: RingTone-AWants: RingTone-B

Has: RingTone-A, BWants: Song-A

MOTIV

13 / 54

Similarity Scenario 5

Has: Song-A Title=title-A Performer= singer-A Style=pop

Wants: RingTone-* Type= polyphonic Length > 8sec

Has: RingTone-A Length= 10sec Type= monophonic Style=dance RingTone-C Length= 5sec Type= polyphonic Style=dance

Wants: Song-* Performer= singer-A

D2D1Has: RingTone-A, CWants: Song-B

D2D1

Has: Song-AWants: RingTone-B

MOTIV

14 / 54

Domain – What are Goods…

• Digital Goods• Ring Tones, MP3s, Podcasts, Mobile

Games, Screen Savers, Wallpaper, Video and Coupons

• Low Cost Items• Replicable• Digital Rights Management (DRM)

• transfer of ownership

• Digital Goods are obtained • for personal use• to be used as token in future

bartering

MOTIV

15 / 54

Double Coincidence of Wants

• A barter exchange requires a double coincidence of wants for trade to take place:

“An exchange between two parties can only occur if both parties desire what the other is willing to give up”

• The probability that one person has what the other desires is not in our favor.

• Our model relaxes the constraint• Improves the participation and tolerance levels

MOTIV

16 / 54

What is Needed?

We need to develop:

• Define and use Bartering protocols that are aware of personal relationships between the devices and their users’ perceived value of electronic goods and services.

• Valuation of electronic goods and services in personalized context conscious manner.

MOTIV

17 / 54


• Introduction• Thesis Statement• Motivation • Proposed Approach• Research Contributions• Research Plan & TimeLine• Preliminary Work• Related Work• Summary and Q&A

18 / 54

Bartering Model

• Context-based, continuous bartering with peers in pervasive environments

• In order to barter, one has to understand what the items are worth and how much they are worth.

• One also wants to evaluate who s/he is dealing with.• Difference between community and anonymous P2P network

19 / 54

Perceived Value

• Value in Use - is the value of the particular electronic good or service for the particular user.

• Value in Exchange - reflects the potential value of the service against any other service in value-for-value exchanges.

20 / 54

Aspects of Value

• Systemic Value represents the essence of the digital goods and services

• Liquidity reflects the ease with which a service can be acquired or exchanged for any service without a significant loss in value.

• Simplicity and similar value are the key factors. • A service is highly liquid if it can be exchanged

frequently by many devices for services of a similar value.

• Services with higher liquidity index would be in greater demand in the computing environment and

could be used by devices as exchange tokens.

21 / 54

Aspects of Value

• Context Based Value is the value that describes importance of the service or information in a particular context.

• Original Cost of the service or information reflects resources or money that had to be spent to initially acquire the services.

• Historic Value refers to the historic recorded value for the service of information.

• Original Value

22 / 54

Aspects of Value

• Store of Value refers to how consistently can the service store its value. Services and information value can depreciate or appreciate over time.

• Depreciation over time• expiration time and date • limit on replication.

• Appreciation over time• Memorabilia

• Transaction Cost describes costs involved in searching, bargaining and transferring data and verifying the correctness and finalization of transaction.

• Service Maintenance Cost describes the costs associated with keeping the service up to date.

• Frequency of Use Valuation - service that is frequently used have greater value

23 / 54

Aspects of Value

• Attribute Based Valuation attributes of the service have a value function that represents the importance of the attribute.

• Composability Index (*) reflects on how many other services can a particular service be composed with.

“Handy component”• Value in exchange - composability index is proportional to the number of the

services on in the environment that could be composed with a particular service.

• Services with high composability index would be in greater demand in the computing environment.

* Looking for input on better definition and terminology.

24 / 54

Value in Use

Valuation S1 S2 S3 S4

Systemic Value

Frequency of Use Valuation

Contextually Based Value

Attribute Based Valuation

Maintenance Costs

Store of Value

25 / 54

Value in Exchange

Valuation S1 S2 S3 S4

Liquidity

Transaction Costs

Service Maintenance Costs

Store of Value

Composability

Store of Value

26 / 54

Relationships

• Exploit relationships between groups of devices

• Self Devices - are personal devices that belong to a single user.

• Sibling Devices - are devices of users that are very close.

• Friendly Devices - are devices that belong to the different users that frequently come in contact and collaborate with one another.

• Strangers Devices - are devices that just meet and are most likely will never come in contact again.

• Siblings and Strangers are special cases of friendliness. • Unfriendly Devices - are devices that are actively uncooperative

• Trust could also be used to determine the level of cooperation

• Other Social Networks • Linked In & Orkut

27 / 54

Bartering Protocol

Each platform has three lists• pHave – list of goods and services that device has but

keeps private • iWant – list of goods and services that device desires

and is actively searching for• iHave – list of goods and services that device is willing

to exchange for other services

iWant

iHave

pHave

28 / 54

iWant

iHave

pHave

Bartering Protocol

iWant List and iHave List will contain value based descriptions of each goods and services

• Value in Use and Value in Exchange

Focus Factor – how much should the device Focus on the service • focus factor in iWant list– represents the intensity of the search

for the desired good or service• focus factor in iHave List - represents actively does the device

advertise the presence of the good or service.

29 / 54

Bartering Protocol

iWant

iHave

iWant

iHave

pHave pHave

30 / 54

Bartering Protocol

initiator participant

Discovery MSG

Not Found

Discovered

Proposal

Reject

Accept

Counter Proposal

Counter Proposal RPL iWantiHave

iWantiHave

31 / 54

Contributions

initiator participant

Discovery MSG

Not Found

Discovered

Proposal

Reject

Accept

Counter Proposal

Counter Proposal RPL iWantiHave

iWantiHave

32 / 54

Contributions

• Bartering Reasoner that answers the following questions:

• What do I want, what do I offer ? (not interested…)

• Who do I want to barter with? • What do I offer in return? • What do I offer them? (What’s the offer?)• Do I accept, Do I reject, or Do I counter-

propose?• Do we have a deal?

33 / 54

Contributions

• Development of value based descriptions for electronic goods and services.

• Development and implementation of a framework that employs and manages valuations.

• Development and implementation of bartering protocols / strategies that take:

• Relationships-Based Bartering • Service Attribute Bartering

• Demonstration of P2P environment that incentivizes collaboration.

34 / 54


• Introduction• Motivation • Proposed Approach• Research Contributions• Research Plan & TimeLine• Preliminary Work • Related Work• Summary and Q&A

PLAN

35 / 54

Tasks

A. Value based descriptions for services and electronic goods

B. Management component that employs these descriptions

C. Bartering support engineD. Bartering protocols and strategies.

• Analysis of effectiveness of these protocols and strategies

• Incorporate and study effects of DRME. Demonstration of P2P environment that

incentivizes collaborationF. Analysis and Evaluation

PLAN

36 / 54

Time Table

Task A Emulator for exchanging Nov 05

Task AValue in Use & Value in

ExchangeDec 05

Task BValue Based Management

ModuleJan 06

Task CInitial version of Bartering

ReasonerFeb 06

Task D Role Based Bartering Strategies Mar 06

Task D Contextual Bartering Strategies Apr 06

Task C Bartering Reasoner Jun 06

Task D Effects of DRM on Bartering Sep 06

Task ETesting & Refinement &

FinalizationOct 06

Task F Analysis and Evaluation Nov 06

Writing PhD Desertion Dec 06

Defense Jan 07

PLAN

37 / 54



PW

38 / 54

Preliminary Work

• Allia - Policy-Based Alliance Formation for Agents in Ad-Hoc Environments

• Agents2Go - An Infrastructure for Location-Dependent Service Discovery in The Mobile Electronic Commerce Environment

• Numi - Using Peer-to-Peer Data Routing for Infrastructure-Based Wireless Networks

• eNcentive - A Framework for Intelligent Marketing in Mobile Peer-To-Peer Environments

• eNcentive +TrueBahn - mCommerce and Trust

PW

39 / 54

Preliminary Work Publications

• Olga Ratsimor, Anupam Joshi, Timothy Finin, Yelena Yesha, eNcentive: A Framework for Intelligent Marketing in Mobile Peer-To-Peer Environments, The 5th International Conference on Electronic Commerce (ICEC), October 2003

• Olga Ratsimor, Anupam Joshi, Timothy Finin, Yelena Yesha, Intelligent Ad Hoc Marketing within Hotspot Networks, Technical Report, Nov 2003

• Olga Ratsimor, Dipanjan Chakraborty, Deepali Khushraj, Anugeetha Kunjithapatham, Anupam Joshi, Timothy Finin, Yelena Yesha Service Discovery in Agent-based Pervasive Computing Environments, Journal on Mobile Networking and Applications (MONET), Special issue on Mobile and Pervasive Commerce. 2003.

• Sethuram Balaji Kodeswaran, Olga Ratsimor, Anupam Joshi, Timothy Finin, Yelena Yesha, Using Peer-to-Peer Data Routing for Infrastructure-based Wireless Networks , IEEE International Conference on Pervasive Computing and Communications (PerCom), March 2003.

• Olga Ratsimor, Sethuram Balaji Kodeswaran, Anupam Joshi, Timothy Finin, Yelena Yesha, Combining Infrastructure and Ad hoc Collaboration For Data Management in Mobile Wireless Networks, Workshop on "Ad hoc Communications and Collaboration in Ubiquitous Computing Environments", November 2002.

• Sethuram Balaji Kodeswaran, Olga Ratsimor, Anupam Joshi, Timothy Finin, Yelena Yesha, Numi: A Framework for Collaborative Data Management in a Network of InfoStations, UMBC SRC, November 2002

• Olga Ratsimor, Dipanjan Chakraborty, Sovrin Tolia, Deepali Kushraj, Anugeetha Kunjithapatham, Gaurav Gupta, Anupam Joshi, Timothy Finin, Allia: Alliance-based Service Discovery for Ad-Hoc Environments, Paper, ACM Mobile Commerce Workshop, September, 2002.

• Tim Finin, Anupam Joshi, Lalana Kagal, Olga Ratsimor, Sasikanth Avancha, Vlad Korolev, Harry Chen, Filip Perich, R. Scott Cost, Intelligent Agents for Mobile and Embedded Devices, International Journal on CooperativeInformation Systems, 2002.

• Timothy Finin, Anupam Joshi, Lalana Kagal, Olga Ratsimor, Vlad Korolev, and Harry Chen, Information Agents for Mobile and Embedded Devices, Paper, Fifth International Workshop Cooperative Information Agents, Modena, Italy, September, 2001.

• Olga Ratsimor, Vladimir Korolev, Anupam Joshi, and Timothy Finin,Agents2Go: An Infrastructure for Location-Dependent Service Discovery in the Mobile Electronic Commerce Environment,Paper, ACM Mobile Commerce Workshop, July, 2001.

PW

40 / 54

Agents2Go

• Location dependent services discovery• Location dependent information retrieval

• Distributed services• Service information is distributed and grouped by regions.• Information about the restaurant is stored locally.

• Automatic location detection• Cell tower ids are mapped to the geographical region name.

• Service provider representation• Service Agents reside at the service provider locations.• Restaurant Agents reside at the restaurant locations.

PW

41 / 54

Numi

• Landing Zones are islands of high speed cheap connectivity around a Service Portal limited only by that portals wireless range

• Transit Zones are regions where there is no network connection

• In Landing Zones, mobile hosts communicate with service portals only

• In Transit Zones, mobile hosts communicate with each other

LandingZone

Transit Zone

LandingZoneMH2

MH1

PW

42 / 54

eNcentive

• eNcentive is a framework that facilitates peer to peer mobile marketing in pervasive environments

• Mobile users collect promotions, advertisements, coupons and other discount information

• User preferences effect adds collection and distribution

• Mobile users market that information to other users in the network

• Active distributors are rewarded • Incentives for distribution are proportional to the amount of

advertisements effectively distributed by the user• Wide choice of Reward Models

PW

43 / 54

Mobility CoordinatorPW

44 / 54

eNcentive PDA Interface

PW

45 / 54

eNcentive + TrueBahn

• Trust based mobile shopping• Mobile users are divided into tow groups

• Kids and Adults

• Groups are interlined• Kids have a circle of friends that can grow and shrink • Adults have circle of other Adults that they trust. The circle can grow

and shrink.

• Kids can shop for items that thy have been authorized to buy• If there is a new item on the wish list then kids need to find an Adult

form their trust network to give them authorization.

PW

46 / 54

Node3[s4,s5]{s2,s3}

Node5[s9,s10]

{s1,s2,s6}

Node1[s1]{s2}

Node2[s2,s3]{s4,s5}

Node4[s6,s7,s8]

{}

Node Alliances

Node1: node2 [s2]Node2: node3[s4,s5]Node3: node2[s2,s3]Node4: Node5: node1[s1], node2[s2] node4[s6]

Node3[s4,s5]{s2,s3}

Node5[s9,s10]

{s1,s2,s6}

Node1[s1]{s2}

Node2[s2,s3]{s4,s5}

Node4[s6,s7,s8]

{}

Node Alliances

Node1: node2 [s2]Node2: node3[s4,s5]Node3: node2[s2,s3]Node4: Node5: node1[s1], node2[s2] node4[s6]

Allia

• Peer-to-peer caching of service information from neighboring nodes• An Alliance of a particular node is a set of nodes whose local service information is cached

by this node.

• Policy-based advertising, caching and Alliance formation• Each node runs a lightweight version of mandatory FIPA platform components• A Policy Manager controlled the behavior of the platform.

Restrict platform functionality in respect to device capability

Specify priorities among services and sharing of available resources among services

Specifying advertisement and request message forwarding algorithms

Specify security restrictions like access rights and credential verification

Specify application specific preferences

Specify caching preferences

Specifying advertisement preferences

Specify personal user preferences

Lightweight DFLightweight AMS

Pol

icy

Ma

nag

er

Network

AgentAgent AgentC

acheM

an

ager

Forwarding Manager

Advertising Manager

Lightweight DFLightweight AMS

Pol

icy

Ma

nag

er

Network

AgentAgent AgentC

acheM

an

ager

Forwarding Manager

Advertising Manager

PW

47 / 54



RW

48 / 54

Related Work

• Context-aware Computing

• P2P File Sharing

• Mobile P2PSystems

• mCommerce

• Electronic Goods and Services

RW

49 / 54

Context-aware Computing

• Ambient Services• l-commerece marketplace

• Context Mediation• Valuation of context information

• myCampus • eWallet manages user’s context• Personal resources are modeled as semantic

web services• Context management includes privacy

management

RW

50 / 54

P2P File Sharing

Mojo Nation$ Internal currency call Mojo was used to purchasing files from

other peers$ Users could earned Mojo currency through sharing their disk

space, processing power, bandwidth …$ Central bank cleared transactions

Karma - Economic Framework for P2P Resource Sharing $ Internal currency called Karma$ Karma used a secure exchange mechanism to prevent

counterfeiting of Karma currency$ Framework used anti-inflation deflation mechanism to

regulates currency in the system.$ Framework used peer-to-peer scheme for tracking currency

transfers

RW

51 / 54

Mobile P2P Computing

• Infostations• “any time, anywhere” connectivity• data hoarding in mobile environments

• Proem – Wearable Computing • Wearable communities • Augmenting face to face interactions• personal “digital sphere”

• Mogatu - Serendipitous Query Routing and Processing

• Personal user profiles• Caching and replication algorithms

RW

52 / 54

mCommerece

• EasiShop • Cross merchant product comparison shopping• Shopping mobile agent• Market Place is a meeting point of shopping

and retailer agents

• iClouds• Mobile Advertising• Anonymous bonus points • iHave and iWant List

RW

53 / 54

Summary

Semi Automated Bartering of

Digital Goods and Services in Pervasive Environments

54 / 54

Q&AThank You.

Q&A

55

Backup Slides

56 / 54

Value in Use

Value of the service for internal use of the device is tied to a set of factors.

• Systemic Value – core function of the service

• Frequency of Use Valuation • Contextually Based Value – importance particular context

• Attribute Based Valuation• Maintenance Costs• Store of Value – degradation or appreciation

57 / 54

Value in Exchange

Service value in exchange is mainly related to the environmental factors.

• Liquidity - simplicity and similar value during exchange

• Transaction Costs • Service Maintenance Costs • Store of Value • Composability

58 / 54

Motivation - Scenario 1

• D1 is interested in acquiring Song-A. • D1 discovers that D2 and D3 are the devices that could potentially offer the song. • D1 contacts D2 and proposes an exchange of Song-A for a RingTone-B. • D2 responds with a rejection. D2 is not interested in ring tones. • D1 contacts D3 with same proposal. • D3 is interested in RingTone-B that D1 offers. • D3 responds with a positive reply. • D1 and D3 conduct a transaction and exchange Song-A and RingTone-B.


D4


D5


D3

D1


D2


59 / 54



D4


D5


D3

D1


D2


• D2 is interested in acquiring ScreenSaver-A. • D2 discovers that D5 is only device that has ScreenSaver-A. • D2 sends a proposal that lists a set of choices that D5 can have in exchange for ScreenSaver-A.

• Choice-A: Wallpaper-A• Choice-B: Song-A• Choice-C: RingTone-B• Choice-D: RingTone-C

• D5 sends a counter proposal. ScreenSaver-A for two ring tones, RingTone-B and C. • D2 agrees. • D2 and D5 conduct a transaction and exchange ScreenSaver-A for RingTone-B and C.

60 / 54



D4


D3

D1


D2


• D2 and device D4 are owned by two sisters (that like each other). • Both devices are aware of this relationship.

• D4 is interested in acquiring RingTone-B. • D4, by default, will prefer to barter with the sibling device even though D1 and D3 have this ring tone• D4 composes proposal requesting RingTone-B • in exchange offering either Map-A or a RingTone-A or C. • D2 is not interested in maps or ring tones. • D2 is looking for Wallpaper-B which D4 does not have. • D2, instead of sending a rejection to D4, considers the relationship and offers D4 much desired RingTone-B

with out anything in return.


D5

61 / 54


• D1 is interested in acquiring RingTone-B. D1 discovers that D2 has RingTone-B.• Unfortunately, D2 is not personally interested in RingTone-A that D1 is offering in return. • D2 identify that RingTone-A is in grate demand by other devices.• D2 looks at RingTone-A as an investment that could be later cashed out. • D2 accepts the proposal from D1 and exchanges RingTone-B for RingTone-A. • At a later time, D2 meets D3. • D2 identifies that D3 has Song-A • D2 composes a counter proposal to exchange of Song-A for RingTone-A or a RingTone-B. • D3 responds with counter proposal suggesting to exchange Song-A for the two ring tones. • D2 agrees to D3’s counter proposal.

Has: Song-AWants: RingTone-A, B

Has: RingTone-BWants: Song-A

D2D1

D3D2

Later


Has: RingTone-A, BWants: Song-A

62 / 54

Has: Song-A Title=title-A Performer= singer-A Style=pop

Wants: RingTone-* Type= polyphonic Length > 8sec

Has: RingTone-A Length= 10sec Type= monophonic Style=dance RingTone-C Length= 5sec Type= polyphonic Style=dance

Wants: Song-* Performer= singer-A


• D1 is interested in acquiring Song-B which is not available in the environment. • D2 is searching for RingTone-B which is also unavailable. • D1 and D2 could keep looking for a perfect match or could look for similar services. • D1 identifies that the most important feature of the song was a performer, Singer-A. • D2 determines that is interested in polyphonic ring tones that are longer then 8 sec. • D1 discovers that D2 has a Song-A performed by Singer-A. • D1 composes a proposal to exchange RingTone-A or RingTone-C for the Song-A. • D2 determines that nether RingTone-A or RingTone-C match all of the attributes • D2 decides to farther relax its requirements and ignore the length of the ring. • D2 accepts the proposal from D1. D1 and D2 exchange Song-A and RingTone-C.

D2D1Has: RingTone-A, CWants: Song-B

D2D1

Has: Song-AWants: RingTone-B

63 / 54

N-way Exchange

Approach A: • D1 discovers the chain/loop

composes a proposal that is forwarded to D2 and D3.

• D2 and D3 generate responses and forward them to the rest of the chain/loop.

• Once the consensus is reached devices exchange the ring tone.

Approach B: • D1 determines that there is a

demand for RingTone-C. • D1 acquires RingTone-C from

D3 as an investment for future use.

• D1 later caches out its investment and resells RingTone-C to D2.

Has: RingTone-BWants: RingTone-C


Has: RingTone-CWants: RingTone-A

D3

D2

D1

•D1, D2 and D3 in the environment. •D1 is interested in acquiring RingTone-B form D2. •D2 is interested in acquiring RingTone-C from D3. •D3 is interested in acquiring RingTone-A.

64 / 54

Allia Protocols

Request Protocol

• Requester• Check DF if the service is local• Check Local Cache if there is a hint • Multicast or Broadcast the request

• Receiver• Decide if to accept the request• Check DF if the service is local• Check Local Cache if there is a

hint

Advertisement Exchange Protocol

• Advertiser• Send advertisement

• Receiver• Decide if to accept the advertisement• Decide if to cache the advertisement• Decide if to forward the advertisement

to there nodes

65 / 54

Numi Framework

Numi Node Framework

Message Handler

Location Monitor

Numi Task Scheduler

FTP Server Agent

Logging Agent

Node Heartbeat Generator

Node Service Manager

Numi Portal Framework

Message Handler

Location Monitor

Numi Task Scheduler

FTP Server Agent

Logging Agent

Portal Heartbeat Generator

Portal Service Manager

Music Service Agent

Heartbeat Generator Agent is responsible for broadcasting device presence messages

Location Monitor Agent is responsible for identifying whether or not that device is currently in a landing zone or a transit zone

Message Handler Agent is responsible for handling the messaging needs of the framework

Logger Agent records every interaction that takes place on the local device

Task Scheduler Agent is responsible for scheduling prescribed tasks at various times

Data Handler Agent is used for transferring data volumes between MHs and between an MH and an SP

Portal Service Agents run on top of our Numi platform on SPs and offer services to a user

Node Service Agent runs within NUMI on an MH offering a service to the user

Service Manager Agent is responsible for managing service agents on a platform

66 / 54

Reward Interface

67 / 54

eNcentive

MH3

MH1

MH2

Animated Slide

68 / 54

Numi Usage Scenario

Bob

Susan

Animated Slide

69 / 54Animated Slide

MH3

MH1

MH2MH4

eNcentive Location Targeting

70 / 54