WO2013114380A1

WO2013114380A1 - Webtask personalization

Info

Publication number: WO2013114380A1
Application number: PCT/IN2012/000070
Authority: WO
Inventors: Geetha Manjunath; Thara SUBRAMONI
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2012-01-30
Filing date: 2012-01-30
Publication date: 2013-08-08

Abstract

A Web-services system (100) includes a personalized parameter database (124), a Webtask personalization handler (122), Webtask execution handler (120). Webtask personalization handler (122) is to respond to user set-Webtask requests specifying respective values for a Webtask parameter of a Webtask by storing in the personalized parameter database respective personal values in association with respective identities of respective users, the Webtask, and the Webtask parameter. The Webtask execution handler (120) is to respond to user execute-Webtask requests specifying said Webtask by: 1) retrieving respective values for respective users from said personal parameter database; and 2) managing executions of said Webtask given the respective values for said Webtask parameter.

Description

WEBTASK PERSONALIZATION [01 ] BACKGROUND

[02] Increasingly, people are accessing Web services (services made available on the World Wide Web) to accomplish a variety of tasks, including, without limitation, purchasing goods and services, making travel reservations, finding local businesses, updating news, weather, and sports information, checking and updating blogs and social media sites. In general, such tasks can be accomplished by interacting with a Web browser. So that such tasks are available "on the go", Web browsers have been made available on mobile devices, e.g., laptops, tablets, and smart phones.

[03] For frequently executed tasks requiring multiple actions, a program (e.g., a script) can be designed so that the entire task is automatically executed by calling the program, e.g., by specifying a URL (Uniform Resource Locator) associated with the program. Herein, such a program is referred to as a "Webtask" or a 'TaskLet'. Webtasks may be "common" in that they can be used by different users. Some common Webtasks may provide for "personalization" so that user preferences or characteristics can affect the execution and/or result of a Webtask.

[04] BRIEF DESCRIPTION OF THE DRAWINGS

[05] The following figures represent examples and not the invention itself.

[06] FIGURE 1 is a schematic diagram of a Webtask system in accordance with an example. [07] FIGURE 2 is a flow chart of a Webtask process in accordance with an example.

[08] FIGURE 3 is a schematic diagram of another Webtask system in accordance with an example.

[09] FIGURE 4 is a flow chart of a Webtask process implementable in the system of FIG. 3 in accordance with an example.

[10] DETAILED DESCRIPTION

[1 1 ] Generally, smart-phone users are able to personalize common Webtasks, e.g., using a browser or other application installed on the smart phone. However, users of other phones, e.g., most feature phones and basic phones, are not able to personalize common

Webtasks.

[ 2] Typically, the author of a Webtask determines which Webtask parameters are "bound", i.e., have values that cannot be controlled by a user, and which parameters are "free", i.e., have values that may be controlled by a user. Normally, values for free parameters may be specified as arguments in an "execute-Webtask" request for execution of a Webtask. Personalizing a Webtask relieves a user from the generally tedious and error-prone task of specifying the same parameter values each time the user wants to execute a Webtask.

[1 3] "Personalize" herein refers to the act of setting a Webtask parameter for a particular user so that that user does not have to specify a value for that parameter every time the user wants to execute the Webtask. When a personal value is set for a particular combination of user and Webtask, both the Webtask and the parameter whose value is set are said to be "personalized". [14] For example, a first user might personalize a common local- weather Webtask so that it returns weather for Chicago in degrees Fahrenheit (^°F) by default, while a second user might personalize the same Webtask so that returns weather for Mumbai in degrees Celsius (^°C) by default. Each user has personalized the local weather Webtask by personalizing location and temperature unit parameters, e.g., specifying user-specific locations and temperature units. Such personalization is routinely accomplished using Web browsers, but may also be

accomplished using "apps" (applications) on smart phones and tablets.

[ 1 5] While many mobile devices, e.g., smart phones, have or may have browsers installed, other mobile devices, e.g., many basic phones and feature phones, do not. While some cell-phone-service providers may permit Short-Message Service (SMS) or voice-based triggering of

Webtasks, there is no per-user control over the free parameter settings of a Webtask.

[ 1 6] A Webtask system 100, shown in FIG. 1 , includes a Webtask translator 101 that extends the ability to personalize Webtasks to non- browser-enabled devices. Translator 101 provides users 102

personalized access to Webtasks via non-Web protocols and browser- less client devices 106.

[ 1 7] Webtask translator 101 includes a processor 110,

communications devices 112, and storage media 114. Media 114 is encoded with code 116 that, when executed using processor 110, defines a Webtask execution handler 120, a Webtask personalization handler 122, and a personalized parameter database 124. Personalized parameter database 124 may be a monolithic or a distributed data structure. In the latter case, some or all personal values may be stored locally, e.g., on respective user devices 106. Such an arrangement may . provide enhanced security for personal data. [1 8] Webtask personalization handler 122 responds to set- Webtask requests to set parameter values for a particular combination of user and Webtask for use in handling future requests for execution of the Webtask. The setting is achieved by storing a personal value in association with identities of the user and Webtask for a specific parameter in personalized parameter database 124. Webtask execution handler 120 responds to execute-Webtask requests for executing a Webtask by: 1) adopting the personal values indicated by personalized parameter database 124 based on the user requesting the execution, and then handling the Webtask execution requests based on the adopted personal values.

[19] Translator 101 implements a process 200, flow-charted in FIG. 2. A set-Webtask request to set a Webtask parameter value is received at 201; the source of the set-Webtask request may be a user via a user device or a program on the user device or elsewhere. At 202, in response to this set-Webtask request, Webtask personalization service 122 sets a personal value for the Webtask parameter for the

combination of Webtask and user. At 203, an execute-Webtask request is received from the user via a respective device. At 204, in response to this execute-Webtask request, the Webtask instance is executed, e.g., by Webtask execution service 120 using the pre-set personal value for the respective Webtask parameter. Thus, Webtask system 100 and process 200 enable users to personalize Webtasks and access personalized Webtasks through simple modes such as SMS and voice from low-end phones.

[20] In an example, process 200 can be implemented by different users to set and use different personal values for the same Webtask parameters. In a scenario for a currency conversion Webtask, one user may set the "from" parameter to "USD" (U.S. Dollars) and "to" parameter to "INR" (Indian Rupees), while leaving the conversion amount (how many USD= 1 INR) as a bound parameter of the Webtask runtime. Similarly, another user may want to set the "from" parameter to "AUD" (Australian Dollars) and "to" to USD. Once a personal value has been set, a user may execute the Webtask repeatedly to get the latest results.

[21 ] Webtask parameter values can be either bound (fixed) or free (variable or context-sensitive). Fixed variables include numerical values (e.g., 1500) and text strings (e.g., Tokyo). Variable values can also include variables that assume numeric values (e.g., the current exchange rate between USD and Indian Rupees INR), and variables that assume text-string variables (e.g., current city location). Thus, a traveling user might set a Currency Webtask to convert from the local currency to the user's home currency. The local currency would be determined as a function of current location, e.g., as indicated by a GPS (Global

Positioning System) system in the user's phone, and thus would be a variable personalized parameter, while the home currency would be a fixed personalized parameter. Thus, in some implementations, process 200 allows access to Webtasks, including Webtasks that take implicit sensor (e.g., GPS) inputs or additional inputs using SMS and voice backends instead of Internet connectivity.

[22] A Web system 300 includes users 302, devices 304, a Webtask system 306, and the World Wide Web 308. Users 302, including users 302A and 302B are users of devices 304, including devices 304A and 304B. Devices 304 are network devices in that they can

communicate over networks such as wired (land-line) and cellular phone networks. Devices 304 can include Web-enabled smart phones, as well as non-web-enabled smart phones, feature phones, and basic phones. [23] Webtask system 306 enables access to Webtasks by devices using non-Web protocols and without relying on Internet connectivity; such devices include devices without Web capabilities as well as devices that provide for Web capabilities as well as non-Web capabilities. For example, some smart phones provide for non-Web SMS and voice , communications as well as browser and Wi-Fi access to the Web. In Webtask system 306, every Webtask can be considered as having a "registration" phase and "transaction phase". In the registration phase, parameters that are common across runs for a particular user can be registered; in the transaction phase, the parameters for per instance variables can be set and executed. The use of the registration phase reduces the number of parameters to be specified for each transaction execution and, hence, enables low-end phones and SMS to be used for task-execution.

[24] In a usage scenario, a user 302 issues a Webtask request via a respective device 304 to Webtask system 306. The user's cell phone number provides for user identification for authentication; additional authentication parameters, e.g., a password, may be implemented to ensure that the "right" person is using the phone. The requested Webtask may be identified in several ways, e.g., each Webtask may have its own phone number or extension, and/or the user's request may identify a Webtask, e.g., by name or URL.

[25] In addition, a user's request may specify per-request (rather than personal) values for some Webtask parameters (i.e., arguments or switches). For example, a user may text "NON-STOP-FLIGHT:

Departure, Destination; Monday" to request that a web service make a reservation for the next non-stop flight from the departure location to the destination location for next Monday; the text may be sent to a phone number dedicated to making such reservations or to a phone number associated with a more general Webtask service.

[26] Webtask system 306 includes a Webtask translator 310 and Webtask cloud services 312, the latter being used by Web-enabled devices as well as devices using translator 310. Translator 310 includes a smart SMS/voice gateway 313 to translate SMS messages and voice requests to hypertext-transfer markup language (HTML), and translating Webtask results to SMS and voice messages (to match respective requests). In addition, Webtask translator 310 includes a Webtask request parser 314, a Webtask execution handler 316, a Webtask personalization handler 318, and a personalized parameter database 320. Webtask cloud services 312 include Webtasks 322, a Webtask parameter service 324, and a Webtask execution service 326.

[27] Personalized parameter database 320 can store personal values for a particular parameters, Webtasks and users. Database 320 can also store certain run-time values of variable values of bound parameters. For example, a Webtask 322 might specify a bound variable

corresponding to the user's driver's license number. Since the driver's license number would differ from user to user, each user's driver's license number could be stored in personalization parameter database 320 in association with the user, bound parameter, and Webtask. Upon execution, a Webtask can query webtask translator for the run- time value of the variable bound Webtask parameter.

[28] After translations by gateway313, Webtask requests are parsed by Webtask request parser 314. To this end, Webtask request parser 314 parses request messages (possibly sent from a low end phone via an SMS or voice messsage to identify the users and Webtasks involved, as well as any instance-specific parameter values accompanying the request. Parser 314 queries personal parameter database 320 for any applicable personalized parameter values (i.e., specific to a logical product combination of user and Webtask). In addition, parser 314 may query Webtask parameter service 324 for Web task-specific (bound) parameter values.

[29] Once parsed and personalized (e.g., parameterized) by parser 314, an execute-Webtask request is forwarded to Webtask request handler 316, which in turn, forwards it to Webtask executing service 326 of Webtask cloud services 312. Webtask execution service executes the Webtask 322 using the parameters provided by parser 314. In executing a Webtask, Webtask execution service 326 may access various sites World-Wide Web 308, including airline reservation sites, retail sites, banking sites, media sites, news sites, etc., to gather information and perform actions.

[30] In addition execution may access the requesting device 304 (e.g., via Webtask translator 310) to evaluate variable values that reference information stored or otherwise available on the requesting device. For example, a bound value of " [LOCATION" (or "!LOCATION-CITY") may be processed by Webtask execution service 326 by querying the user's phone for the current location (as determined by a GPS sensor or wireless location services). For another example, the value "!MOBILE" is replaced during processing with the cell number of the user calling the service. [31 ] Results, e.g., information and confirmation/disconfirmation that requested acts have been performed, can then be returned from

Webtask execution service 326 to Webtask execution hander 316.

Webtask request handler 316 can then translate the results e.g., to an SMS or voice message, and forward the translations to the requesting device and user.

[32] As shown in FIG. 4, Webtask system 306 may include a processor 402 (which may include one or more hardware processing elements), communications (including network and input/ouput) devices 404, and storage media 406. Media 406 is encoded with code 408 that defines the functionality of Webtask system 306, which includes

implementation of a process 410.

[33] The web task under consideration can be either programmer developed are created by a simple user without programming by just showing browser actions for a web task. As flow-charted in FIG. 4, process 410 includes capturing user-browser actions at 411. This capturing may be of a user executing multiple instances of a task using a Web browser installed on a device which may or may not be one of devices 304 (FIG. 3). For example, the Web browser may be installed on a desktop computer operated by the user. At 412, a Webtask 322 is generated based on the captured actions. A new Webtask can also be created by the user using an explicit control to "record" web browser actions corresponding to a web task on single or multiple web sites. Also, a new Webtask can be authored directly in the language, e.g., XML eXensible Markup Language), in which the Webtask is expressed. A Webtask may be triggered, for example, by specifying an associated Uniform Resource Locator (URL). Actions 411-412 constitute a creation phase of process 410. [34] At 413, set-Webtask requests are received for the Webtask. Each set-Webtask request specifies, either explicitly or implicitly a user along with a Webtask reference, a parameter of the Webtask, and a

personalization value for the parameter. Implicit identification of the user can include using the device phone number as an implicit identity. Such a set-Webtask can be submitted by a user, possibly using a non-IP protocol, e.g., via a short text message (SMS) from the user, such as "Set for ex from USD" from a low end phone.

[35] For another example, if "ICICI Balance" is a Webtask that shows the account balance. A user can send a set-Webtask SMS of the form "icici balance set user john" and "icici balance set pwd ppp" this is done once and that user-specific information is stored on the cloud to process the task next time. The Webtask instruction set and parameter XML are modified to use the bound value !USER and !PWD and this signifies that the Webtask is to use personalized parameter during Webtask execution.

[36] The set-Webtask requests may come from different users at different times. Alternatively, a set-Webtask request may originate from a program (e.g., based in the Cloud or on the user device) based on usage data for the respective user with respect to the respective

Webtask as well as usage data for the respective user with respect to other Webtasks or profile data.

[37] At 414, in response to the set-parameter requests, the requested personal values are stored in association with the respective

user/device identities, the respective Webtask identity, and the subject parameter identity. This personalization can be stored in a portion of personalized parameter database 320 resident on respective user devices 304 or elsewhere in translator 310. Actions 413-414 constitute a "registration phase" of process 410. [38] At 415, users submit execute-Webtask requests. These requests may come at different times after a single set-parameter request.

A single user may make multiple execute Webtask requests at different times for the same Webtask. At 416, in response to the execute

Webtask requests, stored respective personal value is retrieved. At 417, the Webtask is executed using the respective personalization parameter value. At 418, results, if any, are returned to respective user/devices. Actions 415-418 constitute an execution phase of process 410.

[39] Herein, a "system" is a set of interacting non-transitory tangible elements, wherein the elements can be, by way of example and not of limitation, mechanical components, electrical elements, atoms, physical encodings of instructions, and process segments. Herein, "process" refers to a sequence or program of actions resulting in or involving a physical transformation.

[40] Herein, a "device" is hardware, the functionality of which may be hardwired, programmed, and/or programmable. Herein, a processor is a device, portion of a device, or a combination of devices designed to execute instructions (instruction-type data). Herein, "communication device" encompasses network devices, e.g., network interface cards, and input/output devices, e.g., interfaces for mice, keyboards, and displays. "Storage medium" and "storage media" refer to a system including non- transitory tangible material in or on which information is or can be encoded e.g., with data including instruction-type data, so as to be readable by a computer.

[41 ] Herein, a Webtask is a program of one or more web actions, e.g., browser actions, arranged to accomplish or return (e.g., to the user initiating the Webtask) some result. Storage media may be encoded with a Webtask that can be executed by calling the corresponding Webtask. Elsewhere, Webtasks may be referred to as "Web tasks", "Webtasks", and "Tasklets". Herein a "database" is a monolithic data structure or a distributed set of data structures for storing data elements (e.g., identities of Webtasks, users, parameters, values) in association with each other.

[42] In this specification, related art is discussed for expository purposes. Related art labeled "prior art", if any, is admitted prior art. Related art not labeled "prior art" is not admitted prior art. In the claims, "said" refers to claim elements for which there is explicit antecedent basis; "the" refers to claim elements for which antecedent basis may be implicit. The illustrated and other described

embodiments, as well as modifications thereto and variations thereupon are within the scope of the following claims.

Claims

1. A process (200) comprising:

in response to set-Webtask requests (201) to set a personalizable Webtask parameter for a Webtask to respective personal values specified in respective set-Webtask requests, personalizing said

Webtask by storing (202) said personal values in association with identities of said Webtask, said personalizable parameter, and respective users; and

in response to execute-Webtask requests (203) from users to execute said Webtask, executing (204) said Webtask using the respective stored personal values for the respective users.

2. A process as recited in Claim 1 wherein said personal values are different for different users.

3. A process as recited in Claim 1 wherein said persona values include fixed values.

4. A process as recited in Claim 1 wherein said personal values include variable values.

5. A process as recited in Claim 4 wherein said variable values are based in part of a current location of a user as indicated by a device making a respective execute-Webtask request to execute a Webtask.

6. A system as recited in Claim 1 wherein said set-Webtask request and said execute-Webtask request are made over a cellular network.

7. A system as recited in Claim 1 wherein said set-Webtask request and said execute-Webtask request are made using a Short Message Service (SMS).

8. A system as recited in Claim 1 wherein said personal value is identified based on a cell phone number used in making said execute- Webtask request.

9. A Web-services system (100) comprising storage media (114) encoded with code (116) to, when executed by a processor (110), define: a personalized parameter database (124);

a Webtask personalization handler (122) to respond to user set- Webtask requests specifying respective values for a Webtask parameter of a Webtask by personalizing said Webtask, said personalizing including storing in said personalized parameter database said respective personal values in association with respective identities of respective users, said Webtask, and said Webtask parameter; and

a Webtask execution handler (120) to respond to user execute- Webtask requests specifying said Webtask by:

retrieving respective values for respective users from said personal parameter database; and

managing executions of said Webtask given the respective values for said Webtask parameter.

10. A system as recited in Claim 9 further comprising said processor.

11. A system as recited in Claim 9 further comprising a request parser to parse set-parameter requests and execute-Webtask requests.

12. A system as recited in Claim 11 wherein said parser is further to set respective personal values for said Webtask parameter for

respective execution instances of said Webtask based on the identities of respective users issuing said execute-Webtask requests.

13. A system as recited in Claim 9 wherein said parser is to receive said set- Webtask and said execute-Webtask requests over a cellular network.

14. A system as recited in Claim 9 wherein said parser is to receive set- Webtask requests and said execute-Webtask requests conforming to an Short Message Service (SMS) protocol.

15. A system as recited in Claim 9 wherein said parser is to identify users based on their cell phone numbers, at least some of said personalized parameter database being stored on a respective user device.