Patent Application
20200118045
There are a number of tools presently available for enabling people to conduct live meetings, conferences, presentations, or other types of gatherings. Typically, such meetings involve an organizer initially scheduling the meeting, identifying a location for the meeting, and sending invitations to the desired participants. Each invited participant can be provided a subject of the meeting, a time and date for the meeting, a location of the meeting and in some cases a list of other participants. An invited participant is then expected to attend the meeting at the scheduled time and place.
In order for meeting spaces to be conducive to group discussions and presentations, the availability of, or access to, specific rooms with various resources can be of great significance to meeting organizers and participants. For example, meeting participants frequently expect to make use of a telephone, computer, or other communication device that connects to a conference system or server. The meetings may also include an audio component and/or a visual component, such as a shared presentation, video, whiteboard, or other multimedia, text, graphics, etc. that require a particular technology component. Furthermore, individual participants may have their own room access and furniture needs that must be accommodated.
Organizers can search for rooms that provide the resources and/or configuration needed and are available at the desired time, but such a task is often burdensome and limited to the organizer's own knowledge of the available rooms, as well as company policies regarding room reservations. Such limitations can diminish the ability of organizations to maximize use of their own resources.
A reservation system, in accordance with a first aspect of this disclosure, includes at least one processor and one or more computer readable media. The computer readable media include instructions which, when executed by the at least one processor, cause the at least one processor to cause to be displayed, to a user, a first user interface including a first selectable option authorizing an automatic room reservation for at least a first meeting event scheduled to occur during a first time period. The instructions also cause the at least one processor to record, in response to a first user selection of the first selectable option, a first authorization to automatically reserve a room for the first meeting event. The instructions further cause the at least one processor to automatically initiate, in response to the recorded first authorization and at a time prior to the first meeting event, a first search for at least a first room that is available during the first time period. In addition, the instructions cause the at least one processor to automatically reserve the first room for use during the first time period.
A method of reserving a room for a meeting, in accordance with a second aspect of this disclosure, includes causing to be displayed, to a user, a first user interface. The first user interface includes a first selectable option authorizing an automatic room reservation for at least a first meeting event scheduled to occur during a first time period. The method also includes recording, in response to a first user selection of the first selectable option, a first authorization to automatically reserve a room for the first meeting event. In addition, the method includes automatically initiating, in response to the recorded first authorization and at a time prior to the first meeting event, a first search for at least a first room that is available during the first time period. Furthermore, the method involves automatically reserving the first room for use during the first time period.
A method of facilitating room selection for a meeting, in accordance with a third aspect of this disclosure, includes causing to be displayed, to a user, a first user interface. The first user interface includes a first input field for scheduling a time for a first meeting event and a second input field for selecting required meeting room resources. The method also includes receiving a start time and an end time for the first meeting event via the first input field. In addition, the method includes receiving a first room criterion via the second input field. The method further includes automatically initiating, in response to receiving the start time, the end time, and the first room criterion, a first search for one or more rooms that are available for use during the first meeting event and meet the first room criterion. The method also includes causing to be displayed, to the user, a list of suggested meeting rooms, the list of suggested meeting rooms including a first room of the one or more rooms that is available for use during the first meeting event and meets the first room criterion.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.
The drawing figures depict one or more implementations in accord with the present teachings, by way of example only, not by way of limitation. In the figures, like reference numerals refer to the same or similar elements. Furthermore, it should be understood that the drawings are not necessarily to scale.
In the following detailed description, numerous specific details are set forth by way of examples in order to provide a thorough understanding of the relevant teachings. However, it should be apparent that the present teachings may be practiced without such details. In other instances, well known methods, procedures, components, and/or circuitry have been described at a relatively high-level, without detail, in order to avoid unnecessarily obscuring aspects of the present teachings.
The following implementations introduce a method and system for automatic reservation or booking of a room for a scheduled meeting event. A meeting organizer may be offered options during the scheduling process (or at other stages or instances prior to the scheduled meeting) for enabling automatic room booking. Traditionally, room booking has included a series of steps where users can: (1) schedule a meeting; (2) identify a list of invitees; (3) select a date and time for the meeting; (4) search for available rooms of the desired size that include any resources necessary for the meeting; and (5) generate and send an invitation to participant(s). However, in many situations, organizers can be unaware of room status changes that occur between the time of scheduling and the meeting event. In addition, organizations frequently establish their own policies that can limit an organizer's ability to plan for events that occur regularly or will not occur until a more distant (future) date. Organizers can be frustrated by the inability to plan ahead for such recurring meetings or meetings being planned further into the future. In some cases, an organizer can forget they have an upcoming meeting in which a room has not been booked, and when they return later to make the booking they are not able to find a room suited to their needs, if at all. Organizers can be required to return to the scheduling system repeatedly, hoping for a cancellation of another booking for the desired room. In addition, if the meeting has been rescheduled to a different time, the room booking may not be updated, and result in a great deal of stress and delay to participants.
Even in cases where the organizer has booked a room, they may encounter situations where the room is under maintenance or otherwise undergoes changes that make the room no longer suitable for their needs, or where the resources needed for the meeting have changed. Similarly, if the number of invitees or expected attendees changes, the previously reserved room may no longer be suitable. Furthermore, in cases where the organizer is no longer in the employment of the company where the meeting was to be held, or is otherwise no longer available in the role of meeting organizer and fails to cancel the meeting before their departure, the room reservation will be (incorrectly) held, resulting in an inadvertent waste of resource(s). There may also be situations in which a recurring meeting is scheduled, but the participants are travelling or working off-site; in such a case, the original room reservation will no longer be useful, and a cancellation should occur, or a remote site may instead be needed.
As will be discussed in detail below, the disclosed implementations describe a system and method that provide straightforward solutions to these issues, providing for the automatic reservation of meeting rooms, as well as the automatic management of reserved rooms and other shared resources. The system can be configured to accommodate updates and other changes in the meeting configuration, room availability, or other user preferences. This mechanism will be provided to the user in a manner that maximizes convenience and efficiency. For example, the option to automatically book a room can be presented to an organizer as he or she is scheduling the meeting, during their review of a previously scheduled or recurring meeting, and/or while viewing reminders, calendar updates or previews, or other items associated with meeting preparation, information, or notifications. By removing the inconvenience of having to search for available rooms with the desired facilities or remembering to return to the meeting listing to update the room booking once the organization policies permit such a booking meeting, a user can make better use of their time, easily accommodate the needs of their presentations and participants, and optimize the management of resources in their organization. Furthermore, in some implementations, a user can customize the automated booking process, per their preferences, by identifying their favorite rooms or locations, or even make reference to favorite rooms of the meeting's other participants.
In general, a meeting event (“meeting”) refers to a real time, or near-real time, in-person use of a physical space. In general, this can involve an in-person communication session between two or more participants. However, in some implementations, only one person may be present in a room and connect to another participant via a telecommunications device, or a single person may wish to make use of a room at a specific time and day for their own purposes. Thus, the term meeting can encompass any event, activity, gathering, assembly, class, conference, convention, summit, session, get-together, congregation, reunion, or the like that may be prescheduled and includes the use of a particular resource. It should further be understood that references to the term “room” encompasses not only enclosed spaces in physical structures or buildings, but any physical space that can be the site of a meeting, enclosed, open, indoors, or outdoors. The room can also include a sub-structure or component(s) within a room, such as a cubicle, conference table, or other designated spaces or resources.
In addition, the term scheduled meeting as used generally refers to a meeting that has been scheduled for a particular date/time or has been designated to occur at a recurring day/time. It should be understood that the disclosed implementations may also be applicable to meetings that have not yet been scheduled. For example, as a user is creating the meeting, or before the meeting invite has been finalized.
As noted above, the option to automatically reserve a room for a meeting can be presented during various workflow instances of a meeting lifecycle. For example, a meeting lifecycle includes the time prior to a scheduled meeting. The workflow instances for a meeting therefore include any step, event, action, or communication associated with the meeting, and can include but are not limited to creation of the meeting, receipt of a meeting invite, communications between invitees of the meeting, meeting documents shared with invitees, agenda or calendar notifications related to the meeting, meeting updates, and so forth. Furthermore, the following implementations may refer to the concept of “first view”, which refers to an instance in which a participant first engages with information for the meeting; for example, while creating the meeting event, or while initially opening or viewing an invitation.
In general, usage of the terms “automatically reserve”, “automatically book”, “auto-reserve”, or “auto-book” refer to the capability of a system to automatically assign and hold one or more room or location options to a user for use at a predetermined date and time and/or as specified conditions are met. For example, if the auto-reserve feature is enabled, the system can be configured to search for a room that meets the organizer's preferences and is available at the stated date/time, present them to the organizer as recommendations, and/or automatically reserve the room without requiring further confirmation from the organizer. As another example, the system may not immediately identify a room for a specific meeting during the meeting creation process, but can be configured to continue searching ‘offline’ for an appropriate room and update the meeting listing when a suitable room is found and/or successfully booked. In addition, the system can be configured to generate and/or transmit notifications to the organizer and/or invitees to provide up-to-date information about the room location.
References to a meeting application, a scheduling application, an organizer application, or simply “application” may be understood to refer to any software applications configured to provide a means of scheduling, viewing, modifying, or organizing a meeting and corresponding meeting room, and/or communicating or transmitting or receiving data associated with the meeting. This can include any type of electronic calendar or electronic scheduling system that is capable of scheduling meetings or appointments. Some such programs can include Skype®, Microsoft Teams®, Microsoft Outlook®, GoToMeeting®, WebEx®, Zoom®, Join.Me®, Calendy®, Boomerang Calendar®, FreeBusy®, NeedToMeet®, Meekan®, Google Calendar®, GoogleHangouts®, AnyMeeting® and other applications that can provide meeting tools and/or facilitate communication or collaboration online. These are non-limiting examples, and any other communication-related application may benefit from the disclosed implementations. Specific references to a software application by name throughout this description should not therefore be understood to limit the use of the proposed systems and methods. It should further be understood that in some implementations, the application used to enable an auto-booking function may differ from the application used to schedule the meeting, while in other implementations, they may be the same.
In order to better introduce the systems and methods to the reader,
As will be described below, in different implementations, the scheduling interface can include a plurality of fields for receiving meeting-related input, including but not limited to a title or subject field, a location field, a start time and end time field(s), a meeting details, notes, or description field, and/or an invitees field. In some implementations, the application can be configured to present additional or alternate options to a user. It should be understood that a Settings option may be made available on each of the user interfaces described herein, whether or not explicitly identified.
In different implementations, each scheduler interface can be accessed by one or more computing device end-users, or simply “users”. As an example, one type of user may be a meeting organizer. An organizer 110 is depicted in
The first option 190 in
It should be understood that the text and specific wording shown in the figures are for purposes of illustration only and in no way limit the manner by which the application may communicate or receive information. In addition, while the first selectable option 190 is positioned beneath or below the first interface portion 130 in
In some implementations, a scheduler interface can also offer one or more auto-booking preferences. As one example, a second interface portion 140 is shown below first option 190, and presents options such as a number of meetings for which rooms should be auto-booked, or which dates or periods in which no rooms should be booked (e.g., “blackout dates”). Additional details regarding such preferences will be described below with reference to
Another implementation of a meeting management system is depicted in
A third implementation of a meeting management system is depicted in
As noted above, a scheduler interface can also offer one or more auto-booking preferences. As one example, a fourth interface portion 144 is shown below second option 194, and presents options such as the building in which the meeting room should be located and the floors of the building that include rooms that may be auto-booked. In other words, a user can ‘vaguely’ or broadly set a boundary or limitation on the pool of rooms that may be considered by the system and auto-booked. This feature can be very attractive to users who often do not need or care to specify a room but simply want assurance that a room will be booked in a general location. Additional details regarding this process will be described below with reference to
As noted above with reference to
In one implementation, a user may manually input or otherwise designate a room or space that the meeting should occur. The user can input a room or space identifier (here shown as “Room 754B”) directly into the location field 218. In some implementations, the system may update the display of the first interface 200 in real-time to inform the user the upcoming availability of the selected room for the date/time chosen. In this example, the user is shown that Room 754B is available for the next two meetings of this recurring event series. In other words, Room 754B is confirmed for use during the first meeting and the second meeting (e.g., the next Tuesday and the next Friday), but cannot be confirmed beyond these two meetings.
In order for an organizer to confidently plan ahead for all foreseeable future meetings beyond—in this case—the second meeting, there is strong motivation to ensure each of those meetings will have a suitable room booked in advance of each meeting. However, an organizer faces an onus in trying to ‘keep up’ with each week of meetings and updating the calendar and event details as a particular room becomes available, repeatedly reviewing the room resource(s) status to see if a desired room has opened up, as well as ensuring each participant is informed about updates or changes in location for each event.
The proposed implementation allows the organizer to relinquish the burden of resource management for all future meetings. In
In some implementations, additional input received by the system can fine-tune the auto-reserve mechanism. In
In different implementations, the proposed systems may include provisions for automatically booking, updating, or otherwise modifying rooms for a meeting and notifying a user of such actions. These notifications can occur via a user's electronic calendar, agenda, planner, reminders, to-do list, ‘toasts’ (pop-up messages), or other communications associated with the upcoming meeting. Referring to
The organizer had also enabled the auto-reservation function in
Thus, with respect to future meeting dates, the system will take into account a variety of factors and preferences of the user and make a determination offline (i.e., in the background, without further user input or interaction) where each meeting will be held. This process can occur at any time prior to the next scheduled meeting. It should be understood that a room assignment can also be automatically revisited and/or modified if another room that is more suitable or closer to the user's preferences (a better or stronger match) becomes available at any time prior to the meeting start time, or up until a “latest” time selected by the user or set as a system default.
The calendar 300 of
In some implementations, the system may include provisions for calculating and assigning a confidence value to its determination that a particular room will be suitable for the meeting. In one implementation, the system may be configured to automatically book and confirm a room for a meeting, and/or communicate a notification of the room assignment when the confidence value is at or above a pre-specified threshold (e.g., 80%, 87%, 95%, 99%, etc.). If the confidence value falls below the threshold, the system can be configured to book the room (or place a temporary hold) and submit a request to the organizer to confirm whether the room is acceptable. This threshold value can be provided by the system, or can be customized by the user. In another implementation, a first room can be initially booked, and if another, second room that is associated with a greater confidence value becomes available subsequent to this first booking, the system can automatically modify the booking to secure the more suitable or optimal room for the meeting.
As noted earlier, in some implementations, a room booking system may be regulated by various resource usage policies and prevented or blocked from booking rooms beyond a certain date (e.g., 6 weeks from the current date, 2 months from the current date, 1 year from the current date, etc.). In such cases, the auto-booking mechanism can be configured to postpone or ‘pause’ its search for a room for meetings that occur past this date, and then automatically make a booking as soon as the restricted time period has elapsed for an upcoming meeting, thereby ensuring the user is provided with a confirmed room at the earliest time, this feature also increases the likelihood of reserving a room that is best suited to the meeting. In addition, as more users opt to use or otherwise rely on automatic booking, the system can consider or compare the requirements of each meeting, or preferences of each user, across multiple meeting events in the organization to determine the optimal room assignment result for the group as a whole, maximizing the allocation of resources and reducing inter-organization friction.
Of course, in some cases, an organizer may disagree or otherwise dislike the room choice made by the auto-booking system. The system can include provisions for allowing a user to readily access the meeting parameters and manually modify the assigned room. One example of this is illustrated by a selectable icon 340, which when triggered can provide the user with a means of cancelling the booking or searching for a different room. Such an option can be provided at any time prior to the meeting, and may be offered across various notification types.
In different implementations, a conference organization request, reminder, or other notification can be sent to the organizer or invitee(s) (e.g., a meeting invitation, meeting update or change message, meeting alert, etc.), typically including details for the upcoming scheduled meeting. In
These and other types of meeting notification can be presented at any time prior to the meeting, and can identify the meeting and indicate the location of the meeting as well as any other details that may help the users prepare for the meeting. For example, in the period of time leading up to the meeting, the meeting location may change one or more times, the meeting that had previously had a “TBA” (to be assigned) location status can confirm a room booking, and/or the reservation can transition from a tentative booking to a confirmed booking, as well as other changes. Thus, alerts and notifications can serve an important function in ensuring users are kept up-to-date on the status and location of the meeting, particularly during use of a system that is capable of flexibility during the room booking process.
It can be understood that a large majority of instances in which users schedule meetings and book rooms occur online or electronically. However, users can be somewhat less reliable in returning to a meeting reservation that has been rescheduled offline or cancelled in person (i.e., no update is made electronically) or otherwise ensuring their modified plans are reflected by the booking shown online. As an example, a room most desired by an organizer for a first meeting may not be shown as available due to another reservation made for the same room for a second meeting that overlaps with the meeting time of the first meeting. Even if the second meeting participants are aware that the second meeting has been cancelled or rescheduled or moved to another location (e.g., by word of mouth, over the phone, a sign on a door, in-person communications) and the room is now available, it remains listed as booked. In some implementations, the proposed system can include provisions for verifying the scheduled use of a room is actually occurring in real-time by making reference to room occupancy or motion sensors and/or by reference to user-to-user communications, user location tracking, usage of sick days or vacation days, calendar conflicts, or other such data.
For example, a sensor may detect an activity of a user within the meeting space. The detected activity may be a motion, a sound, a connection of a client device to a communal meeting device, as a few examples. The sensor(s) can be configured to determine whether the meeting space has a scheduled meeting that intersects with a first time period (when the meeting is scheduled), where the first time period starts with the detected activity and ends based on a default time period, pre-set time slots, and a start time of a next scheduled meeting within the meeting space. In some implementations, a sensor may be configured to monitor activity of users within the meeting space, throughout the first time period, and may delete or extend the meeting room reservation based on whether activity within the meeting space is detected throughout and upon the expiration of the first time period. In other words, in one implementation, real-time usage of a resource can be ascertained and used to automatically update the booking system. This can increase an organizer's confidence that the room(s) they most prefer will continue to be considered—even when it has been shown as having been booked elsewhere—and that usage of an organization's space will be maximized at all times.
Referring next to
In different implementations, the system may include provisions for receiving a user's required or preferred room types, access, or tools for the upcoming meeting. For purposes of illustration, in
The second interface 400 also includes a location field 430, where a user may manually input or otherwise designate a room or space where the meeting should occur. The user can, for example, type directly into the location field 430 a room or space identifier. In some cases, the initial input of an alphanumeric text may trigger a list of suggestions. In some other implementations, the system may immediately (i.e., without any input from the user) display suggested locations 440 for the user's review, for example in a drop-down menu or pop-up window or other native control. Each suggested location presented can be based at least in part on a user's previous room booking history, rooms that a user has identified as favorite, rooms that have been previously booked for this particular meeting, distance of the room from the participants, and/or room availability. In addition, as discussed above with reference to Room Requirement section 420, a user may also provide guidance or otherwise direct or limit range of rooms that may be suggested.
In this particular example, the suggested locations 440 include a first location 442, a second location 444, a third location 446, and a fourth location 448. The suggested locations 440 can be listed in order of likely preference for this user. In addition, information that is determined to be of relevance to the user can also be presented to facilitate a more efficient room selection. In this case, each location is displayed with a room identifier, the room's suggested or maximum capacity, and indication of its availability. Some locations may also be associated with a ‘favorite’ indicator for the organizer or participant(s) that can help organizers determine which room would be most suitable to the group as a whole. In this example, the first location 442 has been favorited by 12 members of the invitee list, the second location 444 has been favorited by 9 members of the invitee list, and the third location 446 has been favorited by 4 members of the invitee list. By allowing users to share and receive information as they schedule meetings and/or presenting this information during the meeting scheduling process, the likelihood of choosing a room that is optimal for the most, if not all, participants is greatly increased, and the booking process itself is significantly simplified.
In
In different implementations, additional or other rooms can be suggested based on user history, as shown in a second suggestion 520 (used 4 times in the last month), a third suggestion 522 (used 3 times in the last month), and a fourth suggestion 524 (used this week). Furthermore, the system may make use of information regarding overall room popularity or popularity for a specific time of day, as represented by a fifth suggestion 526. In one implementation, each option can be understood to also meet the criteria specified by the user in the Room Requirement section 420 of
In
In different implementations, additional or other rooms can be added to the list (see a first selectable favorites option 570), and/or the current list can be edited (see a second selectable favorites option 572). Furthermore, in some implementations, and based on privacy or sharing settings for the members of the group, a user may be able to view another invitee's favorites list (see a third selectable favorites option 574), as well as the room that has been favorited by the most users (see a fourth selectable favorites option 576). While the favorites list may provide a broad range of room selections, it should be understood that in some implementations, a user can filter the favorites listing such that only those rooms that match the criteria specified by the user in the Room Requirement section 420 of
As introduced above with reference to
In different implementations, a user can provide an input to the location field 610 a room or space identifier. In this example, the user has inputted a room ('Room 135”) and a building 614 (“Howard”). In some implementations, the system may update the display of the third interface 600 in real-time to inform the user of the upcoming availability of the selected room for the day/time chosen. An availability notification 620 indicates only that Room 135 is available for the next (upcoming) meeting, but is not able to confirm a booking of that room beyond the next meeting date. This type of situation can occur frequently, and be a source of frustration for organizers, who desire the certainty of a room reservation, and are flexible regarding the actual room that is selected.
The system can, in some implementations, include provisions for enabling auto-booking for a series of meetings without requiring any particular room identification by the organizer. Instead, an organizer can simply indicate a broad location category 680 for the desired room, and the system can take care of the remaining steps. As shown in
In
As noted above, the proposed systems may include provisions for automatically booking, updating, or otherwise modifying rooms for a meeting as well as notifying a user of such changes. Referring to
The organizer in
In different implementations, a conference organization request, reminder, or other notification can be sent to the organizer or invitee(s) (e.g., a meeting invitation, meeting update or change message, meeting alert, etc.), typically including details for the upcoming scheduled meeting. In
It can be understood that two or more of the features described with respect to each of the disclosed implementations above can be combined to provide a different type of interface. One example of a more ‘comprehensive’ auto-booking system is illustrated in
If an auto-reserve option 892 is selected, however, as shown in the second portion 802 of
In order to further the reader's understanding of the proposed systems, a schematic flow diagram depicting one implementation of the system is illustrated in
If, despite a repeated or ongoing search, there are no rooms available that meet the criteria, the system can send a notification to the organizer in a sixth step 932. This provides the organizer an opportunity to perhaps reschedule the meeting, broaden their search parameters, or identify a meeting room manually, or ask a colleague in possession of a desired room during the meeting time to ‘swap’ or make some other arrangements. If, on the other hand, rooms are available, the system can determine which room (if there is more than one) has the greatest likelihood of satisfying the preferences of the user in a seventh step 940. The room can be booked and the organizer notified in an eighth step 950. For example, a notification can be sent to the organizer (and in some cases the participants) confirming the room booking, requesting that the organizer confirm the room is acceptable, or providing the organizer an opportunity to request that the system re-run the search.
As noted earlier, in some implementations, the system can continue to search for rooms that may be a better or closer match, even after identifying and/or booking a room. If a more desirable room is found, and the organizer has authorized automatic modifications of the reservation, the room booking may be automatically updated. If no such authorization was given, the system may send a message to the organizer asking if they would like to ‘upgrade’ the meeting room.
Through the application of such a system, users can be relieved of the stress and expenditure of time needed to find and book a suitable room for any number of future meetings. Users can identify their preferences for various aspects and steps leading to the room reservation, or the system can implement default settings. For example, in some implementations, user or default settings can specify how and when the reservation should be made, as well as what resources should be available in the room. In addition, the system can keep track of the status of each of the rooms, and if a room that has been booked for a future meeting is unexpectedly scheduled for maintenance or is no longer a match for the organizer's needs, the system can automatically search for a new room.
A subsequent second step 1020 includes recording, in response to a first user selection of the first selectable option, a first authorization to automatically reserve a room for the first meeting event. A third step 1030 includes automatically initiating, in response to the recorded first authorization and at a time prior to the first meeting event, a first search for at least a first room that is available during the first time period. A fourth step 1040 involves automatically reserving the first room for use during the first time period.
In other implementations, the method can include additional or alternate steps. For example, the first selectable option can further authorize automatic room reservations for each of a plurality of recurring meeting events including the first meeting event and a subsequent second meeting event. In addition, the method may further include automatically initiating, in response to the recorded first authorization and at a time prior to the second meeting event, a second search for at least a second room that is available during a second time period in which the second meeting event is scheduled to occur, as well as automatically reserving the second room for use during the second time period.
Alternatively, the method can include automatically initiating, in response to the recorded first authorization and at a time prior to the second meeting event, a second search for a room that is available during a second time period in which the second meeting event is scheduled to occur, and determining that there is no room available for use during the second time period. In this case, the method can further include automatically transmitting, to the user, a message indicating that no room is currently available for use during the second time period.
As another example, the method may involve accessing a directory of currently authorized users of an automatic room reservation system, and then determining, based on the accessing of the directory, that the user is no longer an authorized user. In this case, the method can also include automatically canceling the reservation of the first room. In some implementations, the method may involve accessing a resource usage policy associated with an automatic room reservation system, and then determining, based on the accessing of the resource usage policy, that there is a policy precluding reservation of a room for the first meeting for a predetermined period of time prior to the start time of the first meeting. In this case, the method can further include delaying the initiation of the first search until after the expiration of the predetermined period of time.
In another example, the method can include receiving, from the user, a first room criterion, and then creating, in response receiving the first room criterion, a first filter configured to automatically limit the first search to rooms that meet the first room criterion. The method can also include automatically applying the first filter to the first search when the first search is initiated. In some implementations, the first room criterion can correspond to a requirement or preference, for example by the user, that the first room include one or more of a teleconferencing system, a minimum room capacity, and accessibility for persons with disabilities. In another implementation, the first room criterion can correspond to a requirement or preference, for example by the user, that the first room be located within a specific building.
Furthermore, in some implementations, the method may involve detecting, after the reserving of the first room, a change in room availability for the first time period, and then automatically initiating, in response to the detection of the change in room availability, a second search for at least a second room that is available during the first time period. In addition, the method can include determining the second room is a better match with the first room criterion than the first room. This can be based on a comparison of the confidence value assigned to the first room and with the confidence value assigned to the second room in some implementations. In another implementation, this can be based on a determination that the second room is more proximate to the user's location on the date of the first meeting than the first room. In one implementation, this can be based on a higher number of preferences being matched or met by the second room relative to the first room. The method may also include automatically reserving the second room for use during the first time period, and automatically canceling the reservation of the first room. In some implementations, the detection of the change in room availability is based on data obtained by an occupancy sensor associated with the second room, while in other implementations, the cancellation of a room booking for another meeting event can trigger the detection of the change in room availability.
In another implementation, the method can involve detecting, after the reserving of the first room, a change in status for the first room, and then automatically initiating, in response to the detection of the change in status, a second search for at least a second room that is available during the first time period. In addition, the method can include automatically reserving the second room for use during the first time period, and automatically canceling the reservation of the first room.
It should be understood that in different implementations, the method can vary. For example, another method that is within the scope of this application directed toward facilitating selections of meeting rooms includes a first step of causing to be displayed, to a user, a first user interface. The first user interface include a first input field for scheduling a time for a first meeting event and a second input field for selecting required meeting room resources. The method also includes receiving a start time and an end time for the first meeting event via the first input field, and receiving a first room criterion via the second input field. In addition, the method may involve automatically initiating, in response to receiving the start time, the end time, and the first room criterion, a first search for one or more rooms that are available for use during the first meeting event and meet the first room criterion. Furthermore, the method can include causing to be displayed, to the user, a list of suggested meeting rooms, where the list of suggested meeting rooms include a first room of the one or more rooms that is available for use during the first meeting event and meets the first room criterion. In some implementations, the method may further include accessing a list of preferred rooms for the user, and causing to be displayed, to the user, a second room of the one or more rooms that is available for use during the first meeting event and is on the list of preferred rooms.
As a general matter, an example system for management of room reservations for meetings can include or access a network environment. As one non-limiting example, a system can include a data center that can host a cloud-based communication service configured to enable users to share content, interact and communicate with one another, create and share calendars, and schedule meetings, among other things, through various communication modes, such as e-mail, text message, call and video conferencing and the like. A datacenter can include one or more processing servers that are configured to execute various communication services. In one implementation, a processing server is operable to execute a reservation module associated with the communication service. The data center may also include one or more storage servers configured to manage one or more data stores comprising data associated with content stored by the communication service and/or data associated with the reservation module. Furthermore, the communication service(s) and/or reservation module(s) may be implemented as software, hardware, or combinations thereof.
In some implementations, the communication service may be configured to inter-operate with different applications in order to provide its services. For example, a client application may be an application hosted by the communication service such as a calendaring application. There may also be a sensor detection module configured to process signals received from sensors and/or inputs from the meeting rooms. The sensors may include motion detectors, proximity sensors, optical sensors, cameras, microphones, near-field communication (NFC) devices, and/or Bluetooth devices, among other types of sensors. The inputs may include a high-definition multimedia interface (HDMI) port, and software entry points, among other types of inputs. A detection module may be configured to process the signals received from the sensors to detect an activity of the users within various meeting spaces. In some other implementations, a detection module may be configured to determine an identity of the users within a meeting space by processing signals received from the sensors. For example, users may be wearing employee badges with a barcode, or provide biometric input such as finger printing, facial recognition, voice recognition, and iris recognition, among other examples.
Use of the disclosed systems and methods can enable users to schedule meetings for some future date and be presented an option to auto-reserve a physical space for each meeting. In other words, in conjunction with their establishing the details of a meeting such as date, time, invitees, etc., a user can easily opt to enjoy the convenience of automatic room reservations for each meeting date. The user no longer needs to search through different rooms, determine which rooms accommodate the needs of their meeting and participants. The ability to deliberately select this option for individual or recurring meetings during the process of creating a meeting offers a wide range of benefits to organizers. This feature substantially reduces the time needed to organize and prepare for the meeting, the stress of finding a room that includes the resources desired by the organizer, and the aggravation of following up on each individual future meeting and ensuring a room has been booked. Furthermore, users are offered a straightforward means by which to implement their preferences for selecting a room, as well as the ability to easily change one's mind about their preferred rooms or resources.
For the sake of simplicity of description, details are not provided herein for performing various connection processes and the configuration of different telecommunication components. Implementations of the present disclosure can make use of any of the features, systems, components, devices, and methods described in U.S. Patent Publication Number 2018/0253666 to Fix, published Sep. 6, 2018 and entitled “Automatic reservation of meeting space through communal meeting device”; U.S. Patent Publication Number 2016/0180259 to Marianko et al., published Jun. 23, 2016 and entitled “Real-time Automatic Meeting Room Reservation Based on the Number of Actual Participants”; U.S. Patent Publication Number 2015/0186850 to Ramji, published Jul. 2, 2015 and entitled “Smart Meeting Creation and Management”; U.S. Patent Publication Number 2009/0299807 to Schiller et al., published on Dec. 3, 2009 and entitled “Scheduling opportunity previewer”; U.S. Patent Publication Number 2017/0308866 to Dotan-Cohen et al., published on Oct. 26, 2017 and entitled “Meeting Scheduling Resource Efficiency”; U.S. Pat. No. 7,707,256 to Rollin et al., issued on Apr. 27, 2010 and entitled “Suggesting meeting locations for conducting meetings”; U.S. Pat. No. 9,578,461 to Benzatti et al., issued on Feb. 21, 2017 and entitled “Location context, supplemental information, and suggestions for meeting locations”; U.S. Pat. No. 9,760,870 to Nortan et al., issued on Sep. 12, 2017 and entitled “Systems and methods for scheduling events”; U.S. Patent Publication Number 2015/0058425 to Nathan et al., published on Feb. 26, 2015 and entitled “Smart meeting service”; U.S. Patent Publication Number 2008/0133282 to Landar et al., published on Jun. 5, 2008 and entitled “Meeting resource scheduling based upon attendance participation types”; U.S. Patent Publication Number 2012/0078676 to Adams et al., published on Mar. 29, 2012 and entitled “Meeting room scheduling system including room occupancy sensor and related methods”; U.S. Pat. No. 8,041,586 to Jethani et al., issued on Oct. 18, 2011 and entitled “Shared space availability by dynamically responding to user utilization behavior of saved space”; U.S. Pat. No. 7,693,736 to Chu et al., issued on Apr. 6, 2010 and entitled “Recurring meeting schedule wizard”; and U.S. Pat. No. 9,626,660 to Bathiya et al., issued on Apr. 18, 2017 and entitled “Conflict management in scheduling meetings”; as well as each of their disclosed methods and systems for the management of meetings and room reservations and so forth, the disclosures of each of which are herein incorporated by reference in their entirety.
The detailed examples of systems, devices, and techniques described in connection with
In some examples, a hardware module may be implemented mechanically, electronically, or with any suitable combination thereof. For example, a hardware module may include dedicated circuitry or logic that is configured to perform certain operations. For example, a hardware module may include a special-purpose processor, such as a field-programmable gate array (FPGA) or an Application Specific Integrated Circuit (ASIC). A hardware module may also include programmable logic or circuitry that is temporarily configured by software to perform certain operations, and may include a portion of machine-readable medium data and/or instructions for such configuration. For example, a hardware module may include software encompassed within a programmable processor configured to execute a set of software instructions. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (for example, configured by software) may be driven by cost, time, support, and engineering considerations.
Accordingly, the phrase “hardware module” should be understood to encompass a tangible entity capable of performing certain operations and may be configured or arranged in a certain physical manner, be that an entity that is physically constructed, permanently configured (for example, hardwired), and/or temporarily configured (for example, programmed) to operate in a certain manner or to perform certain operations described herein. As used herein, “hardware-implemented module” refers to a hardware module. Considering examples in which hardware modules are temporarily configured (for example, programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where a hardware module includes a programmable processor configured by software to become a special-purpose processor, the programmable processor may be configured as respectively different special-purpose processors (for example, including different hardware modules) at different times. Software may accordingly configure a particular processor or processors, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time. A hardware module implemented using one or more processors may be referred to as being “processor implemented” or “computer implemented.”
Hardware modules can provide information to, and receive information from, other hardware modules. Accordingly, the described hardware modules may be regarded as being communicatively coupled. Where multiple hardware modules exist contemporaneously, communications may be achieved through signal transmission (for example, over appropriate circuits and buses) between or among two or more of the hardware modules. In implementations in which multiple hardware modules are configured or instantiated at different times, communications between such hardware modules may be achieved, for example, through the storage and retrieval of information in memory devices to which the multiple hardware modules have access. For example, one hardware module may perform an operation and store the output in a memory device, and another hardware module may then access the memory device to retrieve and process the stored output.
In some examples, at least some of the operations of a method may be performed by one or more processors or processor-implemented modules. Moreover, the one or more processors may also operate to support performance of the relevant operations in a “cloud computing” environment or as a “software as a service” (SaaS). For example, at least some of the operations may be performed by, and/or among, multiple computers (as examples of machines including processors), with these operations being accessible via a network (for example, the Internet) and/or via one or more software interfaces (for example, an application program interface (API)). The performance of certain of the operations may be distributed among the processors, not only residing within a single machine, but deployed across a number of machines. Processors or processor-implemented modules may be located in a single geographic location (for example, within a home or office environment, or a server farm), or may be distributed across multiple geographic locations.
The example software architecture 1102 may be conceptualized as layers, each providing various functionality. For example, the software architecture 1102 may include layers and components such as an operating system (OS) 1114, libraries 1116, frameworks 1118, applications 1120, and a presentation layer 1144. Operationally, the applications 1120 and/or other components within the layers may invoke API calls 1124 to other layers and receive corresponding results 1126. The layers illustrated are representative in nature and other software architectures may include additional or different layers. For example, some mobile or special purpose operating systems may not provide the frameworks/middleware 1118.
The OS 1114 may manage hardware resources and provide common services. The OS 1114 may include, for example, a kernel 1128, services 1130, and drivers 1132. The kernel 1128 may act as an abstraction layer between the hardware layer 1104 and other software layers. For example, the kernel 1128 may be responsible for memory management, processor management (for example, scheduling), component management, networking, security settings, and so on. The services 1130 may provide other common services for the other software layers. The drivers 1132 may be responsible for controlling or interfacing with the underlying hardware layer 1104. For instance, the drivers 1132 may include display drivers, camera drivers, memory/storage drivers, peripheral device drivers (for example, via Universal Serial Bus (USB)), network and/or wireless communication drivers, audio drivers, and so forth depending on the hardware and/or software configuration.
The libraries 1116 may provide a common infrastructure that may be used by the applications 1120 and/or other components and/or layers. The libraries 1116 typically provide functionality for use by other software modules to perform tasks, rather than rather than interacting directly with the OS 1114. The libraries 1116 may include system libraries 1134 (for example, C standard library) that may provide functions such as memory allocation, string manipulation, file operations. In addition, the libraries 1116 may include API libraries 1136 such as media libraries (for example, supporting presentation and manipulation of image, sound, and/or video data formats), graphics libraries (for example, an OpenGL library for rendering 2D and 3D graphics on a display), database libraries (for example, SQLite or other relational database functions), and web libraries (for example, WebKit that may provide web browsing functionality). The libraries 1116 may also include a wide variety of other libraries 1138 to provide many functions for applications 1120 and other software modules.
The frameworks 1118 (also sometimes referred to as middleware) provide a higher-level common infrastructure that may be used by the applications 1120 and/or other software modules. For example, the frameworks 1118 may provide various graphic user interface (GUI) functions, high-level resource management, or high-level location services. The frameworks 1118 may provide a broad spectrum of other APIs for applications 1120 and/or other software modules.
The applications 1120 include built-in applications 1140 and/or third-party applications 1142. Examples of built-in applications 1140 may include, but are not limited to, a contacts application, a browser application, a location application, a media application, a messaging application, and/or a game application. Third-party applications 1142 may include any applications developed by an entity other than the vendor of the particular platform. The applications 1120 may use functions available via OS 1114, libraries 1116, frameworks 1118, and presentation layer 1144 to create user interfaces to interact with users.
Some software architectures use virtual machines, as illustrated by a virtual machine 1148. The virtual machine 1148 provides an execution environment where applications/modules can execute as if they were executing on a hardware machine (such as the machine 1000 of
The machine 1200 may include processors 1210, memory 1230, and I/O components 1250, which may be communicatively coupled via, for example, a bus 1202. The bus 1202 may include multiple buses coupling various elements of machine 1200 via various bus technologies and protocols. In an example, the processors 1210 (including, for example, a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), an ASIC, or a suitable combination thereof) may include one or more processors 1212a to 1212n that may execute the instructions 1216 and process data. In some examples, one or more processors 1210 may execute instructions provided or identified by one or more other processors 1210. The term “processor” includes a multi-core processor including cores that may execute instructions contemporaneously. Although
The memory/storage 1230 may include a main memory 1232, a static memory 1234, or other memory, and a storage unit 1236, both accessible to the processors 1210 such as via the bus 1202. The storage unit 1236 and memory 1232, 1234 store instructions 1216 embodying any one or more of the functions described herein. The memory/storage 1230 may also store temporary, intermediate, and/or long-term data for processors 1210. The instructions 1216 may also reside, completely or partially, within the memory 1232, 1234, within the storage unit 1236, within at least one of the processors 1210 (for example, within a command buffer or cache memory), within memory at least one of I/O components 1250, or any suitable combination thereof, during execution thereof. Accordingly, the memory 1232, 1234, the storage unit 1236, memory in processors 1210, and memory in I/O components 1250 are examples of machine-readable media.
As used herein, “machine-readable medium” refers to a device able to temporarily or permanently store instructions and data that cause machine 1200 to operate in a specific fashion. The term “machine-readable medium,” as used herein, does not encompass transitory electrical or electromagnetic signals per se (such as on a carrier wave propagating through a medium); the term “machine-readable medium” may therefore be considered tangible and non-transitory. Non-limiting examples of a non-transitory, tangible machine-readable medium may include, but are not limited to, nonvolatile memory (such as flash memory or read-only memory (ROM)), volatile memory (such as a static random-access memory (RAM) or a dynamic RAM), buffer memory, cache memory, optical storage media, magnetic storage media and devices, network-accessible or cloud storage, other types of storage, and/or any suitable combination thereof. The term “machine-readable medium” applies to a single medium, or combination of multiple media, used to store instructions (for example, instructions 1216) for execution by a machine 1200 such that the instructions, when executed by one or more processors 1210 of the machine 1200, cause the machine 1200 to perform and one or more of the features described herein. Accordingly, a “machine-readable medium” may refer to a single storage device, as well as “cloud-based” storage systems or storage networks that include multiple storage apparatus or devices.
The I/O components 1250 may include a wide variety of hardware components adapted to receive input, provide output, produce output, transmit information, exchange information, capture measurements, and so on. The specific I/O components 1250 included in a particular machine will depend on the type and/or function of the machine. For example, mobile devices such as mobile phones may include a touch input device, whereas a headless server or IoT device may not include such a touch input device. The particular examples of I/O components illustrated in
In some examples, the I/O components 1250 may include biometric components 1256 and/or position components 1262, among a wide array of other environmental sensor components. The biometric components 1256 may include, for example, components to detect body expressions (for example, facial expressions, vocal expressions, hand or body gestures, or eye tracking), measure biosignals (for example, heart rate or brain waves), and identify a person (for example, via voice-, retina-, and/or facial-based identification). The position components 1262 may include, for example, location sensors (for example, a Global Position System (GPS) receiver), altitude sensors (for example, an air pressure sensor from which altitude may be derived), and/or orientation sensors (for example, magnetometers).
The I/O components 1250 may include communication components 1264, implementing a wide variety of technologies operable to couple the machine 1200 to network(s) 1270 and/or device(s) 1280 via respective communicative couplings 1272 and 1282. The communication components 1264 may include one or more network interface components or other suitable devices to interface with the network(s) 1270. The communication components 1264 may include, for example, components adapted to provide wired communication, wireless communication, cellular communication, Near Field Communication (NFC), Bluetooth communication, Wi-Fi, and/or communication via other modalities. The device(s) 1280 may include other machines or various peripheral devices (for example, coupled via USB).
In some examples, the communication components 1264 may detect identifiers or include components adapted to detect identifiers. For example, the communication components 1264 may include Radio Frequency Identification (RFID) tag readers, NFC detectors, optical sensors (for example, one- or multi-dimensional bar codes, or other optical codes), and/or acoustic detectors (for example, microphones to identify tagged audio signals). In some examples, location information may be determined based on information from the communication components 1262, such as, but not limited to, geo-location via Internet Protocol (IP) address, location via Wi-Fi, cellular, NFC, Bluetooth, or other wireless station identification and/or signal triangulation.
Furthermore, implementations of the present disclosure can make use of any of the features, systems, components, devices, and methods described in U.S. Pat. No. 8,660,978 to Hinckley et al., issued Feb. 25, 2014 and titled “Detecting and Responding to Unintentional Contact with a Computing Device,” the disclosure of which is herein incorporated by reference in its entirety.
While various implementations have been described, the description is intended to be exemplary, rather than limiting, and it is understood that many more implementations and implementations are possible that are within the scope of the implementations. Although many possible combinations of features are shown in the accompanying figures and discussed in this detailed description, many other combinations of the disclosed features are possible. Any feature of any implementation may be used in combination with or substituted for any other feature or element in any other implementation unless specifically restricted. Therefore, it will be understood that any of the features shown and/or discussed in the present disclosure may be implemented together in any suitable combination. Accordingly, the implementations are not to be restricted except in light of the attached claims and their equivalents. Also, various modifications and changes may be made within the scope of the attached claims.
While the foregoing has described what are considered to be the best mode and/or other examples, it is understood that various modifications may be made therein and that the subject matter disclosed herein may be implemented in various forms and examples, and that the teachings may be applied in numerous applications, only some of which have been described herein. It is intended by the following claims to claim any and all applications, modifications and variations that fall within the true scope of the present teachings.
Unless otherwise stated, all measurements, values, ratings, positions, magnitudes, sizes, and other specifications that are set forth in this specification, including in the claims that follow, are approximate, not exact. They are intended to have a reasonable range that is consistent with the functions to which they relate and with what is customary in the art to which they pertain.
The scope of protection is limited solely by the claims that now follow. That scope is intended and should be interpreted to be as broad as is consistent with the ordinary meaning of the language that is used in the claims when interpreted in light of this specification and the prosecution history that follows and to encompass all structural and functional equivalents. Notwithstanding, none of the claims are intended to embrace subject matter that fails to satisfy the requirement of Sections 101, 102, or 103 of the Patent Act, nor should they be interpreted in such a way. Any unintended embracement of such subject matter is hereby disclaimed.
Except as stated immediately above, nothing that has been stated or illustrated is intended or should be interpreted to cause a dedication of any component, step, feature, object, benefit, advantage, or equivalent to the public, regardless of whether it is or is not recited in the claims.
It will be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein. Relational terms such as first and second and the like may be used solely to distinguish one entity or action from another without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises,” “comprising,” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element proceeded by “a” or “an” does not, without further constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.
The Abstract of the Disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed Description, it can be seen that various features are grouped together in various examples for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claims require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed example. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.
