阅读说明：本技术 实时检测和解决共享资源的冲突的系统 (System for real-time detection and resolution of conflicts in shared resources ) 是由 葛文豪 于 2018-12-29 设计创作，主要内容包括：一种管理共享资源的方法,包括：在接收到用于延长对共享资源的当前使用的请求时,检测当前使用的所请求的结束时间与后续使用的较早的开始时间之间的资源数据的冲突。在一个示例中,共享资源可以是会议室,使用是相邻地安排的会议。该方法还包括：响应于检测到冲突,(1)接收关于请求的准许指示,以及(2)响应于标识对请求的接受的准许指示,(a)计算当前使用的许可的延长时间,以及(b)更新资源数据,以将许可的延长时间加到当前使用的安排的结束时间和后续使用的安排的开始时间,以便能够在不冲突的情况下使用共享资源。(A method of managing shared resources, comprising: upon receiving a request to extend a current use of a shared resource, a conflict of resource data between a requested end time of the current use and an earlier start time of a subsequent use is detected. In one example, the shared resource may be a conference room, and the usage is a adjacently arranged conference. The method further comprises the following steps: in response to detecting a conflict, (1) receiving a grant indication for the request, and (2) in response to the grant indication identifying acceptance of the request, (a) calculating a permitted extension time for the current use, and (b) updating the resource data to add the permitted extension time to a scheduled end time for the current use and a scheduled start time for a subsequent use to enable use of the shared resource without conflict.)

1. A method of managing shared resources, comprising:

in response to receiving a request to extend a current use of a shared resource, detecting a conflict of resource data between a requested end time of the current use and a start time of a subsequent use of the shared resource, the requested end time being later than a scheduled start time of the subsequent use; and

in response to detecting a conflict, (1) receiving a grant indication with respect to the request, and (2) in response to the grant indication identifying acceptance of the request, (a) calculating a permitted extension time for the current use, and (b) updating the resource data to add the permitted extension time to a scheduled end time for the current use and a scheduled start time for the subsequent use, so that the shared resource can be used without conflict.

2. The method of claim 1, wherein the shared resource is a shared conference resource and the resource data is conference data.

3. The method of claim 2, wherein the shared conference resource is a conference room.

4. The method of claim 3, wherein (1) the current usage and the subsequent usage are respective conferences scheduled by respective conference owners, (2) the request is received from a first client device associated with a current conference owner of a current conference, and (3) the permission indication is received from a second client device associated with a next conference owner of a subsequent conference.

5. The method of claim 1, wherein updating the resource data comprises updating data stored at a resource client device, and further comprising: generating, at the resource client device, a local notification to a respective resource user based on the updated data, the local notification notifying the resource user of the adjusted time of the current usage and the adjusted start time of the subsequent usage.

6. The method of claim 1, wherein calculating the permitted extension time comprises a calculation based on historical resource data related to past time extensions.

7. The method of claim 6, wherein the calculation based on historical resource data includes use of a penalty factor for reducing the permitted extension time based on a past occurrence of a prolonged request for the shared resource and a reward factor for countering the penalty factor to increase permitted extension time based on a past occurrence of an early completion of use of the shared resource.

8. The method of claim 7, wherein the calculating further comprises a weighting factor representing a number of users affected by a past occurrence of a prolonged request and an early completion of use.

9. The method of claim 6, wherein the calculation based on historical resource data is further based on policy data explicitly describing an associated policy for permission extension.

10. The method of claim 1, further comprising: based on an occurrence of a trigger, sending a query message to a device of a current user of the shared resource, and wherein the request is received as a response to the query message.

11. A resource management system having one or more computerized devices collectively configured and operable for managing shared resources, the computerized devices including respective processors and memories storing computer program instructions for resource management applications, the computer program instructions being executable by the processors to cause the resource management system to perform management of shared resources, comprising:

in response to receiving a request to extend a current use of a shared resource, detecting a conflict of resource data between a requested end time of the current use and a start time of a subsequent use of the shared resource, the requested end time being later than a scheduled start time of the subsequent use; and

in response to detecting a conflict, (1) receiving a grant indication with respect to the request, and (2) in response to the grant indication identifying acceptance of the request, (a) calculating a permitted extension time for the current use, and (b) updating the resource data to add the permitted extension time to a scheduled end time for the current use and a scheduled start time for the subsequent use, so that the shared resource can be used without conflict.

12. The system of claim 11, wherein the shared resource is a shared conference resource and the resource data is conference data.

13. The system of claim 12, wherein the shared conference resource is a conference room.

14. The system of claim 13, wherein (1) the current usage and the subsequent usage are respective conferences scheduled by respective conference owners, (2) the request is received from a first client device associated with a current conference owner of a current conference, and (3) the permission indication is received from a second client device associated with a next conference owner of a subsequent conference.

15. The system of claim 11, wherein updating the resource data comprises updating data stored at a resource client device configured to operate to generate a local notification to a respective resource user based on the updated data, the local notification notifying the resource user of the adjusted time of the current usage and the adjusted start time of the subsequent usage.

16. The system of claim 11, wherein calculating the permitted extension time comprises a calculation based on historical resource data related to past time extensions.

17. The system of claim 16, wherein the calculation based on historical resource data includes use of a penalty factor for reducing the permitted extension time based on a past occurrence of a prolonged request for the shared resource and a reward factor for offsetting the penalty factor to increase permitted extension time based on a past occurrence of an early completion of use of the shared resource.

18. The system of claim 17, wherein the calculation further includes a weighting factor that represents a number of users affected by a past occurrence of a prolonged request and an early completion of use.

19. The system of claim 16, wherein the calculation based on historical resource data is further based on policy data explicitly describing an associated policy for permission extension.

20. A non-transitory computer-readable medium storing computer program instructions executable by a set of one or more computers to cause the computers to perform a method of managing shared resources, the method comprising:

in response to receiving a request to extend a current use of a shared resource, detecting a conflict of resource data between a requested end time of the current use and a start time of a subsequent use of the shared resource, the requested end time being later than a scheduled start time of the subsequent use; and

in response to detecting a conflict, (1) receiving a grant indication with respect to the request, and (2) in response to the grant indication identifying acceptance of the request, (a) calculating a permitted extension time for the current use, and (b) updating the resource data to add the permitted extension time to a scheduled end time for the current use and a scheduled start time for the subsequent use, so that the shared resource can be used without conflict.

Technical Field

The present disclosure relates to the field of resource management, for example in a calendar application that provides scheduling of shared resources such as meeting rooms, also referred to herein as "meeting halls".

Disclosure of Invention

The present disclosure relates generally to techniques for managing shared resources to avoid conflicts in their use. In one example, the present disclosure includes an intelligent notification and workflow mechanism that enables better collaboration and efficient resource utilization. This general aspect is described with reference to a specific application example based on conference data that describes the use of shared conference resources (e.g., conference rooms). Those skilled in the art will appreciate that the disclosed techniques can be utilized in a variety of other ways.

With respect to the example of sharing conference resources, in today's enterprises, through the use of client collaboration applications (e.g.,

) A specific conference room is reserved to arrange the conference. Based on the schedule, start and end times are assigned for the meeting and meeting room. The application may then send reminders to the conference owner and meeting participants to attend the upcoming conference before the conference begins (e.g., 15 minutes in advance).

In some cases, when a participant arrives for an upcoming conference, the conference room may still be occupied by the previous conference and the previous conference continues (with or without permission) beyond the scheduled start time of the upcoming conference. The start of an upcoming meeting is delayed and thus production time may be wasted. Such scenarios represent reduced organizational efficiency. It arises, in part, from the limitations of existing resource scheduling techniques that do not recognize these types of conflicts, nor provide any support for resolving these conflicts. Allowing the meeting participants to identify and resolve conflicts themselves, wherein the participation is inefficient.

In the disclosed technology, intelligent notifications and workflows are provided in a resource arrangement to reduce the occurrence of such inefficient interactions with shared resources such as conference rooms. The disclosed technique uses a new decision-making method to send a notification to the resource owner to confirm the current usage of the shared resource by the extension and to update the resource data to reflect the extension, thereby proactively notifying the resource user of changes in scheduled usage, thereby eliminating the need for the user to self-learn about and resolve conflicts. Resource data is data representing scheduled use of a shared resource, such as an electronic calendar or similar scheduling data. Additionally, the disclosed techniques may use context information (e.g., historical credits for meeting room/user behavior, etc.) and allocation policies when granting extended use of resources.

More specifically, a method of managing shared resources is disclosed. The method generally includes: in response to receiving a request to extend a current use of a shared resource, a conflict of resource data between an end time of the request for the current use and a start time of a subsequent use of the shared resource is detected. In this case, the end time of the request is later than the scheduled start time of the subsequent use. In one example, the shared resource is a conference room, and conflicts arise due to the scheduled adjacency of conferences in the conference room.

The disclosed method further comprises: in response to detecting a conflict, (1) receiving a grant indication for the request, and (2) in response to the grant indication identifying acceptance of the request, (a) calculating a permitted extension time for the current use, and (b) updating the resource data to add the permitted extension time to a scheduled end time for the current use and a scheduled start time for a subsequent use to enable use of the shared resource without conflict.

Drawings

The foregoing and other objects, features and advantages will be apparent from the following description of particular embodiments as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views.

FIG. 1 is a block diagram of a system that provides management of shared resources;

FIG. 2 is a flow chart of certain operations of the system of FIG. 1;

FIG. 3 is a block diagram of a distributed calendar system as a specific example of the general system of FIG. 1;

FIG. 4 is a block diagram of a calendar server device in the system of FIG. 3;

FIG. 5 is a block diagram of a calendar client device in the system of FIG. 3; and

fig. 6 is a message diagram of some operations of the system of fig. 3.

Detailed Description

FIG. 1 shows a system including a resource manager 10, the resource manager 10 being coupled to a set of resource clients 12 by respective communication links 14. In general, the resource manager 10 and the resource clients 12 are computerized devices that execute specialized software to implement the functions described herein. In particular, in one example, the resource manager 10 may be implemented as a resource manager server (RM server), and the resource clients 12 may be implemented as respective client devices, e.g., personal computers, smart phones, tablet computers, and the like. Accordingly, these computerized devices typically include one or more processors, memory, input/output (I/O) interface circuitry, and non-volatile secondary storage for storing and executing computer program instructions and related data, and for interacting with external devices, as is commonly known in the art.

In another more specific example, the system of FIG. 1 may be implemented in the form of a distributed calendar function of a distributed calendar application or related applications, for example

The calendar function of (1). In this case, the resource client 12 may be implemented as a computerized device running an instance of the client Outlook application, while the resource manager 10 may be implemented as a centralized email server, such as Microsoft Windows

Alternatively, the system may be implemented in a peer-to-peer fashion that does not employ a centralized server, in which case the functionality of the resource manager 10 is distributed across some set of peer devices that also typically include the functionality of the resource clients 12.

Fig. 2 illustrates some operations of the system of fig. 1 at a high level. These functions are described as being performed by the resource manager 10 in connection with data and communications involving the resource client 12. In particular, the illustrated operations occur in the context of shared resource usage by the resource client 12, where the resource manager 10 assists in scheduling usage of the shared resource. In one example described in detail herein, the shared resource is a meeting room for a meeting scheduled in a calendar or similar application. In this arrangement, the illustrated operation addresses the potential problems of the type described above, namely, the potential conflict of conference room usage, and the need to improve the management of conference data and communications associated therewith. Those skilled in the art will appreciate that there may be many other types of resources and circumstances in general to which the illustrated techniques may be applied.

At 20, in response to receiving a request to extend a current use of a shared resource, a resource manager detects a conflict of resource data between an end time of the request to extend the current use of the shared resource and a start time of a subsequent use, wherein the end time of the request is later than a scheduled start time for the subsequent use. For example, the request may be received from a resource client 12 of a current user of the resource. Resource data is data representing scheduled use of a resource, such as an electronic calendar or similar scheduling data. The resource manager 10 interrogates or otherwise queries the resource data to identify the next or subsequent use of the resource and compares the start time of the subsequent use with the end time of the request for the current use. If the end time of the request is later, a conflict is detected, i.e., extending the current usage according to the request will cause it to extend beyond the beginning of the subsequent usage.

At 22, in response to detecting the conflict, the resource manager (1) receives a grant indication for the request, and (2) in response to the grant indication identifying acceptance of the request, (a) calculates an extension time for the grant for the current use, (b) updates the resource data to add the extension time of the grant to a scheduled end time of the current use and a scheduled start time of a subsequent use, so that the shared resource can be used without conflict. Continuing with the above example, the resource manager 10 may receive the permission indication by first sending a notification message to the resource client 12 of a subsequent user (e.g., a meeting organizer) associated with the subsequent use. The notification message conveys a request to extend the current usage. Based on the user's input, the resource client 12 then sends a reply message including an indication of permission, either negative (rejection of the request) or positive (acceptance of the request).

The calculation of the allowed extension time at 22 enables the resource manager 10 to exert some independent control over resource usage, particularly for usage under conflicting conditions. For example, the current user may request an additional half hour, but only some short extension may be possible or desirable for any of a variety of reasons, including input from subsequent users. Examples are discussed below. Thus, the calculation may take various inputs including historical usage data, policies, etc., and generate a permitted extension time therefrom.

Updates to the resource data are typically visible to the current and subsequent resource users in some manner to achieve a conflict-free transition between current use and subsequent use at a later time, in accordance with the extension of the license. For example, in a calendar application, the schedules of both the current meeting and the subsequent meeting are adjusted to reflect the deferred end time of the current meeting and the deferred start time of the next meeting. The resource client 12 may automatically respond to the change by issuing a local notification or other action to the user. Additionally, in some embodiments, in addition to the update of the resource data, the resource manager 10 may also issue explicit communications to the affected resource clients 12 to inform them of the change.

Fig. 3 shows a specific application of the general arrangement of fig. 1, namely a distributed calendar system with a calendar server device 30 and a set of calendar client devices 32. These may be implemented as described above, i.e. as a computerized device executing specialized calendar related software, including for example a distributed email system as described above. The calendar server device 30 provides a specialized interface and communication with an external administrator (Admin)34, which administrator 34 may program certain policies and other configuration data into the system for affecting certain aspects of the operations described herein. Policy data illustratively describing the associated policy for license extension and used for calculation of the extension of the license may be provided by administrator 34.

Fig. 4 illustrates calendar server device 30 in one embodiment. This is a functional block diagram illustrating components implemented by computer circuitry executing dedicated calendaring software. These components include a calendar server function component 40, a calendar server database 42, and a communications component 44.

Calendar server function components 40 are typically those routines, linked libraries, etc. that implement the functionality of a calendar program, i.e., the ability to schedule meetings (i.e., create corresponding entries in calendar server database 42), monitor conflicts, participate in communications, etc. For purposes of this description, they are divided into a meeting control (Cntl) component 46 and other components 48, with the meeting control component 46 providing meeting-related functionality as specifically described herein, and the other components 48 providing all other functionality of a calendar application, as is well known in the art.

Calendar server database 42 stores calendar data 50 that is the basis of a calendar paradigm (param) on which the system operates-i.e., data representing time periods (days, hours, etc.), scheduled items (e.g., meetings), users, resources (e.g., meeting rooms), etc. Example data and organization are shown below. It will be understood that calendar data 50 is a specific example of content, also referred to herein as "meeting data".

The communication component 44 performs details of message exchanges and/or notifications with the calendar client device 32 and, for this purpose, it employs a user-dev table 52 that associates users of the calendar system with corresponding calendar client devices of those users. It should be appreciated that at a high level, typical calendar systems operate with respect to users (e.g., maintain a user's calendar, identify attendees, etc.), and thus require mechanisms for communicating with the user. The communication component 44 provides this mechanism by associating a user with the device 32 via the user-dev table 52.

Fig. 5 shows a calendar client device 32 having a similar organization as the calendar server device 30. It includes a calendar client functionality component 60, a calendar client data storage device 62 and a communications component 64. The calendar client functionality components include a meeting function 66 that implements meeting related functionality as described herein, and other components 68 that implement the remaining client-side calendar components known in the art. The calendar client data storage device 62 includes calendar data 70, the calendar data 70 being maintained in synchronization with the calendar data 50 of the calendar server database 42 (FIG. 4) as is well known in the art. Communications component 64 provides communications (messages and/or notifications) with calendar server 30.

The following table provides a simplified example of the content and organization of calendar meeting data 50. The first table is a representation of scheduled meetings. The second table is a representation of the use of the schedule for a given conference room, which is derived from the schedule information in the first table. These tables show an example in which a first conference, identified as N, is arranged from 12:00 to 1:00, a second conference M is arranged from 1:00 to 2:00, both conferences being in the same conference room X.

TABLE 1 conference

ID

Owner of the system

Themes

Starting time

End time

Room

Participants

…

N

User N

Topic N

12:00

1:00

X

{ List N }

M

User M

Theme M

1:00

2:00

X

{ List M }

TABLE 2 Room usage

Time slot	Conference
		…
12:00-1:00	N
		1:00-2:00	M
…

In operation, the conference controller 46 may periodically scan the room table (table 2) for the situation shown (i.e., two adjacent conferences) as a trigger to communicate with the conference owner and update the conference data to adjust the scheduled process as described below (see fig. 6).

Fig. 6 is a message diagram illustrating operation of the system of fig. 3 in one example. The participants are shown as calendar server (Cal Svr)30, first client device 32 referred to as "current conference owner" device (CMO Dev)32-C and "next conference owner" device (NMO Dev) 32-M. The CMO device 32-C is associated with a user referred to as the "current conference owner" (i.e., the organizer of the first conference currently in progress). The NMO devices 32-N are associated with users referred to as "next meeting owners", i.e., organizers of a second meeting scheduled to follow the current meeting, which typically follows the current meeting immediately (i.e., the start time of the next meeting is within a few minutes after the end time of the current meeting). In this message diagram, time progresses downward.

The operation starts by the occurrence of a Trigger (Trigger) at the calendar server 30. In one example, calendar server 30 continuously scans calendar data 50 (FIG. 4) for upcoming meeting end times, and when one is encountered within a window at the current time, the condition is considered a trigger for a subsequent operation. By way of example, calendar server 30 may scan the schedule of all meeting rooms every minute and trigger when a scheduled end time within 10 minutes of the current time is encountered. In alternative embodiments, the trigger condition may require not only an upcoming meeting end time, but also the presence of a next meeting start time within some window (e.g., within the next 15 or 30 minutes) after it.

The calendar server 30 then sends a notification or other type of query message (extension required. The CMO device 32-C then performs one or more user interface actions (UI actions) in interaction with the local user, which is assumed to be the CMO user. For example, the CMO device 32-C may present a pop-up window with a query message from the calendar server 30 and receive a button press or other user input indicating a response of the CMO user to the query. The response may be an indication that no additional time is required or that additional time is requested, and it may include the user entering the particular extension value requested (e.g., 15 minutes). Based on the UI action, the CMO device 32-C generates an extension Request message (Ext Request) as a response message and sends it to the calendar server 30. Assume that the current user has requested an extension, and that the extension request message conveys a CMO user's request to extend the current use to a new end time. Alternatively, the CMO device 32-C may generate and send a message indicating that no extension request is required, in which case the remaining steps of fig. 6, described below, are not performed for that particular conference room and the current conference.

Next, the calendar server 30 performs a conflict detection operation (detect conflict (det. config)) to determine whether the extension request causes a conflict to the use of the meeting room based on the schedule in the calendar data 50 (fig. 4). In general, a conflict may occur if an extension of the request would cause the end time of the current conference to exceed (be later in time than) the start time of the next conference. If a conflict is detected, the calendar server 30 generates and sends a notification message (Notify) to the NMO device 32-N to Notify the next meeting owner of the requested extension. Then, a UI action occurs at the NMO device 32-N, notifying the NMO user of the request and receiving input from the NMO user indicating whether they accept the request. Based on the UI action, the NMO device 32-N generates a Permission Indication message (Permission Indication) and sends it to the calendar server 30. The grant indication message indicates whether the NMO user agrees to the change to the schedule indicated by the extension request. For example, if the extension request is an additional 10 minutes, this may result in changing the next meeting start time by as much as 10 minutes. The grant indication message indicates acceptance or rejection of the extension and schedule change.

Calendar server 30 then performs an extension calculation (ext. calc.) to calculate the allowed extension time, which may typically be different from the requested extension time. For example, the calculations may use various data and methods to facilitate certain operational goals or strategies, and the calculations may incorporate historical data to reflect past experience of the CMO user. Specific examples are described below. After the extension of the permissions is calculated, the calendar server performs a local Update (Update) of the server calendar data 50 and notifies the CMO user by sending an extension permission message (extension permission (ext. granted)) to the CMO device 32-C and issues a corresponding calendar Update (cal. updates) to the devices 70 of the current meeting and the next meeting participant to Update their respective client calendar data 70. Typically, the calendar update reflects adding the permitted extension time to the scheduled end time of the current meeting and the scheduled start time of the next meeting, moving these times back accordingly. Once completed, any local automated actions at each client device 32, such as local reminders and the like, are based on the adjusted time. Thus, the participants of the next conference receive the conference alert based on the adjusted start time of the next conference rather than based on the originally scheduled start time. In this way, the above-mentioned problem that the next participant has to wait for the end of the current conference outside the conference room is avoided, thereby improving the organization efficiency.

As an alternative to the above method, an extension calculation may be performed prior to notifying the NMO device 32-N and communicating with it for permission to notify the NMO user of the actual extension time to be permitted, rather than the requested extension time.

It should be appreciated that there is a possibility that recursion occurs, i.e., the process of fig. 6 may be performed a second or more times for the same current meeting if a new trigger may occur based on the adjusted meeting end time. This iteration does not result in an infinite extension of the current conference, as permission from the NMO user is required. However, it may even be desirable to avoid repeating the initial messaging (notification, Permission Indication) of the process of FIG. 6, in which case the calendar server 30 may implement additional logic to identify the end time as an adjusted time and to prohibit any triggering of the process in response thereto (i.e., allow only one extension).

The following is a description of the elongation calculation in one embodiment. It is assumed that various data are stored in server calendar data 50 as described below, some of which are static (e.g., meeting room identifiers) and others of which are dynamic. In addition, some data is tracked over time to create a history record that will be used in the manner described. Assuming that no current conference owner has requested an extension, which is denoted as expected deferral time (ExpectedDelayTime) in the following description.

a. Room id (roomid): in particular meeting room i.

b. Start time (StartTime): normal start time of a meeting in meeting room i;

c. end time (EndTime): normal end time of a meeting in meeting room i;

d. reminder time (TimeForReminder): reminding the time of the next conference owner to start the conference in the conference room i in advance;

e. advance frequency (PriorFrequency): historical accumulated time for an owner to complete a meeting in advance in a meeting room i is identified by a variable n;

f. deferral frequency (delayfequency): the historical cumulative number of times the owner has deferred the meeting (extended it beyond the scheduled end time) in meeting room i, identified by variable m;

g. advanced completion time (PriorCompleteTime): the duration of the earlier completion of the conference compared to the end time (EndTime) in room i is identified as PriorTime_k. Here, k is equal to 1, 2,. and n, where n is the PriorFrequency described above.

h. Late completion time (delaycompletimei): the duration of the conference being deferred compared to EndTime in room i is identified as DelayTime_j. Here, j is equal to 1, 2,. and m, where m is the delayfequency described above.

i. Maximum advance time (MaxPriorTime): the maximum remaining duration when the owner ends the meeting in the meeting room earlier than EndTime, for a particular room i, is identified as TPMAX_i. Typically, for a particular room, this may be a constant greater than PriorCompleteTime. Thus, in some slot request scenarios, PriorTime_kNot exceeding TPMAX all the time_j。

j. Maximum delay time (MaxDelayTime): the maximum duration that the owner can request compared to EndTime in conference room i is identified as TDMAX for a particular room i_i. Typically for a particular room, this may be a constant greater than delaycompletimem. Thus, in some slot request scenarios, DelayTime_jDoes not exceed TDMAX all the time_i。

k. Number of participants in advance (priority) (numberofattendes): in the Prior scenario, the number of participants in the next meeting in room i, identified in the history as PNum_k。

i. Number of participants (numberofattendes) at deferral (Delay): in the Delay scene, the roomThe number of participants in the next meeting in i, identified in the history as DNum_j。

Penalty factor (PunishmentFactor): a normalized weighting factor (between 0.0-1.0) is used to calculate the allowed extension time and represents the impact of the previous Delay event.

It can be calculated by the following formula:

reward factor (RewardFactor): similar to PuniscementFactor, but represents the effect of a previous Prior event. It can be calculated by the following formula:

mean factor (MeanFactor): this is an averaging factor used to calculate the allowed extended time GrantedDelayTime, as described below. In one embodiment, a "credit" type of method is used for licensing time extensions. For a MeanFactor for a given conference room, the conference owner may be given an initial credit value, e.g., 1.0. According to the above definitions and formulas, the more Delay the owner has, the larger the publishing factor, with respect to conference hall i. With respect to RewardFactor, the more the owner completes the Prior event (completes the meeting early), the larger the RewardFactor. The MeanFactor can then be calculated as follows:

MeanFactor_i＝1.0-PunishmentFactor_i+RewardFactor_i

how to determine the actual permitted extended time GrantedDelayTime using the above values is explained below.

1. RewardFactor is calculated based on historical data of meeting owners stored in server calendar data 50_iAnd PuniscementFactor_i；

2. MeanFactor for computing conference hall i_i；

3. The GrantedDelayTime is calculated as follows:

a) if MeanFactor_i(ii) 0, then GrantedDelayTime is set to 0.0;

a) if MeanFactor_i1, set GrantedDelayTime to expectedddelaytime (the amount requested by the current conference owner);

c) otherwise, the GrantedDelayTime is calculated as follows, which means that the expectedddelaytime is scaled with the MeanFactor:

GrantedDelayTime＝ExpectedDelayTime*MeanFact0r_i

alternative solution

In addition to the above functionality, other methods may be introduced to judiciously decide when to prompt the owner if additional time needs to be reserved and allow the appropriate amount of additional time based on configured policies other than context information. For example, such a method may include deep learning techniques for detecting the behavior of voice and video information of the participants.

The technology can be combined with internet of things (IoT) hardware or provisions for conference rooms to establish intelligent workspaces. For example, if the current conference owner excessively defers the conference and does not respond to the notification appropriately, the conference controller may automatically disable use of the conference room (e.g., turn off the display/disable the cable).

In addition to managing conflicts at a conference hall, the disclosed techniques may also be used in other ways generally. In one example, it can be used in conjunction with other conference related shared resources (e.g., conference services) or devices (e.g., conference audio/video devices, conference phone lines, etc.). More generally, it may be used in connection with other types of shared resources that are not necessarily related to a meeting. These may include high demand equipment in an office environment, such as copiers or scanners; test equipment or other specialized tools in a factory or store environment, and the like.

While various embodiments have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.