Distribution system and distribution method

Abstract

To enable the distribution of information to registered users at any time from the past to the future.SOLUTION: A notification distribution server 100 constituting a distribution system 10 includes: a distribution destination calculation unit 112 configured to refer to a user database that stores records in which user identification information of an information system is associated with effective start date and expiration date, and acquire a distribution destination that is user identification information of a designated time-registered user who is a user of the information system at a designated registration time, which is a designated past, present, or future time; and a distribution request unit 113 configured to refer to an address database (employee database) storing user identification information and email addresses in association with each other, and request a mail server to distribute distribution information designated by the distribution destination.SELECTED DRAWING: Figure 9

Description

Technical Field

[0001] The present invention relates to a delivery system and a delivery method for delivering information to registered destinations.

Background Art

[0002] In organizations such as companies and government agencies, various business systems including financial systems and procurement systems are used. Emails are also used to notify users of business systems about service outages, system changes, and the like. The email delivery system described in Patent Document 1 enables delivery according to various attributes such as age, gender, region, and occupation.

Prior Art Literature

Patent Literature

[0003]

Patent Document 1

Summary of the Invention

Problem to be Solved by the Invention

[0004] In conventional information delivery including emails, including the email delivery system described in Patent Document 1, information is delivered to destinations (registrants) registered at the time of delivery. However, destinations for information delivery directed to users of a business system are not necessarily registered at the current time, which is the delivery time. For example, it is desirable to deliver a notification of a service outage next month to users registered as of the first day of next month. In addition, when a defect in a business system is found, it is desirable to deliver a request to confirm content that was input into the business system in the past to past users. However, conventional information delivery systems cannot deliver information to users (registrants) at past or future points in time, and delivery to users at past, present, and future points in time is desired.

[0005] This invention was made in view of the above background, and aims to provide a distribution system and distribution method that enables the distribution of information to registered users at any point in time, from the past to the future. [Means for solving the problem]

[0006] To solve the above-mentioned problems, the distribution system according to the present invention includes a user database in which records are stored that associate user identification information of the information system, the effective start date, and the expiration date. , and if the designated registration date is in the past, the update history database; if it is in the future, the user modification / deletion database. The system includes a delivery destination calculation unit that obtains the delivery destination, which is the user identification information of a registered user at a specified time, who is a user of the information system at a specified time, which is a specified past, present, or future point in time, by referring to the specified past, present, or future point in time; and a delivery request unit that requests the mail server to deliver the delivery information specified to the delivery destination by referring to an address database in which the user identification information and email address are stored in association. [Effects of the Invention]

[0007] According to the present invention, it is possible to provide a distribution system and distribution method that enables the distribution of information to registered users at any point in time, from the past to the future. Other issues, configurations, and effects will be clarified by the following description of embodiments. [Brief explanation of the drawing]

[0008] [Figure 1] This is an overall configuration diagram of the distribution system according to this embodiment. [Figure 2] This is a functional block diagram of the database server according to this embodiment. [Figure 3] This is a data structure diagram of the employee database according to this embodiment. [Figure 4] This is a data structure diagram of the user database according to this embodiment. [Figure 5] This is a data configuration diagram of the distribution destination database according to this embodiment. [Figure 6]This is a data structure diagram of the user modification / deletion database according to this embodiment. [Figure 7] This is a data configuration diagram of the update history database according to this embodiment. [Figure 8] This is a functional block diagram of the control device according to this embodiment. [Figure 9] This is a functional block diagram of the notification distribution server according to this embodiment. [Figure 10] This is a flowchart of the user modification / deletion database generation process according to this embodiment. [Figure 11] This is a flowchart of the user database update process according to this embodiment. [Figure 12] This is a flowchart of the distribution destination database update process according to this embodiment. [Figure 13] This is a flowchart of the distribution process according to this embodiment. [Figure 14] This is a flowchart of the distribution process according to this embodiment. [Modes for carrying out the invention]

[0009] ≪Overview of the distribution system≫ The following describes a distribution system in an embodiment for carrying out the present invention. The distribution system distributes notices related to the business system to users of the business system. Current users are registered in the user database. Future updates to the user database are registered in the user update / deletion database. The update history of the user database (past updates) is stored in the update history database. The distribution system obtains users registered at a specified point in time (specified registration point) in the past, present, or future (specified registration point) by referring to the user database, the user update / deletion database, and the update history database, and distributes notices.

[0010] According to such a distribution system, notifications can be distributed not only to users at the current time point, but also to users at past or future time points (designated registration time points). For example, it becomes possible to transmit requests to users at a certain past time point, and notifications to persons scheduled to become users in the future.

[0011] <<Configuration of Distribution System>> FIG. 1 is an overall configuration diagram of a distribution system 10 according to the present embodiment. The distribution system 10 is configured to include a notification distribution server 100 and a management device 200. The distribution system 10 may further include a database server 300. The notification distribution server 100, the management device 200, and the database server 300 are connected to a network 480 and can communicate with each other.

[0012] A mail server 410, a business system 470 (information system), an operator terminal 420, and a user terminal 430 are connected to the network 480. An operator of the business system 470 operates the operator terminal 420 to specify a notification type, notification content, and a designated registration time point, and requests the notification distribution server 100 to distribute a notification. The operator may further specify a destination company (company code) to request distribution of the notification.

[0013] The designated registration time point is any time point among the past, present, and future. The notification distribution server 100 acquires users of the business system 470 who are registered at the designated registration time point and desire distribution of the notification of the corresponding notification type, and requests the mail server 410 to transmit the notification content to said users. The mail server 410 distributes the notification content to the user terminals 430 of users registered as users of the business system 470 at the designated registration time point.

[0014] <<Configuration of Database Server>> FIG. 2 is a functional block diagram of the database server 300 according to the present embodiment. The database server 300 is a computer and includes a control unit 310, a storage unit 320, and a communication unit 380. The communication unit 380 includes a communication device, and can transmit and receive data to and from the notification distribution server 100 and the management apparatus 200. The control unit 310 is configured including a CPU (Central Processing Unit), and searches and updates the database stored in the storage unit 320 in response to requests from the notification distribution server 100 and the management apparatus 200.

[0015] The storage unit 320 is configured including storage devices such as ROM (Read Only Memory), RAM (Random Access Memory), SSD (Solid State Drive), and HDD (Hard Disc Drive). An employee database 330, a user database 340, a distribution destination database 350, a user revision / abolition database 360, and an update history database 370 are stored in the storage unit 320.

[0016] <<Database Server: Employee Database>> FIG. 3 is a data configuration diagram of the employee database 330 according to the present embodiment. The employee database 330 is tabular data, and one row (record) represents an employee of a company group that uses the business system 470. Records in the employee database 330 include columns (attributes) for employee identification information (described as ID (identifier) in FIG. 3), name, email address, company code of the affiliated company, and time zone of the region where the employee's affiliated company is located (described as TZ in FIG. 3). The employee database 330 may include attributes other than those described above, and may include, for example, the employee's working hours.

[0017] <<Database Server: User Database>> Figure 4 is a data structure diagram of the user database 340 according to this embodiment. The user database 340 is tabular data, where each row (record) represents an employee registered as a user of the business system 470. The records in the user database 340 include columns (attributes) for employee identification information (labeled ID in Figure 4), name, email address, company code of the company to which the employee belongs, effective start date, expiration date, and time zone (labeled TZ in Figure 4).

[0018] The identification information corresponds to the identification information in the employee database 330. Users of the business system 470 registered in the user database 340 are registered in the employee database 330. The effective start date indicates the date on which registration as a user of business system 470 becomes effective. If the effective start date is a future date, a record of the user as a user of business system 470 is already stored in the user database 340, and the registration becomes effective from the effective start date.

[0019] The expiration date indicates the period during which the registration is valid. If the usage period for business system 470 is predetermined due to reasons such as retirement, an expiration date will be set. If it is undetermined, the end of 9999 will be set. If the expiration date is in the past, the user indicated by the record is a user who was registered in the past and is currently considered a user whose registration has been canceled (deleted). The time zone is the time zone of the user's workplace as indicated by the record.

[0020] ≪Database Server: Distribution Destination Database≫ Figure 5 is a data structure diagram of the distribution destination database 350 according to this embodiment. The distribution destination database 350 is tabular data, where each row (record) indicates the recipient of the notice. The records in the distribution destination database 350 include employee identification information (labeled as ID in Figure 5), type, and recipient columns (attributes).

[0021] The identification information corresponds to the identification information in the user database 340 and indicates the identification information of the user to whom the notification will be delivered. The type is the type of notification to be delivered to the user indicated in the identification information, and there are types such as "system change," "failure information," and "warning information." The recipient is the identification information of the employee to whom the notification will be delivered along with the user indicated in the identification information. This employee is not necessarily registered in the user database 340 (see Figure 4), but is registered in the employee database 330 (see Figure 3). Notifications of the type marked with "〇" will be delivered to the user indicated in the identification information and the employee listed as the recipient.

[0022] ≪Database Server: User Modification / Deletion Database≫ Figure 6 is a data structure diagram of the user update / deletion database 360 ​​according to this embodiment. The user update / deletion database 360 ​​is tabular data, and each row (record) shows the update content of the user database 340 (see Figure 4). Records in the user update / deletion database 360 ​​include attributes of the user database 340 as well as a category attribute indicating the type of update. In the following description, attributes other than the category (equivalent to the attributes of the user database 340) will be referred to as update content.

[0023] Records with the category "Add" indicate that the updated record will be added to the user database 340. Records with the category "Delete" indicate that the user registration indicated by the identification information (labeled as ID in Figure 6) will be deleted (erased) from the user database 340. In this embodiment, the registration is deleted (erased) by changing the expiration date of the user database 340. Records with the category "Change" indicate that the record in the user database 340 indicated by the identification information will be updated with the attributes of the updated content. The process of updating the user database 340 will be described later (see Figure 11).

[0024] ≪Database Server: Update History Database≫ Figure 7 is a data structure diagram of the update history database 370 according to this embodiment. The update history database 370 is tabular data, where each row (record) represents the update history of the user database 340 (see Figure 4). Records in the update history database 370 include identification information, update date, item, pre-update, and post-update attributes.

[0025] The identification information (labeled as ID in Figure 7) corresponds to the identification information in user database 340 and indicates the record that was updated. The update date is the date when user database 340 was updated.

[0026] The fields "Item," "Before Update," and "After Update" indicate the updates made to the records in user database 340. Each field stores the updated attribute name, its value before the update (attribute value), and its value after the update (attribute value), respectively. If multiple attributes are updated, multiple records are stored.

[0027] ≪Configuration of the control device≫ Figure 8 is a functional block diagram of the management device 200 according to this embodiment. The management device 200 is a computer and comprises a control unit 210, a storage unit 220, and a communication unit 280. The communication unit 280 is equipped with a communication device and is capable of sending and receiving data with the notification distribution server 100 and the database server 300.

[0028] The storage unit 220 is comprised of storage devices such as ROM, RAM, and SSD. The program 228 is stored in the storage unit 220. The program 228 includes descriptions of the procedures for the user modification / deletion database generation process (see Figure 10) and the user database update process (see Figure 11), which will be described later.

[0029] The control unit 210 includes a CPU and is equipped with a user update unit 211 and a notification distribution destination update unit 212. The user update unit 211 generates a user update / deletion database 360 ​​based on applications for new registration (addition), registration cancellation (deletion), and registration content change (modification) of users of the business system 470 (see Figure 10 below). The user update unit 211 also updates the user database 340 based on the user update / deletion database 360 ​​and stores the updated content in the update history database 370 (see Figure 11 below). The notification distribution destination update unit 212 updates the distribution destination database 350 based on the user update / deletion database 360 ​​(see Figure 12 below).

[0030] As described above, the distribution system 10 includes a user update unit 211 that updates the user database 340 by referring to the user modification / deletion database 360, which stores records associated with a category (either modification, addition, or deletion), user identification information (identification information), effective start date, and expiration date. The user update unit 211 stores the updated user database 340 in the update history database 370, which stores records associated with user identification information (identification information), update date, an item whose value is the effective start date (see effective start date in user database 340), expiration date (see expiration date in user database 340), or company code (see company code in user database 340), the pre-update value of the item, and the post-update value of the item (see pre-update and post-update values ​​in update history database 370).

[0031] ≪Configuration of the notification distribution server≫ Figure 9 is a functional block diagram of the notification distribution server 100 according to this embodiment. The notification distribution server 100 is a computer and comprises a control unit 110, a storage unit 120, and a communication unit 180. The communication unit 180 is equipped with a communication device and is capable of sending and receiving data with the management device 200 and the database server 300.

[0032] The memory unit 120 is comprised of memory devices such as ROM, RAM, and SSD. The memory unit 120 stores the program 128. The program 128 includes a description of the procedure for the distribution process (see Figures 13 and 14) described later.

[0033] The control unit 110 includes a CPU and comprises a reception unit 111, a distribution destination calculation unit 112, and a distribution request unit 113. The reception unit 111 receives requests for notification distribution from operator terminals 420 operated by operators of the business system 470. These requests include the notification type, notification content, and the designated registration date. The requests may also include the recipient company (company code).

[0034] The recipient calculation unit 112 obtains users of the business system 470 and recipients (see recipients in the recipient database 350 shown in Figure 5) who are registered at the time of designated registration and who wish to receive notifications of the specified type. The recipient calculation unit 112 obtains users of the business system 470 at the time of designated registration by referring to the user database 340 and other databases. The recipient calculation unit 112 obtains users of the business system 470 at the time of designated registration by referring to the user database 340 and obtaining users whose designated registration date falls between the effective start date and the expiration date.

[0035] The distribution request unit 113 requests the mail server 410 to send the notification content to the recipients. When making the request, the distribution request unit 113 requests that the notification be delivered at a time that matches the recipient's (user or recipient's) time zone, for example, after a predetermined time has elapsed from the start of the workday. If the notification distribution request includes setting a confirmation deadline, the distribution request unit 113 also requests the mail server 410 to resend the notification before the predetermined time before the confirmation deadline. The distribution request unit 113 also obtains the recipient's email address by referring to the employee database 330.

[0036] As described above, the distribution system 10 includes a distribution destination calculation unit 112 that obtains the distribution destination, which is the user identification information of a specified time registered user who is a user of the information system at a specified past, present, or future time, by referring to a user database 340 in which records are stored that associate user identification information (identification information) of the information system (business system 470), the effective start date, and the expiration date. The distribution system 10 also includes a distribution request unit 113 that refers to an address database (employee database 330) in which user identification information and email addresses are stored in association, and requests the mail server 410 to distribute the distribution information specified to the distribution destination.

[0037] ≪User Revision / Deletion Database Generation Process≫ Figure 10 is a flowchart of the user modification / deletion database generation process according to this embodiment. Referring to Figure 10, the process of generating the user modification / deletion database 360 ​​based on applications for new registration (addition), registration cancellation (deletion), and registration content modification (change) of users of the business system 470 will be explained. Note that the user modification / deletion database generation process will be executed once a day. Also, in the diagram, the database will be referred to as DB (database). For example, "user database" will be written as "user DB".

[0038] In step S11, the user update unit 211 starts the process of repeating steps S12 to S16 for each application. In step S12, the user update unit 211 proceeds to step S13 if the application type is new registration (step S12 → new registration), and to step S14 if it is a change in registration details or a cancellation of registration (step S12 → change / cancellation).

[0039] In step S13, the user update unit 211 determines the confirmation result to be OK if the new employee to be registered in the application is in the employee database 330 (see Figure 3) but not in the user database 340 (see Figure 4), and determines the confirmation result to be NG otherwise. In step S14, the user update unit 211 determines the confirmation result to be OK if there is a user in the user database 340 (see Figure 4) whose registration details are to be changed or deleted, and determines the confirmation result to NG if there is no such user.

[0040] In step S15, if the user update unit 211 confirms that the results of steps S13 and S14 are OK (step S15 → OK), it proceeds to step S16. If the user update unit 211 confirms that the results are NG (step S15 → NG), it returns to step S12 and processes the next application.

[0041] In step S16, the user update unit 211 adds the application details to the user modification / deletion database 360 ​​(see Figure 6). More specifically, if the application is a new registration, the user update unit 211 adds a record with the category "addition", the identification information being the identification information in the application, and the other attributes being attribute values ​​from the employee database 330. If the application is a modification, the user update unit 211 adds a record with the category "modification", the identification information being the identification information in the application, and the other attributes being the content included in the application. If the application is a registration cancellation, the user update unit 211 adds a record with the category "deletion", the identification information being the identification information in the application. Regarding the effective start date, if the application specifies a date on which the registration becomes effective, that date will be the effective start date. Otherwise, the effective start date will be the date on which the user modification / deletion database generation process is executed (the day the process is executed).

[0042] ≪User Database Update Process≫ Figure 11 is a flowchart of the user database update process according to this embodiment. The user database update process is executed following the user modification / deletion database generation process.

[0043] In step S21, the user update unit 211 starts the process of repeating steps S22 to S25 for each record in the user modification / deletion database 360. Hereafter, the record in the user modification / deletion database 360 ​​that is the target of this repeated process will be referred to as the target record. In step S22, the user update unit 211 proceeds to step S24 if the category of the target record is "add" (step S22 → add), and to step S23 if it is "modify" or "delete" (step S22 → modify / delete).

[0044] In step S23, the user update unit 211 proceeds to step S24 if the effective start date of the target record is the execution date (step S23 → YES), and returns to step S22 if it is not the execution date (step S23 → NO), and processes the next record in the user modification / deletion database 360 ​​as the target record.

[0045] In step S24, the user update unit 211 updates the user database 340 based on the target record. More specifically, if the category of the target record is "addition," the user update unit 211 adds a record with the content of the target record to the user database 340. If the category of the target record is "modification," the user update unit 211 updates the content of the record in the user database 340 with the same identification information as the target record to the content of the target record. If the category of the target record is "deletion," the user update unit 211 changes the expiration date of the record in the user database 340 with the same identification information as the target record to the execution date or the day before.

[0046] In step S25, the user update unit 211 stores the details of the update performed in step S24, along with the identification information of the target record and the update date (execution date), in the update history database 370 (see Figure 7).

[0047] ≪Database update process for distribution destinations≫ Figure 12 is a flowchart of the distribution destination database update process according to this embodiment. The distribution destination database update process is performed following the user database update process.

[0048] In step S31, the notification distribution destination update unit 212 starts the process of repeating steps S32 to S35 for each record in the user modification / deletion database 360. Hereafter, the record in the user modification / deletion database 360 ​​that is the target of this repeated process will be referred to as the target record. In step S32, the notification recipient update unit 212 proceeds to step S35 if the category of the target record is "addition" (step S32 → addition), and to step S33 if it is "modification" or "deletion" (step S32 → modification / deletion).

[0049] In step S33, the notification recipient update unit 212 proceeds to step S34 if the effective start date of the target record is the end of the month (step S33 → YES), and to step S35 if it is not the end of the month (step S33 → NO). In step S34, the notification recipient update unit 212 proceeds to step S35 if the execution date is a designated day (step S34 → YES), and returns to step S32 if it is not a designated day (step S34 → NO), and processes the next record in the user modification / deletion database 360 ​​as the target record. A designated day is, for example, the fifth business day of the month.

[0050] In step S35, the notification recipient update unit 212 updates the recipient database 350 based on the target record. More specifically, if the category of the target record is "addition," the notification recipient update unit 212 adds a new record to the recipient database 350 (see Figure 5). The identification information of the new record is the identification information of the target record, and all types of notifications are distributed, with no recipients. If the category of the target record is "change," the notification recipient update unit 212 does not update the recipient database 350.

[0051] In step S23 of the user database update process shown in Figure 11, updates to the user database 340 for records whose effective start date is not the execution date (the day of execution) are not performed and will be performed at a later date. The user update unit 211 performs the user database update process so that the user database 340 is updated once for each record in the user modification / deletion database 360 ​​(for example, the same record is not added twice).

[0052] The same applies to the distribution destination database update process shown in Figure 12. In step S34, updates to the distribution destination database 350 for records whose execution date is not the specified date are not performed and will be performed at a later date. The notification distribution destination update unit 212 executes the distribution destination database update process to update the distribution destination database 350 once for each record in the user modification / deletion database 360.

[0053] ≪Distribution Processing≫ Figures 13 and 14 are flowcharts of the distribution process according to this embodiment. Referring to Figures 13 and 14, the processing after the reception unit 111 receives a notification distribution request from the operator terminal 420 will be explained. This request is assumed to include the notification type, notification content, designated registration time, and the recipient company code.

[0054] In step S41, the distribution destination calculation unit 112 clears the distribution destination variable, which contains the identification information of the employee (user or recipient) to whom the distribution will be sent. In step S42, the recipient calculation unit 112 obtains identification information of the recipient users by referring to the recipient database 350 (see Figure 5). More specifically, the recipient calculation unit 112 obtains identification information of records in the recipient database 350 where the notification type included in the notification distribution request is "〇".

[0055] In step S43, the destination calculation unit 112 starts repeating steps S44 to S50 for each identification information obtained in step S42. Hereinafter, the identification information that is the subject of this repeated process will be referred to as the target identification information. In step S44, the destination calculation unit 112 proceeds to step S45 if the designated registration time is in the past (step S44 → past), to step S46 if it is in the present (step S44 → present), and to step S47 if it is in the future (step S44 → future).

[0056] In step S45, the delivery destination calculation unit 112 first checks if the variable is related to the target identification information and rejects it. The delivery destination calculation unit 112 searches the user database 340 (see Figure 4) for records where the identification information is the target identification information. If such a record exists, and the effective start date of the record is before or on the same day as the specified registration date, and the expiration date is on or on the same day as the specified registration date, the delivery destination calculation unit 112 checks the verification variable and rejects it. If such a record exists, and the effective start date of the record is on or after the specified registration date, the delivery destination calculation unit 112 checks the verification variable and rejects it.

[0057] Next, the distribution destination calculation unit 112 searches the update history database 370 (see Figure 7) for records whose identification information matches the target identification information. If the distribution destination calculation unit 112 finds a record where the item is "Expiration Date" and the update date is before or on the same day as the specified registration date, it sets the confirmation variable to OK. If the distribution destination calculation unit 112 finds a record where the item is "Company Code" and the update date is before or on the same day as the specified registration date, it updates the user's company code, indicated by the target identification information in the user database 340, with the updated value from the search result record in the update history database 370, and stores this updated information as the user's company code indicated by the target identification information.

[0058] In step S46, the delivery destination calculation unit 112 first checks if the variable is related to the target identification information and sets it to NG. The delivery destination calculation unit 112 searches the user database 340 for records where the identification information is the target identification information. If such a record exists, and the effective start date of the record is on or before the execution date, and the expiration date is on or after the specified registration date, the delivery destination calculation unit 112 sets the verification variable to OK. If such a record exists, and the effective start date of the record is on or after the present (future effective date), or the expiration date is a past date, the delivery destination calculation unit 112 sets the verification variable to NG. The delivery destination calculation unit 112 stores the company code of the target identification information in the user database 340 as the company code of the user indicated by the target identification information.

[0059] In step S47, the destination calculation unit 112 first checks if the variable is related to the target identification information and sets it to NG. The destination calculation unit 112 searches the user database 340 for records whose identification information is the target identification information. If such a record exists and its effective start date is before or on the same day as the specified registration, the destination calculation unit 112 sets the check variable to OK. If such a record exists and its effective start date is on or after the specified registration, the destination calculation unit 112 sets the check variable to NG. Next, the destination calculation unit 112 searches the user modification / deletion database 360 ​​(see Figure 6) for records whose identification information is the target identification information. If there is a record with the category "deletion" and an effective start date before or on the same day as the specified registration, the check variable is set to NG. If there is a record with the category "addition" and an effective start date before or on the same day as the specified registration, the destination calculation unit 112 sets the check variable to OK. The distribution destination calculation unit 112, if there is a record with the category "change" and an effective start date that is before or on the same day as the specified registration, and the company code is different from that in the user database 340, updates the company code of the user indicated by the target identification information in the user database 340 with the value in the search result record in the user change / deletion database 360, and stores this updated information as the company code of the user indicated by the target identification information.

[0060] In step S48, the destination calculation unit 112 proceeds to step S49 if the verification variable is OK (step S48 → OK), and returns to step S44 to process the next target identification information if it is NG (step S48 → NG). In step S49, the delivery destination calculation unit 112 proceeds to step S50 if the company code of the target identification information it holds is included in the requested delivery destination (step S49 → YES), and returns to step S44 to process the next target identification information if it is not included (step S49 → NO). In step S50, the distribution destination calculation unit 112 adds the target identification information and the recipient identification information of the record in the distribution destination database 350 whose identification information matches the target identification information to the distribution destination.

[0061] Moving to Figure 14, in step S51, the distribution request unit 113 divides the identification information at the distribution destination according to the company to which the employee indicated by the identification information belongs. The company to which the employee indicated by the identification information belongs can be obtained by referring to the company code updated in steps S45 and S47. In step S52, the distribution request unit 113 starts the process of repeating steps S53 to S55 for each identification information segmented in step S51.

[0062] In step S53, the distribution request unit 113 requests the mail server 410 to distribute the notification content to the email address corresponding to the identification information, in accordance with the time zone of the affiliated company. The email address corresponding to the identification information can be obtained by referring to the employee database 330. In accordance with the time zone of the affiliated company means, for example, distributing the notification during working hours, such as 10:00 a.m.

[0063] In step S54, the distribution request unit 113 proceeds to step S55 if the notification has a confirmation deadline (step S54 → YES), and returns to step S53 if it does not (step S54 → NO) to process the next segmented identification information. In step S55, the distribution request unit 113 requests the mail server 410 to redistribute the notification that was requested to be sent in step S53, before the specified date of the confirmation deadline.

[0064] As explained above (see step S47), if the designated registration time is in the future, the distribution destination calculation unit 112 will further include the user identification information of any records in the user modification / deletion database 360 ​​that have an added category and whose effective start date is earlier than the designated registration time, in the distribution destination.

[0065] As explained above (see step S49), the delivery destination calculation unit 112 obtains user identification information limited to the company code of the specified delivery destination and uses it as the delivery destination. If the designated registration date is in the past, the distribution destination calculation unit 112, if there is a record in the update history database 370 whose item is a company code and whose update date is earlier than the designated registration date, refers to the updated company code of that record in the user database 340 instead of the company code included in the user database 340, obtains user identification information, and sets it as the distribution destination.

[0066] Features of the distribution system According to the distribution system 10, notifications can be delivered not only to users in the present but also to users in the past and future (at the time of designated registration). For example, it becomes possible to send requests to users at a certain point in the past, or notifications to people who are expected to become users in the future. Furthermore, according to the distribution system 10, notifications are delivered according to the time zone of the region where the company to which the employee who will receive the notification belongs is located. For example, notifications can be delivered at times that avoid busy periods such as immediately after the start of the workday, such as 10 a.m., increasing the likelihood that the receiving employee will read the notification.

[0067] ≪Variation: Delivery Time≫ In the embodiment described above, the employee's time zone was the time zone of the location of the company to which they belonged. In global companies, employees' work locations are scattered, and they may not be limited to a single time zone. To take such cases into consideration, the employee database 330 may be the time zone of the employee's work location or residence. Taking this time zone into consideration, the distribution request unit 113 may request the mail server 410 to deliver notices within working hours (for example, from 9 a.m. to 5 p.m.) or after a predetermined time has elapsed since the start of work. Alternatively, the employee database 330 may include working hours, and the distribution request unit 113 may request the mail server 410 to deliver notices within these working hours or after a predetermined time has elapsed since the start of work.

[0068] As described above, the distribution request unit 113 refers to the employee database 330, which stores user identification information (identification information) and the time zone of the user's workplace identified by the user identification information, and requests the mail server 410 to distribute the distribution information within the user's working hours.

[0069] <<Other variations>> Although several embodiments of the present invention have been described above, these embodiments are merely illustrative and do not limit the technical scope of the present invention. In the embodiments described above, the recipients were users of the business system 470 or employees of the company using the business system 470. The distribution system 10 may be used not only in an organization's business system 470, but also in an information system that provides services to users not belonging to an organization, such as a membership-based website for general consumers, to provide information to past, present, or future members. Furthermore, although the means of distribution of notices in the embodiments described above was email, in this information system for general consumers, a different means of communication or notification, such as short message or chat, may be used.

[0070] The present invention can take on various other embodiments, and furthermore, various modifications such as omissions and substitutions can be made without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention as described herein, and are included in the scope of the invention and its equivalents as described in the claims. [Explanation of Symbols]

[0071] 10 Distribution System 100 Notification Distribution Servers 111 Reception Department 112 Distribution Destination Calculation Department 113 Distribution Request Department 200 Management device 211 User Update Department 212 Notification Distribution Destination Update Department 300 database servers 330 Employee Database (Address Database) 340 User Database 350 distribution destination databases 360 User Revision / Deletion Database 370 Update History Database 410 Mail Server 420 Operator terminal 430 User terminals 470 Business Systems (Information Systems) 480 Network

Claims

1. A user database that stores records associated with user identification information of the information system, the effective start date, and the expiration date, and a distribution destination calculation unit that obtains the distribution destination, which is the user identification information of a registered user who is a user of the information system at the specified time of registration, which is a specified past, present, or future time, by referring to an update history database if the specified registration time is in the past, or a user modification / deletion database if it is in the future, The system includes a delivery request unit that refers to an address database in which the user identification information and email address are stored in association, and requests the mail server to deliver the delivery information specified to the recipient. Distribution system.

2. The user modification / deletion database stores records associated with a category which is one of modification, addition, or deletion, the user identification information, the effective start date, and the expiration date. The aforementioned distribution destination calculation unit, If the aforementioned registration date is in the future, If the aforementioned user modification / deletion database contains a record in which the aforementioned category is added and the effective start date is earlier than the time of the designated registration, the user identification information of that record should also be included in the distribution destination. The distribution system according to claim 1.

3. The user database also stores a company code, which indicates the company to which the user belongs, in association with the user identification information. The aforementioned distribution destination calculation unit, The user identification information is obtained and the recipient is limited to the designated recipient company code. The distribution system according to claim 1.

4. The user modification / deletion database stores records associated with a category which is one of modification, addition, or deletion, the user identification information, the effective start date, and the expiration date. The update history database stores records that associate the user identification information, the update date, an item whose value is the effective start date, the expiration date, or the company code, the pre-update value of the item, and the post-update value of the item. The aforementioned distribution system The update history database further includes a user update unit that stores the updated content of the user database, The aforementioned user update unit is: The user database is updated by referring to the aforementioned user modification / deletion database. The aforementioned distribution destination calculation unit, If the aforementioned registration date is in the past, If there is a record in the update history database where the item is the company code and the update date is earlier than the time of the designated registration, the updated company code of that record will be referred to in place of the company code included in the user database, the user identification information will be obtained and used as the distribution destination. The distribution system according to claim 3.

5. The aforementioned distribution request department, The system refers to an employee database in which the user identification information and the time zone of the user's workplace identified by the user identification information are stored in association, and requests the mail server to deliver the information within the user's working hours. The distribution system according to claim 1.

6. The distribution system Steps include: obtaining the distribution destination, which is the user identification information of a registered user at a specified time, who is a user of the information system at the specified registration time, which is a specified past, present, or future time; referring to a user database that stores records associated with the user identification information of the information system, the effective start date, and the expiration date; and referring to an update history database if the specified registration time is in the past, or a user revision / deletion database if it is in the future; The steps include: referring to an address database in which the user identification information and email address are stored in association, and requesting the mail server to deliver the delivery information specified to the recipient; and executing the following steps. Distribution method.

Images