Patent Document

BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates to a schedule management method and a schedule management system for managing a schedule utilizing the computer. 
     2. Description of the Related Art 
     It is known that a schedule for persons and facilities such as a meeting room are managed on a server/client system. 
     In the conventional schedule management system, a person A who tries to reserve and register a schedule of a person B first displays the schedule of the person B and selects an optimum time by finding an unoccupied time. 
     JP-A-7-121610 discloses a technique by which a planner of an event collectively displays the persons related to the event and the schedules for the facilities used. 
     SUMMARY OF THE INVENTION 
     In the above-mentioned conventional schedule management system, all the reservation schedules are displayed regardless of whether a schedule owner has approved a particular schedule or not. Also, even in the presence of an established schedule, a new schedule is reserved and registered overlapped with the established schedule. 
     The object of the present invention is to provide a schedule management system which allows selection as to whether a schedule in registration is displayed or not and whether the registration of a new overlapped reservation schedule is permitted or not, depending on the state of the reservation schedules in registration. 
     In order to achieve the object described above, according to the present invention, there is provided a schedule management system comprising a schedule data table for storing the schedule data including an identifier of a schedule owner, the time zone, the activity and the state of a schedule, a definition data table for storing the definition data for determining the relation between the registration and display of the schedule and the schedule state in the schedule data, a schedule data registration unit for receiving a schedule reservation request, determining whether the schedule registration is permitted or not based on the schedule state of the schedule data existing in the schedule data table and the definition data, and when the schedule registration is permitted, registering the reservation schedule in the schedule data table, a schedule data approval unit for accepting a request from the schedule owner for approving/disapproving the schedule and rewriting the schedule state of the corresponding schedule data in the schedule data table, and a schedule display unit for accepting a schedule display request, determining whether the existing schedule is displayed or not based on the schedule state of the schedule data existing in the schedule data table and the definition data, and displaying only the schedule data determined for display. 
     Further, a schedule management system may comprise an unoccupied time search unit for accepting an unoccupied time search request for a schedule and determining whether the time zone of the schedule is rendered an occupied time or not based on the schedule state of the schedule data existing in the schedule data table and the definition data, and when determining that the time zone of the schedule is rendered an occupied time, displaying an unoccupied time by removing the time zone of the schedule from the unoccupied time. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram showing a schedule management system according to an embodiment of the present invention. 
         FIG. 2  shows an example of the record format and the record of a schedule data storage unit. 
         FIG. 3  shows an example of the definition of a definition data storage unit. 
         FIG. 4  is a flow chart showing the operation of receiving a schedule display request. 
         FIG. 5  shows an example of a local schedule data displayed. 
         FIG. 6  shows an example of a remote schedule data displayed. 
         FIG. 7  is a flow chart showing the operation of receiving an unoccupied time search request. 
         FIG. 8  shows an example of an unoccupied time list displayed. 
         FIG. 9  is a flow chart showing the operation of receiving a request for registering a schedule reservation. 
         FIG. 10  is a diagram explaining a general method of using the system. 
     
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     (1) System Configuration 
       FIG. 1  is a diagram showing a configuration of a schedule management system according to an embodiment. 
     A schedule management system  101  comprises schedule management clients  102 , a schedule management server  103  and a communication network  110  connecting the server and the clients. 
     The clients  102 - 1 ,  102 - 2  are each assigned a user ID such as “User 001 ”, “User 002 ”, and are connected with the schedule management server  103  via the communication network  110 . Although two clients are shown in  FIG. 1 , the number of clients connected to the server is not limited to two. Each client transmits the input data or a request to the server via the communication network and also displays the information transmitted from the server. 
     The schedule management server  103  comprises a schedule data storage unit  106 , a definition data storage unit  107 , a schedule data operating unit  108 , and a definition data operating unit  109 . The schedule data storage unit  106  stores the schedule data for persons and facilities, and the schedule data operating unit  108  operates (registration, reference, change and deletion) the data in the schedule data storage unit. The definition data storage unit  107  stores the definition data for defining the manner of handling the schedule data for registration and display, and the definition data operating unit  109  sets the definition data. 
     The schedule management server  103  and the clients  102  each includes a computer such as a personal computer or a work station including an input/output unit, a CPU, a memory and a communication network interface. The transmission of requests and data from the clients, the display of the information sent from the schedule management server and the user interface are realized by software executed by the CPU of the clients. The schedule data operating unit  108  and the definition data operating unit  109  of the schedule management server are realized by software executed by the CPU of the schedule management server, and the data storage units  106 ,  107  are realized by a memory (a main memory and/or an external memory) in the schedule management server. 
     The communication network  110  is a general-purpose network such as a LAN (local area network). The communication between the server and the clients is effected in accordance with the protocol used by the communication network  110 . In the case where the network is a LAN, the protocol is TCP/IP. 
       FIG. 2  shows an example of a record format and a record in the schedule data storage unit  106 . The record includes a user ID, a reservation state, a starting time, an ending time, an activity, a schedule No. and a registrant ID. The schedule No. is an identifier of the schedule data. The user ID represents the owner of the schedule and is information for identifying the clients. The user ID may be the name of a facility such as a first meeting room or a guest room A. In this case, the schedule is adjusted by the facility manager. The user IDs and the facility names are unique in the system. 
     The reservation state is the state of the schedules reserved and registered, and includes “approved”, “disapproved”, “suspended” and “unread” (described later). The symbol “-” in  FIG. 2  indicates the schedule data registered locally, that is, registered by the schedule owner. The starting time is the time when the schedule starts, the ending time is the time when the schedule ends, and the activity indicates the business of the schedule. The registrant ID indicates a person who has registered a reservation. Further, the schedule data can include additional information such as the object of the schedule, the place and participants. 
     In the example shown in  FIG. 2 , the schedule data for a plurality of user IDs are stored sequentially in a single table for facilitating the understanding. Actually, however, each user ID has a pointer indicating the earliest-registered record of the schedule data owned by the particular user ID. Also, each record has a pointer indicating the next-registered record, so that the schedule data are chained sequentially in the order of registration. The table of  FIG. 2  can be realized by other than this format. 
       FIG. 3  shows an example of definition in the definition data storage unit  107 . The definition data defines the manner in which a schedule data display request or a reservation registration request is processed upon receipt thereof, in accordance with the schedule reservation state. In the case of  FIG. 3 , the system displays the schedule data approved or unread, but does not display the schedule data disapproved or suspended, upon receipt of a request for displaying the schedule data. Also, the schedule management system according to this embodiment has the function of searching for an unoccupied time, and upon receipt of an unoccupied time search request, the search result is displayed in accordance with the definition of FIG.  3 . Specifically, a schedule is assumed to exist for the schedule data approved or not read, and the time zone for the schedule data disapproved or suspended is kept unoccupied. 
     Also, the definition data registration unit  107  defines whether or not a new reservation registration request from another client is accepted in the case where a schedule already exists in the same time zone. In the embodiment, if the existing schedule data is approved, the new registration request is rejected, whereas if the existing schedule is disapproved, suspended or unread, the new schedule data is registered. 
     The system has one definition data  107  of  FIG. 3  which can be applied to all the users or facilities. As another method, the definition data is produced for each user or each facility, so that a corresponding data can be referred to at the time of registration or display of a schedule owned by a user or a facility. 
     In the former case, the definition data is produced by the system manager on the schedule management server  103 . In the latter case, on the other hand, the definition data is produced on the clients  102  and sent to the server  103  by each user or facility manager. In either case, the definition data is produced and updated through the definition data operating unit  109 . 
     (2) System Operation 
       FIG. 10  shows an ordinary method of use and an example operation of the schedule management system  101 . In this case, a user having ID User 001  (hereinafter referred to as User 001 ) reserves a schedule of a user having ID User 002  (hereinafter referred to as User 002 ). 
     A menu is displayed on the client  102 - 1  of User 001 , and User 001  selects the schedule reservation registration process. Then, the screen switches to the one for inputting the record items of FIG.  2 . Upon complete record item input by User 001  and selection of the transmission button, the client  102 - 1  transmits the input items as a reservation registration request  1001  to the server  103 . 
     The schedule data operating unit  108  of the server  103  checks the reservation registration request (described later), registers it in the schedule data storage unit  106  as the schedule data of User 002 , and transmits a registration OK  1002  to the client  102 - 1  together with the schedule number. In the process, the reservation state of this data is “unread”. Though not shown in  FIG. 10 , the server  103  can notify User 002  that the reservation of the schedule has been registered anew. 
     A menu is displayed on the client  102 - 2  of User 002 . Upon selection of a schedule display by User 002 , the client  102 - 2  transmits a schedule display request  1003 . The server  103  selects a part of the schedule data associated with User 002  (described later). The “unread” record then selected is changed to “suspended” in reservation state. The server  103  transmits the selected schedule data as display data to the client  102 - 2  ( 1004 ). 
     The client  102 - 2  displays the transmitted display data in the form shown in FIG.  5 . User 002  selects a “suspended” schedule (say,  502 ), and approves/disapproves the schedule using the pull-down menu. The approval/disapproval is transmitted as an approved request ( 1005 ) or a disapproved request to the server  103  from the client  102 - 2 . The server  103  changes the reservation state of the record to “approved” or “disapproved”, and notifies the change to the client  102 - 2  ( 1006 ). Though not shown in  FIG. 10 , the server  103  can notify User 001  as to whether the schedule of which the reservation has been registered is approved or not. 
     When User 001  selects the reservation check from the menu on the client  102 - 1  again, the client  102 - 1  transmits a reservation check request  1007  to the server  103  together with the schedule number of the schedule data of which the reservation has been registered. The server  103  checks the schedule data having the schedule number sent to him, and transmits the reservation state (“approved”  1008  in the case of  FIG. 10 ) to the client  102 - 1 . 
     (4) Server Operation 
     An explanation will be given of the operation of the schedule data operating unit  108  of the schedule management server  103 . 
     Assume that the server  103  has received from a client  102  a schedule display request for displaying the schedule data of the 7-day period from Jun. 30, 1997, of the user having the user ID “User  001 ”. The schedule display process of the schedule data operating unit  108  starts as shown in FIG.  4 . 
     First, in step  401 , the display process sets “User 001 ”, “Jun. 30, 1997” and “7 days” in the received schedule display request as the search keys for the referred user ID, the starting date and the number of days, respectively. The data (record) conforming to the conditions of the search keys are acquired from the schedule of the user ID “User 001 ” in the schedule data storage unit  106 . In the example record of  FIG. 2 , Nos.  1  to  8  are acquired (step  402 ). The user ID of the request source is compared with the referred user ID (step  403 ). 
     If the user ID of the request source coincide with the referred user ID, it indicates that the display is requested by the owner of the schedule. Therefore, the reservation state of the record in the schedule data storage unit  106  corresponding to the record having the reservation state “unread” in the data acquired at step  402  is changed to “suspended” (step  410 ). After that, the schedule data acquired at step  402  are all transmitted to the client as display data (step  409 ). At step  410 , only the data reservation state in the schedule data storage unit  106  is updated, and therefore the reservation state “unread” in the display data transmitted to the client is not changed. 
     An example display of the display data on the client is shown in FIG.  5 . Numeral  501  in  FIG. 5  corresponds to record No.  1  in  FIG. 2 ,  502  to record No.  2 ,  503  to record No.  3 ,  504  to record No.  8  and  505  to record No.  4 . 
     If the user ID of the request source and the user ID of the reference fail to coincide with each other at step  403 , the number of schedule data acquired at step  402  is substituted into the variable Count (step  404 ), and the leading data of the schedule data list acquired is compared to see whether the reservation state of the schedule data is “-” or not (step  405 ). If it is “-”, the data is not the reservation schedule data but a schedule set by the referred user himself, and therefore the schedule data is added unconditionally to the display data (step  407 ). In the case where the data is found to be the reservation schedule data at step  405 , on the other hand, the display or no-display is determined from the reservation state of the schedule data and the data in the definition data storage unit  107  (step  406 ). 
     In the case where the system has only one definition data under this condition, the particular definition data is referred to. In the case where the definition data is produced for each user ID, on the other hand, the definition data for the schedule owner (User 001 ) is referred to. 
     The “display” data in the definition data is compared with the reservation state of the schedule data, and only the schedule data of “O” is selected (step  407 ). In the example of  FIG. 3 , only the record with the reservation state of “approved” and “unread” are the object to be displayed. Thus, Nos.  1 ,  2  and  5  of the schedule data for “User 001 ” in  FIG. 5  are selected. The variable Count is decremented by one (step  408 ), and as long as the variable Count is larger than zero, the process of steps  405  to  408  is repeated. Once the schedule data to be displayed is determined, the schedule data is transmitted to the display request source client (step  409 ). 
     An example of display on the client is shown in FIG.  6 . Numeral  601  in  FIG. 6 , corresponds to record No.  1  in  FIG. 2 ,  602  to record No.  2 , and  603  to record No.  8 . On the other hand,  FIG. 5  shows an example display of the schedule data list as seen on the client  102  by the user “User 001 ” himself of the reference for comparison. Numeral  503  in  FIG. 5  represents the reservation state “suspended” of the schedule. Once the definition data is acquired in  FIG. 3 , therefore, “no display” is indicated for the state. Thus, the schedule data corresponding to  503  is not displayed in “the schedule list referred to by another client”. 
     Also, when one of the schedule data displayed as shown in  FIGS. 5 and 6  on the client is selected by the user and detailed information display is designated by the pull-down menu or the like, the client displays all the items available in FIG.  2 . 
     Assume that the server  103  has received from the user (User 002 ) of the client  102  an unoccupied time search request for another user (User 001 ). The schedule search process of the schedule data operating unit  108  starts as shown in FIG.  7 . Assume that User 002  has set one hour on Jun. 30, 1997, as a condition for the search. 
     At step  701 , the search process sets the referred user ID, the date and the search time zone as “User 001 ”, “Jun. 30, 1997” and “One hour” in the received unoccupied time search request, respectively, as search keys. Then, the client  102  acquires the schedule data including the user ID of “User 001 ” and the date of “Jun. 30, 1997” from the schedule data storage unit  106 . In the example of the record shown in  FIG. 2 , Nos.  1  to  8  are acquired (step  702 ). The number of the schedule data acquired is substituted into the variable Count (step  703 ), and from the leading data in the schedule data list acquired, the reservation state of the schedule data is compared to see whether it is “-” or not (step  704 ). If it is “-”, it indicates that the schedule is set by the referred user himself. Therefore, the process unconditionally proceeds to step  706 , and the time zone of the schedule data is stored as an occupied time zone (a time zone not unoccupied), and the process proceeds to step  707 . In the case where the result of comparison is not “-”, the display/no-display information is acquired from the definition data in the definition data storage unit  107  using the reservation state of the schedule data. Which definition data is referred to is determined at step  705  in the same manner as the schedule display process. If the reservation state of the schedule data is defined as displayable, the particular reservation schedule is handled as established. In other words, the time zone of the schedule data is stored at step  706  as an occupied time zone, and the process proceeds to step  707 . In the case where the reservation state of the schedule data is defined as non-displayable, on the other hand, the process proceeds directly to step  707 . In other words, the time zone of the schedule data is handled as an unoccupied time. At step  707 , the variable Count is decremented by one, after which the process of steps  704  to  707  is repeated as long as the variable Count is larger than zero. Next, at step  708 , the unoccupied time is searched for by reflecting the stored data in the occupied time zone. Specifically, during the designated period, i.e. from 0000 hours until 2400 hours on Jun. 30, 1997, the time zone lasting at least one hour continuously in other than the stored unoccupied time zone is used as an unoccupied time. Once the unoccupied time is determined, an unoccupied time list is transmitted to the client (step  709 ). 
     An example of display of the unoccupied time list on the client is shown in FIG.  8 . On the client, the user selects one of the unoccupied times displayed as shown in  FIG. 8 , and designates the reservation registration by a pull-down menu or the like. Thus, a reservation registration request can be transmitted to the server  103 . 
     Assume that the server  103  has received a reservation registration request for the schedule data from a client  102 . The schedule reservation registration process in the schedule data operating unit  108  starts as shown in  FIG. 9. A  case in which the user of “User 002 ” registers the reservation of the schedule data of the user of “User 001 ” will be described. 
     At step  900 , the reservation registration process sets the user ID (User 001 ) to be schedule-registered and the search date (Jun. 30, 1997) in the received reservation registration request as search keys. A list of the schedule data on the search date of the user ID “User 001 ” is acquired from the schedule data storage unit  106  of the server  103 . In the example of the record shown in  FIG. 2 , the schedule data Nos.  1  to  8  are acquired (step  901 ). Then, in step  902 , the number of the schedule data acquired is substituted into the variable Count. Next, at step  903 , from the received reservation registration request the starting time and the ending time of the new schedule data to be registered are obtained. The schedule data acquired at step  901  are checked sequentially from the leading data to see whether the new schedule data is registered without any problem. 
     First, step  904  checks whether the time zone of the new schedule to be registered is overlapped with the time zone of the existing schedule data. If the time zones are not overlapped, the process immediately proceeds to step  907 . If the time zones are overlapped even partially, the process proceeds to step  905  for checking whether the existing schedule data is for a reservation schedule or not. If it is not a reservation schedule, i.e. if the reservation state of the schedule data is “-”, the process proceeds to step  907 . In the case where the existing schedule data is for a reservation schedule, on the other hand, the process proceeds to step  906 , where the possibility of registration is determined from the reservation state of the existing schedule data and the data in the definition data storage unit  107 . 
     In the case where the system has one definition data, the particular definition data is referred to. In the case where the definition data is produced for each user ID, on the other hand, the definition data for the user ID (User 001  in this case) to be schedule-registered is referred to. 
     The “registration” data in the definition data is compared with the reservation state of the existing schedule, and if the result is “O”, the registration of the new schedule data is permitted. 
     If the definition shown in  FIG. 3  is involved, the registration of a new schedule is not permitted only when the reservation state of the existing schedule data is “approved”, and the new schedule can be registered in cases other than “approved”. When the registration is permitted, the process proceeds to step  907 . At step  907 , 1 is decremented from the variable Count. After that, the next existing schedule data are checked repeatedly at steps  904  to  906 . 
     When the variable Count reaches 0 as a result of the repetition, it is determined that none of the existing schedule data on the search date is adversely affected by the registration of a new schedule data. Thus, the new schedule data is registered at step  908 , and the completion of the reservation registration is notified to the client, then ending the whole process. 
     In the case where the reservation state of the existing schedule data does not permit the registration of a new schedule data in step  906  during the repetition, on the other hand, the process immediately proceeds to step  909 , and the client is notified that the new schedule data could not be registered, then ending the whole process. Step  909  can be modified in such a manner that a notice prompting the input of a correction of the time zone of the new schedule data is transmitted to the client and when a correction input is received, the process is repeated from step  900 . 
     The schedule data operating unit  108  of the server  103  performs the following additional tasks. 
     As shown in  FIG. 10 , upon receipt of an approval/disapproval request ( 1005 ) of a schedule data in “suspended” state from a client, the schedule data operating unit  108  checks the request source user ID and the user ID of the owner of the particular schedule data. Only when both are coincident with each other and the reservation state of the schedule data is “suspended”, the reservation state is updated in accordance with the received request, and the request source is notified of the complete updating ( 1006 ). 
     In the case where a request ( 1007 ) for checking the reservation state of the schedule data of which the reservation has been registered is received from the client as shown in  FIG. 10 , the schedule data operating unit  108  reads the reservation state of the particular schedule data and transmits it to the request source ( 1008 ). 
     Also, the schedule data operating unit  108  checks the schedule data in the schedule data storage unit  106  regularly, and deletes the schedule data for which a predetermined storage period is overdue. In the case where the storage period is determined as three months, for example, the data that have passed three months from the date of the schedule data are deleted. For deletion of old schedule data, the storage period can be set for each user ID or such data can be deleted in response to a schedule data delete request from a client. 
     When checking the schedule data in the schedule data storage unit  106  regularly, the schedule data operating unit  108  can transfer the past schedule data to a place other than the storage unit  106  and store them there. 
     (5) Modifications 
     In the embodiments, a system for communication between clients and a server via a communication network is described. As an alternative, the functions of the server and the clients can be integrated so that a system may be configured of one computer and more than one terminals or remote terminals. 
     In  FIG. 9 , a registered schedule is always permitted to overlap with an existing schedule in the reservation state of “-”, i.e. an existing schedule set by the schedule owner. This can be modified in such a way that the established state of the schedule set by the schedule owner is also classified and registered in the definition data as additional data. In the schedule registration process, an overlapped reservation registration of a new schedule requested from a different client may not be permitted in the case where the degree of established state is high in the classification. 
     The four reservation states were described above as “approved”, “disapproved”, “suspended” and “unread”. In addition, the states such as “provisionally approved” and “delegated” can be defined. In such a case, a similar determination is possible if “provisionally approved” and “delegated” are additionally defined as the items of FIG.  3 . The permission of display and registration is determined in accordance with the definition in the definition data storage unit  107 . Therefore, if the process corresponding to the reservation state is added to the definition, it can be reflected in the determination process of steps  406 ,  705  and  906 . 
     In the embodiment, when the schedule display request from the schedule owner is received, the schedule display process ( FIG. 4 ) updates the schedule data from “unread” to “suspended” at step  410 . Alternatively, the schedule data may not be updated when the display request is received. And when the detailed information display request from the schedule owner is received, the schedule data may be updated from “unread” to “suspended”.

Technology Category: 3