Program, method, and system

Abstract

To provide a system capable of managing information on prospective customers who may become parishioners in the future, not limited to parishioners who have already made a contract. [Solution] A program to be executed on a computer having a processor and memory, the program causing the processor to execute the steps of storing first information including unique information about parishioners and potential customers, storing second information including information regarding contracts for parishioners or potential customers, and displaying a portal page that arranges the second information in a list form so that it is accessible to the first information.

Description

[Technical Field]

[0001] The present invention relates to a program, a method, and a system. [Background technology]

[0002] In recent years, a system has been proposed to strengthen the ties between temples and their parishioners. For example, Patent Document 1 discloses a system that stores information about parishioners, such as a parishioner list, and information about the temple's schedule, allowing the temple to refer to the information about parishioners at any time and allowing parishioners to access the temple's terminal and obtain the temple's schedule. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2002-352017 Summary of the Invention [Problem to be solved by the invention]

[0004] The system described in Patent Document 1 can manage the schedules of parishioners and temples. However, temple operations are not limited to this, and there is room for improvement in the system's usability.

[0005] The present disclosure aims to support smooth communication between temples and their customers so that temple operations can be carried out more efficiently. [Means for solving the problem]

[0006] The program disclosed herein is a program to be executed by a computer having a processor and a memory, and causes the processor to execute the steps of storing first information including unique information of parishioners and potential customers, storing second information including information regarding contracts for memorial services from parishioners or potential customers, and displaying a portal page that arranges the second information in a list form so that it can be accessed from the first information. [Effects of the Invention]

[0007] The program of the present invention can support smooth communication between temples and their customers so that temple operations can be carried out more efficiently. [Brief explanation of the drawings]

[0008] [Figure 1] 1 is a diagram showing the overall configuration of a system according to an embodiment of the present invention; [Figure 2] FIG. 2 is a block diagram showing the configuration of a terminal device included in the system of the present embodiment. [Figure 3] FIG. 2 is a block diagram showing the functional configuration of a server included in the system of the present embodiment. [Figure 4] FIG. 2 is a diagram showing the data structure of a database relating to first information. [Figure 5] FIG. 10 is a diagram showing the data structure of a database relating to second information. [Figure 6] FIG. 10 is a diagram showing the data structure of a database relating to third information. [Figure 7] FIG. 10 is a diagram showing the data structure of a database relating to fourth information. [Figure 8] 1 is a diagram illustrating an overview of the processing of the temple affairs register system according to this embodiment. [Figure 9] FIG. 2 is a diagram showing an example of a first screen of the temple affairs ledger system according to this embodiment. [Figure 10] This is a diagram showing the first example screen of the temple affairs register system of this embodiment after it has been updated. [Figure 11]A figure showing a second example screen of the temple affairs ledger system related to this embodiment. [Figure 12] FIG. 10 is a diagram showing a third example screen of the temple affairs ledger system according to this embodiment. [Figure 13] FIG. 10 is a diagram showing a fourth example screen of the temple affairs register system according to this embodiment. [Figure 14] A figure showing a fifth example screen of the temple affairs ledger system related to this embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0009] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. In the drawings for explaining the embodiment, the same components are generally designated by the same reference numerals, and repeated description thereof will be omitted.

[0010] <1. Overview> The temple affairs ledger system 1 (hereinafter simply referred to as system 1) according to this embodiment manages information on customers involved in funerals. Funeral-related parties refer to organizations that operate businesses related to memorial services for the deceased, such as temples, ossuaries, funeral homes, stonemasons, and Buddhist altar and altar equipment stores. In the following explanation, a temple that manages graves and ossuaries and provides them to customers will be used as an example of a funeral-related party.

[0011] In this embodiment, customers include parishioners and potential customers. "Parishioner" is a collective term for both temple parishioners and believers. In this embodiment, temple parishioners refer to a family (clan) that belongs to a temple. In other words, a temple parishioner refers to, for example, a family that has a grave at the temple. A temple parishioner may also be an individual. A believer refers to a person who does not have a grave at the temple but requests the temple to perform personal memorial services. A believer also includes, for example, a person who requests the temple to inter the ashes of a relative in an ossuary. A believer may be an individual or a family. In other words, a temple parishioner refers to a person who has already entered into a contract with a temple regarding memorial services for a deceased person.

[0012] On the other hand, potential customers are those who have not yet signed a contract with a temple regarding memorial services, but who have the potential to become parishioners in the future. Potential customers include, for example, those who make new inquiries to a temple regarding memorial services for the deceased, specifically, those who make new inquiries regarding funerals, memorial services, graves, and ossuaries.

[0013] System 1 manages customer information and presents the information to temple staff, who are users of System 1. This facilitates smooth communication between customers and temples, deepening interactions between parishioners and temples. It also makes it possible to maintain good relationships between customers and temples.

[0014] <2. Overall structure> Fig. 1 is a diagram showing the overall configuration of a system 1 of this embodiment. As shown in Fig. 1, the system 1 includes a terminal device 10 used by temple staff, who are users, and a server 20. The terminal device 10 and the server 20 are connected to each other via a network 80 so that they can communicate with each other using a wired or wireless communication standard. In the illustrated example, multiple terminal devices 10 are included in the system 1. The number of terminal devices 10 can be changed as desired to match the number of users. Users are temple staff, including the head priest, monks, and other people engaged in temple work, regardless of their position or employment status within the temple.

[0015] The terminal device 10 is a terminal used by a user. Each user is identified by account information 171 (see FIG. 2). An account is set for each temple staff member, for example. For example, the account may identify the position at the temple, and the information that can be accessed by each account in the system 1 may be differentiated.

[0016] The terminal device 10 is realized by, for example, a desktop personal computer (PC) or a laptop PC. The terminal device 10 may also be a portable computer such as a smartphone, a tablet terminal, or a head-mounted display.

[0017] As shown in FIG. 1, the terminal device 10 includes a communication IF (Interface) 12, an input device 13, an output device 14, a memory 15, a storage unit 16, and a processor 19.

[0018] The communication IF 12 is an interface for transmitting and receiving signals so that the terminal device 10 can communicate with an external device. The input device 13 is an input device for receiving input operations from users (parishioners), and includes, for example, a touch panel, a touch pad, a pointing device such as a mouse, a keyboard, and the like.

[0019] The output device 14 is an output device for presenting information to a user, and includes, for example, a display, a speaker, and the like. The memory 15 is for temporarily storing programs and data to be processed by the programs, and is realized by a volatile memory such as a DRAM (Dynamic Random Access Memory).

[0020] The storage unit 16 is a storage device for saving data, and is realized by, for example, a flash memory or an HDD (Hard Disc Drive). The processor 19 is hardware for executing an instruction set written in a program, and is composed of an arithmetic unit, a register, a peripheral circuit, and the like.

[0021] The server 20 is a device that manages information about customers and temples. The server 20 is a computer connected to a network 80.

[0022] As shown in FIG. 1, the server 20 includes a communication IF 22, an input / output IF 23, a memory 25, a storage 26, and a processor 29.

[0023] The communication IF 22 is an interface for transmitting and receiving signals so that the server 20 can communicate with external devices. The input / output IF 23 functions as an interface with an input device for receiving input operations from the user and an output device for presenting information to the user.

[0024] The memory 25 is for temporarily storing programs and data to be processed by the programs, and is realized by a volatile memory such as a DRAM. The storage 26 is a storage device for saving data, and is realized by, for example, a flash memory or a HDD. The processor 29 is hardware for executing an instruction set written in a program, and is composed of an arithmetic unit, registers, peripheral circuits, and the like.

[0025] <3. Configuration of terminal device> 2 is a block diagram showing the configuration of a terminal device 10 included in the system 1 of this embodiment. As shown in FIG. 2, the terminal device 10 includes a communication unit 121, an input / output unit 130 (including a keyboard 131 and a display 132), an audio processing unit 140, a microphone 141, a speaker 142, a camera 160, a storage unit 170, and a control unit 180. The terminal device 10 also includes functions and configurations (e.g., a battery for storing power, a power supply circuit for controlling the supply of power from the battery to each circuit, etc.) that are not shown in FIG. 2. The blocks included in the terminal device 10 are electrically connected by, for example, a bus or the like.

[0026] The communication unit 121 performs processing for the terminal device 10 to communicate with other devices. The communication unit 121 performs transmission processing on a signal generated by the control unit 180 and transmits the signal to the outside (for example, the server 20). The communication unit 121 performs reception processing on a signal received from the outside and outputs the signal to the control unit 180.

[0027] The input / output unit 130 has a mechanism for accepting input operations from the user who owns the terminal device 10 and displaying output contents. Specifically, the input / output unit 130 includes a keyboard 131 and a display 132. The input / output unit 130 may also include other input devices such as a mouse.

[0028] The keyboard 131 outputs typed text data to the control unit 180 as an input operation from the user. Display 132 displays data such as images, videos, and text under the control of control unit 180. Display 132 is realized by, for example, an LCD (Liquid Crystal Display) or an organic EL (Electro-Luminescence) display.

[0029] The audio processing unit 140 modulates and demodulates audio signals and is realized by, for example, a processor for audio processing. The audio processing unit 140 modulates the audio signal provided by the microphone 141 and outputs the modulated signal to the control unit 180. The audio processing unit 140 also demodulates the audio signal provided by the control unit 180 and provides the demodulated signal to the speaker 142.

[0030] The microphone 141 receives a voice input and outputs a voice signal corresponding to the voice input to the voice processing unit 140. The speaker 142 converts the voice signal provided from the voice processing unit 140 into a voice and outputs the voice to the outside of the terminal device 10.

[0031] Camera 160 is a device that receives light with an imaging element and outputs the light as an image signal. Camera 160 is disposed, for example, in terminal device 10. Camera 160 captures an image of a subject in response to a user operation and outputs an image signal.

[0032] The storage unit 170 is configured with, for example, a flash memory, and stores data and programs used by the terminal device 10. For example, the storage unit 170 stores account information 171.

[0033] The account information 171 is information relating to the account of the temple staff member who operates the terminal device 10. The account information 171 includes, for example, the user name, login ID, login password, business operator identification information (temple ID), terminal device 10 identification information (terminal ID), and attributes of the funeral-related personnel. The attributes of the funeral-related personnel include, for example, temple, ossuary, funeral home, stonemason, Buddhist altar / accessory store, etc.

[0034] The control unit 180 is realized by the processor 19 reading a program stored in the storage unit 170 and executing instructions included in the program. The control unit 180 controls the operation of the terminal device 10. Specifically, for example, the control unit 180 fulfills the functions of an operation reception unit 181, a transmission / reception unit 182, an acquisition unit 183, and a presentation unit 184.

[0035] The operation accepting unit 181 performs processing for accepting user operations input from the input device 13. For example, the operation accepting unit 181 accepts operations based on text data input to the keyboard 131.

[0036] The transmitting / receiving unit 182 performs processing for the terminal device 10 to transmit and receive data to and from an external device such as the server 20 in accordance with a communication protocol.

[0037] The acquisition unit 183 acquires information input by the user of the terminal device 10. Examples of the acquired information include information input by the user from the keyboard 131 of the terminal device 10, and information based on an image signal captured by the user with the camera 160. The information acquired by the acquisition unit 183 is transmitted to the server 20 via the transmission / reception unit 182. The presentation unit 184 presents various information to the user.

[0038] <4. Functional configuration of the server> 3 is a block diagram showing the functional configuration of the server 20 included in the system 1 of this embodiment. As shown in FIG. 3, the server 20 functions as a communication unit 201, a storage unit 202, and a control unit 203.

[0039] The communication unit 201 performs processing for the server 20 to communicate with external devices.

[0040] The storage unit 202 stores data and programs used by the server 20. For example, the storage unit 202 stores the following databases: Database of parishioner's unique information (primary information) Database of contractual information (secondary information) about parishioners or potential customers Database of information on memorial services exchanged between parishioners and funeral officials (third information) -Database of information on events hosted by temples (Fourth information)

[0041] The first information is unique information registered about parishioners and potential customers, specifically various personal information about parishioners and potential customers. The first information includes, for example, various types of information stored in a customer database (DB) 281, a user database (DB) 282, and a grave and stage database (DB) 283. The first information may also include image information. Details of each of these databases will be described later.

[0042] The second information is information about contracts for parishioners and potential customers, specifically, an agreement between a parishioner and a temple, which is information about the memorial service services provided by the temple and the fees for those services. It is also information about memorial service services provided by the temple in which a potential customer is interested. The second information is managed, for example, by case. In this embodiment, a case refers to, for example, the management items when managing a contract for a parishioner. It also refers to, for example, the management items when managing inquiries about a contract for a potential customer. The second information includes, for example, various types of information stored in the case database (DB) 284 and the contract status database (DB) 285. Image information may also be included in the second information. Details of each of these databases will be described later.

[0043] The third information is information about memorial services exchanged between parishioners and funeral-related parties, specifically, information about details of events related to memorial services for relatives held at the initiative of parishioners. The third information also includes information about contact details exchanged regarding memorial services and their history. The third information includes, for example, various types of information stored in a history database (DB) 286 and a memorial service database (DB) 287. The third information includes contact information from parishioners to funeral-related personnel. The third information may also include image information. Details of each of these databases will be described later.

[0044] The fourth information is information about events hosted by the temple, in which parishioners and potential customers can voluntarily participate, and is information about details of events held for the purpose of offering prayers for relatives and encouraging faith among parishioners and potential customers. The fourth information includes, for example, various types of information stored in the event database (DB) 288. Details of each of these databases will be described later.

[0045] The control unit 203 is realized by the processor 29 reading a program stored in the storage unit 202 and executing instructions included in the program. The control unit 203 controls the operation of the server 20. Specifically, for example, the control unit 203 fulfills the functions of a transmission / reception unit 2031, an acquisition unit 2032, a search unit 2033, a screen creation unit 2034, an output unit 2035, and a proposal unit 2036.

[0046] The transmitting / receiving unit 2031 controls the process in which the server 20 transmits and receives data to and from external devices such as the terminal device 10 in accordance with a communication protocol.

[0047] The acquisition unit 2032 acquires various pieces of information received by the transmission / reception unit 2031 and stores them in the storage unit 202. The acquisition unit 2032 stores the acquired information as a new record in each database stored in the storage unit 202, depending on the content of the acquired information.

[0048] The search unit 2033 searches the first information to the fourth information for information that matches the search query entered in a search field on the output screen, which will be described later. When the search unit 2033 finds information that matches the search query, it outputs the information.

[0049] The screen creation unit 2034 creates an output screen based on the information recorded in the storage unit 202. The screen creation unit 2034 acquires information necessary to create the output screen from various databases and creates the output screen. The output screen of the system 1 includes a portal page and multiple content pages. The portal page is the first screen displayed when the system 1 is accessed, and functions as a portal (entrance) that displays a list of information managed by the system 1 as cases. The portal page is a page that allows users to grasp an overview of various types of information stored in the system 1. The portal page is a page that allows users to smoothly and comprehensively grasp the latest updated information. The content page is a screen that displays details of the first to fourth information. The content page displays detailed information about the content set for each page. The content page can be accessed from the portal page. Depending on the content, the content page may also display past history.

[0050] In this embodiment, the content pages include various pages such as "Cases," "Parishioners," "Pastoral Register," "Memorial Service," "Plot," "Altar," "Contract," "Enshrinement," "Events," "Letters," "Membership Fees," "Count," and "Settings." The contents of each content page are as follows: · Project page: A page that displays details of projects managed for each contract with a customer. ·Parishioner page: A page that displays detailed information about parishioners (and customers) · Past record page: A page that displays information about past records containing information about parishioners Memorial service page: A page that displays detailed information about a memorial service scheduled for a customer. Plot page: A page that displays detailed information about the location of the grave and its user. Altar page: A page that displays detailed information about the location of the ossuary and its users. Contract page: A page that displays detailed information about a customer's contract. · Joint Enshrinement Page: A page that displays detailed information about the joint enshrinement Events page: A page that displays detailed information about events hosted by the temple. Letter page: A page that displays detailed information about messages sent from the temple to customers. · Membership fee page: A page that displays detailed information about charges based on the customer's contract. · Aggregation page: A page that displays information on the number of contracts chronologically. Settings page: This page is used to set up System 1 functions. The specific display contents of a representative page among these pages will be described later.

[0051] The suggestion unit 2036 makes various suggestions based on the information that has already been input. The suggestion unit 2036 outputs information regarding joint interment based on the date of death of the deceased included in the customer's unique information, which is the first information. Joint interment refers to the procedure of removing the bones from the urn and burying them together in a communal grave after a preset period (e.g., seven years) has elapsed in the ossuary, for example. The suggestion unit 2036 suggests that the time for joint interment is approaching before the preset period starting from the date of death of the deceased expires, so that the temple can easily inquire from the customer about whether or not to perform joint interment.

[0052] Furthermore, the suggestion unit 2036 outputs information regarding birthday wishes to the customer based on the information on the parishioner's date of birth stored as the first information. Specifically, it outputs a birthday card for the customer. The temple staff sends the output birthday card to the customer and asks about the customer's recent situation. This can encourage interaction between the temple and the customer.

[0053] <5. Data Structure> 4 to 7 are diagrams showing the data structures of the databases stored in the storage unit 202 of the server 20. Note that Figs. 4 to 7 are merely examples and do not exclude data not shown. Fig. 4 shows the data structure of a database that stores the first information. Fig. 4A shows an example of the data structure of a customer DB 281. Fig. 4B shows an example of the data structure of a user DB 282. Fig. 4C shows an example of the data structure of a grave / altar DB 283.

[0054] <5-1. Customer database> 4A is a database that stores information about customers of the temple. That is, the customer DB 281 stores unique information about parishioners and potential customers. Each record in customer DB281 includes the following items: "Customer ID," "Case ID," "Name," "Gender," "Age," "Date of Birth," "Address," "Relationship," "Counter ID," "Email Address," "Daytime Contact," "Last Contact," "District," "Caretaker," "Registration Date," etc.

[0055] The item "customer ID" stores an ID for identifying a customer.

[0056] The item "Project ID" stores the ID of the project of the customer corresponding to the customer ID. For example, if six customers belonging to the "Tanaka family" are registered as one parishioner and ask the temple to perform memorial services for four deceased members, the "Tanaka family" will be managed as one case. On the other hand, if an individual requests memorial services for their parents as a customer of the ossuary, that individual will be managed as a single case.

[0057] The item "Name" stores the name of the customer corresponding to the customer ID.

[0058] The item "gender" stores the gender of the customer corresponding to the customer ID.

[0059] The item "age" stores the age of the customer corresponding to the customer ID.

[0060] The item "Date of Birth" stores the date of birth of the customer corresponding to the customer ID.

[0061] The item "Address" stores information about the address of the customer corresponding to the customer ID.

[0062] The "Relationship" field stores the relationship to the customer corresponding to the customer ID. For example, in the case of a temple parish, the relationship is stored as a relationship based on the head of the temple, such as "head of the family," "head's wife," or "head's eldest son." On the other hand, in the case of a believer, the relationship is stored as a relationship based on the contract holder, such as "(contract holder) himself" or "his wife."

[0063] The "Customer ID" field stores the customer ID that identifies the person (customer) who represents the parishioner and communicates with the temple. In the case of a believer, the customer ID of the person in question is stored in the Customer ID field.

[0064] The "email address" field stores the email address used to send an email to the customer corresponding to the customer ID. The "email address" field may store the email address of the customer corresponding to the contact ID.

[0065] The item "Daytime Contact" stores the phone number to call from the temple to the customer corresponding to the customer ID. The item "Daytime Contact" may also store the phone number of the customer corresponding to the counter ID.

[0066] The "Last Contact" field stores the contact information of a relative of the client who the temple will contact if, for some reason, the client or the front desk cannot be contacted, mainly for parishioners of the ossuary. For example, in the case of the ossuary, requests often come in on an individual basis, and if the client suddenly passes away due to unforeseen circumstances, they may not be able to be contacted. In preparation for such cases, the last contact information is set. If the customer is a parishioner, it is basically sufficient to contact the members of the household, so there is no need to set a final contact point, but it may be set if necessary.

[0067] The item "district" stores the district where the customer corresponding to the customer ID lives.

[0068] The "caretaker" field contains the name of the caretaker who acts as an intermediary between the temple and the parishioners. A caretaker does not need to be set for parishioners of a charnel house.

[0069] The item "Registration Date" stores the date when the information of the customer corresponding to the customer ID was first registered. The customer DB 281 may also store information about the customer's occupation and lifestyle, information about the introducer who introduced the customer to the temple, image data of the customer's face, and other attributes.

[0070] <5-2. User Database> The user database shown in Figure 4B is a database that stores information about users of graves or altars. A user primarily refers to a deceased person, and use of a grave or altar refers to memorial services being held at that grave or altar. In addition, since a customer may enter into a contract for their own memorial services in order to prepare a grave or altar before they die, users also include living people who are expected to use the grave or altar in the future.

[0071] Each record in customer DB281 includes the following items: "User ID", "Case ID", "Name", "Gender", "Relationship", "Age at death", "Birth and death", "Date of death", "Posthumous name", "Records during death", etc.

[0072] The item "user ID" stores an ID for identifying a user.

[0073] The item "Case ID" stores the ID of the case that manages the memorial service for the user corresponding to the user ID.

[0074] The item "Name" stores the name of the user corresponding to the user ID.

[0075] The item "gender" stores the gender of the user corresponding to the user ID.

[0076] The item "Relationship" stores the relationship of the user corresponding to the user ID. Specifically, in the case of a parishioner, the relationship is stored based on the head of the parishioner managed by the corresponding case ID. In the case of a believer, the relationship to the contractor is stored.

[0077] The "Age at Death" field stores the age or age at death according to the Japanese age system of the user corresponding to the user ID. If the user is still alive, the "Age at Death" field is left blank.

[0078] The "alive / death" item stores information indicating whether the user corresponding to the user ID is currently alive or deceased. If the user is deceased, the "alive / death" item is set to "deceased," and if the user is living, the "alive / death" item is set to "living."

[0079] The "Date of Death" field stores the date on which the user corresponding to the user ID passed away. If the user is still alive, the "Date of Death" field is left blank.

[0080] The "Posthumous Buddhist name" field stores the posthumous Buddhist name of the user corresponding to the user ID. If the user is still alive, the "Posthumous Buddhist name" field is left blank.

[0081] The item "Pre-death Record" stores the pre-death record of the user corresponding to the user ID. Examples of information set as pre-death records include the following: Information about the user's occupation, place of residence, and other details of the user's life Personal information about the user, such as their personality, special skills, hobbies, etc. - Information related to the user's origins, family structure, and other family ties -Other information that indicates the characteristics of the user and is useful for relatives to remember the user. The user DB 282 may also store information about other attributes, such as image data of the user's funeral portrait.

[0082] <5-3. Tomb and Altar Database> The grave / altar DB 283 shown in Fig. 4C is a database that stores information about graves or altars. An altar refers to a section in a charnel house where bones are interred. Each record in the grave / altar DB 283 includes an item "grave / altar ID," an item "case ID," an item "user ID," an item "plot information," and the like.

[0083] The item "Tomb / Altar ID" stores an ID for identifying the grave or altar.

[0084] The item "Case ID" stores the case ID of the case that manages the grave or altar corresponding to the grave / altar ID.

[0085] The item "User ID" stores the user ID of the user who uses the grave or altar corresponding to the grave / altar ID.

[0086] The "plot information" item stores information indicating the location (plot) of the grave or altar corresponding to the grave / altar ID. For graves, the "plot information" item corresponds to plot information (location information) in the cemetery, and for altars, it corresponds to plot information in the ossuary. The grave / altar DB 283 may store information about other attributes such as the grade of the grave or altar, the period until enshrinement, etc. The grave / altar DB 283 may also store image data of photographs of the grave or altar.

[0087] 5A and 5B are diagrams showing data structures of databases that store second information. Fig. 5A is a diagram showing an example of the data structure of the case DB 284. Fig. 5B is a diagram showing an example of the data structure of the contract status DB 285.

[0088] <5-4. Project Database> The case DB 284 shown in FIG. 5A is a database that stores various information handled in case management. Each record of the case DB 284 includes an item "case ID", an item "case name", an item "customer ID", an item "inquiry category", an item "registration date", and the like.

[0089] The item "case ID" stores an ID for identifying a case.

[0090] The item "Project Name" stores information about the name of the project corresponding to the project ID. The project name may be automatically entered from the customer's name or other unique information.

[0091] The item "Customer ID" stores the customer ID of the customer who made a contract or inquiry with the temple regarding the case corresponding to the case ID.

[0092] The "Inquiry Category" field stores the type of inquiry made to the temple regarding the case corresponding to the case ID. Inquiry categories include, for example, "Memorial service, funeral," "Grave," and "Funeral." The inquiry category is a service that the temple provides to customers, and can be changed as desired to match the content of the matter the customer is inquiring about.

[0093] The item "registration date" stores the date and time when the case corresponding to the case ID was registered. The case DB 284 may also store information about other attributes related to cases.

[0094] <5-5. Contract Status Database> The contract status DB 285 shown in FIG. 5B is a database that stores information about the contract between the temple and the customer. Each record of the contract status DB 285 includes an item "contract ID", an item "project ID", an item "contractor ID", an item "contract status", an item "contract classification", and the like.

[0095] The item "contract ID" stores an ID for identifying a contract.

[0096] The item "Project ID" stores the project ID of the project related to the contract corresponding to the contract ID.

[0097] The item "Contractor ID" stores the customer ID of the customer who made the contract corresponding to the contract ID.

[0098] The "Contract Status" item stores the status of the contract corresponding to the contract ID. Contract statuses include "Concluded," "In Progress," and "Suspended." A contract in "In Progress" refers to the stage where the temple is preparing an estimate, where the client is not yet ready to arrange a site visit, or where the client is still considering the matter. A contract in "Suspended" refers to the stage where the client has requested to withdraw from the contract.

[0099] The item "contract category" stores the details of the contract corresponding to the contract ID. The contract category indicates the specific type of service related to memorial services that the temple provides to its customers, and specifically corresponds to the inquiry category in the case DB 284 shown in Figure 5A. In other words, the contract category includes, for example, "memorial service," "funeral," "grave," and "ossuary." If the contract category is "memorial service," it means that a contract is concluded between the temple and the customer regarding the holding of various memorial services, such as annual memorial services. If the contract category is "funeral," it means that a contract regarding the execution of a funeral has been concluded between the temple and the customer. If the contract category is "grave," it means that a contract regarding the management of the grave has been concluded between the temple and the customer. If the contract category is "columbarium," it means that a contract regarding the management of the columbarium has been concluded between the temple and the customer. The contract status DB 285 may also store information on other attributes related to the contract.

[0100] 6A and 6B are diagrams showing the data structures of databases that store the third information. Fig. 6A is a diagram showing an example of the data structure of the history DB 286. Fig. 6B is a diagram showing an example of the data structure of the memorial DB 287.

[0101] <5-6. History Database> The history DB 286 shown in FIG. 6A is a database that stores information on various transactions that have taken place between the temple and customers. Each record of the history DB 286 includes an item "history ID", an item "matter ID", an item "enter", an item "content", an item "input date and time", and the like.

[0102] The item "history ID" stores an ID for identifying the history.

[0103] The item "case ID" stores the case ID of the case to which the information on the exchange corresponding to the history ID relates.

[0104] The item "inputter" is entered with the name of the user who inputs the information on the exchange corresponding to the history ID. Specifically, the name of the temple staff member who operates the terminal device 10 and inputs the information on the exchange is entered. The user's name is identified from the account information 171 used.

[0105] The "Content" field contains the content of the exchange information corresponding to the history ID. The content of the exchange information is diverse and includes, for example, telephone exchanges, verbal exchanges, messages from customers to the priest, reservations for various events, and detailed information about memorial services.

[0106] The item "input date and time" stores the date and time when the information of the exchange corresponding to the history ID was input. The history DB 286 may also store information about other attributes related to the exchange information.

[0107] <5-7. Memorial Service Database> The memorial service database 287 shown in Figure 6B stores information about memorial services held based on requests from customers. Memorial services held based on requests from customers include the seventh day memorial service, the 49th day memorial service, the annual memorial service, and the auspicious death anniversary memorial service. The dates of these memorial services are set based on the date of death of the deceased.

[0108] Each record in the memorial DB287 includes the following items: "Memorial ID," "Name ID," "Case ID," "Applicant ID," "Recipient ID," "Schedule," "Location," "Stupa List," "Offerings," "Meals," "Attendance Information," "Registration Date," etc.

[0109] The item "Memorial service ID" stores an ID that identifies the memorial service.

[0110] The item "Name ID" stores the name of the memorial service corresponding to the memorial service ID.

[0111] The item "Case ID" stores the case ID of the case to which the memorial service corresponding to the memorial service ID is related.

[0112] The item "Applicant ID" stores the customer ID of the customer who applied for the memorial service corresponding to the memorial service ID.

[0113] The item "Memorial recipient ID" stores the user ID of the user (deceased person) who will be memorialized by the memorial service corresponding to the memorial service ID.

[0114] The item "Date" stores the date of the memorial service corresponding to the memorial service ID.

[0115] The item "Location" stores the location where the memorial service corresponding to the memorial service ID is held.

[0116] The item "stupa name list" stores information on the list of names of stupas offered at the memorial service corresponding to the memorial service ID.

[0117] The item "Offerings" stores information about the offerings at the memorial service corresponding to the memorial service ID.

[0118] The item "meals" stores information about the contents and quantity of meals provided to participants at the memorial service corresponding to the memorial service ID.

[0119] The item "Attendance Information" stores information about people who plan to attend the memorial service corresponding to the memorial service ID, as well as information about people who actually attended.

[0120] The item "Registration Date" stores the date when various information related to the memorial service corresponding to the memorial service ID was first registered. The memorial DB 287 may also store information about other attributes related to memorial services.

[0121] <5-8. Event Database> FIG. 7 is a diagram showing an example of the data structure of the event DB 288 as a database for storing the fourth information. The event DB 288 shown in Fig. 7 is a database that stores information about memorial services or other Buddhist ceremonies hosted by temples. Memorial services hosted by temples include equinox memorial services, Segaki memorial services, and Obon memorial services. These memorial services are held mainly at seasonal intervals. Other Buddhist events hosted by the temple include zazen sessions, sutra copying sessions, and koan sessions.

[0122] Each record in the event DB288 includes the following items: "Event ID", "Name ID", "Participant ID", "Recipient ID", "Schedule", "Stupa List", "Offerings", "Meals", "Attendance Information", "Registration Date", etc.

[0123] The item "event ID" stores an ID for identifying an event.

[0124] The item "Name ID" stores the name of the event corresponding to the event ID.

[0125] The item "Participant ID" stores the customer ID of the customer who has applied to participate in the event corresponding to the participant ID. The item "Participant ID" may store multiple customer IDs.

[0126] The "Recipient ID" field stores the user ID of the deceased person who will be memorialized through the event corresponding to the event ID. If the event does not involve a memorial service, such as a Zen meditation session or sutra copying session, the "Recipient ID" field will be left blank.

[0127] The item "Schedule" stores the schedule of the event corresponding to the event ID.

[0128] The "Stupa List" item stores information about the list of stupas offered at the event corresponding to the event ID. If the event does not involve a memorial service, such as a Zen meditation session or sutra copying session, the "Stupa List" item will be left blank.

[0129] The "Offerings" field stores information about offerings for the event that corresponds to the event ID. If the event is a Zen meditation session or a sutra copying session, where no memorial service is performed, the "Offerings" field is left blank.

[0130] The "Meals" item stores information about the type and quantity of food provided to participants at the memorial service corresponding to the event ID. If the event is one in which no food is provided, such as a Zen meditation session or sutra copying session, the "Meals" item will be left blank.

[0131] The item "attendance information" stores information about people who plan to attend the event corresponding to the event ID, as well as information about people who actually attended.

[0132] The item "Registration Date" stores the date when information about the memorial service corresponding to the event ID was first registered. The event DB 288 may also store information relating to other attributes related to events.

[0133] <6. System processing flow> The processing performed by the system 1 will be described below with reference to FIG. FIG. 8 is a diagram illustrating an example of the operation of the system 1.

[0134] 8, in the system 1, the temple staff operates the terminal device 10 to input various pieces of information (step S101). The temple staff inputs information in the following manner, for example. When a new inquiry is made to the temple, the temple staff member who receives the inquiry will enter the name of the potential customer who made the inquiry, the person who introduced them, and other unique information (primary information). When a potential customer contacts the temple to request a tour, the temple staff member who receives the contact will enter information about the potential customer, such as the tour date and the details of the consultation. When a contract for memorial services is concluded between a temple and a potential customer, the temple staff member in charge of the contract procedures enters information related to the contract (second information) and converts the potential customer into a parishioner. When a contract regarding memorial services between a temple and a parishioner is renewed or when part of the contract content is changed, the temple staff member in charge of the contract procedures will update the contract-related information (secondary information) about the parishioner. When an application for memorial services such as an annual memorial service is received from a parishioner, the temple staff who received the application will enter information about the memorial service (third information) for the parishioner. When a parishioner calls the temple to inquire about memorial services for the head priest, the temple staff member who answers the phone will enter a message (third information) about the parishioner. When a temple receives an application from a customer to participate in an event hosted by the temple, the temple staff member who receives the application enters information about the customer's participation in the event (fourth information). The terminal device 10 transmits the various pieces of input information to the server 20. In addition, when various applications, contract procedures, and telephone inquiries are received via an automatic response, various information may be automatically entered into system 1 by establishing API integration between the application that received the automatic response and system 1.

[0135] After step S101, the server 20 acquires the transmitted data (step S201). Specifically, the acquisition unit 2032 of the server acquires various data received by the transmission / reception unit 2031 of the server 20.

[0136] After step S201, the server 20 updates the database based on the acquired information (step S202). Specifically, the acquisition unit 2032 records the acquired data as a new record in the corresponding database among the databases stored in the storage unit 202.

[0137] After step S202, the server 20 notifies the terminal device 10 that the information has been updated. Specifically, the transmitting / receiving unit 2031 of the server 20 notifies the terminal device 10 held by the temple staff member by email that the information has been updated (step S203). The server 20 may notify the terminal device 10 held by the temple staff member that the information has been updated by using a message function, chat function, or the like of a predetermined application.

[0138] The server 20 generates a portal page in which the display mode of the field L (see FIG. 9) representing the case related to the updated information has been changed (step S204). For example, the server 20 displays the field L representing the case related to the updated information on the portal page in a manner that is likely to catch the user's eye. Specifically, the server 20 displays the field L representing the case at the edge of the portal page, which is displayed first when the portal page is displayed. More specifically, the server 20 displays the field L representing the case at the top of the portal page. A portion of the updated information may be displayed in the field L representing the case. The server 20 checks the date and time when the information was updated for each item, and arranges the fields in order of update, starting with the most recently updated item.

[0139] For example, in the example portal page screen shown in Fig. 9, when information is updated for the matter indicated in field L4 displayed in the center of the portal page, the server 20 generates the portal page shown in Fig. 10. In Fig. 10, the matter indicated in field L4 is displayed at the top of the portal page.

[0140] The temple staff accesses the system 1 based on the notification received by the terminal device 10, and causes the updated portal page to be displayed on the terminal device 10 (step S102). By checking the display of the portal page shown in Fig. 10, the temple staff confirms that the information for the case indicated by field L4 has been updated.

[0141] <7. Screen Examples> Next, an example of a screen of the system 1 will be described. FIG. 10 is a diagram showing an example of the first screen. The example of the first screen shown in FIG. 10 is the portal page of the system 1. The output screen of the system 1 has an index label A for each page at the top. The index label A has labels for each page, such as "Case," "Parishioners," "Pastoral Register," "Memorial Service," "Plot," "Altar," "Contract," "Combined Enshrinement," "Events," "Letters," "Membership Fees," "Count," and "Settings." Clicking on each label will display the corresponding content page.

[0142] A search field S is displayed below label A on the portal page. In the search field, you can enter search keywords and set search conditions to search for relevant cases.

[0143] The portal page displays a list of fields L, which are areas where information about each case is aggregated. Field L displays the following display items: case name B, icon C indicating the contract category, message column D, memorial service column E, and history column F.

[0144] By clicking on the project name B on the portal page, the project page among the content pages can be accessed. The project page contains the customer's unique information (first information). That is, on the portal page, the project names, which are the second information, are arranged in a list format so that the details of the first information can be accessed. Details of the project page will be described later.

[0145] On the portal page, the contract category icon C indicates the contract category of the customer corresponding to the field. For example, the icons in fields L1 to L3 indicate that the contract category is "Ossuary," and the icon in field L4 indicates that the contract category is "Grave."

[0146] On the portal page, messages received from parishioners and sent to other temple staff are displayed in message column D. By clicking on this display, you can access the message details on the case page.

[0147] On the portal page, the memorial service column E displays information about memorial services that are already scheduled for the customer corresponding to the field at the time of viewing. Note that the memorial service column E may selectively display information about memorial services that are scheduled within a predetermined period (e.g., six months from the time of viewing). By clicking on the display in the memorial service column E, the project page can be accessed. On the project page, detailed information about the annual memorial service requested by the customer can be confirmed. In other words, information about memorial services can be accessed from the portal page. Note that the specifications may also allow access to the memorial service page by clicking on the memorial service column E.

[0148] On the portal page, the history of the message is displayed in the history column F. By clicking on this display, you can access the details of the message history on the case page.

[0149] On the portal page, in response to an update of at least one of the first information and the third information, a field L containing the second information about the parishioner whose information has been updated is displayed at the end of the portal page. Specifically, based on new input of a customer's unique information (first information), a field L relating to the corresponding case is displayed at the top of the field display area on the portal page. Also, based on new input of information (third information) from a customer regarding an application for memorial service, a field L relating to the corresponding case is displayed at the top of the portal page. In other words, the field L relating to the case for which information was most recently entered is always displayed at the top, and those that have not been updated are displayed in order, one below the other.

[0150] The field L displayed on the portal page includes projects related to parishioners who have already signed contracts and projects related to prospective customers who have not yet signed contracts. In this way, on the portal page, the field L related to prospective customers and the field L related to parishioners are displayed in a list, arranged vertically in the order in which the information was updated. On the portal page, the field L related to the potential customer and the field L related to the parishioners are displayed in a distinguishable manner. For example, the background colors of the field L related to the potential customer and the field L related to the parishioners are different from each other. Note that the field L related to the potential customer and the field L related to the parishioners may be displayed in a distinguishable manner in other ways, such as by changing the color of the text.

[0151] The portal page can also display the second information in a manner that allows access to the fourth information. For example, if a customer has applied to participate in an event hosted by a temple, an event column containing an overview of the event can be provided in field L, which indicates the project. In this case, by clicking on the event column, the customer can access the project page and can access detailed information regarding attendance at the event. Note that the specification may also be such that the event page can be accessed by clicking on the event column.

[0152] FIG. 11 is a diagram showing an example of a second screen of the system 1. The example of the second screen is a content page (project page) about "project." On this page, detailed information about the project can be confirmed. On the project page, detailed information about the project is listed for each item (M1 to M7) related to the project. Items related to the project include the following: Message (M1) Family name of parishioner (M2) Believer's name (M3) ·Membership fees, management fees (M4) Contract Information (M5) Memorial Service (M6) History information (M7)

[0153] The item "Message (M1)" displays details of messages from customers that are kept by the temple, which are included in the third information. The messages are displayed in chronological order.

[0154] The item "Parishioner's name (M2)" is used when the customer is a parishioner or a prospective customer who wishes to sign a contract as a parishioner, and displays the information about the relatives of the family included in the first information. By clicking on the display of this item, you can access the parishioner page.

[0155] The item "Family Member's Surname (M3)" is used when the customer is a member or a potential customer who wishes to sign a contract as a member, and displays information about the member and their relatives included in the first information. By clicking on the display of this item, you can access the parishioner page.

[0156] The item "Membership fees, management fees (M4)" displays details about the expenses incurred under the contract included in the second information. By clicking on the display of this item, you can access the accounting page.

[0157] The item "Contract Status (M5)" displays details about the contract included in the second information. By clicking the display of this item, you can access the contract page.

[0158] The item "Memorial Service (M6)" displays information about future memorial services that have already been scheduled, which is included in the third information. By clicking on the display of this item, you can access the memorial service page.

[0159] The item "History Information (M7)" displays detailed information about the history of interactions between the customer and the temple, which is included in the third information.

[0160] 12 is a diagram showing an example of a third screen of the system 1. The example of the third screen is a content page (parishioner page) about "parishioners." On the parishioner page, detailed information about parishioners can be confirmed. A search field is provided at the top of the third example screen. In the search field S, you can search for relevant customer information using the customer's name in kana or kanji. Customer information may also include the customer's maiden name, and by entering the maiden name in the search field, you can search for customer information registered under the current surname. In addition, by entering text in the search field, you can perform text mining processing on the text and search for images registered as customer information. Customer information can be accessed from the third example screen, and information about the newly acquired customer can be entered.

[0161] Below the search field on the parishioner page, the list of customers is displayed. The list of customers is displayed for each parishioner or parishioner. By clicking on each name, you can access the corresponding case page.

[0162] FIG. 13 is a diagram showing an example of a fourth screen of the system 1. The example of the fourth screen is a content page (memorial service page) about "memorial services." On the memorial service page, you can check detailed information about memorial services requested by parishioners. By clicking on the name of each memorial service, you can access the corresponding case page. In the fourth example screen, information about memorial services is displayed side by side, including details of past memorial services and details of future plans. Specifically, column G displays an outline of the next memorial service, and column H displays an outline of the previous memorial service. This allows the user to instantly make suggestions based on the previous results when proposing details of the memorial service to a customer, and to make appropriate suggestions for matters that the customer should consider, such as setting the number of participants and deciding on offerings. By displaying each item from the fourth screen example, you can check detailed information about the memorial service and enter new information.

[0163] 14 is a diagram showing a fifth example screen of the system 1. The fifth example screen is a content page (event page) about "events." On the event page, detailed information about events hosted by the temple can be confirmed. The fifth screen example displays the attendance information of attendees for the equinox memorial service. Specifically, column I displays information about the planned attendance, and column J displays the attendance status for the day. Column K in the fifth screen example displays whether or not there has been a request to donate a stupa at this equinox memorial service.

[0164] Based on the operation from the fifth example screen, the output unit 2035 outputs a list of parishioners' attendance at the event. This makes it easy to check the attendance status on the day. The output unit 2035 also outputs a list of posthumous Buddhist names to be inscribed on the stupas dedicated to the event. The list of posthumous Buddhist names includes the pronunciation of the posthumous Buddhist names. This ensures convenience for temple staff when they read out the posthumous Buddhist names at the equinox memorial service.

[0165] <8. Other features> Other functions of system 1 will now be described. The output unit 2035 of system 1 extracts the scheduled dates and times for Tanakyou prayers included in the third information of each parishioner and outputs a temple schedule for Tanakyou prayers. Tanakyou prayers are an event during the Obon period in which the head priest visits the homes of each parishioner and performs a Buddhist memorial service, including sutra chanting, at the parishioner's home. In system 1, the output unit 2035 of server 20 extracts the scheduled dates and times for each parishioner from the information regarding Tanakyou prayer requests recorded as information related to the Buddhist memorial service, and outputs a schedule listing the names and addresses of parishioners the head priest should visit according to the scheduled dates and times. This allows for smooth schedule management for the head priest during the busy Obon period.

[0166] System 1 has the function of supporting the creation of various transaction documents. Transaction documents are documents related to transactions concluded between customers and other businesses affiliated with the temple. Other businesses include funeral homes, stonemasons, Buddhist altar and accessory stores, notaries, etc. Generally, temples receive consultations from customers regarding funerals, purchasing a new grave, inheritance, and pre-death organization. In response to such consultations, temples will introduce other affiliated businesses to help resolve the customer's issues. In response to input from the temple, the output unit 2035 of the system 1 creates transaction documents such as estimates, contracts, and purchase orders, which are exchanged between the customer and other businesses, based on introductions to other related businesses, and outputs them to the terminal device 10. Temple staff check the output transaction documents and present them to the other businesses or customers, thereby supporting communication between the customer and other businesses. This allows the temple to respond quickly to requests and inquiries from customers.

[0167] <9.Summary> As explained above, the system 1 according to this embodiment handles information on all customers, including parishioners who have already signed a contract with the temple and potential customers who have not yet signed a contract with the temple, and displays information on each contract on the portal page. Therefore, it is possible to manage information on potential customers who may become parishioners in the future, not just parishioners who have already signed a contract. In addition, temple staff can deepen interactions between temples and customers by checking each customer's unique information and contract status.

[0168] In addition, in system 1, the second information is arranged in a list on the portal page so that it is accessible to the first and third information, making it easier to view detailed information regarding memorial services that have already been requested of the temple, thereby improving convenience for the temple.

[0169] Furthermore, in response to an update of at least one of the first information and the third information, the portal page displays the second information about the updated customer at the edge of the portal page. In the illustrated example, information about the most recently updated project is displayed at the top. Then, when information about another project is newly updated, the second information about that other project is displayed at the top again.

[0170] In addition, the portal page clearly displays the second information about parishioners and the second information about potential customers, making it easier to see which cases are information about potential customers who may have a chance of signing a contract in the future, making it easier for temples to consider measures to acquire new customers.

[0171] In addition, the third information displayed on the portal page includes messages from parishioners to the temple, so by accessing the third information from the portal page, parishioners can easily check messages from the temple to the temple.

[0172] Furthermore, since the third information displayed on the portal page includes the history of messages, it is possible to ensure a list of past messages.

[0173] In addition, since the first information of the customer is displayed on the portal page together with the second information, by checking the portal page, the customer's unique information can be confirmed and the case can be immediately grasped.

[0174] In addition, the portal page displays the customer's tertiary information along with the secondary information, so by checking the portal page, you can immediately understand the details of the memorial service requested by the customer.

[0175] In addition, the portal page displays each case individually, ensuring a clear overview of the cases that the temple is responsible for.

[0176] Furthermore, the first information, second information, or third information managed by the system 1 includes image information, which allows the system 1 to handle a variety of data, such as image data of a customer's face.

[0177] In addition, the portal page allows access to the fourth information, which is information about events hosted by the temple, making it easy for customers to check the events they have participated in, and by suggesting topics for conversation between the temple and customers, it can deepen the interaction between the two.

[0178] <10. Variations> In the above embodiment, a temple is used as an example of a funeral-related party, but this is not limited to this. Funeral-related parties may also be businesses other than temples, such as ossuaries, funeral parlors, Buddhist altar and accessory stores, and stonemasons. In the above embodiment, the system 1 is used in a Buddhist temple, but the system 1 may also be used in other religions. For example, in Shinto, a temple is a shrine and its parishioners are parishioners. In Christianity, a temple is a church and its parishioners are association members.

[0179] While the preferred embodiments of the present disclosure have been described above, the present disclosure is not limited to such specific embodiments, and includes the inventions set forth in the claims and their equivalents. Furthermore, the device configurations described in the above embodiments and modifications can be combined as appropriate as long as no technical contradiction occurs.

[0180] <Additional Notes> The matters described in the above embodiments will be supplemented below.

[0181] (Appendix 1) A program to be executed by a computer having a processor and a memory, the program causing the processor to: A step of storing first information including unique information of a parishioner or a prospective customer (step S202); storing second information (step S202) including information regarding the contract for the parishioner or prospective customer; and displaying a portal page in which the second information is arranged in a list form so as to be accessible to the first information (step S102).

[0182] (Appendix 2) A program to be executed by a computer having a processor and a memory, the program causing the processor to: A step of storing first information including unique information of the parishioner (step S202); A step of storing second information including information regarding the contract for the parishioner (step S202); A step (step S202) of storing third information including information regarding memorial services exchanged between parishioners and funeral-related parties; and displaying a portal page in which the second information is arranged in a list form so as to be accessible to the first information and the third information (step S102).

[0183] (Appendix 3) In the step of displaying the portal page (step S102), A program as described in Appendix 2, which displays second information about the parishioner whose information has been updated at the end of the portal page in response to an update of at least one of the first information and the third information.

[0184] (Appendix 4) The first information includes unique information of the prospective customer, the second information includes information regarding a contract for the prospective customer; The program according to claim 2 or 3, wherein in the step of displaying a portal page (step S102), the second information about potential customers and the second information about parishioners are displayed in a list format.

[0185] (Appendix 5) The program according to claim 4, wherein in the step of displaying the portal page (step S102), the second information about the potential customer is displayed in a manner that makes it distinguishable from the second information about the parishioners.

[0186] (Appendix 6) The third information is a program described in any one of Appendix 2 to Appendix 5, including information to be communicated by parishioners to those involved in the funeral.

[0187] (Appendix 7) The third information is the program described in Appendix 6, including a history of contact information.

[0188] (Appendix 8) 8. The program according to claim 1, wherein in the step of displaying a portal page (step S102), part of the first information is displayed together with the second information.

[0189] (Appendix 9) 9. The program according to claim 2, wherein in the step of displaying a portal page (step S102), part of the third information is displayed together with the second information.

[0190] (Appendix 10) A program according to any one of appendices 1 to 9, wherein in the step of displaying a portal page (step S102), each contract or inquiry related to a contract is managed as a case, and second information is arranged in a list for each case.

[0191] (Appendix 11) The program according to any one of Supplementary Note 2 to Supplementary Note 10, wherein the first information and the second information include image information.

[0192] (Appendix 12) having the processor perform a step of storing fourth information regarding an event hosted by a funeral official (step S202); 12. The program according to claim 1, wherein in the step of displaying a portal page (step S102), the second information is arranged in a list form so that the fourth information can be accessed.

[0193] (Appendix 13) The processor A program described in any one of Appendix 1 to Appendix 12, which executes a step of extracting the scheduled date and time for the Tanagura contained in the second information of each parishioner and outputting a schedule for those involved in the funeral regarding the Tanagura.

[0194] (Appendix 14) 1. A computer-implemented method comprising a processor and a memory, the method comprising: The method includes: A step of storing first information including unique information of parishioners and potential customers (step S202); Storing second information including information regarding the contract for the parishioner or prospective customer (step S202); and displaying a portal page in which the second information is arranged in a list form so as to be accessible to the first information (step S102).

[0195] (Appendix 15) A system comprising a processor and a memory, The system is A means for storing first information including unique information of parishioners and potential customers; means for storing second information including information regarding a contract for a parishioner or a prospective customer; and means for displaying a portal page in which the second information is arranged in a list form so as to be accessible to the first information.

[0196] (Appendix 16) 1. A computer-implemented method comprising a processor and a memory, the method comprising: The method includes: A step of storing first information including unique information of the parishioner (step S202); a step of storing second information including information regarding the contract for the parishioner (step S202); A step (step S202) of storing third information including information regarding memorial services exchanged between parishioners and funeral-related parties; and displaying a portal page in which the second information is arranged in a list form so as to be accessible to the first information and the third information (step S102).

[0197] (Appendix 17) a system comprising a processor and a memory; The system is means for storing first information including unique information of parishioners; means for storing second information including information regarding the contract for the parishioner; A means for storing third information including information regarding memorial services exchanged between parishioners and funeral-related parties; and means for displaying a portal page in which the second information is arranged in a list form so as to be accessible to the first information and the third information. [Explanation of symbols]

[0198] 1. System 10...Terminal device 13...Input device 14...Output device 15...Memory 16...Storage section 19...Processor 20...Server 201…Communications Department 202...Storage section 203...Control unit 25…Memory 26…Storage 29...Processor

Claims

1. A program to be executed by a computer having a processor and memory, wherein the program is to be executed by the processor, A step of storing second information, which includes information regarding contracts with parishioners or prospective customers, A step of storing third information, including information regarding memorial services exchanged between the aforementioned parishioners and funeral service personnel, The steps include: displaying a portal page in which, in response to an access request from a user, the second information is arranged in a list format to allow access to the third information exchanged between the temple members or prospective customers; Steps to accept updates regarding the aforementioned third piece of information, Make it run, A program that, in the step of displaying the portal page, when the third information is updated, displays the second information about the parishioner or prospective customer with whom the updated interaction took place on the portal page in the order in which it was updated.

2. The program according to claim 1, wherein the third information includes information relating to a memorial service whose timing is set using the date of death of the deceased as the starting date.

3. A method performed by a computer comprising a processor and memory, wherein the processor A step of storing second information, which includes information regarding contracts with parishioners or prospective customers, A step of storing third information, including information regarding memorial services exchanged between the aforementioned parishioners and funeral service personnel, The steps include: displaying a portal page in which, in response to an access request from a user, the second information is arranged in a list format to allow access to the third information exchanged between the temple members or prospective customers; The steps include accepting updates regarding the aforementioned third information, and A method for displaying the portal page, wherein when the third information is updated, the second information concerning the parishioner or prospective customer with whom the updated interaction took place is displayed on the portal page in the order in which it was updated.

4. A system comprising a processor and memory, wherein the system is A means for storing second information, including information regarding contracts with parishioners or prospective customers, A means for storing third information, including information concerning memorial services exchanged between the aforementioned parishioners and funeral service personnel, In response to an access request from a user, means for displaying a portal page in which the second information is arranged in a list format, making it accessible to the third information exchanged between the temple members or prospective customers, The system includes a means for receiving updates regarding the aforementioned third information, The means for displaying the portal page is a system that, when the third information is updated, displays the second information about the parishioner or prospective customer with whom the updated interaction took place on the portal page in the order in which it was updated.

Images