JP2024051127A - Chat-based activity management method and management server - Google Patents

Abstract

[Problem] To provide a mechanism for managing activities for assets owned by an owner using chat. [Solution] A method for managing activities using chat, which stores a list of activities that require confirmation from the owner of a real estate property, accepts a selection of the real estate property, accepts a selection of the activity from the activity list, obtains real estate property information related to the activity of the selected real estate property, generates an activity card inputting the obtained real estate property information, and posts the activity card to a chat where messages are exchanged with the owner. [Selected Figure] Figure 32

Description

The present invention relates to an activity management method and management server using chat.

JP 2017-224207 A (Patent Document 1) is a background technology in this technical field. This publication states that "When setting the rent for a rental property, the structural information and subjective evaluation of the rental property are referenced, so that the self-managed landlord can easily set the rent for himself/herself, aiming for the maximum profit that can be expected, without deviating too far from the market rent for similar properties in the surrounding area. In addition, because the ranking information of the real estate agents and sales representatives who are requested to find customers for the real estate property is managed, the self-managed landlord can select the real estate agent or sales representative of the appropriate rank for each rental property when requesting rental brokerage. Furthermore, because the information of the businesses related to the repair work and cleaning work required for restoration to the original state at the time of vacating is stored by rank, it is possible to easily find a business suitable for each rental property from among multiple businesses" (see abstract).

There is also JP 2017-138932 A (Patent Document 2). This publication states that "the system includes an authentication unit 14 that authenticates a system user, an authority granting unit 15 that grants a first authority when the system user authenticated by the authentication unit 14 is a salesperson, and grants a second authority different from the first authority when the system user authenticated by the authentication unit 14 is a customer, a customer information registration unit 16 that registers customer information, an ownership information registration unit 17 that registers ownership information by associating customer information with property information, an ownership information storage unit 18 that stores the ownership information registered by the ownership information registration unit 17, a page generation unit 19 that generates a management web page for each customer, and a simulation execution unit 20 that executes a simulation based on input information."

JP 2017-224207 A JP 2017-138932 A

The above-mentioned Patent Document 1 describes a system for managing rental income properties. The above-mentioned Patent Document 2 describes a system for executing a profitability simulation of an investment property. However, neither of the above-mentioned Patent Documents discusses a method for communicating with customers.
Therefore, the present invention provides a mechanism for managing activities regarding assets owned by an owner using chat.

In order to solve the above problems, for example, the configurations described in the claims are adopted.
The present application includes multiple means for solving the above-mentioned problems, and one example is an activity management method using chat, which stores a list of activities that require confirmation from a real estate property owner, accepts a selection of the real estate property, accepts a selection of the activity from the activity list, obtains real estate property information related to the activity of the selected real estate property, generates an activity card inputting the obtained real estate property information, and posts the activity card to a chat where messages are exchanged with the owner.

According to the present invention, it is possible to provide a mechanism for managing activities regarding assets owned by an owner using chat.
Problems, configurations and effects other than those described above will become apparent from the following description of the embodiments.

1 is a diagram illustrating an example of a configuration of an entire asset management system 1. 2 is an example of a hardware configuration of a management server 101. 3 is an example of a hardware configuration of the owner terminal 102. 2 is an example of a hardware configuration of the asset management company terminal 103. 5 is an example of user information 500. 6 is an example of topic category information 600. 7 is an example of activity category information 700. 8 is an example of activity master information 800. 9 is an example of activity detail information 900. 1 is an example of message information 1000. 11 is an example of access token information 1100. 12 is an example of asset management information 1200. 13 is an example of a chat screen 1300. 14 is an example of a topic creation screen 1400. 15 is an example of an activity detail input screen 1500. 16 is an example of an activity card preview screen 1600. 17 is an example of an activity card submission screen 1700. 18 is an example of an activity denial screen 1800. 19 is an example of an activity approval screen 1900. 2 shows an example of an activity details screen 2000. 21 is an example of a notification setting screen 2100. 22 is an example of an activity list screen 2200. 23 is an example of an activity details screen 2300. 24 is an example of an activity master screen 2400. 25 is an example of an activity master addition screen 2500. 26 is an example of a chat screen 2600. 27 is an example of an activity details screen 2700. 28 shows an example of an activity approval screen 2800 and a denial screen 2850. 29 is an example of a chat screen 2900 after denial. 3 shows an example of an activity list screen 3000. 13 is an example of an activity filter screen. 32 is an example of an asset management screen 3200. 3 shows an example of an activity card posting process flow 3300. 3 shows an example of an activity card display and response process flow 3400. 3 shows an example of an owner verification response receipt process flow 3500. 36 illustrates an example of a process flow 3600 for displaying a list of activity cards.

Hereinafter, the embodiments will be described with reference to the drawings.
FIG. 1 is a diagram showing an example of the configuration of an entire asset management system 1.
The asset management system 1 comprises a plurality of owner terminals 102 and a plurality of asset management company terminals 103, each of which is connected to a management server 101 via a network. Regardless of whether the network is wired or wireless, each terminal can send and receive information via the network.
The owner terminal 102 is a terminal used by an owner who owns an asset such as an investment property.
The asset management company terminal 103 is a terminal used by the asset management company that manages assets.

Each terminal of the asset management system 1 and the management server 101 may be, for example, a portable terminal (mobile terminal) such as a smartphone, tablet, mobile phone, or personal digital assistant (PDA), or a wearable terminal such as glasses, wristwatch, or clothing. They may also be stationary or portable computers, or servers located on the cloud or network. In terms of functionality, they may be a VR (Virtual Reality) terminal, an AR terminal, or an MR (Mixed Reality) terminal. Or they may be a combination of multiple of these terminals. For example, a combination of one smartphone and one wearable terminal can logically function as one terminal. They may also be other information processing terminals.

Each terminal and management server 101 of the asset management system 1 includes a processor that executes an operating system, applications, programs, etc.; a main storage device such as a RAM (Random Access Memory); an auxiliary storage device such as an IC card, a hard disk drive, an SSD (Solid State Drive), or a flash memory; a communication control unit such as a network card, a wireless communication module, or a mobile communication module; input devices such as a touch panel, keyboard, mouse, voice input, and input based on motion detection captured by a camera unit; and an output device such as a monitor or display. The output device may be a device or terminal that transmits information to be output to an external monitor, display, printer, or device.

The main memory stores various programs, applications, etc. (modules), and the processor executes these programs and applications to realize each functional element of the overall system. Each of these modules may be implemented in hardware, for example by integration. Each module may be an independent program or application, or may be implemented as a subprogram or function within a single integrated program or application.

In this specification, each module is described as an entity (subject) that performs processing, but in reality, the processing is carried out by a processor that processes various programs, applications, etc. (modules).
Various databases (DB) are stored in the auxiliary storage device. A "database" is a functional element (storage unit) that stores a data set so that it can handle any data operation (e.g., extraction, addition, deletion, overwriting, etc.) from a processor or an external computer. The method of implementing the database is not limited, and may be, for example, a database management system, spreadsheet software, or a text file such as XML or JSON.

FIG. 2 shows an example of the hardware configuration of the management server 101 .
The management server 101 is configured, for example, as a server deployed on a cloud.
The main memory device 201 stores programs and applications such as an activity management module 211, a data registration management module 212, and an asset registration management module 213, and each functional element of the management server 101 is realized by the processor 203 executing these programs and applications.

The activity management module 211 provides a chat function between the owner terminal and also manages activities for assets such as real estate owned by the owner. The following describes activity management for real estate properties, but it can be applied to a wide range of asset management, including movable property such as automobiles, jewelry, and jet planes, and financial assets such as stocks, securities, and savings.

Activities are various matters that require confirmation by the owner regarding assets such as managed real estate properties. For example, activities include reports of move-outs, recruitment of new tenants, restoration to the original state, construction, renewal, income and expenditure reports, demand for overdue payments, taxes, repair proposals, sales appraisal proposals, and others, and are matters that require reporting, proposing, or notifying the owner and obtaining confirmation or approval from the owner.
Incidentally, the term "confirmation" is sometimes used to mean both confirmation and approval.

The data registration and management module 212 registers and manages user information, activity-related information, and the like.
The asset registration management module 213 registers and manages information on assets owned by an owner or an asset management company in asset management information 1200. The asset registration management module 213 also cooperates with an owner asset management module 310 of the owner terminal 102 to display the asset information on the owner terminal.

In this embodiment, the activity management module 211 provides the chat function, but the chat function may be provided by a chat management module configured separately. Also, the chat function may be provided by a chat management module of a chat management server configured separately from the management server 101.
The asset registration management may be implemented by an asset registration management module of an asset information management server configured separately from the management server 101 .

The auxiliary storage device 202 includes a main DB 220 .
The main DB 220 stores user information 500, topic category information 600 which is information relating to activities, activity category information 700, activity master information 800, activity detail information 900, message information 1000 which is information relating to chats, access token information 1100 which is information relating to authentication, asset management information 1200 regarding assets to be managed, and the like.

FIG. 3 shows an example of the hardware configuration of the owner terminal 102. As shown in FIG.
The owner terminal 102 is configured as a terminal such as a smartphone, a tablet, a notebook PC, or a desktop PC.
The main memory device 301 stores programs and applications such as an owner asset management module 310, and the processor 303 executes these programs and applications to realize the various functional elements of the owner terminal 102.

The owner asset management module 310 cooperates with the asset registration management module 213 of the management server 101 to display property information, current value, cash flow, etc. of assets such as real estate owned by the owner.
The auxiliary storage device 302 stores owner asset management information 320, which is information about assets owned by the owner.

FIG. 4 shows an example of the hardware configuration of the asset management company terminal 103 .
The asset management company terminal 103 is composed of a terminal such as a smartphone, a tablet, a notebook PC, or a desktop PC.
The main memory device 401 stores programs and applications such as a management company asset management module 410, and the processor 403 executes these programs and applications to realize each functional element of the asset management company terminal 103.

The management company asset management module 410 cooperates with the asset registration management module 213 of the management server 101 to transmit property information, revenue information, and the like of assets such as real estate managed by the asset management company to the management server 101. It also receives confirmation information and the like regarding the owner's activity with respect to real estate properties.
The auxiliary storage device 402 stores management company asset management information 420, which is information about assets managed by the asset management company.

5 to 12 show various types of information stored in the management server. It is assumed that all or part of this information is stored in a JSON format file, but this is not limited to this. It may also be configured to be stored in a relational database or a non-relational database.
FIG. 5 is an example of user information 500 .
The user information 500 stores information about a user whose activity is to be managed by the activity management module 211. For example, information about a real estate owner is stored.

The user information 500 includes a user ID 501 , a user display ID 502 , a job title 503 , a location 504 , and an attribute tag 505 , and values such as those shown as sample values 540 are input for each field name 530 .
The user ID 501 is a unique ID such as an automatically generated hash value, and is a primary key referenced by other information.

The user display ID 502 is a user ID to be displayed on the screen of the management server 101, the owner terminal 102, etc., and is an automatically generated unique ID such as USER-1234.
The position 503 indicates the position or role of the user.
Location 504 indicates the location, language, region, etc. of the user.
The attribute tag 505 indicates a tag to be attached to the attribute of each user. For example, it is possible to tag a person as being from the Tokyo office or a person as being from Shibuya Ward.

FIG. 6 is an example of topic category information 600.
The topic category information 600 stores a list of topics (items) to which conversations exchanged in chat belong.
The topic category name 601 indicates the content of the topic. For example, topics such as move-out report, tenant recruitment, restoration to original state, construction, renewal, income and expenditure report, delinquent payment reminder, tax, repair proposal, and sales appraisal proposal are stored.
The topic category ID 602 is a unique ID given to each topic, and is stored as, for example, a hash value.

FIG. 7 is an example of activity category information 700.
The activity category information 700 stores a list of categories to which each activity used by the activity management module 211 belongs.
The activity category name 701 indicates the type to which the activity card belongs. For example, expense approval, rental condition approval, etc. are stored.
The activity category ID 702 is the ID of the category, a primary key referenced from other information, and is an automatically generated unique ID.

FIG. 8 is an example of activity master information 800.
The activity master information 800 stores the contents of each activity. Information on commonly used activities is stored in advance, but users or administrators can also add new activities.
The activity master name 801 indicates the name of the activity master. When entered by the user, the name can be freely written.

The activity master type 802 indicates the type of activity master. It is selected from preset values, and for example, approval, notice, contract, etc. are stored. The approval type (Approval) is to send an approval request to obtain approval of the confirmation items from the owner. An input of approval (Approval) or denial (Decline) is accepted from the owner. The notice type (Notice) is to send a confirmation request to have the owner confirm the confirmation items. An input of a confirmation button is accepted from the owner. The contract type (Contract) is to send an electronic approval request to obtain electronic approval from the owner. An input of electronic approval using an electronic contract service is accepted from the owner.
The activity category ID 803 indicates the category of the activity, and refers to the value of the activity category ID 702 in the activity category information 700.
The activity master purpose 804 indicates the purpose of the activity master, and can be freely described by the user or administrator.

The title 805 indicates the title to be used in chat messages sent in relation to the activity. The title can be freely written.
The content 806 indicates the content of the chat message sent in relation to the activity. Predefined content is written, but it can also be written freely. For example, as shown in the sample value 823, room cleaning costs, wallpaper replacement costs, tatami mat replacement costs, door lock replacement costs, etc. are written as examples of predefined content for expenses.
The destination user 807 indicates the user to whom the activity card is to be sent.

Attachment 808 indicates the path to the file that is sent as an attachment.
The display ID 809 is the ID of the activity to be displayed on the screen of the management server 101, the owner terminal 102, etc., and is an automatically generated unique ID such as ACT-1234.
Activity master ID 810 indicates a unique ID generated for the activity master.
The deletion flag 811 indicates whether the activity master has been deleted.

FIG. 9 is an example of activity detail information 900 .
The activity detail information 900 stores detailed information about each activity.
An activity message content 901 indicates the content of the activity. The message is updated and stored by inputting an amount, adding a description, etc., for the information called up from the activity master.
For example, in the case of sample value 940, amounts are input and stored as expenses for room cleaning costs, wallpaper replacement costs, tatami mat replacement costs, and door lock replacement costs read from the activity master content 806.

These amounts may be entered by the user or administrator, but the data registration management module 212 and the asset registration management module 213 may be configured to input the amounts based on past activity for the same real estate property owned by the owner and past asset management information obtained from past information stored in the main DB 220, such as asset management information 1200.
In addition, values may be entered based on information not only about real estate properties owned by the same owner, but also about the same property owned by other owners, properties similar to the property being input, properties in the vicinity of the property being input, etc.

The activity message sending date 902 indicates the date and time when the message corresponding to the activity was sent.
The status 903 indicates the status of the activity. For example, information such as approved or rejected is stored.
The user ID 904 indicates the user who sent the activity.

The activity master ID 905 indicates the ID of the activity master, and reference is made to the activity master ID 810 of the activity master information 800.
The message ID 906 is an ID indicating a message sent in response to an activity, and the message ID 1007 in the message information 1000 is referenced.

FIG. 10 is an example of message information 1000.
The message information 1000 stores the contents of messages sent and received on the chat.
The message content 1001 indicates the content of the message. For example, as in the example of the sample value 1040, the message exchanged with the owner is stored.
The user type 1002 indicates the type (attribute) of the user who sends the message, for example, a PM (Property Management Company) operator, an owner, or the like is stored.
The expansion area 1003 is an area that can be freely expanded.

Read date/time 1004 stores the timestamp of when the message was read.
The sender ID 1005 indicates the ID of the user who sent the message. The value of the user ID 501 in the user information 500 is input and referenced, or the value of the token ID 1102 in the access token information 1100 is input and referenced.
The topic category 1006 indicates which topic the message belongs to by referring to the value of the topic category ID in the topic category information 600.
Message ID 1007 indicates a unique ID that is generated for each message.

FIG. 11 is an example of access token information 1100.
The access token information 1100 is a token used for authenticating a user.
The authentication token 1101 indicates a randomly generated token.
The token ID 1102 is an automatically generated unique ID and a primary key.

FIG. 12 is an example of the asset management information 1200.
The asset management information 1200 stores information about assets such as real estate owned by an owner and about assets such as real estate managed by an asset management company.
For example, information for identifying assets, such as an asset ID 1201, a name 1202, an address 1203, and an asset type 1204, as well as revenue information, present value, cash flow, and the like for these assets are stored.
The asset management information 1200 stores information about a large number of assets using a relational database or the like, but the storage format is not limited to this.

FIG. 13 is an example of a chat screen 1300.
The activity management module 211 of the management server 101 displays a list of chat exchanges 1303 regarding each of the owned assets for a specific owner 1302 in information 1301 about a plurality of owners that it manages.
When the activity management module 211 receives an instruction from a user to display a specific property, it displays chat conversations about the specific property in a chat window 1310. In the chat window 1310, a message 1304 from an operator who operates the management server 101 and a corresponding message 1305 from the owner are displayed in chat format.

The operator can create chat rooms with multiple topics for the owner. For example, topics can be freely created, such as "Regarding taxes" or "Regarding repairs to property A." When the operator selects an owner and clicks the topic creation button 1330, a topic creation screen 1400 is displayed.
When the operator wishes to notify the owner of confirmation items such as approval, notification, and contract, the operator selects the activity creation button 1320 and performs the activity card submission process.

FIG. 14 shows an example of a topic creation screen 1400.
When the operator presses the topic creation button 1330 , the activity management module 211 displays a topic creation screen 1400 .
On a topic creation screen 1400, an operator inputs a topic 1401 and selects a target topic from a topic category 1402. Note that a topic name corresponding to the selection of the topic category 1402 may be automatically input to the topic 1401.
The activity management module 211 accepts the selection of the target asset from the operator. The operator selects the asset owned by the owner from the asset selection area 1403 using a pull-down menu.

FIG. 33 shows an example of an activity card posting process flow 3300.
When an operator operating the management server 101 needs to confirm with the owner of a real estate property, the activity management module 211 generates an activity card and makes an inquiry to the owner by chat. Note that the configuration may be such that not only the operator of the management server 101, but also an operator of the asset management company makes an inquiry via the activity management module 211 using the management company asset management module 410.

When the operator presses the activity creation button 1320, the activity management module 211 displays the activity selection screen 1550 (step 3310).
The activity management module 211 receives the selection of an activity from the operator (step 3320).
The bolded portion 1551 and the like are activity categories and are predefined by the system. The thinned portion 1552 is predefined by the system, but can be edited by the operator, and new activities can also be added.

It should be noted that when a topic category 1402 is selected, the activity management module 211 may be configured to display only a list of activities belonging to this topic category in a pop-up screen. For example, when the topic category 1402 "Leasing" is selected, an activity selection screen 1550 pops up, and activities 1552 under Leasing 1551, such as "Approval for Leasing criteria,""Propertyinquiries,""Applicationnotice," and "Application approval," are displayed selectably and the operator can select an activity.
After selecting a category, the user may select the content to be confirmed according to the category, such as "approval of conditions for tenant recruitment," confirmation of conditions for tenant recruitment, approval, notification, contract, etc.

The activity management module 211 displays an activity details input screen 1500 for the selected activity (step 3330), and accepts the input of detailed information from the operator (step 3340).
FIG. 15 shows an example of an activity detail input screen 1500 .
The activity title 1510 is a title that indicates an overview of the activity.
Property information 1501 shows property information. It can be changed on this screen.
The target room number 1502 indicates the target room owned by the owner in the property.
Message 1503 describes the content of a message to be conveyed to the user along with the delivery of the activity card.
Attachments 1504 indicate attachments to be sent with the activity card.

The title of the inquiry is displayed in the inquiry title 1512. The inquiry content 1511 is where the content for which the owner's confirmation is desired is entered, along with numerical information for confirmation, etc.
For example, the example of the activity detail input screen 1500 shows an input for the activity of "obtaining approval for occupancy conditions." As the occupancy conditions in the inquiry content 1511, amounts, figures, and text for rent, management fee, security deposit, key fee, key money, advertising, etc. are entered and approved by the owner.
Past information on the corresponding property stored in the asset management information 1200 is retrieved and input into this inquiry content 1511. It is also possible to overwrite and update the input information.

Alternatively, information on the occupancy conditions of other rooms in the same real estate property managed by the asset registration management module 213 can be obtained from the asset management information 1200, and the activity management module 211 can analyze this to present new occupancy conditions adjusted based on the occupancy conditions of other rooms in the same property. In this case, only the parts that differ from the previous occupancy conditions are highlighted by changing the color, etc., and the proposal is made to the owner, and confirmation is requested.
For example, if the previous rent was 101,000 yen and the rent for another room has increased to 103,000 yen, the user can create an activity card with the proposed rent to the owner rewritten to 103,000 yen and highlighted in red, and ask the owner for approval.

Other possible methods include deriving the proposed rent from the average rent of similar properties in the same area, or deriving the proposed rent based on the increase or decrease in rent from the past to the present.
In this embodiment, multiple assets managed by multiple asset management companies are managed in a unified manner by the management server 101, and based on the integrated information spanning multiple properties, inquiries can be revised and proposals can be made for confirmation by the owner.

When the send button 1520 is pressed, the activity management module 211 generates an activity card based on the input information and the information called from the asset management information and input (step 3350). If necessary, a pre-send confirmation screen may be displayed.
When the operator confirms the contents of the activity card, the activity management module 211 posts the generated activity card to the chat where messages are being exchanged with the owner (step 3360).

FIG. 17 is an example of an activity card submission screen 1700.
In a chat where messages are exchanged between the owner and the operator, an activity card 1702 is posted together with a message 1701 from the operator in the same manner as the message. The content entered in message 1503 on the activity detail input screen 1500 is posted and displayed as a chat message 1701. It is also possible for the operator to enter a message in a normal chat.
Activity card 1702 includes activity title 1703, display ID 1704, content 1705, and attachment 1706.
These pieces of information are stored in the corresponding items of the activity master information 800 .

When sending and receiving activity cards in chat, the activity card on the owner's chat screen displays the approval button 2720 and the denial button 2730, but the approval and denial buttons are not displayed on the operator's chat screen. In chat, the same message is usually displayed on both the sending and receiving sides, but in this embodiment, the operator does not approve or deny, so the approval and denial buttons are not displayed on the operator's side to avoid confusion. However, it is also acceptable to display these buttons on the operator's side.

FIG. 18 is an example of an activity denial screen 1800.
This is an example of a screen that is displayed after the owner selects "Decline" on the confirmation button 1707 and performs the activity card display and response process 3400.
The activity management module 211 displays the comment entered by the owner when denying the request as a chat message 1801.
Furthermore, the activity management module 211 displays the details and reasons for the denial as a reply screen 1802.

FIG. 19 is an example of an activity approval screen 1900.
This is an example of a screen that is displayed after the owner selects the approval (Approve) of the confirmation button 1707 and performs the activity card display and response process 3400.
The activity management module 211 displays the approved content as a response screen 1901 .
When approving, the owner is not asked to enter a comment, so no message is displayed, and only a message indicating that the request has been approved is displayed. However, the owner may optionally enter a comment, which is then posted as a message in the chat.

FIG. 35 shows an example of an owner verification response receipt process flow 3500.
The activity management module 211 receives the answer information (answer screen) sent in the chat by the owner asset management module 310 of the owner terminal 102 (step 3510).
The activity management module 211 analyzes and captures the response information (step 3520), and updates the status 903 of the activity detail information 900 based on the content of the response information (step 3530).

FIG. 20 is an example of an activity details screen 2000.
View detailed information about activities that have been submitted and those that have been approved, rejected, or confirmed by the owner.
The activity details screen 2000 displays the activity history 2001 of past exchanges between the owner and the activity, including the owner's confirmation contents 2004, an activity card 2003, and activity details 2002.

FIG. 21 is an example of a notification setting screen 2100.
The activity management module 211 displays a notification when a message or a confirmation response is sent from the owner for an activity in the category selected in the notification category 2101 .

FIG. 22 shows an example of an activity list screen 2200.
FIG. 36 shows an example of an activity card list display process flow 3600.
The activity list screen 2200 is displayed when an activity list display button 2201 is selected.
The activity management module 211 accepts conditions for narrowing down the list of activities to be displayed (step 3610). For example, narrowing down can be performed based on information such as the owner name 2202, category name 2203, activity name 2204, status 2205, read/unread 2206, and creation date 2207.

The activity management module 211 obtains corresponding activity information from the activity master information 800 and the activity detail information 900 according to the narrowing down conditions (step 3620).
The activity management module 211 displays the acquired information on the activity list screen 2200 (step 3630).

The example of the activity list screen 2200 displays a list of activities related to leasing for a specific owner. For multiple real estate properties 2211 owned by this owner, those with a category 2212 of leasing are extracted, and the current status 2214 of each activity 2213 is displayed in a list.
According to this embodiment, it is possible to display and manage a list of the current status of each activity while communicating with the owner in conjunction with chat, making it easier and more efficient for the operator to manage their real estate.

FIG. 23 is an example of an activity details screen 2300.
The activity details screen 2300 is displayed when a specific activity is selected from the activity list screen 2200 .
The activity history 2302, owner confirmation status 2304, and activity details 2303 of the selected activity are displayed.

FIG. 24 is an example of an activity master screen 2400.
The operator of the management server 101 can tally up activities for each activity category. For activities filtered by the same conditions as those on the activity list screen 2200, the activity management module 211 acquires corresponding activity information from the activity master information 800 and the activity detail information 900, and tallys and displays the information for each activity master item 2401.
The number of sent messages 2402, the number of messages approved by the owner 2403, the number of messages confirmed by the owner 2404, etc. are tallied and displayed.

FIG. 25 is an example of an activity master addition screen 2500.
When the operator clicks the activity master add button 2405 , the activity management module 211 displays an activity master add screen 2500 .
The activity management module 211 has a plurality of activity information registered in advance, but the operator can add an activity at will.
The activity management module 211 accepts input of an activity name 2501 , an activity category 2502 , an activity type 2503 , a purpose 2504 , a message 2505 , a title 2506 , and a content 2507 , and adds them to the activity master information 800 .
The activity type 2503 includes, for example, approval, notice, contract, and the like, and is selected according to the content of the confirmation request to be sent to the owner.

FIG. 16 is an example of an activity card preview screen 1600.
When the operator clicks the preview button 2508 , the activity management module 211 displays the activity card preview screen 1600 .
The activity card 1601 includes an inquiry content 1602 and a confirmation button 1603 .
In the inquiry content 1602, amounts, figures, text, etc. to be confirmed by the owner are entered for each item of the inquiry content 1511 on the activity detail input screen 1500.
The activity management module 211 uses, as the confirmation button 1603, an "Approve/Reject" button according to the content of the activity, as well as a "Confirm" button and a "Contract" button for proceeding to electronic contract.

26 to 32 are examples of screens displayed on the owner terminal 102. FIG.
FIG. 26 is an example of a chat screen 2600.
The owner asset management module 310 of the owner terminal 102 cooperates with the activity management module 211 of the management server 101 to provide a chat function between the owner and the operator.
A chat screen 2600 displays a message 2601 from an operator and a message reply 2602 from the owner.

An activity card 2604 generated by an operator's operation is posted to the chat together with the operator's message 2603, and is displayed on the chat screen 2600. When details 2610 is selected, the owner asset management module 310 displays an activity details screen 2700.
Within the chat, an attachment 2611 is sent along with the activity card 2604 .

FIG. 27 is an example of an activity details screen 2700.
The activity details screen 2700 has a topic 2701 , an activity title 2702 , a property name 2703 , a status 2704 , a message 2705 , an inquiry 2710 , an attachment 2711 , an approve button 2720 , and a deny button 2730 .
The contents of the activities and activity cards described above are entered.
When the owner presses the approve button 2720, the owner asset management module 310 displays an activity approve screen 2800. When the owner presses the deny button 2730, the owner asset management module 310 displays an activity deny screen 2850.

FIG. 28 is an example of an activity approval screen 2800 and a denial screen 2850 .
The owner rechecks the inquiry content 2810, and if he/she approves it as is, he/she taps the approve button 2820. If he/she does not approve it, he/she taps the reject button 2830.
If the request is denied, a message input field 2801 is made a required input field to request the owner's comment in order to notify the owner of the reason for the denial.

FIG. 29 is an example of a post-denial chat screen 2900.
In the case of denial, the owner asset management module 310 posts the message 2901 entered in the message input field 2801 to the chat, and posts a reply screen or reply information 2902 to the chat. In this way, by posting the reason for denial entered along with the denial of the activity card as a chat message, communication between the operator and the owner can be made smooth.
The reply screen displays information such as a topic 2903, an activity title 2904, and the like, as well as a status 2905 of the owner's reply.

FIG. 34 shows an example of an activity card display and response process flow 3400.
The owner asset management module 310 displays the chat message related to the activity card sent from the activity management module 211 of the management server 101 (step 3410).
The owner asset management module 310 displays the activity card on the chat (step 3420).

The owner asset management module 310 accepts from the owner a selection of approval, denial, confirmation, etc. for the activity (step 3440). If the answer is denial (Yes in step 3440), the message input field 2801 is made a required input item, and a message input from the owner is accepted (step 3450).
Based on these inputs, the owner asset management module 310 generates a response screen (response information) for the activity (step 3460), and posts the response screen in the chat between the operator and the owner (step 3470).

FIG. 30 is an example of an activity list screen 3000.
The owner asset management module 310 acquires information on the corresponding activity from the activity management module 211 of the management server 101 based on the narrowing down condition 3001 for the activity.
The owner asset management module 310 displays a list of acquired activity information 3003, 3004, and 3005. It also displays a summary 3002 of the current status.
In this way, by displaying activity information indicating confirmation items for multiple assets managed by the management server 101 together on the owner terminal 102, the owner can easily manage multiple assets.

FIG. 31 is an example of an activity filter screen.
When the owner asset management module 310 receives a selection of the narrowing down condition 3001 from the owner, it displays an activity filter screen or displays similar information in a pull-down format to receive the selection of an item from the owner.

FIG. 32 shows an example of an asset management screen 3200.
The owner asset management module 310 of the owner terminal 102 collectively displays information on a plurality of assets 3203 owned by the owner on an asset management screen 3200 .
The owner asset management module 310 collects and displays a total present value 3201 of a plurality of assets 3203, 3204, 3205, etc., and asset information 3202 such as cash flow.

Typically, when a company has a large number of real estate or other assets, it will have multiple asset management companies, and the management methods and confirmations, etc. that arise for each asset will be communicated in different ways depending on the asset management company.
According to this embodiment, the management server 101 first accepts and integrates confirmation items from the asset management company terminals 103 owned by each of multiple asset management companies via a platform provided by the management server 101, and notifies the owner in the form of an activity card in a chat with the owner according to a set format called an activity.
Responses to each activity are accepted via chat, and the activity master information 800 and activity detail information 900 in the management server 101 are managed and updated, allowing the status of multiple assets owned by the owner to be centrally managed by the management server 101.

By simply introducing the owner asset management module 310 that works in conjunction with the activity management module 211 of the management server 101, the owner can manage multiple assets using a centrally managed screen and method, rather than having to deal with multiple assets and multiple asset management companies in different ways.
In addition, approvals, confirmations, and other matters that arise in large numbers for multiple assets can be approved and confirmed while interacting with an operator via real-time chat, making this a very user-friendly service for owners.

The present invention is not limited to the above-described embodiments, but includes various modified examples. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and are not necessarily limited to those having all of the configurations described. It is also possible to replace part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. It is also possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

Furthermore, the above-mentioned configurations, functions, processing units, processing means, etc. may be realized in hardware, in part or in whole, for example by designing them as integrated circuits. Furthermore, the above-mentioned configurations, functions, etc. may be realized in software, by a processor interpreting and executing a program that realizes each function. Information on the programs, tables, files, etc. that realize each function can be stored in a memory, a recording device such as a hard disk or SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.

In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be considered that almost all components are connected to each other.
The above-described embodiments disclose at least the configurations described in the claims.

1...Asset management system, 102...Owner terminal, 103...Asset management company terminal, 211...Activity management module, 212...Data registration management module, 213...Asset registration management module, 310...Owner asset management module, 410...Management company asset management module

In order to solve the above problems, for example, the configurations described in the claims are adopted .

In addition, the control lines and information lines shown are those that are considered necessary for the explanation, and not all control lines and information lines in the product are necessarily shown. In reality, it can be considered that almost all components are connected to each other.
The above-mentioned embodiment discloses at least the following configurations.
(1)
A method for managing activity using chat, comprising:
It remembers the list of activities that need to be confirmed with the property owner,
Accepting the selection of the real estate property;
Accepting a selection of the activity from the activity list;
Obtaining property information regarding the activity of the selected property;
Generate an activity card by inputting the acquired real estate property information;
Post the activity card to a chat room where messages are exchanged between the owner and the activity card owner.
2. An activity management method comprising:
(2)
The activity management method according to (1),
The real estate property information includes information regarding the amount of the real estate property,
Enter the amount information into the activity card
2. An activity management method comprising:
(3)
The activity management method according to (1) or (2),
There are approve and deny buttons corresponding to the activity card;
The button displayed in the chat accepts a selection of approval or rejection of the activity from the owner.
2. An activity management method comprising:
(4)
The activity management method according to (3),
If a denial decision is received from the owner,
A reason for denial is accepted, and the reason for denial is posted as a message to the chat.
2. An activity management method comprising:
(5)
The activity management method according to (3) or (4),
Store the date and time when the activity was approved or denied.
2. An activity management method comprising:
(6)
An activity management method according to any one of (3) to (5),
Acquire information regarding a predetermined activity for a plurality of real estate properties owned by the owner, and display a list of approval or denial statuses regarding the predetermined activity for the plurality of real estate properties.
2. An activity management method comprising:
(7)
A management server,
A storage means for storing real estate property information and a list of activities that require confirmation from the owner of the real estate property;
an input means for accepting a selection of the real estate property and accepting a selection of the activity from the activity list;
an activity management means for acquiring real estate property information related to the activity of the selected real estate property, generating an activity card by inputting the acquired real estate property information, and posting the activity card to a chat room in which messages are exchanged between the owner and the activity card;
A management server comprising:
(8)
(7) A management server according to (7),
The real estate property information includes information regarding the amount of the real estate property,
Enter the amount information into the activity card
13. A management server comprising:
(9)
A management server according to (7) or (8),
There are approve and deny buttons corresponding to the activity card;
The activity management means receives a selection of approval or rejection of the activity from the owner using the button displayed in the chat.
13. A management server comprising:
(10)
(9) A management server according to (9),
If a denial decision is received from the owner,
A reason for denial is accepted, and the reason for denial is posted as a message to the chat.
13. A management server comprising:
(11)
The management server according to (9) or (10),
The storage means stores the date and time when the activity is approved or rejected.
13. A management server comprising:
(12)
A management server according to any one of (9) to (11),
Obtaining information regarding a predetermined activity for a plurality of real estate properties owned by the owner, and displaying a list of approval or denial statuses regarding the predetermined activity for the plurality of properties.
13. A management server comprising:
(13)
A program for causing a management server to execute each step of the activity management method according to any one of (1) to (6).

Claims (13)

A method for managing activity using chat, comprising:
It remembers the list of activities that need to be confirmed with the property owner,
Accepting the selection of the real estate property;
Accepting a selection of the activity from the activity list;
Obtaining property information regarding the activity of the selected property;
Generate an activity card by inputting the acquired real estate property information;
The activity management method includes posting the activity card to a chat room where messages are exchanged between the activity card owner and the activity card owner. 2. The activity management method according to claim 1,
The real estate property information includes information regarding the amount of the real estate property,
The activity management method further comprises inputting the amount information into the activity card. 3. The activity management method according to claim 1, further comprising:
There are approve and deny buttons corresponding to the activity card;
an activity management method comprising: receiving a selection of approval or rejection of the activity from the owner by the button displayed in the chat; 4. The activity management method according to claim 3,
If a denial decision is received from the owner,
An activity management method comprising: accepting an entry of a reason for denial; and posting the reason for denial as a message in the chat. 5. The activity management method according to claim 3, further comprising:
A method for managing activities, comprising: storing a date and time when the activity was approved or rejected. The activity management method according to any one of claims 3 to 5,
An activity management method characterized by obtaining information regarding specified activities for multiple real estate properties owned by the owner, and displaying a list of approval or denial status for the specified activities for the multiple real estate properties. A management server,
A storage means for storing real estate property information and a list of activities that require confirmation from the owner of the real estate property;
an input means for accepting a selection of the real estate property and accepting a selection of the activity from the activity list;
an activity management means for acquiring real estate property information related to the activity of the selected real estate property, generating an activity card by inputting the acquired real estate property information, and posting the activity card to a chat room in which messages are exchanged between the owner and the activity card;
A management server comprising: 8. The management server according to claim 7,
The real estate property information includes information regarding the amount of the real estate property,
A management server that inputs the amount information into the activity card. 9. The management server according to claim 7 or 8,
There are approve and deny buttons corresponding to the activity card;
The activity management means receives a selection of approval or rejection of the activity from the owner by using the button displayed in the chat. 10. The management server according to claim 9,
If a denial decision is received from the owner,
A management server that accepts entries of reasons for denial, and the reasons for denial are posted as messages in the chat. 11. The management server according to claim 9,
The management server according to claim 1, wherein the storage means stores a date and time when the activity is approved or rejected. The management server according to any one of claims 9 to 11,
A management server characterized by acquiring information regarding specified activities for multiple real estate properties owned by the owner, and displaying a list of approval or denial status for the specified activities for the multiple properties. A program for causing a management server to execute each step of the activity management method according to any one of claims 1 to 6.

Images