JP2005004307A - Schedule management support system, and appointment adjustment support system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To improve productivity by sharing schedule information of a group even when a user not used to using a computer belongs to the group. <P>SOLUTION: A server is provided with a calendar image plane control part 13 retrieving request data and normal schedule data stored in a schedule associated table 29 in regard to a period (month, week, day, or the like) responding to display designation 13b, describing the request data and the schedule data in each calendar field 13e dividing the period into days, and generating a calendar table 13d having the calendar fields 13e of the days within the period. The calendar image plane control part 13 is provided with a request display control function 18 describing the request data in a request display area outside the calendar table in a calendar image plane. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a schedule management support system, and more particularly to a system for supporting a schedule management operation of each user using a server and a terminal.
[0002]
[Prior art]
2. Description of the Related Art Conventionally, companies, universities, etc., confirm the date and time while adjusting the schedule of candidates for participation in appointments for appointments such as meetings, workshops, exhibitions, and trips. The organizer requesting participation (owner) requests participation from the organizer (conventional user), and decides the final date and time by referring to the response from the invited user. To do. The convened user adjusts the schedule according to his / her own schedule and the appointment requested to participate, and manages the schedule using schedule management software, a notebook, and the like.
[0003]
Patent Document 1 discloses a mechanism for referring to a schedule of another user for the purpose of sharing schedule information and a mechanism for facilitating determination of a common schedule such as a meeting. In FIG. 7 of this patent document 1, the schedule indicated by the thick solid double arrow is a personal schedule in which the start time and end time are fixed, and the thick dotted arrow indicates that either the start time or the end time is fixed. In the personal schedule, the thick hollow arrow is the common schedule confirmed at the meeting, etc. The thick hollow arrow with the “?” Mark is the common schedule notified by the meeting organizer. The schedule does not reply. The indeterminate state with the “?” Mark is confirmed by replying to participate or not participate.
[0004]
Patent Document 2 discloses a system for systematically managing each user's individual schedule and a total schedule (group schedule) common to a plurality of users. Paragraphs 0073 and 0079 of Patent Document 2 disclose a method of changing display attributes such as colors depending on the type of schedule so that the normal schedule and the total schedule can be grasped at a glance.
[0005]
[Patent Document 1]
JP-A-5-165836
[Patent Document 2]
JP 2000-57217 A
[Patent Document 3]
JP 2002-49729 A
[0006]
[Problems to be solved by the invention]
In each of the above conventional examples, there is a disadvantage that the convening user is difficult to notice that the owner has requested the appointment. In other words, in Patent Documents 1 and 2, since the group schedule is displayed only inside the calendar, the calendar is not used to notice the request unless the month and week calendars including the requested date are displayed. . From the convening side, it is difficult to predict when the appointment request will be received, and it is also difficult to predict when the date of the request will be. In addition to the schedule confirmation work, it is necessary to regularly confirm that there is no request.
[0007]
In Patent Document 2, since the total schedule is already determined by the owner, the original schedule must be adjusted separately by e-mail or telephone. Therefore, in this conventional example, the schedule is adjusted. It must be done separately from the daily check of your schedule. In Patent Document 1, since a schedule is determined when a reply is made to an appointment request, the appointment cannot be adjusted using a plurality of candidate dates in the system. The schedule management is complicated when there are a plurality of requests for which a plurality of candidate dates have been proposed, and it is extremely complicated to adjust the schedule of such appointments using e-mail or the like.
[0008]
In a situation where requests with multiple candidate dates and requests with a single candidate date coexist, careful and elaborate work is required to manage which date finally entered which schedule. It was necessary, especially for users who were not familiar with how to use computers. On the other hand, in systems such as Patent Documents 1 and 2, where a group-scheduled schedule can be managed together with an individual schedule, there are users who cannot use computers in the group, and the schedule is reliably input to the system. If it is not received, it will become an impediment to productivity improvement by sharing schedule information.
[0009]
OBJECT OF THE INVENTION
The present invention can improve productivity by sharing schedule information of a group, even if a user who is not familiar with the use of a computer belongs to a group in terms of schedule management. The purpose is to provide a schedule management support system that does not feel as complicated as software for beginners.
[0010]
The present invention also includes a schedule management in which a plurality of candidate dates are included in a request for a single appointment, and the appointment can be adjusted in the system so that the owner selects a final candidate date. The purpose is to provide a support system.
[0011]
[Means for Solving the Problems]
The inventor of the present invention is basically used for both beginners and experts who use a schedule management software in which a confirmed individual schedule is input and confirmed in units of weeks or months. We focused on the fact that both beginners and skilled workers routinely check this schedule. And if you can inform users about appointment requests and confirmation of candidate dates during this daily schedule check, you can provide a system that is easy for beginners and does not require a lot of time for skilled workers. I got an idea.
[0012]
Therefore, in the present invention according to claim 1, a server that processes transmission / reception of various data via a network with a terminal that is used by each of a plurality of users, and a database that manages data related to the user's schedule that is provided alongside this server And. The database includes a user table for storing data relating to the user, and a schedule related table for storing the normal schedule data that is the normal schedule of each user and the request data that the user who is the appointment owner requests to join. I have.
In addition, when the appointment of the request data is confirmed by the owner, the server converts an appointment confirmation processing unit of the requested data into the normal schedule data, and a calendar screen transmitted from the terminal. When the display command and the display designation are received, the request data and the normal schedule data stored in the schedule related table are searched for the period according to the display designation, and the period is set for each day for the request data and the schedule data. And a calendar screen control unit for generating a calendar table having a calendar field for dates within the period.
In addition, the calendar screen control unit has a request display control function for describing the request data in a request display area outside the calendar table in the calendar screen. This solves the problem described above.
[0013]
The calendar screen control unit describes the normal schedule data and the request data in the calendar field according to the display designation such as month display or week display, and generates a calendar table for the period specified by the display designation. Then, the request display control function describes request data in a request display area outside the calendar table. Therefore, the request data is always displayed on the calendar screen regardless of the display designation period. Therefore, it is possible to notify the user of the existence of request data whose scheduled date and time is outside the period displayed on the calendar screen. In addition, during the period to be confirmed as daily work, the request data is displayed in the calendar field together with the normal schedule data. For this reason, it is possible to confirm on the calendar screen the contents of the request data within the period to be confirmed and the presence or absence of the request data for other periods during the routine schedule confirmation work. Therefore, even a beginner can easily check the contents of request data within the period and the presence or absence of request data outside the period without requiring any special operation. Since there is only a display of the schedule and the presence / absence of a request, there is no complication.
[0014]
DETAILED DESCRIPTION OF THE INVENTION
Next, an embodiment of the present invention will be described.
[0015]
FIG. 1 is a block diagram illustrating a configuration example of an appointment adjustment support system according to the present embodiment, and FIG. 2 is an explanatory diagram illustrating an example of a data structure used in the present embodiment.
Referring to FIG. 1, the appointment adjustment support system according to the present embodiment includes a terminal 10 that is used by a plurality of users and a server 10 that processes transmission / reception of various data via a network, and the user who is attached to the server 10 and the user And a database 2 for managing data relating to the schedule.
[0016]
The database 2 includes a schedule related table 29 and a user table 30 as shown in FIG. The schedule related table 29 stores normal schedule data that is a normal schedule of each user and request data that is requested to participate by the user who is the appointment owner. In the example shown in FIG. 2, the schedule related table 29 includes an appointment schedule table 32 that stores request data and reply status data, and a normal schedule table that stores confirmed normal schedule data.
[0017]
Referring again to FIG. 1, the server 10 includes an appointment confirmation processing unit 12 and a calendar screen control unit 13. The appointment confirmation processing unit 12 converts the data regarding the confirmed date and time of the request data into the normal schedule data when the appointment of the request data is confirmed by the owner. This conversion process may be a process of generating normal schedule data from the reply status data stored in the appointment schedule table 32 and storing it in the normal schedule table 34, for example. In this case, the confirmed request data and reply status data are deleted from the appointment schedule table.
[0018]
The calendar screen control unit 13 generates a calendar table 13d that displays a schedule in accordance with the display designation 13b in the calendar screen 13a. Specifically, when the calendar screen control unit 13 receives a display command and display designation 13b (individual month, group week, etc.) of the calendar screen 13a transmitted from the terminal 1, first, according to the display designation 13b. The request data and the normal schedule data stored in the schedule related table 29 are searched for a certain period (month, week, day, etc.). Subsequently, the calendar screen control unit 13 describes the request data and the schedule data in each calendar field 13e in which the period is divided into days, and generates a calendar table 13d having a calendar field 13e for dates within the period.
[0019]
Particularly in the present embodiment, the calendar screen control unit 13 is provided in a request display area outside the calendar table in the calendar screen (in the example shown in FIG. 3, areas indicated by reference numerals 13f, 13g, 13h, 13i, and 13j). A request display control function 18 describing the request data is provided. Since the calendar screen control unit 13 displays the undecided schedule based on the request data on the calendar table 13d in the same manner as the normal schedule, the presence / absence of the request data and the request are requested for the period that the user should confirm as the daily work. The date and the like can be confirmed integrally with the normal schedule data. Further, since the request display control function 18 always displays the request data on the calendar screen regardless of the display designation period, the request in the calendar screen 13a is checked even if the daily schedule is confirmed, for example, on a weekly basis. By referring to the data display area, it is possible to confirm during daily work whether or not request data is scheduled to be received a few weeks or a month or two ahead.
[0020]
For this reason, it is possible to confirm the contents of the request data within the period to be confirmed and the presence / absence of the request data for other periods only on the calendar screen 13a during the routine schedule confirmation operation. Therefore, even a beginner can easily check the contents of request data within the period and the presence or absence of request data outside the period on a daily basis without requiring special operations. For the user, only the schedule and the presence / absence of the request are simply displayed, and there is no complication.
[0021]
The calendar screen shown in FIG. 3 is Mr. B's personal calendar screen, and the display designation indicated by reference numeral 13b is an individual and monthly. Mr. B currently displays the schedule for April, the next month, as March. Mr. B has received five appointment requests, and the requests on March 24th, 26th and May 22 are not displayed in the calendar table 13d for the period of April. The calendar screen control unit 13 displays the request data for April 2 and April 3 on the calendar table 13d.
[0022]
The calendar screen control unit 13 also reads out the regular meeting held every week at 9:30 on Friday and the business trip schedule on April 21, 22 from the normal schedule table 34 and displays them. The request display control function 18 reads the request data of the appointment designated as Mr. B from the appointment schedule table 32, and in the example shown in FIG. 3, the request data is displayed on each request data on the left side of the calendar table 13d. Set the area and display part (summary) or all of each request data. The request display control function 18 displays all the request data regardless of the period of the calendar table 13d (here, April in units of months). Therefore, a user who confirms a schedule using a calendar screen can easily find new request data during the daily work of confirming the schedule because the number and date of the requested data are in the same field of view. . In particular, even users who are unfamiliar with computer use can view a list of requested data in the calendar screen 13a without any special operation, so it is easy to manage schedules and schedules that are common to groups and members. Can be managed electronically. Therefore, there is no need for computer literacy training on adjusting appointments and sharing schedules.
[0023]
Referring to FIG. 1 again, when there are a plurality of request data read from the schedule related table 29, the calendar screen control unit 13 arranges the plurality of request data by using one or more items of the request data. A request data sorting function 19 to be replaced is provided. Preferably, when there are a plurality of request data, the request data sorting function 19 sorts the plurality of request data according to the order from the present to the future using the scheduled date / time data of the request data. In the example shown in FIG. 3, the scheduled date / time of the request data is arranged from the upper part to the lower part in FIG. In general, since the schedule is confirmed from a schedule with a date close to the present, in this case, the request data sorting function 19 does not perform the requested order, but the plurality of requests according to the order from the present to the future. Sort the data. The request data sorting function 19 allows the user to check the request data in a natural order. When there are a plurality of candidates in one piece of request data, the date made the first candidate by the owner may be used as one or more items of the request data. In addition, even in the case of the date and time, the time zone such as morning, afternoon, and evening is used as the first key for sorting, and then sorting by date is used to postpone the reply to appointment requests after evening. You can also In addition, when a convening user adopts flextime in a company, the convening user requests a defined time period to separate the handling of request data between his / her office hours and non-office hours. It may be a first key for sorting data.
Further, as one or more items of the request data, a user ID, a title that can be specified by the user ID, or the like may be adopted, and the request data may be rearranged. If the request data is rearranged for each user ID of the owner, the same appointment is often requested from the same owner, and therefore, it can be rearranged according to the content and type of the appointment.
For example, in the example shown in FIG. 3, when the request data is sorted by the user ID, the user ID is in the order of Mr. A, Mr. C, and Mr. F, and the codes are 13f, 13h, 13g, 13i, and 13j. Are displayed from top to bottom in the figure. Then, the convened user can easily find out, for example, that the request from Mr. C on March 26 and April 3 relates to the same company Q.
When using titles, for example, when there are general managers, section managers, etc., regardless of the candidate date, the rank of the owner's title is used as the first sort key, and the second sort key is used by the user. As the ID, the third sorting key may be the date and time. In this case, it is preferable to store a code for designating a title in the user table or the like, or use a code that can specify the rank of the title in the department table or the like that manages the user's affiliation. Alternatively, the numerical value of the user ID may be determined according to the rank.
In the relationship of the project described later, the project ID may be included in the contract data, and whether or not the project is a leader of the project, or may be sorted for each project ID.
[0024]
In addition, the calendar screen 13 has the following functions as to how to display on the calendar screen when the request data has a plurality of candidate dates. Depending on the amount of the appointment request or the amount scheduled, the user or the following function can be selected and used.
First, preferably, when the request data read from the schedule related table 29 has a plurality of candidate dates for the appointment, the calendar screen control unit 13 generates one request display area for one request data. And a first candidate display control function 20 in the request area that describes the date and time selected as the first candidate by the owner in the request display area. Displaying the presence / absence of request data in the request area is sufficient for immediate confirmation, and even when there are a large number of request data, the display can be made less complicated. In the specific schedule adjustment, in the calendar table 13d, by providing a function such as a display command 13b for displaying all candidate dates of each request data, it is convenient to select which candidate date for a single request data. It can contribute to the visual judgment of whether or not.
Secondly, preferably, the calendar screen control unit 13 generates one request display area for one request data when the request data read from the schedule related table 29 has a plurality of candidate dates for the appointment. The request display area may be provided with a function for controlling all candidates in the request display area that describes the dates and times of all candidate dates. In this example, one request display area is generated for each appointment, and the dates and times of all candidate dates are described in the request display area. As a result, the number of appointment requests and whether or not the appointment dates need to be adjusted for each appointment can be grasped visually.
Third, preferably, when a plurality of candidate dates are defined in the request data, the calendar screen control unit 13 generates one request display area for one request data, and requests the user specified in advance. According to the display area display setting, it is preferable to provide a function for displaying the date and time of all candidate dates only in one of the calendar field and the request display area. In this example, a plurality of candidate dates are displayed on either the calendar or the request display area of the calendar screen 13a for users who have many appointment requests and plans. Therefore, the same information of a plurality of candidate dates is not displayed twice.
[0025]
When the request data is received, the convened user creates reply data such as presence / absence of participation. In this example, the server 10 includes an adjustment control unit 16. When the adjustment control unit 16 receives an adjustment screen display command for creating a reply to the appointment request from the terminal 1 used by the convened user who is requested to participate in the appointment, the adjustment control unit 16 responds to the request for the appointment. An adjustment screen that prompts each convened user to input reply data is generated. In the present embodiment, in relation to the adjustment screen display command, the calendar screen control unit 13 displays the request display areas 13f and 13g for each request data, and the like, by transmitting the adjustment screen display command from the terminal. A request display area button control function 21 to be set in the command button is provided. That is, the request display area button control function 21 defines, as an execution button or a link, a text displaying a part of the request data of Mr. C shown in FIG. The area click operation is used as the adjustment screen display command. In the example provided with the request display area button control function 21, a special operation for creating reply data is not required, and creation of reply data for the request is promoted by an integrated work with a schedule confirmation work by a calendar. Can do.
[0026]
Next, the setting of the display format according to the schedule type will be described. In the present embodiment, the calendar screen control unit 13 includes a schedule type notation setting function 22 for setting the display format 13c of the description in the calendar field to a different display format for the request data and the schedule data. In the example shown in FIG. 3, the display format 13c is a black circle or white circle displayed on the time portion. The display format 13c may be color-coded such as time display of request data and schedule data. In the example shown in FIG. 3, the request data during the appointment adjustment is red, the normal schedule is black, and the recurring schedule of a regular meeting on Friday in the figure is light blue.
[0027]
When the appointment confirmation processing unit 12 confirms the appointment date and time, etc. by the owner, the calendar screen control unit 13 converts the request data into normal schedule data. The confirmed request data is displayed as a normal schedule in the calendar field 13e of the calendar table 13d. Then, the schedule type display setting function 22 changes the display format 13c depending on the type of the schedule, so that the change from the adjustment to the confirmation is changed by the change of the color or the like during the daily calendar screen browsing operation. I can grasp it.
[0028]
In particular, it is difficult for the calling user to predict when it will be confirmed by the appointment owner, so if you need a special action to check whether it has been confirmed or not, it will It becomes necessary to perform a confirmation operation for confirmation. The mechanism for notifying the confirmation according to the present embodiment in the display format of the schedule is easy to understand even for beginners because it is clear at a glance that the schedule within the period to be confirmed is confirmed in daily schedule confirmation work. It is easy, and it can be a mechanism that does not require any effort even for the skilled person.
[0029]
In addition, since the time when the confirmation process is performed by the owner is not necessarily the time when the user wants to confirm the schedule, when the user confirms the schedule, the display format is asynchronous to the owner's confirmation work. It can be understood that the change is confirmed by the change of 13c. For schedule management, whether the schedule is a group common schedule or an individual schedule is not necessarily important, it is more important whether it is a confirmed schedule or being adjusted, The mechanism for changing the display format between the adjustment and the fixed schedule is convenient for everyone.
[0030]
Further, for example, even if the user always displays the calendar display designation 13b as a weekly display, requests other than that week are displayed on the same screen by the request display control function 18, while The schedule can be grasped naturally by checking the daily schedule. Therefore, the individual's normal schedule, the appointment request, and the fixed common schedule after adjusting the appointment are managed by natural work. be able to.
[0031]
In addition, when the request data read from the schedule related table 29 has a plurality of candidate dates for the appointment, the calendar screen control unit 13 sets the request data at the date and time selected as the first candidate by the owner in the calendar field. The first candidate display control function 23 in the calendar described in 13e may be provided.
In this example, when request data having a plurality of candidate dates is displayed in the calendar field for each candidate date individually, the same task (appointment, request data) is considered to be a plurality of tasks in view of daily work. Therefore, only the date and time of the first candidate is displayed in the calendar field 13e.
[0032]
In the example shown in FIG. 3, the display format from reception of appointment request data to confirmation is displayed in red, and normal data including the confirmed appointment request is displayed in black. If the request data is divided into two types, and the appointment request is very active, a different display format (for example, green) may be used for the schedule until the decision is made after replying to the request data. Regarding the adjustment of the appointment, when the adjustment control unit 16 receives an instruction to display an adjustment screen for creating a reply to the appointment request from the terminal 1 used by the convened user who is requested to participate in the appointment. First, an adjustment screen is generated that prompts each convened user to input reply data for the appointment request. Then, the adjustment control unit 16 stores the reply data input to the adjustment screen in the schedule related table 29.
[0033]
In this example, preferably, the calendar screen control unit 13 includes a participation reply candidate date display control function 24. The participation reply candidate date display control function 24 stores the request data for all candidate dates returned as participation in the reply data for the request data before the confirmation by the owner after storing the reply data. Describe in the field. That is, of the candidate dates, the date and time of replying to participate must be avoided from overlapping with other schedules. If the request data is displayed on the calendar table 13b for all candidate dates or only the first candidate, an operation for confirming the returned candidate date is required. In the example provided with the participation reply candidate date display control function 24, the request data is displayed on the calendar table 13b for the date of reply that the participant participates.
[0034]
In this example, the relationship between the reception of the request data having a plurality of candidate dates and the display on the calendar table 13b first displays only the date of the first candidate in red when received. Subsequently, when participation or non-participation on the candidate date is announced using the adjustment screen, the candidate date on which participation is announced is displayed in green. Subsequently, when the appointment is confirmed by the owner, the appointment data is converted into normal schedule data by the appointment confirmation processing unit 12, so the schedule displayed in green disappears and becomes black. In this example, when non-participation is announced for all candidate dates on the adjustment screen, the request data is not displayed on the calendar screen.
On the other hand, when it is desired to display only the first candidate in the calendar field, the first candidate display control function in the calendar selects the request data before the confirmation by the owner after storing the reply data as participation in the reply data. It is preferable to provide a function for describing the request data in the calendar field only on the date and time when the convened user makes the first candidate among the returned candidate dates. In this example, when request data is received, the request data is displayed in red only on the date and time of the first candidate designated by the owner (candidate date rank is “1”). Subsequently, when participation or non-participation is announced on the adjustment screen using the adjustment screen, the request data is displayed in green only on the date and time selected as the first candidate by the calling user among the candidate dates on which participation was announced. . Subsequent determination is the same as described above. The candidate date specified as the first candidate by the convened user may be, for example, a candidate date with a high candidate date rank designated by the owner among the candidate dates that the convened user has announced to participate.
[0035]
FIG. 4 is a sequence diagram illustrating an example of the appointment adjustment support process in the present embodiment. The appointment adjustment support process according to this embodiment includes a request control process (A1, B1, etc.) for creating and notifying a participation request, and an adjustment control process (B3, B4, etc.) for adjusting appointment attendance and candidate date selection. And a confirmation step (A5, B5, etc.) for confirming the appointment.
[0036]
In the request control step, first, the user connects to the database, communicates with the terminal used by the owner, and prompts input of request data regarding the request for the appointment (step A1). In the request control process, when request data is input by the owner, the input request data is transmitted to a terminal used by the convened user convened for the appointment (steps B1 and B2). The notification of the request data is a display on the calendar screen 13a in the present embodiment. Furthermore, notification by electronic mail may be added. The display on the calendar screen 13a includes the display of request data in the calendar field 13e and the display in the request display area of the calendar screen. In the example using the calendar screen 13a, the request data is also displayed on the owner's personal calendar.
[0037]
In the adjustment control process, first, the database 2 is connected, and then communication with the terminal used by the convened user to which the request data is transmitted, and reply data such as attendance request for the request data is input. Prompt (step B3). At this time, referring to the appointment schedule table 32, the step B3 may transmit the reply status data of all other invited users to the terminal 1 used by all the invited users (step B4). The return status of the convened user can be sequentially referred to at the terminal used by the owner (step A3).
[0038]
In the adjustment control step, subsequently, communication with the terminal 1 used by the owner is performed, and the reply status data stored in the appointment schedule table 32 is displayed on the terminal 1 (step A3). Subsequently, the owner is forced to perform an appointment adjustment operation, and if the owner compulsorily adjusts the participation of unconvenied convened users or non-participating convened users to attend, The reply status data that has been adjusted is managed as the latest reply status data (step A4).
[0039]
In the confirmation control step, when the appointment operation is performed by the owner for the reply status data by communicating with the terminal used by the owner, the confirmed reply status data is set as the scheduled decision data. Manage (step A5). That is, the request data and the reply status data are converted into normal schedule data. In the confirmation control step, the confirmation schedule data is further notified to all the convened users (step B5). Then, the confirmed schedule is displayed as a normal schedule on the calendar screen 13a of the convened user who has confirmed participation (step B6). Further, it is also displayed as a normal schedule on the owner's personal calendar (step A6).
[0040]
The configuration shown in FIG. 1 and the processing steps shown in FIG. 4 can be realized by the CPU of the server executing a predetermined program. A CPU (not shown) of the system according to the present embodiment performs various calculations according to a predetermined program (command). The CPU drives the database 2 in accordance with various processing requests, executes generation and transmission / reception of various pages (screens), and transmits the execution results to the terminal 1. When the CPU executes the appointment adjustment support program, the system processes adjustment data generation, input reply data management, and the like.
[0041]
<Example>
FIG. 5 is a block diagram illustrating a configuration example of the present embodiment, and FIG. 6 is an explanatory diagram illustrating an example of a data structure in the present embodiment. An example of the field name of each table shown in FIG. 6 is shown in FIG. In the present embodiment, in the embodiment, an example is disclosed in which a Web server and a terminal including a browser that displays a screen (page) described in a markup language such as HTML are used.
[0042]
In the present embodiment, the appointment adjustment support system includes a terminal (Web server) 10 that processes transmission and reception of various data via a network with a terminal 1 that is used by each of a plurality of users, and the user's And a database 2 for managing data related to the schedule. As shown in FIGS. 6 and 7, the database 2 includes a user table 30, an appointment schedule table 32, a normal schedule table 34, and a schedule main table 36. In the present embodiment, as shown in FIG. 6, the normal schedule table 34 and the appointment schedule table 32 are selectively used according to the schedule type code of the schedule main table 36.
[0043]
The user table 30 stores user name data that is the name of the user for each user ID that identifies the user.
The schedule main table 36 includes, for each schedule ID for identifying a schedule, the user ID, a schedule type code for identifying the type or state of a schedule such as normal or during appointment adjustment, schedule content data as schedule contents, and appointments. The planned location data that is the planned location is stored.
The normal schedule table 34 stores schedule start date / time data and schedule end date / time data for each schedule ID.
The appointment schedule table 32 identifies, for each schedule ID for each candidate date rank, a user ID that specifies an owner who is an appointment requester of the schedule ID and a convened user to be convened, and the owner and the convened user. Together with an appointment user order that specifies the order of the convened user, an appointment candidate date order that identifies the candidate date when a plurality of dates and times are specified for adjustment for the same appointment by the owner, a scheduled start date and time, The scheduled end date and time, the attendance flag, and reply comments for each appointment request or candidate date rank are stored.
When a plurality of dates and times are designated for adjustment for the same appointment by the owner, the schedule ID may be an individual ID for each candidate date rank. In addition, it is preferable to use a common schedule ID, schedule location data, schedule start date / time, and schedule end date / time for the schedule confirmed by adjusting the appointment, and to use common data for each user. . In this case, each user cannot edit the confirmed appointment schedule individually. Further, the schedule ID may be set for each user so that each user can edit the schedule of the confirmed appointment.
[0044]
FIG. 7 illustrates the contents of each field of each table 30, 32, 34, 36. As shown in FIG. 7, the schedule type code indicating the type of schedule is “0” for a confirmed normal schedule, “1” for an appointment schedule that is being adjusted, The repeat schedule is “2”. As for the appointment user ranking, the owner is “0”, and the convened user is numbered sequentially from “1”. The appointment candidate date rank is a number for identifying a plurality of appointment candidate dates. In this embodiment, there are only two types of attendance flags, participation is “1”, non-participation is “0”, and there is no data structure indicating reply suspension. Therefore, attendance is flagged.
[0045]
Referring to FIG. 5 again, the server includes a request creation screen generation unit 50, a request data storage control unit 52, an adjustment screen generation unit 56, a reply data storage control unit 58, a confirmation process control unit 60, and a calendar screen. And a control unit 51. The process according to the present embodiment discloses the appointment adjustment support process shown in FIG. 4 in more detail using a characteristic screen using a Web server. In this embodiment, the “screen” is described in a markup language such as HTML displayed on the browser or the like of the terminal 1, and definition of options such as input fields, check boxes, and pop-up menus that are input by the user of the terminal 1. Is a file containing
[0046]
When the request creation screen generation unit 50 receives a display command of the request creation screen 42 for creating an appointment request from the terminal 1 used by the owner, the schedule creation data, the schedule location data, and the A request creation screen 42 (for example, the screen shown in FIG. 9) for prompting the owner to input the user name of the convened user and the scheduled start date and time and scheduled end date and time for each candidate date ranking is generated. In the example illustrated in FIG. 4, the request creation screen generation unit 50 performs the process of step A1.
[0047]
The request data storage control unit 52 first transmits the request creation screen 42 to the terminal used by the owner when the request creation screen is generated. Then, the request data storage control unit 52 receives the request data input to the request creation screen by the owner. The control unit 52 further stores the schedule content data and the schedule location data in the schedule main table while the appointment type code is being adjusted for appointment, while the contents of the other fields of the request creation screen 42 are stored in the schedule creation table 42. Store in appointment appointment table. The request data storage control unit 52 executes, for example, the flowchart shown in FIG. In the example illustrated in FIG. 4, the request data storage control unit performs the process of step A1. That is, in the present embodiment, the flowchart shown in FIG. 13 is the detailed process of step A1.
[0048]
When the calendar screen control unit 51 receives the display instruction and display designation of the calendar screen transmitted from the terminal 1, it is stored in the appointment schedule table 32 according to the schedule type code stored in the schedule main table. The request data and the schedule data stored in the normal schedule table 34 are described in each calendar field obtained by dividing the period into days. Thereby, the calendar screen control part 41 performs the process of step B1 and / or B2. Notify the convened user of the request data. The calendar screen control unit 51 may also include a request data notification control unit 54 that controls transmission of an e-mail that informs a convened user that the server 10 has transmitted the contents of request data or request data.
[0049]
When the adjustment screen generation unit 56 receives a display instruction of the adjustment screen 46 for creating a reply to the appointment request from the terminal used by the convened user, the attendance flag and each appointment request or candidate date ranking An adjustment screen 46 (for example, the screen shown in FIG. 11) that prompts each convened user to input each reply comment is generated. In the example illustrated in FIG. 4, the adjustment screen generation unit 56 performs the process of step B3.
[0050]
In a preferred example, the adjustment screen generation unit 56 may include an other user attendance reference control function 62. This function 62 has the same effect as the function 18 of the first embodiment or the like. That is, in this embodiment, the other user attendance reference control function 62 refers to the appointment schedule table 32 using the schedule ID as a key when receiving a display command for the adjustment screen 46 from the terminal 1 used by the convened user. Then, the user names, attendance flags and reply comments of other convened users are read from the appointment schedule table 32 and synthesized on the adjustment screen 46. In the example shown in FIG. 4, the other user attendance reference control function 62 performs the process of step B4.
[0051]
The reply data storage control unit 58 first transmits the adjustment screen 46 to the terminal used by the convened user when the adjustment screen 46 is generated. Subsequently, the control unit 58 receives reply data input to the adjustment screen by the convened user. Further, the control unit 58 stores an attendance flag and a reply comment for each appointment request or each candidate date rank in the appointment schedule table. In the example shown in FIG. 4, the reply data storage control unit 58 performs the process of step B3.
[0052]
In the present embodiment, the adjustment screen generation unit 56 preferably includes a determination adjustment screen generation function 64. When the confirmation adjustment screen generation function 64 receives a display instruction for the confirmation adjustment screen 48 from the terminal 1 used by the owner, the appointment adjustment screen generation function 64 refers to the appointment schedule table using the schedule ID as a key and calls all the invitations. The user name, the contents of the attendance flag and the reply comment for the convened user in which the reply data is stored are extracted. Subsequently, the confirmation adjustment screen generation function 64 generates a confirmation adjustment screen 48 (for example, the screen shown in FIG. 12) to which a forced participation check box is added regarding the attendance of each convened user. In the example illustrated in FIG. 4, the confirmation adjustment screen generation function 64 performs the process of step A3.
[0053]
In particular, in this embodiment, the calendar screen control unit 51 includes a request display control function 70 for describing the request data in a request display area outside the calendar table in the calendar screen, regardless of the display designation period, and a calendar field. And a schedule type notation setting function 71 for setting different display formats for each schedule type code stored in the schedule main table. The request display control function 70 executes the process shown in Step B2 of FIG. The schedule type notation setting function 71 plays the role of step B5 shown in FIG.
[0054]
The adjustment screen generator 56 may include a forced adjustment control function 66. The compulsory adjustment control function 66 forcibly confirms the attendance of attended users whose participation check box 49 on the adjustment screen 48 for confirmation is checked by the owner as participation. The forced adjustment control function 66 stores the start date / time and end date / time of the candidate date ranking determined by the owner in the normal schedule table 34 of the convened user. In the example illustrated in FIG. 4, the forced adjustment control function 66 performs the process of step A4.
[0055]
The confirmation processing control unit 60 refers to the appointment schedule table 32 and receives the confirmed candidate date when receiving the attendance at the appointment by the owner and the confirmation operation for the candidate date from the terminal used by the owner. The start date / time and end date / time of the candidate date for ranking are stored in the normal schedule table of the convened user confirmed to participate by the owner, and the schedule type code of the schedule is updated to the normal schedule. The confirmation process control unit 60 executes, for example, the flowchart shown in FIG. In the example illustrated in FIG. 4, the confirmation process control unit 60 performs the process of step A5. That is, the flowchart shown in FIG. 14 is a detailed process of step A5 in the present embodiment.
[0056]
Next, specific usage will be described with reference to the screen. Here, the following situation settings and characters are set. Mr. Abe, the sales manager of a major office furniture company, K, proposed a furniture layout plan for the purchase of office furniture following the relocation of customer Q. Project leader Abe is in a position to coordinate the presentation schedule for members. Members of this project include salesman Ebizawa, designers Yamada, Wada and Suzuki.
[0057]
FIG. 8 is an explanatory diagram showing an example of a user schedule data display screen. 8 to 12 show a state in which data transmitted from the server 10 is displayed as a screen using a browser application on a personal computer or the like. The underline in the figure is a link, which is a display command for other screens.
[0058]
The calendar screen control unit 51 generates a user schedule screen 40 (actually, a calendar screen 44) that displays a registered schedule of users belonging to a project or department for the appointment owner. Mr. Abe displays the user schedule screen shown in FIG. 8 and confirms the member's free schedule. On Thursday, Mr. Ebizawa, Mr. Yamada, and Mr. Wada have predecessors, and all members have no plans on Friday. The owner will propose both days as candidate dates. Mr. Abe who is the owner performs an operation such as clicking on the appointment link 40a shown as the appointment in FIG. The operation to the appointment link 40a is a display command for a request creation screen.
[0059]
In addition, Mr. Abe finds that Mr. Yamada has sent an appointment request with a scheduled date of January 21 to the request display area indicated by reference numeral 40b in FIG. This is request data. In the example shown in FIG. 8, since the scheduled date is within the period of the currently displayed calendar screen, the calendar screen control unit 51 displays the request in the display format (black circle) indicated by reference numeral 40e. Data is displayed in the calendar field 40h.
[0060]
FIG. 9 shows an example of the request creation screen 42. Mr. Abe inputs the appointment content “Q company visit” in the content field 42a of the request creation screen 42 and similarly enters “Yokohama” in the location field 42b. Subsequently, the candidate date and time are input using the GUI component in the date / time area 42c. Mr. Abe uses the date / time field in the combo box to specify the date / time. At this time, the first candidate is Friday (24th), and the second candidate is Thursday (23rd). In addition, the user to be convened is selected using the convened user specifying area 74.
[0061]
Referring to FIG. 5 again, in addition to the table shown in FIG. 6 and the like, for each project ID that identifies a project in which some or all of the users participate, the user ID of a user who is a member of the project, A project relation table 38 for storing contents belonging to the project, and a department table 31 for storing a user ID belonging to the department for each department ID for identifying the department to which the user belongs.
[0062]
Then, the server 10 refers to the project related table 38, communicates with a terminal used by the member of the project, and manages the project activity support for managing the project screen 90 that prompts to reference, edit, and register the content of the project. A control unit 72 is provided.
[0063]
Then, as shown in FIG. 9, the request creation screen 42 extracts a candidate list that is a candidate for the convened user to be convened for the appointment, and also specifies a convened user for urging the selection of the convened user from the candidate list An area 74 is provided. Then, a candidate list box 75 for displaying a candidate target list in the calling user specifying area 74, and a calling user list box 76 for displaying a list of user names as elements selected from the candidate list box 75, And a pop-up list 77 that prompts the user to select a project name or department name as a key of the candidate list. When the owner specifies a project name or a department name using the pop-up list 77, the request creation screen generation unit 50 refers to the department table 31 or the project related table 38 to list a list of user names belonging to the department, A member list is extracted and displayed in the candidate list box 75. The owner selects the user name displayed in the candidate list box 75 and adds it to the invited user list box 76.
[0064]
When the owner specifies the date / time and the user to be convened, the owner pushes down the request button 42 e and transmits the request data from the owner terminal 1 to the server 10. Mr. Abe also accepted the appointment request from Mr. Yamada and expressed his participation.
[0065]
FIG. 10 is an explanatory diagram showing an example of a calendar screen 44 having request display areas 44a and 44b. Mr. Yamada, the convening user, first received the reply data from Mr. Abe, and immediately confirmed the schedule for January 21st. When the appointment is confirmed and redisplayed, the display format is normally scheduled as shown by reference numeral 44d in FIG. 10, and a black circle is removed here.
[0066]
When the user's calendar screen 44 is opened, a request from Mr. Abe is displayed in the request display area 44b. For this reason, you can notice the appointment request in the usual activity of checking your schedule. And the schedule is filled in with a black circle on the 24th of the calendar. This is a notification to the convening user of the request data. For this appointment, Mr. Yamada who is the convening user simply opens the personal calendar screen 44, and the summary of the request data is displayed in the request display area 44b. , Appear on my calendar as my event. That is, the calendar screen control unit 51 notifies the request data by displaying the appointment request data as a schedule on each individual calendar. The request display area 44 b is a button, and an operation of clicking on this area transmits a display command for the adjustment screen 46 to the server 10.
In the example shown in FIG. 10, since a plurality of candidate dates are included in the request data, first, the all candidate display control function in the request display area is the candidate date of the first candidate in the request display area 44b. The month 24 and January 23, the candidate date of the second candidate, are described. In the example shown in FIG. 10, the first in-calendar display control function 23 displays the request data only in the calendar field on January 24, designated as the first candidate by the owner, out of the two candidate days. The request data is not displayed in the calendar field of January 23, which is the second candidate.
[0067]
Further, the request data notification control unit 54 may transmit the request data in real time by e-mail. Mr. Yamada, I tried opening the response screen (adjustment screen 46) for the time being.
[0068]
FIG. 11 is an explanatory diagram showing an example of the adjustment screen 46 for the convened user, and here is an adjustment screen for Mr. Yamada who is the convened user. Mr. Yamada understands that Mr. Ebizawa and Mr. Suzuki have already answered “No” (no participation) on Thursday and ○ (Participation) on Friday, and Mr. Wada has not answered. In this reply status data, Mr. Yamada thinks that the first candidate will be held, so that the first candidate is ○ (participation) and the second candidate is × (non-participation).
[0069]
When Mr. Abe opens the adjustment screen 48 for confirmation in this state, the screen shown in FIG. 12 is displayed. FIG. 12 is an explanatory diagram showing an example of an adjustment screen for owner (final adjustment screen 48). Mr. Abe thought that unanswered Wada would not be able to write a reply while going out, and decided to force participation without obtaining his consent. Therefore, Mr. Abe checked Mr. Wada's compulsory check box 49 on the adjustment screen 46, and pressed the first candidate confirmation button 49a. At this moment, an email was sent to everyone that the presentation was decided on Friday, and the official schedule (usually scheduled) was entered in the calendar of all members. That is, it is possible to confirm the schedule of all the convened users at the same time (simultaneous confirmation control function 67).
[0070]
FIG. 13 is a flowchart illustrating an example of request data storage processing by the request data storage control unit. When the required input items shown in FIG. 9 are input and the request button 42e is clicked by the owner, the browser of the terminal 1 adds the login user ID (in this case, the owner) to the input request data. The request data is transmitted to the server 10. Upon receiving the request data, the server 10 starts the process shown in FIG. That is, the request data storage control unit 52 first acquires a new schedule ID for new request data (step S1). Here, the schedule ID is acquired for each candidate date rank of the request data. Subsequently, the appointment candidate date rank is set to “1” (step S2). Further, the appointment user ranking of the owner is set to “0”.
[0071]
Subsequently, in order to assign the appointment user ranking, x = 1 is set (step S4), and the appointment user ranking of the convened user is x (step S5). Until this is completed for all “users to be called” shown in FIG. 9 (step S6), the value of x is incremented to set the appointment user rank.
[0072]
When the appointment user rank is set, the schedule ID, user ID, appointment user rank, candidate date rank, schedule start date and schedule end date and time are stored in the appointment schedule table 32 having the data structure shown in FIG. 6 (step S8). ). Subsequently, the schedule main table 36 stores the schedule ID, the user IDs of all users, the schedule type code, the schedule content data (Q company visit), and the schedule location data (Yokohama). Here, the schedule type code stores a code “1” indicating that the appointment is being adjusted. Thus, the request data for the first candidate date rank is stored using the schedule ID as a key. By referring to the schedule main table 36 using the schedule ID as a key, the various control units can specify whether the schedule identified by the schedule ID is a normal schedule or a schedule that is being adjusted for appointments.
[0073]
Subsequently, it is confirmed whether or not there is data for the next candidate date ranking (step S10). Here, since there is data for the second candidate date ranking, the process returns to step S1 and is scheduled for the second candidate date ranking. Get an ID. Similarly, for the second candidate date ranking, the request data is stored as schedule data during the adjustment of the appointment. Since there is no data for the third candidate date ranking, the processing ends.
[0074]
FIG. 14 is a flowchart showing an example of appointment confirmation processing by the confirmation processing control unit 60. When the button 49a to be confirmed is clicked while the latest reply status data shown in FIG. 12 is displayed, the browser of the terminal 1 transmits an event by the confirmation operation to the server. The browser also transmits to the server 10 whether or not the forced check box 49 is checked. Since the confirm button 49 a is related to the schedule ID and the candidate date rank, the server 10 receives at least the schedule ID, the candidate date rank, and the on / off of the forced check box 49 from the terminal 1. .
[0075]
In the server 10, when the confirmation process control unit 60 receives this confirmation operation, the process shown in FIG. 14 is started. First, all records related to the scheduled IDs other than the confirmed candidate date rank are deleted (step S11).
[0076]
Subsequently, the appointment schedule table 32 is searched from the schedule IDs of the determined candidate date rankings, and the schedule start date and time and the schedule end date and time are read. The schedule ID, the schedule start date and the schedule end date and time are newly newly set. It stores in the schedule table 34 (step S12). That is, the data regarding the confirmed schedule is copied from the appointment schedule table 32 to the normal schedule table.
[0077]
Further, the attendance user's attendance is confirmed in order from the appointment schedule table 32 using the schedule ID as a key (step S13). The search order of the convened user is the order of the appointment user ranking. Here, first, Mr. Abe who is the owner of the ranking “0” is confirmed. Since Mr. Abe's attendance flag is “1”, the schedule main table is searched with the schedule ID and the user ID of Mr. Abe, and the schedule type code is changed from “1” to “0” (step S15). . That is, the appointment of the first candidate is assumed to be Mr. Abe's normal schedule. Then, after making the normal schedule, the record of the appointment schedule table 32 regarding the corresponding user ID is deleted. Next, in steps S16 and S13, Mr. Ebisawa of rank “1” is specified and processed in the same manner.
[0078]
As for Mr. Wada, since the attendance flag is not stored in step S14 and is not “1”, the process proceeds to step S17. In step S17, it is confirmed whether or not the forced check box is turned on. Since the forced check box is turned on, the schedule type code is similarly updated to the normal schedule in step S15. When the schedule type code is a normal schedule, the schedule type code is displayed on each calendar screen 44 of each user as his / her schedule.
[0079]
FIG. 15 is a flowchart illustrating an example of a schedule display process on a calendar. The calendar screen 44 shown in FIG. 8 includes a display designation area 40c, a month / week designation area 40d, and a request display area 40b from the upper left in the figure, and further includes a project / department selection combo box 40f and a calendar table 40g. And a calendar field 40h. In this embodiment, the display designation includes personal month display, department week display and day display, project week display and day display. In the example shown in FIG. 8, the display designation is a weekly display of a project, and a project called Company P New Building Project is selected by the combo box 40f. The week to be displayed is from January 19, 2003 according to the operation of the month / week designation area 40d.
[0080]
When receiving a calendar screen display command from the terminal 1, the calendar screen control unit 51 of the server 10 performs a calendar screen display process shown in FIG. As shown in FIG. 15, the calendar screen control unit 51 first reads setting information and the like with reference to the user ID, and generates standard information for the calendar screen (step S <b> 21). Here, the areas 40c, 40d, and the like. Subsequently, the calendar screen control unit 51 generates a calendar table according to the display designation (step S22). For weekly display, an empty calendar table having columns from Sunday to Saturday and the number of rows corresponding to the number of members of the project is generated. Each field in the calendar table is called a calendar field.
[0081]
Subsequently, the calendar screen control unit 51 performs display processing for each calendar field in the calendar table. That is, in the example shown in FIG. 8, the scheduled start date and time of the normal schedule table 34 and the appointment schedule table 32 are referred to for each user ID. And a calendar field is specified in order from the past date in a calendar table (step S23). First, in the specification of the 19th calendar field for Mr. Abe, whether or not the 19th schedule is stored in both tables 32 and 34 is searched (step S25). It is confirmed whether or not (step S30), and since it is not completed, the process is moved to the 20th.
[0082]
On the 20th, a schedule for “strategic meeting” is stored in the normal schedule table 34. Since the answer is yes in step S24, the scheduled type code 25 is referred to, and the scheduled date and time is set to black because it is a normal schedule. If there is no other schedule on the same day (step S29), the 21st process is started via steps S30 and S23. On the 21st, there is an appointment request from Mr. Yamada, and the appointment schedule table 32 stores the scheduled start date and time of 13:00 on January 21st. In step S25, since the schedule type is an appointment schedule, the character display of the scheduled date and time is set to red. In the drawing, a black circle 40e is added instead of the process of making the character red.
[0083]
In the example shown in FIG. 10, Mr. Yamada's appointment schedule table 32 has two candidate days, 23 and 24, for one piece of requested data, visit Q company. In the case where it is specified that only the first candidate is displayed in the calendar table, in the example shown in FIG. 15, in step S33, the appointment schedule is stored in the appointment schedule table 32 for the 23rd. Referring to the candidate date ranking, since it is the second candidate, it is not determined as the candidate date to be displayed in step S33, and the display process is not performed. For the 24th day, the candidate date order is confirmed in step S33, and since it is the first candidate, the scheduled date and time is set to red in step S28 and the display process proceeds. Also, in this step S33, referring to the attendance flag for each candidate date in the appointment schedule table, among the candidate dates for participation (flag is “1”), the candidate date with the highest candidate date ranking (smallest value) It may be determined whether the date is a candidate date to be displayed on the calendar.
Further, in the example shown in FIGS. 8 and 10, the schedule is similarly searched for each user. In the example shown in FIG. 15, since the color of the characters displayed in the appointment schedule and the normal schedule is changed, it is possible to grasp at a glance that the appointment has been requested.
[0084]
When the reading of the schedule data and the color setting are all completed (step S31), the calendar table is described in a markup description language such as HTML.
[0085]
Further, referring to the appointment schedule table 32, the request data is described in the request display area 40b in the order of the request date. This request display area is a button for displaying an adjustment screen.
[0086]
As described above, in this example, in addition to the same effects as the embodiment, for example, by the combination of the function of forced adjustment by the owner and the function of changing the display format after confirmation (from red to black), The participation order by forced adjustment is displayed on the convocation user's calendar in the same way as a normal schedule, so it is more effective to participate than to call or send an e-mail to instruct the user to participate. In addition, the owner and the convened user who compulsorily participates require little effort. Further, since appointment adjustment and schedule management are supported as screen generation using Web technology, an asynchronous environment can be provided in which both parties can work when they want to work, unlike e-mail. In addition, in the combination of the other user attendance reference control function 62 and the schedule type notation setting function 71, all users can know the status of other invited users during the appointment adjustment, and a specific invitation You can also see how much appointment requests are coming from users. Therefore, it is possible to determine whether to convene or participate in consideration of not only the adjustment of one appointment but also the workload of the user.
[0087]
【The invention's effect】
According to the present invention, according to the configuration, the calendar screen control unit describes normal schedule data and request data in a calendar field according to display designation such as month display, week display, etc., and generates a calendar table of a period by display designation To do. Then, the request display control function describes request data in a request display area outside the calendar table. Therefore, the request data can always be displayed on the calendar screen regardless of the display designation period. Therefore, it is possible to notify the user of the existence of request data outside the period displayed on the calendar screen. In addition, the calendar screen control unit displays the request data and the normal schedule data together in the calendar field during the period to be confirmed as daily work. For this reason, it is possible to confirm on the calendar screen the contents of the request data within the period to be confirmed and the presence or absence of the request data for other periods during the routine schedule confirmation work. Therefore, even a beginner can easily check the contents of request data within the period and the presence or absence of request data outside the period without requiring any special operation. Since there is only a display of the schedule and the presence / absence of a request, there is no complication.
As described above, according to the present invention, the normal schedule data and the appointment schedule data are promoted in the daily work of confirming the schedule, that is, the individual schedule data and the schedule data that needs to be adjusted by the group are integratedly managed. be able to. As a result, even if a user who is not used to using a computer belongs to a group regarding schedule management, productivity can be improved by sharing schedule information of the group.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a configuration example of a schedule management support system in the present embodiment.
FIG. 2 is an explanatory diagram showing an example of a data structure in the present embodiment.
FIG. 3 is an explanatory diagram showing an example of a calendar screen handled in the present embodiment.
FIG. 4 is a sequence diagram illustrating an example of an appointment adjustment support process in the present embodiment.
FIG. 5 is a block diagram illustrating a configuration example of the present embodiment.
FIG. 6 is an explanatory diagram showing an example of a data structure in the present embodiment.
FIG. 7 is an explanatory diagram illustrating an example of a field name of each table in the embodiment.
FIG. 8 is an explanatory diagram showing an example of a user schedule data display screen.
FIG. 9 is an explanatory diagram illustrating an example of a request creation screen.
FIG. 10 is an explanatory diagram showing an example of a personal calendar screen having a request display area.
FIG. 11 is an explanatory diagram illustrating an example of an adjustment screen for a convened user.
FIG. 12 is an explanatory diagram showing an example of an adjustment screen (confirmation screen) for the owner.
FIG. 13 is a flowchart illustrating an example of request data storage processing;
FIG. 14 is a flowchart illustrating an example of a confirmation process.
FIG. 15 is a flowchart illustrating an example of a schedule display process.
[Explanation of symbols]
1 terminal
10 servers
12 Appointment confirmation processing section
13 Calendar screen controller
16 Adjustment control unit
18 Request display control function
19 Request data sorting function
20 First candidate display control function in request area
21 Request display area button control function
22 Notation setting function by schedule type
23 First candidate display control function in calendar
24 Participation Reply Date Display Control Function

Claims (16)

A server that handles transmission and reception of various data via a network and a terminal used by each of a plurality of users, and a database that is attached to the server and manages data related to the user's schedule,
The database includes a user table that stores data related to users, and a schedule related table that stores normal schedule data that is a normal schedule of each user and request data that is requested to participate by a user who is the appointment owner. ,
The server is
An appointment confirmation processing unit that converts data about the confirmed date and time of the request data when the appointment of the request data is confirmed by the owner;
When receiving a display instruction and display designation of a calendar screen transmitted from the terminal, the request data and the normal schedule data stored in the schedule related table are searched for a period according to the display designation, and the request A calendar screen control unit that generates a calendar table having a calendar field for dates within the period, describing each period of the data and schedule data in each calendar field divided into days.
A schedule management support system, wherein the calendar screen control unit includes a request display control function for describing the request data in a request display area outside the calendar table in the calendar screen. The calendar screen control unit includes a request data sorting function for rearranging the plurality of request data using one or more items of the request data when there are a plurality of request data read from the schedule relation table. The schedule management support system according to claim 1, wherein: 3. The request data sorting function includes a function of rearranging the plurality of request data according to an order from the present to the future using the scheduled date and time data of the request data. Schedule management support system. When the request data read from the schedule association table has a plurality of candidate dates for the appointment, the calendar screen control unit generates one request display area for one request data, and the owner selects the first candidate. 4. The schedule management support system according to claim 1, further comprising a first candidate display control function in the request display area for describing the date and time specified in the request display area. When the request data read from the schedule association table has a plurality of candidate dates for the appointment, the calendar screen control unit generates one request display area for one request data, and the request display area The schedule management support system according to claim 1, 2 or 3, further comprising a function for controlling display of all candidates in the request display area describing the dates and times of all candidate dates. When a plurality of candidate dates are defined in the request data, the calendar screen control unit generates one request display area for one request data, and according to a request display area display setting of a user specified in advance, The schedule management support system according to claim 1, 2 or 3, further comprising a function of displaying the date and time of all candidate dates only in one of the calendar field and the request display area. When the server receives an instruction to display an adjustment screen for creating a reply to the appointment request from a terminal used by the convened user who is requested to participate in the appointment, a reply to the request for the appointment An adjustment control unit that generates an adjustment screen that prompts each convened user to input data,
The calendar screen control unit includes a request display area button control function for setting a request display area for each of the request data to a display command button for transmitting a display command for the adjustment screen from the terminal. The schedule management support system according to claim 1, 2, 3, 4, 5, or 6. A server that handles transmission and reception of various data via a network and a terminal used by each of a plurality of users, and a database that is attached to the server and manages data related to the user's schedule,
The database includes a user table for storing data related to users, a request for participation from a user who is the appointment owner, and request data that is being adjusted for the date and time of the appointment, and a normal schedule for each user. And a schedule related table for storing data,
The server is
An appointment confirmation processing unit that converts data about the confirmed date and time of the request data when the appointment of the request data is confirmed by the owner;
When receiving a display instruction and display designation of a calendar screen transmitted from the terminal, the request data and the normal schedule data stored in the schedule related table are searched for a period according to the display designation and the request A calendar screen control unit that describes data and schedule data in each calendar field that divides the period into days,
The calendar screen control unit includes a schedule type notation setting function for setting the display format of the description in the calendar field to a different display format for the request data and the schedule data. system. 9. The schedule management support system according to claim 8, wherein the display format is color coding such as time display of request data and schedule data. 10. The schedule management support system according to claim 8, wherein the calendar screen control unit has a request display control function for describing the request data in a request display area outside the calendar table in the calendar screen. . When the request data read from the schedule association table has a plurality of candidate dates for the appointment, the calendar screen control unit describes the request data in the calendar field at the date and time that is the first candidate by the owner. The schedule management support system according to claim 8 or 9, further comprising a first candidate display control function in the calendar. When the server receives an instruction to display an adjustment screen for creating a reply to the appointment request from a terminal used by the convened user who is requested to participate in the appointment, a reply to the request for the appointment An adjustment screen for generating an adjustment screen that prompts each convened user to input data and storing the input reply data in the schedule related table is provided, and the first candidate display control function in the calendar stores the reply data The request data before being confirmed by the owner is provided with a function for describing the request data in the calendar field only at the date and time selected as the first candidate by the convened user among the candidate dates returned as participation in the reply data. The schedule management support system according to claim 11, wherein: When the server receives an instruction to display an adjustment screen for creating a reply to the appointment request from a terminal used by the convened user who is requested to participate in the appointment, a reply to the request for the appointment An adjustment screen that generates an adjustment screen that prompts each convened user to input data and stores the reply data to be input in the schedule related table is provided. The request data before confirmation is provided with a participation reply candidate date display control function for describing the request data in a calendar field of the candidate date for all candidate dates returned as participation in the reply data. Item 10. The schedule management support system according to Item 8 or 9. A server that handles transmission and reception of various data via a network and a terminal used by each of a plurality of users, and a database that is attached to the server and manages data related to the user's schedule,
The database is
A user table storing user name data which is the name of the user for each user ID for identifying the user;
For each schedule ID for identifying a schedule, a schedule main table for storing the user ID, a schedule type code for identifying a schedule type or status such as normal or during appointment adjustment, and schedule content data that is a schedule content;
A normal schedule table storing schedule start date and time data and schedule end date and time data for each schedule ID;
For each schedule ID for each candidate date ranking, a user ID that specifies an owner who is a requester of the appointment of the schedule ID and a convened user to be convened, and a plurality of dates and times are designated by the owner for adjustment for the same appointment An appointment schedule table for storing the appointment candidate date order for identifying the candidate date, the scheduled start date and time, the scheduled end date and time, the attendance flag, and a reply comment for each appointment request or each candidate date order. Prepared,
The server is
When receiving a request creation screen display command for creating an appointment request from a terminal used by the owner, the planned content data, the planned location data, the user name of the convened user, and the candidate A request creation screen generation unit for generating a request creation screen that prompts the owner to input a schedule start date and time and a schedule end date and time for each day order;
When the request creation screen is generated, the request creation screen is transmitted to the terminal used by the owner, the request data input to the request creation screen by the owner is received, and the scheduled type code is appointmented. A request data storage control unit that stores the scheduled content data and the planned location data in the scheduled main table as being adjusted, and stores the contents of other fields of the request creation screen in the appointment scheduled table;
When an instruction to display an adjustment screen for creating a reply to the appointment request is received from the terminal used by the convened user, input of an attendance flag and a reply comment for each appointment request or candidate date rank An adjustment screen generation unit that generates an adjustment screen to prompt each convened user,
When the adjustment screen is generated, the adjustment screen is transmitted to the terminal used by the convened user, the reply data input to the adjustment screen by the convened user is received, the attendance flag, and the appointment A reply data storage control unit for storing reply comments for each request or candidate date ranking in the appointment schedule table;
When the terminal used by the owner receives an attendance to the appointment by the owner and a confirmation operation for the candidate date, the appointment date start date and time of the confirmed candidate date ranking is referred to the appointment schedule table. And an end date and time are stored in the regular schedule table of the convened user confirmed to participate by the owner, and a schedule processing control unit for updating the schedule type code of the schedule to the normal schedule,
When receiving the display instruction and display designation of the calendar screen transmitted from the terminal, the request data stored in the appointment schedule table according to the schedule type code stored in the schedule main table and the normal schedule table A calendar screen control unit that describes stored schedule data in each calendar field that divides the period into days,
This calendar screen control unit
A request display control function that allows the request data to be described in a request display area outside the calendar table in the calendar screen regardless of the display designation period.
An appointment adjustment support system comprising a schedule type notation setting function for setting a display format of the description in the calendar field to a different display format for each schedule type code stored in the schedule main table. 15. The appointment adjustment support system according to claim 14, wherein the display format is color coding for each schedule type code. When the reply data storage control unit receives an adjustment screen display command from the terminal used by the owner, the user name and reply data of all invited users are stored with reference to the appointment schedule table. The contents of the attendance flag and reply comments for the invited users are extracted, and if the attendance of each attending user is forcibly adjusted, the attendance of the attending user forcibly adjusted by the owner is confirmed to participate. The appointment adjustment support function according to claim 14 or 15, further comprising a forcible adjustment control function for storing the start date and time and the end date and time of the candidate date order determined by the owner in the normal schedule table of the convened user. system.

Images