personalized service discovery in ubiquitous computing environments

58 PERVASIVEcomputing Published by the IEEE CS n1536-1268/09/$25.00©2009IEEE

S e r v i c e D i S c o v e r y

Personalized Service Discovery in Ubiquitous computing environments

Kyung-Lang Park, Uram H. Yoon, and Shin-Dug KimYonsei University

Personalizing service discovery can ensure that users only receive services that fit their preferences and are appropriate to their context.

I n ubiquitous computing, many comput-ers—possibly small objects based on computer technologies—and their ser-vices are available throughout the world. People can use these services to perform

tasks in various places without being aware of the underlying computer systems. Mainstream service discovery protocols (SDPs), such as Jini,1 Service Location Protocol (SLP),2 univer-sal plug and play,3 and Bonjour (www.apple.com/macosx/features/bonjour), provide enough functionality for mobile ad hoc networks. How-ever, in a ubiquitous computing environment, SDPs must find the most appropriate services. Handheld devices have limited resources and user interfaces, so users shouldn’t be presented

with a long list of discovery results. Moreover, SDPs must find useful services automati-cally because users might not be aware of the available ser-vices.

To find the most appropriate services, SDPs should exploit context.4,5 The most appropriate service isn’t always the nearest or the highest qual-ity. Rather, it varies according to the user’s pref-erences. More importantly, user criteria change with their context. A user might generally prefer to use the most popular services, but in a par-ticular case, might want to use only high-quality services. Service discovery protocols should also be able to locate services beyond the local do-main.6 A ubiquitous computing environment has many types of services, and not all are location

specific (for example, media streaming and sen-sor services). In addition, users move from place to place and their interests aren’t constrained by a fixed boundary. Likewise, we shouldn’t confine the service discovery to a fixed location.

We developed a service discovery framework based on virtual personal space (VPS)—a vir-tual administrative domain of services man-aged for the user. The framework exploits user context and extends the search for services to the global domain. By personalizing discovery, it lets users find the most appropriate services for their immediate situation.

extending Service Discovery ProtocolsThe following scenario highlights the chal-lenges of service discovery in a ubiquitous com-puting environment.

Tommy attends a conference to present his paper. He’s unfamiliar with the facility holding the conference. Fortunately, he can view a list of conference-related services in his PDA’s service discovery browser. He uses a service to register as a presenter and make his presentation slides public. Tommy also finds a multimedia service that introduces the conference through a video delivered to his PDA. After a while, his PDA’s discovery service finds a shared high-quality display in the lounge. He moves to the lounge and watches the content on this display. While there, Dana,

S e r v i c e D i S c o v e r y

January–march2008 PERVASIVEcomputing 59

a student who discovered his presentation service, approaches to inquire about his research.

During Tommy’s presentation, an audience member comments on a part of his work. Tommy wants to show this person supplemental material. He looks for a printer service to print out a related report. A printer service in the same room is displayed at the top of the result. He gives the audience member documents printed by the service. Dana also looks for a printer service to print out a document to show the audience member. She discovers a printer in the next room, which has no job pending, first. After the presentation, Tommy and Dana meet to discuss their research. Tommy looks for a printer service to print a document for Dana. This time, the service discovers a color laser printer service in the lounge first because Tommy generally prefers the most widely used printer.

In the first part of this scenario, the discovery service browser found use-ful services for Tommy automatically even though he was unaware of their existence. The services weren’t just close to Tommy, but were related to his context. In the second part of the scenario, Tommy and Dana’s service browsers used contextual information and applied different criteria to find the most appropriate service according to their preferences and context.

Conventional SDPs are mainly loca-tion oriented (see the “Related Work on Service Discovery in Ubiquitous Computing Environments” sidebar). A directory manages services in the same local network or services are federated within a local network. On top of this directory, the protocols define query propagation or directory brokers to lo-cate services in the wide area network.

Figure 1a is a conceptual diagram of conventional service discovery. A ser-vice discovery starts from the user’s own services and moves to the local domain. If it fails to find an appropriate service

in the local domain, it propagates dis-covery queries to other appropriate di-rectories. In this infrastructure, aggre-gating a sufficient number of services from several directories to find the most appropriate one takes a long time. In addition, you can’t attach user contexts to queries because user contexts might include private user information.

As Figure 1b shows, our personalized service discovery method aggregates ser-vices that are contextually close to the user in the VPS in advance, instead of attaching user contexts to a discovery query or generating unrealistic queries to find appropriate services. Personaliza-tion is the process of bringing services from the global domain to the VPS. In humans, it’s similar to trying to distin-guish things that you’ll use in the near future from among everything you see.

In our framework, a discovery query first looks up the VPS. So, having an appropriate set of services in this space will greatly help users discover appro-priate services quickly. Explicitly spec-ifying the personalization produces

Localinformation

MP3streaming

(b)

Discovery priorityPersonalization

Userservices

Virtualpersonal space

Global domain

Localinformation

MP3streaming

(a)

Discovery priority

Userservices

Proximity serviesLocal domain

Global domain

Figure 1. Comparison of conventional and personalized service discovery. (a) A conventional service discovery protocol looks first at local services and then extends to the wide area network, without accounting for user context. (b) Service discovery based on the virtual personal space looks at services that are close to the user contextually more so than physically.

60 PERVASIVEcomputing www.computer.org/pervasive

Service DiScovery

the most accurate results. However, in ubiquitous computing, where many services exist, managing the VPS ex-plicitly using a limited user interface might be impractical. We therefore de-veloped an intelligent module to per-form personalization on users’ behalf. This module manages the VPS accord-ing to user context and preference.

Personalized Service Discovery FrameworkFigure 2 shows our framework’s three main components: services, directories, and personal operating middleware (POM).

Services automatically discover an appropriate directory to which to send their advertisements. Directories index and cache these service advertisements. The basic operations of these services and directories are the same as in SLP,

but our framework defines two addi-tional functions. First, directories can propagate queries to adjacent directo-ries if they don’t have appropriate ser-vices for the queries. Second, service advertisements carry services’ contex-tual attributes:

class is the service’s name and category;location is a 2D coordinate repre-senting a user’s or service’s physical position;popularity is the number of users that include the service in their VPS; quality is a discrete value between 0 and 1 that represents the service’s general quality specified by the ser-vice owner;service load is the capacity in use di-vided by the service’s maximum ca-pacity; and

•

•

•

•

•

required services are the services that the user might need to invoke while the service is operating.

The POM provides two func-tions to help users discover appropri-ate services: service recognition and personalization.

Service recognition collects service information using the service crawler. When a user moves into a new place, the service crawler automatically finds available directories and retrieves ser-vice advertisements. Services recog-nized by the service crawler are simply those services that are near the user. The POM must then select services that suit the user’s context and prefer-ence. The crawler transmits collected information to the personal space manager (PSM), which personalizes each service. If the PSM decides that a

•

M anyarticlesdealingwithservicediscoveryforubiqui-touscomputingproposeusingcontext.however,many

ofthemconsideronlyalocaldomainorgivelocationtoohighofapriority.1–4Theythereforefailtofindthemostappropriateserviceswhenthoseservicesaren’tclosetotheuser.

Inaddition,someofthearticlesdon’taddresshowtoselectthemostappropriateservicefromavailableservices.Theyin-troducesophisticatedqueriescontainingcontextualattributestofindthebestservice,butdon’tdiscusshowtogeneratethembasedonuserpreferenceorcontext.5Ifusersmustexplicitlyspecifyqueries’contextualattributes,servicediscoveryisn’tcontextaware.

Littleofthepriorworkhasconsideredhowtheselectionprocedurecanchangeaccordingtousersandtheircontext.Therefore,theselectionalgorithmscanmakeerrorsinvarioussituations.6–8Finally,fewresearchersconsiderservicediscoveryperformanceinpracticalsettingswhenapplyingtheircontext-awarediscoverymethods.5–7

RefeRences

1. F.Zhu,m.mutka,andL.ni,“Splendor:aSecure,Private,andLoca-tion-awareServiceDiscoveryProtocolSupportingmobileServices,”

Proc. 1st IEEE Ann. Conf. Pervasive Computing and Comm.,IEEEcSPress,2003,pp.235–242.

2. h.chen,a.Joshi,andT.Finin,“DynamicServiceDiscoveryformo-bilecomputing:IntelligentagentsmeetJiniintheaether,”Baltzer Science J. Cluster Computing,vol.4,no.4,mar.2001,pp.343–354.

3. m.coen,“DesignPrinciplesforIntelligentEnvironment,”Proc. Nat’l Conf. Artificial Intelligence,amer.assoc.forartificialIntelligence,1998,pp.547–554.

4. S.chetanetal.,“amiddlewareforEnablingPersonalubiquitousSpaces,”Proc. System Support for Ubiquitous Computing (ubisys),Springer,2004,pp.41–50.

5. a.Fridayetal.,“SupportingServiceDiscovery,QueryingandInter-actioninubiquitouscomputingEnvironments,”Wireless Networks,vol.10,no.6,2004,pp.631–641.

6. a.-r.El-sayed,“Semantic-Basedcontext-awareServiceDiscoveryinPervasive-computingEnvironments,”master’sthesis,Dept.ofcomputerScience,univ.ofWaterloo,2006.

7. S.cuddy,m.Katchabaw,andh.Lutfiyya,“context-awareServiceSelectionBasedonDynamicandStaticServiceattributes,”Proc. IEEE Int’l Conf. Wireless and Mobile Computing, Networking, and Comm. (Wimob),IEEEPress,2005,pp.13–20.

8. S.E.czerwinskietal.,“anarchitectureforaSecureServiceDiscov-eryService,”Proc. 5th Ann. Int’l Conf. Mobile Computing and Net-works(mobicom99),acmPress,1999.pp.24–35.

related Work on Service Discovery in Ubiquitous computing environments


service is contextually close to the user, it includes the service in the VPS until the PSM drops it. Because personaliza-tion varies by user, we can’t use a fixed set of rules or a static function. We de-veloped an adaptive inference module based on the adaptive-network-based fuzzy inference system.7 ANFIS com-bines a fuzzy rule-based inference sys-tem and a neural network’s learning capability.7 So, the ANFIS module works on a set of fuzzy rules, but it can also learn. It can therefore imple-ment a user’s own personalization function.

Figure 3a shows the service activa-tor, which provides a service discovery interface. When the user inputs a ser-vice discovery query, the service activa-tor first searches the VPS. If it fails to find any appropriate services, it sends the query to a local service directory. The list box shows discovery results, ordered by the query-response arrival time. As mentioned earlier, the VPS already maintains an appropriate set of services for the user. Thus, the ser-vice activator will find most of the re-quested services there.

The service activator also provides an interface for managing services in the VPS. Figure 3b shows Viewform, which displays services as rectangu-lar icons with geometric locations and other users as circles. Users can in-voke services and view explanations of services or latest events by clicking the icons. The second panel lists user services, and the third lists services that are located in different places. In addition, the service activator interface includes a list view of ser-vices in the VPS (Figure 3c).

Our framework offers two supple-mentary components. The location

resolver obtains the user’s location via a positioning module such as GPS and provides it to other components in the POM. The neighbor manager main-tains a list of other users. A directory maintains POM handles accessing the directory. Thus, a POM can discover

another POM via directories. The neighbor manager provides an inter-face to discover other users. When the POM discovers a user, it adds the user to the list of neighbors in the neighbor manager. Then, the service crawler can access the user’s VPS.

Personal operating middleware (POM)

Service activator

Personal space manager (PSM)

Servicevector

Virtual personal space

Contextual distance

Feedback

Localresolver

Neighbormanager

Personalizationprocessor

Personalizedinference

engine(PIE)

Services

Service crawler

Softstates

POMinformation

Otherusers

Advertisements

OtherdirectoriesService

directoryCache

Service information

Serviceinformation

User servicesUser servicesUser services

Figure 2. System architecture for personalized service discovery. The personalized operating middleware component provides service recognition and personalization to help users find appropriate services.

(b) (c)(a)

Figure 3. Service activator user interface. (a) The service discovery interface shows results for a query listed by response times. (b) Users can manage services in their virtual personal spaces using a Viewform, which represents services and users as icons. (c) Users can also view available services in their VPS through the service activator interface.


Service DiScovery

Managing virtual Personal SpaceThe PSM manages the VPS using AN-FIS modules. First, it puts user context and information about a service into the personalization processor. (Here, we define user context as the user’s lo-cation and a list of services being acti-vated in the VPS.) The personalization processor then generates a service vec-tor describing the service using numeric parameters. It uses service vectors to determine service quality and value.

Service vector attributes include lo-cation, distance, necessity, popularity, quality, service load, and user rate. The PSM obtains some parameters (popu-larity, quality, service load) directly from the service advertisement and cal-culates others using service information and user context.

Distance refers to the distance be-tween the user and service locations. Our framework represents the user’s lo-cation as a polygon. Vertices represent the user’s current location as well as the locations of services being activated for the user as the user moves near the ser-vice being activated. To determine the distance parameter, we measure the distance between the polygon and the location of the service being considered. Necessity is the probability that another service in the VPS uses this service. We obtain this parameter by counting the number of services in the VPS that re-quire the service. If some services in the

VPS are in the same class, we divide this by the number of services of the same class. Use rate represents how often the user employs this class of services. It’s the number of service invocations of this class divided by the total number of service invocations.

After generating a service vector, the personalization processor sends it to the personal inference engine (PIE). The inference module then produces a value denoting the contextual distance, which describes the service’s contextual proximity to the user. We used the AN-FIS approach to implement the PIE. The PIE has a set of fuzzy rules, as Table 1 shows, and makes a decision by apply-ing these rules on a service vector.

We generated 100 rule sets based on our common knowledge of ser-vice usage and chose the best set by experimentally comparing them. We obtained all results in this article us-ing this rule set. After we put a service vector into the PIE, the PIE fuzzifies the service vector parameters, applies them to all the rules, and defuzzifies the result to output a value between 0 and 1. To calculate the output, we use the Takagi and Sugeno method. The PIE returns the output value to the personalization processor. If the value is greater than the user-defined threshold value, the personalization processor includes the service in the VPS and starts managing it.

However, these fuzzy rules alone can’t

satisfy all users because users have dif-ferent preferences and criteria. We there-fore added a learning capability to the PIE (as in ANFIS) to reflect user pref-erences. After personalization, the per-sonalization processor maintains a table that lists services that are considered for personalization and checks whether the decision is correct. After the personal-ization processor determines whether a decision is correct, it sends feedback to the PIE. It sends immediate feedback when the user employs a service. If the service is already included in the VPS, it sends positive feedback; if the ser-vice isn’t included in the VPS, it sends negative feedback. The personalization processor sends periodic feedback at predefined intervals about unused ser-vices. If an unused service is included in the VPS, it sends negative feedback to the PIE. If the service isn’t included in the VPS and the user hasn’t requested the service until that moment, the per-sonalization processor sends positive feedback. Given our experimental envi-ronments, periodic feedback is required every three hours if the user employs five to 10 services per hour.

As the PIE processes this feedback, it adapts to the user’s patterns so it can produce personalized results. The learning in the PIE affects each fuzzy variable’s membership function.7 Rules in the PIE use fuzzy variables such as “close” and “far.” The range of fuzzy variables depends on the user. For ex-

TABLE 1 Fuzzy-variable-based rules in the personal inference engine (PIE).

Input service vector Output

Distance necessity Popularity Quality service load Use rate contextual distance

close high middle high Low middle Veryclose

Far Low middle Low high middle Veryfar

middle high middle middle middle high close

middle middle Low Low high middle Far

middle high high middle middle middle close

Far Low high high middle middle Far

middle high middle high Low high close

close Low middle Low middle Low Far


ample, one user might regard a distance of 70 as far, whereas another regards it as close. Assume that a user regards a distance of 30 as close, so the user’s personal space includes a service at that distance after the personalization. If the service goes unused, the PIE re-ceives negative feedback from the per-sonalization processor. Then, the PIE adjusts the distance variable’s member-ship function for the user to correct the error. Figure 4 illustrates membership function adjustment. The PIE can learn these fuzzy meanings as it repeatedly performs personalization and receives feedback results. Thus, a PIE starts with a set of general rules defined by system developers, but it gradually re-flects the user’s personal preferences.

The PSM can maintain multiple PIEs because the personalization can change according to the user context. The PSM starts with only one PIE, but it creates another PIE if the ANFIS makes many errors. The PSM names each PIE based on the user context (that is, the location and services in the VPS). Before per-forming the personalization, the PSM chooses the proper PIE by matching the user’s current context and the PIEs’ names. Consequently, each PIE learns the user’s preferences in each context and reflects these learning results in the fuzzy rules, letting the POM manage a personalized set of services accord-

ing to the user’s context. Based on our simulation results, a PIE can learn the user’s preferences in two days if the user tries to discover five services per hour and the PIE performs a periodic learn-ing phase every three hours. However, the learning rate depends on how of-ten the user discovers services. If the user discovers services more often, the learning can be accomplished faster.

evaluationWe implemented a prototype service discovery system for evaluation. We implemented services and directories on the top of Java SLP. We deployed one directory in each of 16 computers to represent a local domain. We repre-sent a location in a domain with 100 × 100 2D coordinates. We defined 10 types of services and made 10 services of each type. All services have different attributes, which we randomly gener-ated, deploying between eight and 10 services in each domain. We developed the POM using Java and SLP to inter-act with directories. We deployed five POMs in different computers. If a POM is deployed in a computer, the user cor-responding to the POM is located at the location corresponding to the computer. A user agent implemented on each POM emulates the user’s actions. It generates discovery queries and moves the POM to other computers randomly. When

a POM moves to another computer, it connects to a new directory in the com-puter. Each user agent has a service pref-erence table. By using the table, the user agent can decide if a discovered service is appropriate for the user. To eliminate the gap between the prototype and the real system, each component introduces a delay before transmitting a message to another component.

On this prototype system, we first compared the proposed method to the simple SLP model. The SLP model doesn’t manage any set of services in the POM, so it sends queries to the connected directory as soon as the user agent generates a discovery query. Our first metric is time to discover an appropriate service. If a discovered service doesn’t suit the requirement specified by the user agent, we drop it. We performed this simulation for an hour and checked the average service discovery times every five minutes. Figure 5a shows how the average ser-vice discovery time changed. At first, the proposed method (denoted as PSD) was slightly faster than the simple SLP. But, by the end of the simulation the average service discovery time was one second faster than the simple SLP. If we assume larger environments and poor network conditions, the differ-ence can be larger because of the ap-proach’s caching effect.

(b)(a)–0.2

0

0.2

0.4

0.6

0.8

1.0

1.2

–0.2

0

0.2

0.4

0.6

0.8

1.0

1.2

0 10 20 30 40 50 60 70 80 90 1000 10 20 30 40 50 60 70 80 90 100

Close

Middle

Far

Close

Middle

Far

Distance Distance

Figure 4. Adjusting membership functions. Learning in the personal inference engine (PIE) affects each variable’s membership function. For example, (a) before learning, the fuzzy variable for a particular service might be “close,” but (b) after learning how the user employs the service, the PIE adjusts the variable to “far.”


Service DiScovery

As the POM learns the user agent’s usage patterns and preferences in several situations, it refines the set of services in the VPS. Thus, service discovery more often finds an appro-priate service in the VPS, further re-ducing the service discovery time. In our simulation, learning the user agent’s preferences took roughly 20 minutes. However, in the current IT infrastructure, users don’t try to dis-

cover services as frequently as in our simulation. Assuming that a user tries to discover five services per hour, our one-hour simulation is equivalent to 200 hours in the real world. We can therefore estimate that periodic learn-ing occurs every three hours and the user agent will achieve an equivalent level of learning in 60 hours if it con-tinuously interacts with the system.

We also measured the discovery fail-

ure ratio. We varied the time-out period for each query from 0.3 to 2 seconds. If a query doesn’t discover an appropriate service within the time-out period, we consider it a failure. The failure ratio is the number of failures divided by the number of discovery queries. As Figures 5b and 5c show, the PSD had a much lower failure ratio than the simple SLP. We also limited the display size to show query results. If we set the limit to 1,

(a)

(b) (c)

(e)

Failu

re ra

tio (%

)

0 5 10 15 20 25 30 35 40 45 50 55

Aver

age

disc

over

y tim

e (s

econ

ds)

Experiment time elapsed (minutes)

0.3 0.5 0.7 1 1.5 2Discovery timeouts

Proposed method

Service Level Protocol

0

0.2

0.4

0.6

0.8

1.0

1.4

1.8

1.6

1.2

Seco

nds

0

0.2

0.4

0.6

0.8

1.0

1.2

Proposed methodService Location Protocol

Proposed methodService Location Protocol

1009080706050403020100

Failu

re ra

tio (%

)

1 2 3 4 5Result limit (number of items displayed)

PSD Location Quality LRU Rules

Space management models

1009080706050403020100

Average discovery time

(d) Space management models

Hit ratio Utilization

PSD Location Quality LRU Rules

Perc

enta

ge (%

)

1009080706050403020100

Figure 5. Experimental results. The graphs show (a) average discovery time (the proposed method, or PSD, versus SLP); failure ratio according to (b) timeout and (c) display limit; and a comparison of our method to other personal space management models showing (d) hit ratio and service utilization and (e) average discovery time.


the POM can display only a result that was first discovered. When we set it to 3, the PSD shows only an 11-percent failure ratio, but the simple SLP shows a more than 30-percent failure ratio. These results demonstrate that manag-ing the VPS can reduce the time to find appropriate services.

We also compared the PSD to other possible management models. The lo-cation model manages services that are close to the user in the VPS. The quality model considers only services’ quality attributes. This model’s PSM includes services with higher qualities than a given value. The least recently used (LRU) model manages services that the user has recently used. When a user finds an appropriate service, the PSM includes it in the VPS. When the space is full, the PSM replaces the least recently used service with the new ser-vice. The rule-based model has a set of rules in the PSM, similar to those in Table 1. This model manages services that satisfy the rules. We limited the VPS’s size to 20 in every model. We performed a simulation for an hour for each model and analyzed the results. Figure 5d compares the hit ratio. In the PSD model, 70 percent of the discovery queries found an appropriate service in the VPS, but other models had only 30- to 50-percent hit ratios. The aver-age service discovery time was affected, as Figure 5e shows. Our average ser-vice discovery time is 300 percent faster than the location model and about 150 percent faster than other models.

Finally, Figure 5d shows the utilization of services in the VPS. Low utilization means that the POM wastes resources by managing useless services. Con-versely, high utilization suggests that the user would find only a few services listed in the VPS irrelevant. We determine uti-lization by dividing the number of ser-vices found by any discovery query by the number of services in the VPS. In the PSD model, queries discover 59 percent of services. In the quality model, queries discover only 30 percent of services, and the rule-based model discovers 40 per-

cent of services. The difference between management models demonstrates the effectiveness of the proposed personal-ization method using PIEs.

S o far, we haven’t had the re-sources to conduct real-world usage studies to confirm our simulation results outside the

laboratory. We hope to conduct such studies in the future as a means to in-crease our simulation’s accuracy and to obtain feedback on how we could ad-just the system to work better for real-world users. We’re currently construct-ing a realistic testbed and developing a discovery widget (that is, a practical POM) for smart phones in cooperation with a commercial vendor. Our goal is to begin helping mobile phone users find appropriate services according to their preferences and contexts in the near future.

ACknowLEDgmEnTSWethankcharlesWeemsattheuniversityofmassachusettsforhisfeedbackandguidanceinrevisingthearticle.

REFEREnCES 1. Sun Microsystems, “Jini Architecture

Specification,” 1999.

2. J. Veizades et al., “Service Location Proto-col,” IETF RFC 2165, 1997; www.javvin.com/protocol/rfc2165.pdf.

3. Understanding Universal Plug and Play, white paper, Microsoft Corp., 2000; www.upnp.org.

4. A.K. Dey, “A Conceptual Framework and a Toolkit for Supporting the Rapid Proto-typing of Context-Aware Applications,” Human-Computer Interaction, vol. 16, 2001, pp. 97–166.

5. D. Fournier et al., “Towards Ad Hoc Con-textual Services for Pervasive Comput-ing,” Proc. 1st Workshop Middleware for Service-Oriented Computing (MW4SOC 06), ACM Press. 2006, pp. 36–41.

6. J. Rosenberg, H. Schulzrinne, and B. Suter, “Wide Area Network Service Loca-tion (WASVR),” 1997; www.jdrosen.net/papers/gwloc_slides.ps.

7. J.R. Jang, “ANFIS: Adaptive-Network-Based Fuzzy Inference System,” IEEE Trans. Systems, Man, and Cybernetics, vol. 23, no. 3, 1993, pp. 665–685.

Formoreinformationonthisoranyothercom-putingtopic,pleasevisitourDigitalLibraryatwww.computer.org/csdl.

theAUThoRSKyung-Lang Park isaseniorresearchengineerinthemobileandcommunica-tionDivisionatLGElectronics.hisresearchinterestsincludeubiquitouscom-puting,locationandcontextprocessing,andnext-generationmobilehandsetdevelopment.hehasaPhDincomputersciencefromyonseiuniversity,Seoul,Korea.heisamemberoftheIEEEcomputerSociety.contacthimatlanx@yonsei.ac.kr.

Uram H. Yoon isaresearchengineerinthemobileandcommunicationDivi-sionatLGElectronics.hisresearchinterestsincludeubiquitouscomputing,gridcomputing,P2Parchitecture,andcontext-awarecomputing.hehasanmSincomputersciencefromyonseiuniversity,Seoul,[email protected].

shin-Dug Kim isaprofessorofcomputerscienceatyonseiuniversity,Seoul,Korea.hisresearchinterestsincludeadvancedcomputerarchitectures,mediaprocessingsystems,intelligentmemorysystemdesign,andubiquitouscom-putingplatforms.hehasaPhDinelectricalandcomputerengineeringfromPurdueuniversity.heisamemberoftheIEEEcomputerSociety.contacthimatsdkim@yonsei.ac.kr.

personalized service discovery in ubiquitous computing environments

Documents