(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2006/0225076 A1
`Longobardi
`(43) Pub. Date:
`Oct. 5, 2006
`
`US 20060225076A1
`
`(54) LOCATION-AWARE PERSONAL
`SCHEDULER
`
`(76) Inventor: Roberto Longobardi, Rome (IT)
`Correspondence Address:
`IBM CORPORATION
`INTELLECTUAL PROPERTY LAW
`114OO BURNET ROAD
`AUSTIN, TX 78758 (US)
`Appl. No.:
`
`11/375,467
`
`(21)
`(22)
`(30)
`
`Filed:
`
`Mar. 14, 2006
`Foreign Application Priority Data
`
`Mar. 29, 2005
`
`(EP)........................................ O51024594
`
`Publication Classification
`
`(51) Int. Cl.
`(2006.01)
`G06F 9/46
`(52) U.S. Cl. .............................................................. 71.8/102
`
`ABSTRACT
`(57)
`A personal scheduler (103) is proposed. The scheduler is
`used to define tasks (210), each one consisting of an activity
`to be performed by a defined deadline at a specific location,
`and appointments (215), each one consisting of an activity
`to be performed at a precise time at a specific location. The
`scheduler warns (265,285) the user whenever S/he passes
`(245) close to the location of each task. Moreover, at the
`morning (270) the scheduler reminds (265,285) all the tasks
`that might be performed during the day, according to an
`expected traveling path of the user (275) based on the
`appointments to be attended.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Personal
`directory
`
`interval
`
`Traveling
`path
`
`Threshold
`value
`
`
`
`
`
`Probability,
`density index
`
`60
`
`Spead
`
`Google, Exhibit 1013
`IPR2022-00742
`Page 1 of 17
`
`

`

`Patent Application Publication Oct. 5, 2006 Sheet 1 of 8
`
`US 2006/0225076 A1
`
`
`
`s
`
`i
`
`r
`CN
`w
`
`Google, Exhibit 1013
`IPR2022-00742
`Page 2 of 17
`
`

`

`Patent Application Publication Oct. 5, 2006 Sheet 2 of 8
`
`US 2006/0225076 A1
`
`200
`
`215
`S-1-
`
`C C Scheduler
`r X
`
`225
`
`205
`
`CD 240 -
`
`Personal
`directory
`
`Downloader
`
`210
`
`Central O
`
`directory
`
`C Locations
`==b Estimator
`
`Einar
`
`s
`
`
`
`Threshold
`value
`
`235
`
`Probability,
`density index
`
`Time
`
`interval
`
`
`
`Traveling
`
`60
`
`Spead
`
`275
`
`Controller
`
`Activator =
`
`270
`
`Position
`
`245
`
`GPS
`
`Google, Exhibit 1013
`IPR2022-00742
`Page 3 of 17
`
`

`

`Patent Application Publication Oct. 5, 2006 Sheet 3 of 8
`
`US 2006/0225076 A1
`
`/ 300
`
`303
`
`306
`
`New
`
`312 \
`
`Activity
`
`Appointment/Journey
`
`
`
`321
`Entity
`
`Location(C)
`
`
`
`Single
`
`327
`Category
`
`
`
`
`
`
`
`381 8
`
`3
`24
`
`Personal
`directory
`
`Central
`directory
`
`378
`
`
`
`
`
`
`
`Prerequisites
`
`342
`
`Update
`
`339
`
`FIG.3a
`
`Google, Exhibit 1013
`IPR2022-00742
`Page 4 of 17
`
`

`

`Patent Application Publication Oct. 5, 2006 Sheet 4 of 8
`
`US 2006/0225076 A1
`
`
`
`345
`
`Automatic
`
`Time-out
`
`FIG.3b
`
`Google, Exhibit 1013
`IPR2022-00742
`Page 5 of 17
`
`

`

`Patent Application Publication Oct. 5, 2006 Sheet 5 of 8
`
`US 2006/0225076 A1
`
`/ 400
`
`406
`
`N
`
`N
`
`Y
`
`41 6
`
`Location(s)
`
`424
`
`426
`
`Output
`
`FIG.4a
`
`Google, Exhibit 1013
`IPR2022-00742
`Page 6 of 17
`
`

`

`Patent Application Publication Oct. 5, 2006 Sheet 6 of 8
`
`US 2006/0225076 A1
`
`
`
`Operation
`
`444
`
`Snooze
`
`to-ri, Delay
`
`448
`
`450
`
`452
`
`Return
`
`454
`
`Go on
`
`FIG.4b.
`
`Google, Exhibit 1013
`IPR2022-00742
`Page 7 of 17
`
`

`

`Patent Application Publication Oct. 5, 2006 Sheet 7 of 8
`
`US 2006/0225076 A1
`
`455
`
`456
`
`
`
`458
`
`460
`
`
`
`462
`
`466
`
`
`
`
`
`Threshold
`
`FIG.4C
`
`Google, Exhibit 1013
`IPR2022-00742
`Page 8 of 17
`
`

`

`Patent Application Publication Oct. 5, 2006 Sheet 8 of 8
`
`US 2006/0225076 A1
`
`
`
`'t
`V
`V
`
`515h.
`
`a
`
`1
`
`N.
`
`Y
`Tha
`S
`
`505a
`
`11
`N-510a
`
`Y
`
`m
`
`V
`y
`M
`
`N-
`as
`
`N
`Y
`
`/
`N / f
`W
`1
`
`530
`
`505b
`1
`
`?
`
`51Ob v1.
`Thb
`
`S.
`1
`
`- 's
`
`-
`
`a
`
`1
`
`w
`y
`
`f
`
`1
`103
`
`505C
`
`- - - - a.
`
`m
`
`7
`
`FIG.5b.
`
`Google, Exhibit 1013
`IPR2022-00742
`Page 9 of 17
`
`

`

`US 2006/0225076 A1
`
`Oct. 5, 2006
`
`LOCATION-AWARE PERSONAL SCHEDULER
`
`TECHNICAL FIELD
`0001. The present invention relates to the data processing
`field. More specifically, the present invention relates to a
`Solution based on a mobile data processing device for aiding
`a user to organize tasks.
`
`BACKGROUND ART
`0002. Several mobile data processing devices have been
`proposed in the last years for aiding a user to perform a
`number of activities. For example, so-called organizers have
`become very popular for specific applications; typically,
`these devices are used as a phone book, a calendar, an alarm
`clock, a scheduler, and the like.
`0003 Considering in particular the scheduler, the orga
`nizer is very useful for managing a personal agenda of a
`corresponding user. For this purpose, the scheduler allows
`the user to define different types of activities to be per
`formed. Typical examples are tasks without specific time
`constraints (i.e., which may be executed at any time, gen
`erally within a defined deadline); generally, the tasks are
`location-dependent, that is, they must be performed at
`specific locations (such as an office, a shop, and the like).
`0004 Most of the schedulers known in the art provide
`different functions for remembering the tasks to be per
`formed to the user. Typically, the scheduler warns the user
`when the deadline of each task is approaching (for example,
`Some days before); moreover, the scheduler continues
`remembering the task periodically (for example, every 1-2
`hours) until it has been completed.
`0005. However, the available solutions are not com
`pletely satisfactory. Indeed, the user generally forgets the
`tasks to be performed until the corresponding deadlines are
`very close (when the organizer remembers them). Moreover,
`it might now be difficult (if not impossible) to perform some
`task; a typical example is when the user is far away from the
`corresponding location, or when the task is remembered
`during a holiday period. Moreover, the user can be very busy
`at the moment. A worst situation arises if the user is away
`(for example, for a trip) and S/he is then unable to perform
`the task by its deadline.
`0006 All of the above is even more frustrating if the user
`had passed several times close to locations where the tasks
`were to be performed in the preceding days (without real
`izing that S/he could have done the tasks at that moment).
`0007 Another problem arises when the tasks require
`Some prerequisites for their execution (such as carrying a
`document, having specific information available, and the
`like). In this case, even if the user had remembered the tasks
`when around their locations it would have been very unlike
`that S/he had all the required documents or information.
`0008. The above-described drawbacks cause a substantial
`waste of time for the user. Moreover, in some cases they can
`even result in the missing of Some tasks (with the corre
`sponding negative consequences).
`
`SUMMARY OF THE INVENTION
`0009. According to the present invention, the idea of
`organizing tasks according to the position of the user is
`Suggested.
`
`0010 Particularly, an aspect of the invention provides a
`method for aiding a user to organize tasks; each task is
`suitable to be performed by the user at a predefined set of
`(one or more) locations. The user is associated with a mobile
`device (for example, an organizer). The method includes the
`step of monitoring the position of the device. The user is
`then warned when the position of the device approaches one
`or more locations.
`0011. The proposed solution remembers the tasks to the
`user whenever they can be actually performed. This avoids
`forgetting the tasks until their deadlines are approaching. As
`a result, the risk of having difficulties in performing the tasks
`(for example, because of a holiday period, a busy condition,
`or a trip) is strongly reduced (if not avoided at all).
`0012 More specifically, in this way the tasks are remem
`bered to the user exactly when S/he is passing close to their
`locations. Therefore, the tasks can be generally performed
`easily when it is more convenient.
`0013 All of the above results in a substantial saving of
`time. Even more important, the devised solution strongly
`reduces the risk of missing some tasks (with the correspond
`ing negative consequences).
`0014. In a preferred embodiment of the invention, the
`location of some tasks is defined by selecting an entity (Such
`as a shop or a person), which is then resolved into the
`corresponding location.
`0015 This feature facilitates the specification of the
`tasks.
`In addition or in alternative, some tasks are asso
`0016.
`ciated with a category of entities (such as pharmacies or
`plumbers), which is then resolved into one or more locations
`of the corresponding entities.
`0017. The proposed solution adds further flexibility to the
`specification of the tasks.
`0018) A preferred implementation of the invention is
`based on the comparison of a distance (of the locations of the
`tasks from the position of the device) with a threshold value.
`0019. This algorithm is very simple but at the same time
`effective.
`0020. A way to further improve the solution is to set the
`threshold value for each location according to a probability
`of passing in an area around it (which probability is esti
`mated from a set of preceding positions of the device).
`0021. As a result, it is possible to define the threshold
`value automatically (taking into account how often the user
`passes close to the location).
`0022. As an additional enhancement, the threshold value
`is also set according to a density of the entities of the
`corresponding category.
`0023 This feature further improves the accuracy of the
`defined threshold value (taking into account how many
`entities are available for performing the corresponding task).
`0024. In a more sophisticated implementation, each
`threshold value is updated according to a movement speed
`of the device (estimated from a further set of preceding
`positions thereof).
`
`Google, Exhibit 1013
`IPR2022-00742
`Page 10 of 17
`
`

`

`US 2006/0225076 A1
`
`Oct. 5, 2006
`
`0025. In this way, the solution self-adapts to the actual
`condition of the user (for example, taking into account
`whether s/he is moving on foot or by car).
`0026.
`In a different embodiment of the invention,
`appointments (associated with a corresponding time and
`with one or more locations) are defined; eligible tasks are
`then selected (and notified to the user) according to their
`distance from an expected traveling path of the user, which
`path is determined from the locations of the appointments to
`be attended in a selected time interval (for example, today).
`0027. This solution is very useful for planning the tasks
`to be performed by the user.
`0028 Particularly, the user can also define her/his jour
`neys (each one including one or more appointments to be
`attended in a selected period); in this case, the time interval
`is set to the period of an approaching journey.
`0029. As a result, the user can advantageously organize
`the tasks to be performed while away.
`0030 Preferably, the above-described operations are
`executed in response to an activation of the device (for
`example, when an alarm goes off); in this case, any prereq
`uisite of the eligible tasks is also reminded to the user.
`0031. This allows the user to check all the prerequisites
`that are required for the tasks being planned for the time
`interval (for example, before leaving home); therefore, the
`risk of forgetting some prerequisite is strongly reduced (if
`not avoided at all).
`0032. As a further enhancement, any prerequisites that
`have not been fulfilled are reminded again as soon as the
`device exits an activation area (for example, home).
`0033. The proposed feature provides a further check,
`which Substantially prevents forgetting the necessary pre
`requisites.
`0034. Another aspect of the present invention provides a
`method for deploying a corresponding service.
`0035 A further aspect of the present invention provides
`a computer program for performing the above-described
`method.
`0036) A still further aspect of the invention provides a
`program product embodying this computer program.
`0037. A different aspect of the invention provides a
`corresponding data processing system.
`0038 Another aspect of the invention provides a mobile
`data processing device for use in this system.
`0.039 The characterizing features of the present invention
`are set forth in the appended claims. The invention itself,
`however, as well as further features and advantages thereof
`will be best understood by reference to the following
`detailed description, given purely by way of a nonrestrictive
`indication, to be read in conjunction with the accompanying
`drawings.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0040 FIG. 1 is a schematic block diagram of a data
`processing system in which the Solution according to an
`embodiment of the invention is applicable;
`
`FIG. 2 depicts the main software components that
`0041
`can be used for practicing the Solution according to an
`embodiment of the invention;
`0.042 FIGS. 3a-3b show a flow chart describing an
`exemplary definition of activities in an organizer,
`0043 FIGS. 4a-4c show a further flow chart describing
`the management of tasks defined in the organizer according
`to an embodiment of the invention; and
`0044 FIGS. 5a-5b are illustrative representations of
`exemplary scenarios relating to different embodiments of the
`invention.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT(S)
`0045. With reference in particular to FIG. 1, a data
`processing system 100 illustrated. The system 100 is based
`on an organizer 103; the organizer 103 consists of a small
`electronic device, which provides computing and storage
`capabilities for performing specific personal activities of a
`corresponding user.
`0046) The organizer 103 is formed by several units that
`are connected in parallel to a communication bus 105. In
`detail, a microprocessor (uP) 110 controls operation of the
`organizer 103. A RAM 115 is used as a working memory by
`the microprocessor 110, while a solid-state mass memory
`120 (for example, consisting of a flash EPROM) stores
`information that must be preserved even when a power
`Supply is off (such as a control program and persistent data).
`Several peripheral units are further connected to the bus 105
`by means of respective interfaces. For example, the orga
`nizer 103 includes a TFT display 125, and an electronic pen
`(or stylus) 130 for entering commands and handwritten text.
`Abuzzer 135 is used to emit several acoustic warnings (for
`example, with different sounds). A Transceiver (TX/RX) 140
`allows implementing a wireless connection with a server
`150 (through a network, typically consisting of the Internet).
`0047 Moving now to FIG. 2, the main software com
`ponents that run on the organizer are denoted as a whole with
`the reference 200. The information (programs and data) is
`typically stored on the flash EPROM and loaded (at least
`partially) into the working memory of the organizer when
`the programs are running, together with an operating system
`and other application programs (not shown in the figure).
`0048. As far as the present invention is concerned, the
`core module of the organizer consists of a scheduler 205.
`The scheduler 205 allows the user to define, edit, view, and
`perform any other management actions relating to tasks,
`appointments and journeys. The definition of the tasks,
`appointments and journeys are stored in corresponding files
`210, 215 and 220, respectively.
`0049 Particularly, each task consists of an activity that
`may be done at any time; typically, the task must be
`completed within a defined deadline (which can be either
`strict or loose). The task must be performed at one or more
`specific locations. An area is also defined around each
`location of the task according to a corresponding threshold
`value; said area consists of a circle centered on the location
`and having a radius equal to the threshold value. Moreover,
`the task often requires the fulfillment of one or more
`prerequisites for its execution; the prerequisites can be of the
`
`Google, Exhibit 1013
`IPR2022-00742
`Page 11 of 17
`
`

`

`US 2006/0225076 A1
`
`Oct. 5, 2006
`
`physical type (i.e., consisting of objects to be carried), of the
`logical type (i.e., consisting of information to be available),
`of the attachment type (i.e., consisting of files to be loaded
`in the organizer), of the activity type (i.e., consisting of other
`tasks to be performed), and so on.
`0050. An example of task is changing the residence of the
`user, which task must be performed by the end of the year
`(in order not to loose a corresponding tax exemption); for
`this purpose, the user must go to a specific public office with
`a copy of the rental contract (physical prerequisite). A
`further example is questioning a telephone bill (within two
`months from its issue date); the task must be performed at
`the telephone company and requires the knowledge of a
`customer number of the user (information prerequisite). A
`still further example is preparing a personalized cheers card
`for the birthday of a nephew of the user (at a printing shop):
`in this case, it is necessary to buy the cheers card (activity
`prerequisite), and then go to the printing shop with a digital
`picture of the nephew (attachment prerequisite).
`0051. On other end, each appointment consists of an
`activity to be done at a definite time; in Some cases, the
`appointment also has an expected duration. In this case as
`well, the appointment is arranged at a specific location.
`Examples of appointments are a business meeting, a medical
`check, a dinner with friends, and the like.
`0.052 At the end, each journey consists of the traveling
`from one place to another over a certain period. The journey
`is defined by a sequence of appointments being logically
`grouped (which appointments are specified in the corre
`sponding file 215). An example of journey involves spend
`ing a whole week away; during this week, the user will meet
`with several clients (during the first five days) and then will
`visit Some archeological sites (during the last two days); it
`should be noted that all the activities of the journey are
`defined by corresponding appointments (even when they do
`not relate to an actual appointment in the strict sense of the
`word, but simply specify an activity planned for a period
`without any real time-constraint).
`0053. In order to define the locations of the above
`described activities (tasks, appointments, and journeys), the
`scheduler 205 accesses a series of maps 225; each map 225
`provides a digital representation of an area of interest (with
`a desired resolution). In this case, each location is directly
`defined by a pair of spatial coordinates (latitudes and lon
`gitudes). The scheduler 205 also controls a personal direc
`tory 230. The personal directory 230 consists of an alpha
`betical list of nicknames, each one identifying a specific
`entity (Such as a person, a shop, an office, and the like); for
`each entity, the personal directory 230 provides an address
`(for its location) and other information (for example, a
`telephone number, an e-mail address, and the like). More
`over, the scheduler 205 accesses a central directory 235. The
`central directory 235 likewise lists multiple categories of
`entities (such as pharmacies, banks, post offices, hospitals,
`plumbers, and the like). For each category, the central
`directory 235 provides the corresponding entities in an area
`of interest; as in the preceding case, each entity is associated
`with a corresponding address (for its location) and other
`information (for example, a telephone number, a web site,
`the opening hours, and the like). The maps 225 and the
`central directory 235 are maintained up-to-date by a module
`240, which downloads them from the Internet.
`
`0054 The organizer further includes a position detector
`245 based on the Global Positioning System (GPS) tech
`nology. The GPS detector 245 determines a position of the
`organizer (defined by the corresponding spatial coordinates)
`with an accuracy of a few tens of meters. Some of the
`detected positions (such as one every 10-30 minutes) are
`stored into a log 250; in this way, the position log 250 traces
`the movement of the organizer in a preceding period (for
`example, the last 2-12 weeks).
`0.055 An estimator 255 accesses the task file 210 and the
`position log 250. The estimator 255 calculates a probability
`of passing in the area around each location (associated with
`the tasks defined in the file 210) according to the preceding
`positions of the organizer (stored in the log 250); for
`example, the probability is obtained dividing the number of
`preceding positions inside a default area around the location
`(defined by a predefined threshold value) by the total num
`ber of preceding positions. At the same time, the estimator
`255 calculates a density (in the area of interest) of the
`entities for each category associated with the tasks (as listed
`in the corresponding file 210); for example, the density is
`defined by an index (such as from 0 to 2), which is obtained
`dividing the number of entities for the task by a normaliza
`tion factor. The estimator 255 supplies the probability and
`the density index to an optimizer 260. For each location of
`the tasks defined in the file 210, the optimizer 260 sets the
`threshold value (defining the area around it) according to the
`corresponding probability and/or density index. For
`example, the threshold value is obtained starting from a
`maximum allowable value (such as 1-10 Km), which is
`divided by the probability and the density index (when
`available). In this way, the threshold value increases as the
`probability and/or the density decreases and vice-versa. This
`means that the area around the corresponding location is
`larger when the user is unlike to pass close to it or when it
`is difficult to find the desired entities; conversely, the area is
`Smaller when the user passes often around the location or
`many entities for the category at issue are available. The
`threshold values so obtained are then stored into the task file
`210.
`0056. The organizer further includes a controller 265,
`which receives the position of the organizer from the GPS
`detector 245. The controller 265 also receives an enabling
`signal from an activator 270. A selector 272 accesses the
`journey file 220, in order to determine a time interval for an
`analyzer 275; for example, the time interval is set to the
`duration of a journey to be taken by the user in the next
`day(s), or it is set from now to the end of the day when no
`journey is planned for today. The analyzer 275 further
`accesses the appointment file 215 and the journey file 220;
`the analyzer 275 determines an expected traveling path of
`the user in the selected time interval, according to the
`appointments that have been arranged for this time interval
`(in both the files 215 and 220). The analyzer 275 returns the
`traveling path so obtained to the controller 265. The position
`log 250 is also accessed by another estimator 280. The
`estimator 280 calculates a speed of the organizer according
`to its previous positions; for example, the speed is obtained
`by averaging a set of basic speeds, each one calculated
`dividing the gap covered between a pair of adjacent preced
`ing positions by the corresponding elapsed time. The speed
`so obtained is likewise returned to the controller 265. As it
`will be apparent in the following, the controller 265 deter
`mines the tasks that might be performed at the moment
`
`Google, Exhibit 1013
`IPR2022-00742
`Page 12 of 17
`
`

`

`US 2006/0225076 A1
`
`Oct. 5, 2006
`
`(according to the position of the organizer) or during the
`selected time interval (according to the traveling path);
`corresponding information is then Supplied to the user by
`means of an output drive 285 (controlling the TFT display
`and the buZZer of the organizer).
`0057 Considering now FIGS. 3a-3b, the logic flow of
`the operations that are executed for defining the activities in
`the organizer is represented with a method 300. The method
`begins at the start block 303, and then passes to block 306
`wherein a new activity is created. Continuing to block 309.
`the user selects the desired type of activity (task, appoint
`ment or journey). The flow of activity then branches at block
`312 according to the selected type of activity. Particularly, if
`the user desires to define a new task the blocks 315-360 are
`executed, whereas is the user desires to define a new
`appointment/journey the blocks 363-381 are executed; in
`both cases, the method then ends at the final block 384.
`0.058 Considering now block 315 (new task), the user
`enters a corresponding description (typically in the text
`form). The method then passes to block 318, wherein the
`user can define the deadline of the task. Considering now
`decision block 321, if the user decides to specify the location
`of the task directly the block 324 is executed, whereas if the
`user decides to specify the location of the task through an
`entity or a category of entities the blocks 327-339 are
`executed; in both cases, the method then continues to block
`342 (described in the following).
`0059. With reference in particular to block 324 (location
`defined directly), the user selects one of the maps and then
`chooses a point on it; the spatial coordinates of the selected
`point then define the desired location. Conversely (location
`defined by the entity/category), the flow of activity branches
`at block 327 according to whether the user desires to define
`the location through an entity or a category of entities. In the
`first case, the user selects the desired entity at block 330 in
`the personal directory. In the other case, the user selects the
`desired category at block 333 in the central directory;
`moreover, the user at block 336 can also specify one or more
`of the entities of the selected category as preferred. In both
`cases, the method joints at block 339. In this phase, the task
`is associated with the address of the selected entity or with
`the address of each entity of the selected category (as defined
`in the personal directory or in the central directory, respec
`tively); those addresses are then resolved into the corre
`sponding spatial coordinates, which define the desired loca
`tion(s). The same operations are also performed for the
`relevant outstanding tasks in the corresponding file when
`ever the personal directory and/or the central directory are
`updated.
`0060 Considering now block 342, the user can define
`any prerequisite that is required by the task (if it is neces
`sary). The flow of activity then branches again at block 345
`according to the mode that has been set for defining the
`threshold value (defining the area around each location
`associated with the task). Particularly, if the user desires to
`enter the threshold value manually the operation is per
`formed directly at block 348; the method then ends at the
`final block 384. Conversely, if the threshold value must be
`calculated automatically the probability of passing in the
`default area around each location associated with the task is
`calculated at block 354 (according to the preceding locations
`stored in the corresponding log); the same point is also
`
`reached whenever a predefined time-out expires (for
`example, every 10-20 days), so as to refresh all the threshold
`values previously determined as the relevant conditions
`change. Proceeding to block 357, if the task is associated
`with multiple locations (i.e., it has been defined through a
`category of entities), the corresponding density index is
`calculated. With reference now to block 360, the threshold
`value for each location is calculated (as a function of the
`probability and/or of the density index); the method then
`ends at the final block 384.
`0061 Considering instead block 363 (new appointment
`or journey), a corresponding description is entered by the
`user. The method then passes to block 366, wherein the time
`of the desired appointment or of the first one of the journey
`is defined. Passing to block 369, it is also possible to specify
`the expected duration of the appointment. The location of
`the appointment is then selected at block 372 (by repeating
`the same operations described above with reference to
`blocks 321-339). If necessary, the user can also define any
`prerequisite that is required by the appointment at block 375.
`The flow of activity then branches at block 378 according to
`whether the user is defining a (single) appointment or a
`journey. In the first case, the method descends into the final
`block 384 directly. On the contrary, a test is made at block
`381 to determine whether the definition of the journey is
`complete. If so, the method ends at the final block 384 as
`well. Conversely, the flow of activity returns to block 363 for
`defining a further appointment of the journey.
`0062 Moving now to FIGS. 4a-4c, the management of
`the tasks defined in the organizer implements a further
`method 400. The method begins at the start block 402, and
`then passes to block 404 wherein the organizer is activated
`(for example, when it is turned-on or an alarm wakes up the
`user in the morning). The controller is then enabled by the
`corresponding signal provided by the activator; in response
`thereto, a test is made at block 406 to determine whether any
`journey is planned starting from today. If not, the time
`interval for defining the traveling path is set from now to the
`end of the day at block 408; conversely, the same time
`interval is set from now to the end of the approaching
`journey(s) at block 410. In both cases, the method passes to
`block 412, wherein the appointments that have been defined
`for said time interval are extracted from the respective file
`and inserted into a list of eligible activities. Descending into
`block 414, the expected traveling path of the user in the time
`interval is determined according to the locations of those
`appointments.
`0063 A loop is then performed for each task defined in
`the corresponding file (starting from the first one); the loop
`begins at block 416, wherein the location(s) associated with
`the task are extracted from its definition. Proceeding to block
`418, a distance of each location of the task from the traveling
`path is calculated. The distance is then compared with the
`threshold value associated with the location at block 420. If
`at least one distance is lower than the corresponding thresh
`old value (meaning that the user is expected to pass in the
`area around the location), the task is added to the list of
`eligible activities at block 422; the method then descends
`into block 424. The same point is also reached from block
`420 directly when the distance is higher than the threshold
`value. A test is then made at block 424 to determine whether
`all the tasks have been processed. If not, the flow of activity
`returns to block 416 for reiterating the same operations with
`
`Google, Exhibit 1013
`IPR2022-00742
`Page 13 of 17
`
`

`

`US 2006/0225076 A1
`
`Oct. 5, 2006
`
`respect to a next task. Conversely, the method exits the
`above-described loop and passes to block 426. In this phase,
`the buzzer is actuated (to warn the user) and the list of
`eligible activities (tasks and/or appointments) is shown on
`the TFT display.
`0064. The flow of activity then branches at block 428
`according to the operation selected by the user. Particularly,
`if the user decides to process the eligible activities the blocks
`430-442 are executed, whereas if the user decides to post
`pone them the blocks 444-446 are executed.
`0065 Considering now block 430 (processing), the user
`selects one of the eligible activities. Different actions are
`then performed according to the choice of the user (decision
`block 432). Particularly, is the user wishes to analyze the
`eligible activity the blocks 434–438 are executed, if the used
`desires the skip the eligible activity the block 440 is
`executed, and if the user desires to cancel the eligible
`activity the block 442 is executed; in any case, the method
`then returns to block 428.
`0066. With reference in particular to block 434 (analyz
`ing), the information available for the eligible activity is
`retrieved from the relevant file and displayed (for example,
`specifying its description, deadline or time, and locations).
`Continuing to block 436, the associated prerequisites (if
`any) are likewise retrieved and displayed. For each prereq
`uisite, the user at block 438 can fulfill it and then thick a
`corresponding flag (for example, when an object to be
`carried has been taken, w