WO2012155235A1

WO2012155235A1 - Dynamic calendar management

Info

Publication number: WO2012155235A1
Application number: PCT/CA2011/050305
Authority: WO
Inventors: Brian Edward Anthony Mccolgan; Neeraj GARG; Salvatore Ierullo
Original assignee: Research In Motion Limited
Priority date: 2011-05-16
Filing date: 2011-05-16
Publication date: 2012-11-22

Abstract

Information pertaining to an entity of interest is used to automatically assess viability of a calendared event. This information can comprise location information and/or non-location information pertaining to the entity of interest. The entity of interest can comprise an individual and/or any of a variety of presentities. The viability of the calendared event can refer, for example, to a present likely or confirmed assurance that the calendared event can be successfully logistically provisioned.

Description

DYNAMIC CALENDAR MANAGEMENT

Technical Field

[0001] This disclosed concept relates generally to calendar management.

Background

[0002] Electronic calendars are known in the art. Such calendars serve as a tool to manage calendared events by, for example, scheduling and facilitating actions and events. Individual persons, groups, facilities, and enterprises are increasingly utilizing electronic calendars. In some cases calendar use includes sharing calendared information. For example, a person seeking to schedule a meeting with a group of people may be able to view information regarding the already-scheduled activities of these people in order to identify possible times when the meeting can be held without a scheduling conflict.

Brief Description of the Drawings

[0003] FIG. 1 comprises a block diagram of an example electronic calendaring device in accordance with various embodiments of the disclosed concept;

[0004] FIG. 2 comprises a block diagram of an example calendaring system in accordance with various embodiments of the disclosed concept;

[0005] FIG. 3 comprises an information flow diagram of example calendaring operations in accordance with various embodiments of the disclosed concept;

[0006] FIG. 4 comprises a block diagram of another example calendaring system in accordance with various embodiments of the disclosed concept;

[0007] FIG. 5 comprises a block diagram of yet another example calendaring system in accordance with various embodiments of the disclosed concept;

[0008] FIG. 6 comprises an information flow diagram illustrating another example calendaring operations in accordance with various embodiments of the disclosed concept; [0009] FIG. 7 comprises another example block diagram in accordance with various embodiments of the disclosed concept; and

[0010] FIG. 8 comprises another example information flow diagram in accordance with various embodiments of the disclosed concept.

[0011] The present figures illustrate example embodiments of the present subject matter. To this end certain actions or steps illustrated in the figures may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. Similarly, it should be understood that certain components or parts shown in the figures may be configured differently (for example, as combined, separated, and so forth). The terms and

expressions used herein have the ordinary technical meaning as is accorded to such terms and expressions by persons skilled in the technical field as set forth above except where different specific meanings have otherwise been set forth herein.

Detailed Description

[0012] Generally speaking, pursuant to various approaches described hereinafter, information pertaining to an entity of interest is used to automatically assess viability of calendared event (i.e., an already-scheduled event). By one approach the information can comprise location information (correlated, if desired, to a particular time) pertaining to the entity of interest. By another approach, in combination with the foregoing or in lieu thereof, this information can comprise non-location information pertaining to the entity of interest.

[0013] By one approach the entity of interest comprises an individual. This individual may, for example, be a person scheduled to attend or participate in the calendared event. These teachings will accommodate, however, considerable flexibility in these regards and hence the entity of interest can comprise any of a variety of presence entities (i.e. entities having presence information associated therewith), hereinafter presentities. Accordingly, the entity of interest may comprise, by way of illustration, a meeting room, a teleconference facility, an on-line meeting/conferencing service, and so forth. [0014] The aforementioned viability of the calendared event can refer, for example, to a present likely or confirmed assurance that the calendared event can be successfully logistically provisioned. The specifics of this viability can and will vary with the application setting. Examples of assessed criteria might include, but are not limited to, the likelihood that all scheduled participants will be physically able to attend a meeting, that all scheduled participants will be able to attend a meeting in some acceptable fashion (for example, by a communication link of choice if not in person), that persons critical to the intended purpose or nature of a meeting will be able to attend the meeting, that a scheduled meeting facility will be open and properly equipped and enabled at the appropriate time, that appropriate information technologies including artifacts for a scheduled meeting are in fact functioning and/or available, and so forth.

[0015] This information regarding an entity of interest can be received from any of a variety of sources. By one approach, for example, receipt of entity information can comprise receiving such information from a public or private server (e.g. presence, location, and/or information server). By another approach, receipt of entity information can comprise receiving such information from a user equipment (for example, a portable electronic device such as a cellular telephone or tablet computing device) associated with a user of that equipment.

[0016] This assessed viability of a calendared event can then be communicated in any of a variety of ways. This can comprise, for example, providing this information to one or more targeted recipients including, but not limited to, subscribed watchers

(including both overtly-subscribed watchers as well as subscribers-by-implication such as, for example, meeting co-participants who become automatically subscribed to possibly varying-levels of this information depending upon their status or role with respect to the calendared event). As another example this information can be published or otherwise made available in a form that can be accessed by authorized persons on an on- demand basis.

[0017] Information regarding assessed viability of a calendared event can be conveyed as text and/or graphics as desired. Example methods and apparatuses described hereinafter may also accommodate using an indication or indicium such as color-coded information or icon to represent viability of the calendared event. For example, a green color can indicate uncompromised viability, a yellow color can indicate some level of concern or a warning level (for example, whether a scheduled participant will be able to arrive at a meeting on time), and a red color can indicate unviability.

[0018] The present methods and apparatuses may also accommodate providing a user with an opportunity to alter the calendared event when the assessed viability information indicates a challenge to the viability of the calendared event. Alteration of the calendared event can comprise, for example, permitting this user to cancel the calendared event and, if desired, facilitating the rescheduling of the calendared event.

[0019] The foregoing-mentioned receipt of information pertaining to entities of interest and the use of that information to automatically assess viability of a calendared event can be carried out as frequently or infrequently as may be desired. By one approach, such an assessment process can vary dynamically over time and can occur, for example, more aggressively as the time for the calendared event approaches such that the overall process vets or re-establishes the continued viability of the calendared event more frequently as the time of the event nears.

[0020] In at least some application settings one or more of the entities of interest will be people who carry with them a portable electronic device. Examples of portable electronic devices include mobile, or handheld, wireless communication devices such as pagers, cellular phones, cellular smart-phones, wireless organizers, personal digital assistants, wirelessly enabled notebook computers, tablet computers, and so forth. The portable electronic device may also be a portable electronic device without wireless communication capabilities, such as a handheld electronic game device, digital photograph album, digital camera, or other device.

[0021] A block diagram of an example of a portable electronic device 100 is shown in FIG. 1 . The portable electronic device 100 includes multiple components, such as a processor 102 that controls the overall operation of the portable electronic device 100. Communication functions, including data and voice communications, are performed through a communication subsystem 104. Data received by the portable electronic device 100 is decompressed and/or decrypted by a decoder 106. Similarly, data sent by the portable electronic device 100 may be compressed and/or encrypted by the processor 102 alone or in cooperation with another component such as the decoder 106 or the communication subsystem 104. The communication subsystem 104 receives messages from and sends messages to a wireless network 150. The wireless network 150 may be any type of wireless network, including, but not limited to, data wireless networks, voice wireless networks, and networks that support both voice and data communications. A power source 142, such as one or more rechargeable batteries or a port to an external power supply, powers the portable electronic device 100.

[0022] The processor 102 interacts with other components, such as Random

Access Memory (RAM) 108, memory 1 10, a display screen 1 12 (optionally with a touch- sensitive overlay 1 14 as shown) operably coupled to an electronic controller 1 16 that together comprise a display 1 18, one or more actuators 120, one or more force sensors 122, an auxiliary input/output (I/O) subsystem 124, a data port 126, a speaker 128, a microphone 130, short-range communications 132, and other device subsystems 134 (such as, but not limited to, a Global-Positioning System (GPS) receiver to permit the device to calculate its geographic location and to provide that information to, for example, the processor 102). User-interaction with a graphical user interface is performed via one or more of the display screen 1 12, the touch-sensitive overlay 1 14, and the actuators 120. The processor 102 interacts with the display screen 1 12 and optionally the touch-sensitive overlay 1 14 via the electronic controller 1 16. Information, such as text, characters, symbols, images, icons, and other items that may be displayed or rendered on a portable electronic device, is displayed on the display 1 18 via the processor 102. The processor 102 may interact with an accelerometer 136 that may be utilized to detect direction of gravitational forces or gravity-induced reaction forces.

[0023] To identify a subscriber for network access, the portable electronic device 100 uses a Subscriber Identity Module or a Removable User Identity Module

(SIM/RUIM) card 138 for communication with a network, such as the wireless network 150. Alternatively, user identification information may be programmed into the nonvolatile portion of memory 1 10.

[0024] The portable electronic device 100 includes an operating system 146 and software programs, agents, or components 148 that are executed by the processor 102 and are typically stored in a persistent, updatable store such as the memory 1 10. Additional applications, agents or programs may be loaded onto the portable electronic device 100 through the wireless network 150, the auxiliary I/O subsystem 124, the data port 126, the short-range communications subsystem 132, or any other suitable subsystem 134.

[0025] A received signal such as a text message, an e-mail message, or web page fetch is processed by the communication subsystem 104 and input to the processor 102. The processor 102 processes the received signal for output to the display screen 1 12 and/or to the auxiliary I/O subsystem 124. A subscriber may generate data items, for example e-mail messages, which may be transmitted over the wireless network 150 through the communication subsystem 104. For voice communications, the overall operation of the portable electronic device 100 is similar. The speaker 128 outputs audible information converted from electrical signals, and the microphone 130 converts audible information into electrical signals for processing.

[0026] The touch-sensitive overlay 1 14 may be any suitable touch-sensitive component, such as a capacitive, resistive, infrared, surface acoustic wave (SAW) touch- sensitive display, strain gauge, optical imaging, dispersive signal technology, acoustic pulse recognition, and so forth, as known in the art. In an embodiment with the display 1 18 being a capacitive touch-sensitive display, a capacitive touch-sensitive overlay 1 14 is coupled, integrated or made unitary with the display screen 1 12. The overlay 1 14 may be an assembly of multiple layers in a stack including, for example, a substrate, a ground shield layer, a barrier layer, one or more capacitive touch sensor layers separated by a substrate or other barrier, and a cover. The capacitive touch sensor layers may be any suitable material, such as patterned indium tin oxide (ITO).

[0027] The actuator(s) 120 may be depressed or activated in some instances by applying sufficient force to the (touch-sensitive) display 1 18 to overcome the actuation force of the actuator 120. However, in other instances the actuator(s) 120 may be buttons, keys, or the like (such as, but not limited to, a QWERTY-type keyboard) that are separate from the display 1 18. The actuator(s) 120 may be actuated by pressing anywhere on the touch-sensitive display 1 18. The actuator(s) 120 may provide input to the processor 102 when actuated. Actuation of the actuator(s) 120 may result in provision of tactile feedback. When force is applied, the touch-sensitive display 1 18 is depressible, pivotable, and/or movable. Such a force may actuate the actuator(s) 120. The touch- sensitive display 1 18 may, for example, float with respect to the housing of the portable electronic device, i.e., the touch-sensitive display 1 18 may not be fastened to the housing. A mechanical dome switch actuator may be utilized. In this example, tactile feedback is provided when the dome collapses due to imparted force and when the dome returns to the rest position after release of the switch. Alternatively, the actuator 120 may comprise one or more piezoelectric (piezo) devices that provide tactile feedback for the touch- sensitive display 1 18.

[0028] Optional force sensors 122 may be disposed in conjunction with the touch- sensitive display 1 18 to determine or react to forces applied to the touch-sensitive display 1 18. The force sensor 122 may be disposed in line with a piezo actuator 120. The force sensors 122 may be force-sensitive resistors, strain gauges, piezoelectric or piezoresistive devices, pressure sensors, quantum tunneling composites, force-sensitive switches, or other suitable devices. Force as utilized throughout the specification, including the claims, refers to force measurements, estimates, and/or calculations, such as pressure, deformation, stress, strain, force density, force-area relationships, thrust, torque, and other effects that include force or related quantities.

[0029] Such a portable electronic device can be configured as desired to support one or more of the actions or capabilities presented herein. This can include, for example, determining a present geographic location of the user and transmitting that information to, for example, a presence, location, or other information service of choice. This can also include, by way of another example, configuring the portable electronic device (for example, by use of executable instructions on a non-transitory machine-readable medium) to manage an electronic calendar (either via a calendar application itself or via, for example, a calendar client application) or to interact with a remote manager of an electronic calendar, again in accordance with embodiments of the present disclosure.

[0030] In any event, the present disclosure generally serves to provide a meeting organizer and others with a mechanism for determining the status of scheduled meeting participants and hence an ability to monitor, over time, the viability of the calendared event. Status determination can include, but is not limited to, determining the location of such persons (at least to a certain degree). The present methods and apparatuses can permit such an organizer to understand, for example, whether intended participants are currently running late or are otherwise involved in other higher priority activities, such that one or more of these persons may be unable to attend a given meeting on time (or may miss the meeting altogether). The meeting organizer can leverage such information to, for example, re-schedule the meeting to a later time, cancel the meeting, alter the agenda of the meeting to better accommodate the persons who can attend, defer the meeting to a completely different location, and so forth. Such actions, in turn, can serve to greatly minimize or nullify the impact of such circumstances (for example, by reducing productivity loss, misallocations of resources, and so forth) on other meeting participants.

[0031] The present disclosure also illustrates that a portable electronic device user, who is a participant in an upcoming calendared event, can have ready access to a generalized mechanism capable of conveying the user's status relative to a calendar event. That is, calendared event meta-data (for example, a meeting participant' s current location, a meeting participant' s estimated time of arrival at the meeting, a meeting participant' s probability of attendance at the meeting, a meeting participant's current activities, a meeting participant's relative priority or importance to the conduct of the meeting, and so forth) relative to an upcoming calendared event can be tracked or communicated as desired. Further, if desired, a calendared event can itself serve as an observable entity (e.g. a presentity) on behalf of meeting participants or a calendar application. This approach, in turn, permits watchers (such as intended-meeting participants, meeting-support personnel, and so forth) to subscribe or to be implicitly auto- subscribed to such information regarding a meeting.

[0032] For the sake of illustration and without intending any particular limitations in these regards by the presentation of specificity, a number of different application settings and corresponding approaches that accord with the present teachings will be described.

[0033] Referring to FIG. 2, a given platform such as a private network enterprise desktop computer 201 that connects to a network such as the Internet 202 via a firewall 203 (using, for example, a virtual private network (VPN)) or a portable communication device 204 that communicatively couples via a mobile base station 205 and

corresponding radio network infrastructure 206 to that network can correspond to a meeting organizer. In this illustrative example, meeting participants who are scheduled to participate in a calendared event can inquire as to the status of at least some and perhaps all other meeting participants using, for example, peer-to-peer (P2P) communications.

[0034] For example, the meeting organizer can send a series of P2P messages

(using, for example, an HTTP:POST issued from within the private network to such portable communication devices) containing P2P poll-meeting status requests to meeting participants (including, for example, both mandatory and optional attendees as desired). The meeting organizer's user equipment receives and consolidates the resulting P2P meeting status responses from each meeting participant (including, for example, his or her own meeting status) and transmits or otherwise publishes consolidated meeting-status information to some or all of the proposed meeting participants using additional P2P message primitives.

[0035] In such a case the calendar application service running on each meeting- participant' s device can be configured to provide a centralized view of a calendared event corresponding to a meeting and/or distribute the resulting meeting status toward other meeting participants utilizing P2P messages. These teachings will also accommodate polling or updating meeting status information at specified time (or event) intervals leading up to a calendared event.

[0036] An illustrative, non-limiting example in these regards would be to conduct such an information-gathering exercise one hour before the meeting, a half hour before the meeting, fifteen minutes before the meeting, five minutes before the meeting, and even during or at the conclusion of the meeting if desired. For example, meeting status could continue to be updated during the meeting (where this might comprise, for example, conveying current items on the meeting's agenda, representing each

participant' s status (presence, speaking, listening, muted, and so forth). By one approach, meeting or event status information could be refreshed based on a meeting participant' s most current status or could be a combination of their last known/published status (relative to the meeting) along with more up-to-date status provided by other meeting participants.

[0037] By way of further example in these regards, FIG. 3 illustrates an information flow for an upcoming finance conference-call meeting event between a meeting organizer and two additional meeting participants (denoted "Meeting Participant A" and "Meeting Participant B") where Meeting Participant B is a important stakeholder with respect to the substance of the meeting (this participant might be categorized as a stakeholder, for example, because they are the Chief Financial Officer (CFO) and hence they are the person who can approve all expenses incurred that are greater than $ 10,000). In this example the meeting organizer provides to both meeting participants an initial meeting status request 301.

[0038] In response, both Meeting Participant A and B establish 302 their meeting status (that is, their presently-measured ability to attend the calendared event). When implementing this activity via, say, a modern smartphone, this can include, for example, determining a present location of the smartphone (and hence the corresponding participant), calculating the distance/route that separates the participant from the meeting venue, and calculating a likelihood that the participant can traverse this distance/route in time to arrive at the calendared event. As another example, perhaps in combination with the foregoing, this activity might comprise receiving current traffic information for the route being traveled by the participant and using information regarding traffic delays or the like to further inform this assessment of the participant's likelihood of being able to attend the meeting as planned.

[0039] The non-stakeholder meeting participant (Meeting Participant A) reports 303 their meeting status (in this case, that the meeting participant is "on time" with respect to attending the upcoming meeting) voluntarily at the one-hour marker. Similarly the stakeholder meeting participant (Meeting Participant B) reports 304 their status as well. In the case of this Meeting Participant B, however, the status is "tentative - in traffic." Accordingly, there is some present concern that Meeting Participant B might not be able to attend the scheduled meeting as planned based on their current activities.

[0040] Upon receiving this information the meeting organizer provides a status update 305 regarding the various parties. This status update 305 indicates that both the meeting organizer and Meeting Participant A presently remain able to attend the meeting, but that Meeting Participant B's ability to attend is "tentative." This status update message 305 can be provided to only particular participants if desired or can be distributed to all participants (based, for example, on an implicit auto-subscription to meeting information by meeting participants). These teachings will also accommodate providing this status update 305 to others as well, including but not limited to

administrative assistants for any of the meeting participants, facilities support personnel, or any of a variety of registered watchers or subscribers including the meeting facility itself.

[0041] In this example neither meeting participant follows up with a voluntary status report at the half-hour marker. Instead, the meeting organizer sources, transmits, or otherwise outputs a meeting- status poll message 306. Again, such a communication can be directed to all meeting participants or only to certain targeted participants as desired.

[0042] This flow illustrates that Meeting Participant B again establishes 307 their meeting status and responds with a message 308 to indicate that the participant is presently "stuck in traffic" and that the participant is likely to arrive at the meeting in around fifty minutes - "eta=50min." Since the meeting is scheduled to begin in around thirty minutes, however, it is now likely that Meeting Participant B will not be able to attend the scheduled meeting in person (at least from the beginning of the meeting). In effect, Meeting Participant B must now decline attending the meeting.

[0043] The meeting organizer transmits a message 309 to this effect. This message

309 will permit both Meeting Participant B and other intended participants to pursue other plans or opportunities. Before or as an alternative to cancellation of the scheduled meeting, additional messaging may occur between the meeting organizer and the participants to assess whether Meeting Participant B may "attend" the meeting remotely - for example by calling in to a phone that will be present at the meeting room location (e.g. a conference phone or a mobile phone belonging to Meeting Participant A). In this illustrative example the meeting organizer also determines 310 the need to reschedule the meeting and can take follow-on steps to provide corresponding notifications or suggestions in these regards. These teachings will accommodate having a person make some or all of these decisions as well as automating the process (relying, for example, upon one or more rules, preferences, policy, or the like regarding preferred or appropriate actions in view of certain specified conditions). [0044] These teachings will accommodate triggering meeting status updates by a calendaring client application that runs on a meeting participant' s portable electronic device. Such triggering could be time based, for example. This might comprise, by way of illustration, pushing meeting status updates to the meeting organizer at one hour before the scheduled meeting time, one-half-hour before the scheduled meeting time, and then every ten minutes up to and even during the meeting. These teachings will also accommodate basing this triggering on predetermined events and/or locations (for example, an automatic update can be sent upon determining that the participant has entered their vehicle (which might be determined, for example, when the participant' s smartphone establishes a Bluetooth connection with the vehicle).

[0045] By one approach these meeting participants can all be peers. In such a case, when the meeting organizer is, for example, out of coverage, the meeting participant peer devices (including a stakeholder such as the CFO) could themselves renegotiate (at a communications protocol level) to determine a new meeting organizer and to initiate the P2P poll/query meeting status events described above without direct involvement by the original meeting organizer.

[0046] These teachings will also accommodate using any of a variety of different user-interface embodiments. This can include approaches based on colored status indicator lights that are rendered on the device display. For example, a traffic-light motif can overlay a calendar icon in the device' s task or status bar. By one approach the particular color (or colors) displayed can be based on factors such as an assessment of the overall state of the meeting. When, for example, a non-required meeting participant is unable to make the calendared event the traffic light can be green. When, however, a stakeholder or more than an acceptable minimum number of participants are unable to attend, the traffic light may automatically be updated to yellow or even red.

[0047] These teachings will also accommodate an approach that automatically performs any of a variety of predefined actions (dictated, for example, by rules, or policies, or the like. For example, the predefined action could be to send meeting participants a message (such as a voice message or a text message) that the calendared event is to be re-scheduled to a particular time and day, or cancelled, due to a described circumstance. In addition, and as desired, such actions can also occur for scenarios when the calendared event remains viable and the information provided to the participants (and others as desired) reflects and/or reinforces this state.

[0048] FIG. 4 illustrates an approach where a private network 401 includes a calendar service 402 as a network service for various devices including both wireless and non-wireless devices as desired. This calendar service 402 may comprise a dedicated- purpose network element, or may share the capability of a multi-purpose network element. These teachings will also accommodate distributing the calendar service functionality across a plurality of network elements (including, if desired, network elements that are external to this particular private network 401 ). By one approach this calendar service 402 is fully supported by a mobile network infrastructure 206 (for example, via a relay 403 or other suitable functional entity).

[0049] Various calendar-service behaviors can be established, for example, based on a policy resolution mechanism, or by the calendar service 402 itself using local policy or configuration settings. In this illustrative example the calendar service 402 is configured to request meeting status updates of meeting organizers and meeting participants, or to otherwise be notified their respective meeting status updates. This capability can in turn be enabled by calendar- service clients that run on portable electronic devices or desktop computers and so forth.

[0050] This calendar service 402 can further serve to gather meeting status updates (i.e., as a logical organizer) and consolidate meeting status updates on behalf of meeting participants including the physical meeting organizer. The calendar service 402 can also serve to distribute meeting status updates at suitable intervals (for example, as described above). The particular view of this individual or aggregated meeting status can be shared with all meeting participants or can differ depending on, for example, the associated meeting principal dictates. For example, it may be appropriate for the meeting organizer to have immediate access to a more detailed account of meeting status information than ordinary participants.

[0051] Meeting-participant status may include location information if desired. This can comprise simple location characterizations such as "at work" or more

detailed/complex characterizations such as GPS or A-GPS-type positioning information (such as street intersections, civic-address, latitude/longitude coordinates, cell-tower mapping information, and so forth).

[0052] The view of a particular meeting participant's location may be further narrowed, expanded, highlighted, muted, or otherwise dynamically transformed to support the conveyance of visual information regarding a given participant's ability to attend the calendared event. For example, the calendar service 402 may only present location information to underscore a particular point regarding the participant's likely ability to attend the calendared event.

[0053] As a variation on the foregoing, and referring now to FIG. 5, the calendar service 402 can interconnect to a presence and/or location service 501. In this scenario, the presence and/or location service 501 receives, directly (for example, from calendar clients) or indirectly (for example, from a calendar service on behalf of calendar clients) participant, meeting, and perhaps other status information, including location information.

[0054] In the direct scenario, a calendar client interacts directly with the information capture platforms (such as, for example, the presence/location service 501 ) as an information source to provide generic-type information updates particular to the platform. In the indirect scenario, the calendar service 402 facilitates the request/receipt and gathering of source information from a calendar client, and publishes it (either as a delegate publisher or as a logical entity such as a logical meeting or meeting location presentity) to reflect current status. This published information can be specific to the platform in question (and hence not targeted specifically for a calendar application) and may include extended calendar-related and/or meeting-status indicators applicable to the information capture platform being used.

[0055] In each case, the calendar service 402 can interact with these information sources as a presentity to establish and/or provide or reflect meeting status to interested observers. If desired, this calendar service 402 may also act in the role of an observer (often referred to as a watcher) to retrieve or be notified (e.g. via subscription) of updates of meeting participant status information by the presence and/or location service 501 . Alternatively an individual meeting participant (including, if desired, the meeting organizer) could also act as a watcher (for example, through a suitably-configured calendar client). Either scenario provides enhanced meeting status/location reporting on behalf of the calendar service 402 and calendared-event participants.

[0056] By one approach a calendared event (such as a meeting), a calendared- event location, or even the associated resources a calendared event requires (such as, for example, an overhead projector, a speaker phone, a video-conference link,

food/refreshments, and so forth) could be considered or treated as an observable entity. In this case, these kinds of entities can themselves comprise a type of logical presentity within a presence service.

[0057] Each of these entities could also be considered an observer or watcher, if desired. For example, a meeting or calendared event (as a logical entity) could subscribe to receive the presence and/or location information of meeting participants. This provides a generic mechanism for separating the reporting of information into disparate

information owning services, such as a presence service or a location service, on behalf of the calendar service 402.

[0058] These teachings will also accommodate permitting a meeting presentity (or an information owning service (that serves, for example, on behalf of a meeting presentity) to aggregate and incorporate other logical presentities into logical abstractions. When conveying information regarding meeting status, then, a calendar user could drill down or expand information (presuming this activity to be within permitted policy limits) to discover other relevant status relating or impactful to the meeting (such as, for example, the location of the meeting, a map, a specific route to the meeting venue from various points-of-interest (such as a local airport), login details for an audio, video, or Internet connection, a set of web-ex or gotomeeting.com connection parameters, and so forth).

[0059] Analysis and aggregation of information may also be utilized to resolve inconsistencies and/or conflicting information. This can support, for example, providing logical abstraction(s) of meeting participants and their devices. These abstraction(s) could be used to determine whether a reported geographical position (for example, of the device) is directly attributable to the device-user's position (based, for example, on textual-location attributes of the presentity/person) or whether the person is perhaps not with their device (as might occur, for example, when the person leaves their device on their desk or in a taxi). These types of abstractions can be useful to aid in evaluating (or validating) whether a meeting participant may actually be able to attend a scheduled meeting. Policy may also be utilized in this scenario to assist a consolidation and/or evaluation process.

[0060] FIG. 6 provides an illustrative information flow in these general regards.

In a presence service or location service-based application setting it is possible that meeting participants could unilaterally publish their current status/location at specific intervals in lieu of a polling-based approach. Published messages could originate from each meeting participant and be directed toward the calendar service and/or presence server. When directed to the presence service, the latter could act to notify authorized watchers including, for example, the calendar service, the meeting participants themselves, and other interested entities as desired.

[0061] The information flow of FIG. 6 assumes that meeting participants have authorized the meeting organizer to retrieve or be updated regarding their calendar event state by other participants of the calendar service. This authorization could be overt or it could be implied, for example, by being a participating user of the calendar service.

[0062] The illustrated information flow of FIG. 6 assumes the same kind of calendared event as the example of FIG. 3 and the same participants as well. In this example, at about one hour prior to the calendared event, a calendar service and/or presence service (hereinafter, for this figure, "CS/PS") sends a poll request 601 to the meeting organizer. The meeting organizer establishes 602 its own meeting status and replies with a corresponding meeting- status message 603. The CS/PS then similarly polls 604 Meeting Participant A. This prompts the latter to establish 605 its own meeting status and to reply with a corresponding meeting-status message 606. The CS/PS then continues by polling 607 Meeting Participant B to cause the latter to establish 608 its meeting status and to return that meeting status in a corresponding message 609.

[0063] In this illustrative example, the meeting status for both the meeting organizer and Meeting Participant A is nominal and without issue. Meeting Participant B, however, has a more tentative status owing to a traffic-based delay. [0064] The CS/PS processes 610 the received meeting-status messages and provides 61 1 this information in corresponding notification messages to various ones of the meeting participants. As exemplified in this illustrative example, once information is gathered by an appropriate entity within a calendar service or the like, a status notification can be automatically provided to each meeting participant, or interested observer, regarding a meeting participant status, or status of a meeting in general.

[0065] The following XML example illustrates a notification payload based on the information flow shown in FIG. 6 and provided by, for example, a SIP/SIMPLE presence server to relay meeting participant status information. This example relates to meeting participant status for a meeting organizer (denoted here as "Bob") that is represented in FIG. 6's flow. More particularly, the two Notify message primitives illustrate when a CS/PS notifies other meeting participants of the organizer's status relative to a calendared event. (This XML content is based on the Presence Information Data Format (PIDF) provided by a SIP/SIMPLE presence server that supports the information flow

represented in FIG. 6.)

<?xml version=" 1 .0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

xmlns:pdm="urn:ietf:params:xml:ns:pidf:data-model"

xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid"

xmlns:op="urn:oma:xml:prs:pidf:oma-pres"

xmlns:ca="urn:oma:xml:prs:pidf:calendar-event"

xmlns:xsi="http://www.w3. org/2001/XMLSchema-instance"

entity="sip:bob@xyz.org"> <tuple id="al 232">

<ca:calendar-event id="ccfinance">

</ca: calendar-e vent>

<op:willingness>

<op:basic>open</op:basic>

</op:willingness> <op:registration-state>active</op:registration-state>

<op: service-description>

<op:service-id>com.service.calendar</op:service-id>

<op:description>CC-Finance</op:description>

</op:service-description>

<pdm:deviceID>urn:uuid:48662e 19-5fbf-43fc-a2fd- d23002787599</pdm:deviceID>

<contact>sip: ccfinance.organizer @ cs.service.com</contact>

</tuple>

<pdm:device id="al 233">

<pdm:deviceID>urn:uuid:48662e l 9-5fbf-43fc-a2fd-d23002787599</pdm:deviceID> <pdm:timestamp>2009- 12-20T l l :58:56Z</pdm:timestamp>

</pdm:device>

</presence>

[0066] Within this example XML content the calendar-event status indicator is described by the calendar-event XML element '<ca:calendar-event>' which in this example derives from a PIDF <tuple>. The child '<open>' XML element value indicates that Bob will 'attend' the meeting. Further, the 'id' attribute within the <ca:calendar- event> element shown in the example above is established to provide a calendar service with a generic correlation function to thereby establish precisely which calendar event Bob' s meeting participant status relates to within the calendar service. The OMA

Presence/SIMPLE <sevice-description> XML element describes or narrows the specific CS.

[0067] The optional <contact> XML element provided in the example above shows a SIP based URI, which is Bob's contact information relative to the CS. The <contact> XML element is utilized (in this example) to provide a canonical SIP URI which associates the presentity with: (a) a calendar event identifier (i.e. ccfinance); and (b) a role this presentity relative to a calendared event (i.e. organizer).

[0068] By one approach a calendar service can interwork with a presence service or location service (such as an Open Mobile Alliance (OMA) or proprietary presence and/or location service) as well as the OMA Presence Access Layer (PAL) Enabler. Using this approach, consumption of meeting/meeting participant status, either by a calendar service or a calendar client can be dramatically simplified and reduced under at least some operating circumstances. Further, meeting participant and/or meeting-related status updates published to the presence service/location service can be processed via the PAL Enabler in a contextual manner on behalf of a presence-aware service such as the calendar service.

[0069] To support the foregoing FIG. 7 depicts a PAL server that is co-located with the calendar service 402. Such co-location, of course, is not necessary and this functionality can be parsed and distributed as desired to suit the needs or opportunities as tend to characterize a particular application setting.

[0070] A PAL server, operating with contextually-relevant meeting-oriented presence aspects (e.g. "meeting-status"), presence triggers (e.g.

"onKeyParticipantCancel"), PAL policy, and interoperable PAL rules can consolidate and/or abstract raw meeting/status information (for example, as exemplified by the XML example above) provided to the PAL server by one or more information sources (such as the presence service and/or the location service) to thereby provide a presence aspect and an associated, derived value therefor. As noted, PAL processing occurs based on a calendar-service context. This context provides a unique calendar-specific perspective of calendared events needed to fulfill functionality specific to the calendar service. This further abstracts and simplifies calendar application service interaction with information- owning services such as the presence service or the location service. The result is a view of meeting status and associated meeting participants, provided to a calendar client, as manifested, for example, on a personal computer and/or a portable electronic device such as a mobile wireless device. [0071] FIG. 8 depicts an information flow that serves as an illustrative example in these regards. In this example, Meeting Participant B transmits a publish message 801 to a corresponding presence/location service as does Meeting Participant A (as denoted by reference numeral 802). The presence/location service, in turn, processes 803 this information to capture the presence/location state of these entities.

[0072] Around one hour prior to the calendared event, the meeting organizer transmits a PAL establish context message 804 to the calendar service/PAL server. The latter establishes 805 the corresponding PAL context relative to the calendar service and transmits a corresponding response 806 to the meeting organizer (such as, for example, a response containing a resolved PAL presence context identifier and, optionally a verbose description (e.g. an enumeration of aspects, triggers, and so forth related to the calendar service) for the established PAL calendar context).

[0073] The meeting organizer then transmits a meeting-status inquiry 807 to the calendar service/PAL server. The calendar service/PAL server acting as a

watcher/observer to the presence/location service, in turn, transmits a corresponding SUBSCRIBE message 808 to the presence/location service which responds with a NOTIFY message 809. The calendar service (via the PAL server) then consolidates 810 the meeting status information into at least one contextually-relevant presence aspect, and transmits this information in a message 81 1 to the meeting organizer.

[0074] Later in this example Meeting Participant B publishes 812 its information to the presence/location service which causes a NOTIFY message 813 to update the calendar service/PAL server. This NOTIFY message 813 contains information which when processed 814 by the calendar service/PAL server determines that a key participant has initiated cancellation of the meeting. As a result, the calendar service/PAL server updates 814 the meeting status information and provides this information in a

corresponding message 815 to the meeting organizer. Message 815 is a trigger "action" corresponding to presence trigger "onKeyParticipantCancel" that is invoked (i.e., message 815is sent for example as an asynchronous NOTIFY message to the meeting organizer) approximately one-half hour before the actual calendared event. In this example the meeting organizer elects to reschedule the calendared event via a corresponding message 816 and the calendar service/PAL server transmits 817 a message to the meeting participants regarding the rescheduling of the event.

[0075] In this example, two PUBLISH messages originate from meeting participants. These publications utilize a PIDF format similar to that shown in the XML example above. This publication could also be extended to include location information provided to a presence service or a location service (as determined, for example, from a portable electronic device's GPS or through A-GPS, translated into GEOPRIV or other positioning primitives, and published as a PIDF or other format on behalf of the meeting participant).

[0076] Thus configured the presence/location service captures participant meeting- status-information. At about one hour prior to the calendared event the meeting organizer requests establishment of a PAL context for use with the calendar service via his calendar service/PAL client running on his personal computer or portable electronic device. Once a context is established, a subsequent presence aspect request for aspect MeetingStatus is provided by the meeting organizer' s client. The calendar service receives the request, determines the appropriate meeting participants applicable to the calendared event, and utilizes the PAL server to fetch, process, and consolidate meeting-status information based on the meeting organizer's context.

[0077] The presence context at the PAL server, in turn, provides the relevant PAL policy, rules, and so forth for the calendar service. Once a MeetingStatus (presence) aspect is computed, the result is provided to the meeting organizer's calendar

service/PAL client. The corresponding indicator can combine several indications including, for example, the overall meeting status (using, for example, the color yellow) as well as the granular meeting-participant status (by providing a separate discrete indicator for each of the participants, including the meeting organizer).

[0078] Thus configured, an electronic calendar paradigm can serve in a more dynamic fashion to not only help various entities to more assuredly support calendared events but also to help avoid wasted time and effort such as, but not limited to, manually calling and checking on meeting participants or re-scheduling when a calendared event cannot be carried out in a manner sufficient to facilitate the purpose of the event. Information to inform such a process can be developed in a variety of ways and by a variety of enabling platforms. The collected and processed information, in turn, can be provided to recipients using any of a wide variety of push and pull methodologies as desired.

[0079] These teachings will facilitate, for example, receiving location information pertaining to an apparatus (such as a portable electronic device), accessing entity information regarding an entity (such as a person) that corresponds to the apparatus, the entity information pertaining to the entity' s planned participation in a calendared event, and using the location information and the entity information to automatically determine whether to source a message regarding impaired viability of the calendared event.

[0080] Those skilled in the art will recognize that a wide variety of modifications, alterations, and combinations can be made with respect to the above described embodiments without departing from the spirit and scope of the disclosed concept, and that such modifications, alterations, and combinations are to be viewed as being within the ambit of the inventive concept.

Claims

We claim:

1. A method comprising:

receiving location information from a presence service pertaining to an apparatus; and

using the location information to automatically assess viability of a calendared event.

2. The method of 1 wherein using the location information comprises, at least in part, using the location information as correlated to a particular time.

3. The method of claim 1 wherein using the location information to automatically assess viability of a calendared event comprises, at least in part, determining whether a person who is associated with the apparatus will be able to participate as planned in the calendared event notwithstanding the location information.

4. The method of claim 3 wherein using the location information to automatically assess viability of a calendared event further comprises, at least in part, determining, when the person is not able to participate as planned in view of the location information, whether the person is important to the calendared event.

5. The method of claim 1 further comprising:

when the location information challenges the viability of the calendared event, automatically providing a user with an opportunity to alter the calendared event.

6. The method of claim 1 wherein:

receiving location information from a presence service pertaining to an apparatus comprises receiving a plurality of location information updates from the presence service pertaining to the apparatus; and

using the location information to automatically assess viability of a calendared event comprises using the plurality of location information updates to monitor, over time, the viability of the calendared event.

7. The method of claim 6 wherein using the plurality of location information updates to monitor, over time, the viability of the calendared event comprises monitoring the viability of the calendared event more frequently over time when monitoring location information for an apparatus that corresponds to a person considered important to the calendared event.

8. The method of claim 1 further comprising:

providing information regarding viability of the calendared event to at least one recipient.

9. The method of claim 8 wherein the information regarding viability of the calendared event includes color-coded information representing viability of the calendared event.

10. The method of claim 8 wherein the information representing viability of the calendared event includes status information for at least one entity associated with the calendared event.

1 1 . The method of claim 10 wherein the status information comprises location information and wherein the entity comprises a scheduled calendared-event participant.

12. The method of claim 1 wherein the presence service comprises one of the group consisting of:

- a public presence service;

- a private presence service.

13. A method comprising:

receiving location information pertaining to an apparatus;

accessing entity information regarding an entity that corresponds to the apparatus, the entity information pertaining to the entity's planned participation in a calendared event; and using the location information and the entity information to automatically determine whether to source a message regarding impaired viability of the calendared event.

14. The method of claim 13 wherein the apparatus comprises a personal

communication device.

15. The method of claim 13 wherein the entity information comprises information regarding at least one of:

- whether the entity is planning to attend the calendared event in person;

- whether the entity is identified as being a necessary participant of the calendared event.

16. The method of claim 13 wherein receiving location information pertaining to an apparatus comprises receiving the location information from a presence service.

17. The method of claim 13 wherein the message includes, at least in part, an opportunity for a corresponding recipient to change the calendared event.

18. The method of claim 13 wherein the message includes, at least in part, color coding to convey information regarding viability of the calendared event.

19. A method comprising:

receiving an electronic message that includes non-location-based information pertaining to an entity; and

using the non-location-based information from the electronic message to automatically assess viability of a calendared event.

20. The method of claim 19 wherein the non-location-based information comprises information regarding at least one of:

- viability of a communications link;

- availability of a meeting facility; - a number of persons available to attend the calendared event;

- an indication of a calendared-event scheduled attendee's importance to the calendared event;

- an activity being engaged in by a person scheduled to attend the calendared event.

21 . The method of claim 19 further comprising maintaining a calendar that governs management of the calendared event.

22. The method of claim 21 further comprising:

automatically updating the calendar to reflect the viability of the calendared event.

23. The method of claim 22 wherein automatically updating the calendar to reflect the viability of the calendared event comprises, at least in part, using color coding to indicate viability information.

24. The method of claim 19 wherein receiving non-location-based information pertaining to an entity comprises receiving the non-location-based information from a presence server.

25. The method of claim 19 wherein receiving non-location-based information pertaining to an entity comprises receiving the non-location-based information from the entity.

26. The method of claim 19 further comprising:

receiving location-based information pertaining to the entity;

automatically using the location-based information to automatically

viability of the calendared event.

27. The method of claim 19 further comprising:

automatically publishing information regarding the assessed viability of calendared event.

28. The method of claim 27 wherein publishing the information comprises, at least in part, pushing the information to previously-determined watchers.

29. The method of claim 19 further comprising:

transmitting a request for the non-location-based information pertaining to an entity.

30. A method comprising:

receiving information from a user equipment (UE), the information pertaining to at least one of presence and location associated with a user of the UE;

deriving an indication for the user by processing the information regarding at least one of presence and location associated with a user of the UE

reflecting the indication in a meeting request managed by a calendar service that is configured as a logical observer.

31 . The method of claim 30 further comprising using the indication to assess viability of a calendared event.

32. The method of claim 30 further comprising notifying meeting participants regarding viability of the meeting request relative to the indication.