JP7241785B2 - Asset management system - Google Patents

Description

The present invention relates to asset management technology, and more particularly to technology effectively applied to an asset management system that supports various processes related to asset transfer such as inheritance performed by a potential decedent.

Along with the development of IT technology, mechanisms for managing personal assets have been proposed, such as generating and managing a user's household account book, managing bank account information, and the like. In recent years, there has been proposed a mechanism for easily collecting and viewing information using a mobile terminal such as a smartphone owned by each user.

For example, Japanese Patent Application Laid-Open No. 2001-306798 (Patent Document 1) discloses that income and expenditure information including debit card transaction information and financial institution account information is collected from a host computer, and household account book data is generated based on this information. A technology related to a household account book data creation system is described.

In addition, Japanese Patent Application Laid-Open No. 2005-38130 (Patent Document 2) discloses that a Web site for aggregation acquires and collectively displays deposit and withdrawal details of multiple financial institutions, so that the deposit and withdrawal details can be viewed in a household account book application. describes a technique that makes it possible to easily import all at once.

Money Forward (registered trademark, Non-Patent Document 1), which is a household account book application, cooperates with Internet services provided by multiple financial institutions such as banks, securities companies, and credit card companies. It is possible to automatically create a household account book and check the asset status by acquiring accounts and information related to the accounts.

On the other hand, for example, in Japanese Patent Laying-Open No. 2015-132882 (Patent Document 3), when creating a family tree to be used for trial calculation of inheritance tax, the user requests icons of legal heir candidates, placement of additional icons, A technique for improving operability by receiving input of spouse and child information is described.

Japanese Patent Application Laid-Open No. 2001-306798 JP-A-2005-38130 JP 2015-132882 A

“Fully automatic household account book money forward”, [online], Money Forward Co., Ltd., [searched on June 14, 2016], Internet <URL: https://moneyforward.com/>

By using conventional technology, it is possible to grasp, form, and manage financial assets that are mainly necessary for individuals to carry out their daily lives now and in the future. However, the conventional technology is limited to management as the individual's financial assets. Therefore, for example, the distribution of surplus assets to close relatives of the individual concerned, asset formation of these persons, etc., mainly centered on inheritance, and asset management in a certain group of close relatives and relatives, etc., are not considered at all. do not have.

SUMMARY OF THE INVENTION Accordingly, an object of the present invention is to provide an asset management system that supports not only management of personal financial assets but also various processes related to transfer of assets to close relatives including inheritance.

The above and other objects and novel features of the present invention will become apparent from the description of the specification and the accompanying drawings.

A brief outline of typical inventions disclosed in the present application is as follows.

An asset management system according to a representative embodiment of the present invention is an asset management system that supports management of assets owned by a user connected via a network using a user terminal, wherein the asset owned by the user is an asset management unit that records information related to the asset status recording unit, performs processing related to the transfer of assets between the user and another user, and records the content of the processing in a transfer history recording unit; and an inheritance management unit that performs processing related to transfer of at least part of the assets held by the user before or after the user's death.

The inheritance management unit further receives registration of the details of a gift given to other second users within a predetermined range from the first user during the lifetime of the first user or a gift due to death, and inherits the details. a gift management unit that records in a property recording unit; and a will management unit that receives registration of the contents of a will from the first user while the first user is alive and records the contents in a will management information recording unit. , after the death of the first user, the content of the will of the first user recorded in the will management information recording unit can be referred to by the second user within a predetermined range; an inheritance processing unit that receives information related to the transfer of the assets held by the second user to the second user, and records the content of the information in the inherited property recording unit; If the contents related to the transfer of assets recorded in the inherited property recording department satisfy the conditions for the transfer, the processing related to the transfer of the assets is performed.

Among the inventions disclosed in the present application, the effects obtained by representative ones are briefly described below.

That is, according to the representative embodiment of the present invention, it is possible to support not only the management of personal financial assets but also various processes related to the transfer of assets to close relatives including inheritance.

BRIEF DESCRIPTION OF THE DRAWINGS It is the figure which showed the outline|summary about the structural example of the asset management system which is Embodiment 1 of this invention. FIG. 4 is a flow chart showing an outline of an example of a flow of assisting various kinds of processing related to inheritance, etc. performed by a target user while alive according to Embodiment 1 of the present invention. FIG. 4 is a flow chart showing an overview of an example of a flow of supporting various processes related to inheritance and the like performed after the death of a target user according to Embodiment 1 of the present invention. 1(a) and 1(b) are diagrams showing an overview of an example of a data configuration of a user DB according to Embodiment 1 of the present invention; FIG. FIG. 2 is a diagram showing an overview of an example data configuration of an asset status DB according to Embodiment 1 of the present invention; FIG. 2 is a diagram showing an overview of an example of a data configuration of a transfer history DB according to Embodiment 1 of the present invention; FIG. FIG. 2 is a diagram showing an overview of an example of a data configuration of an inheritance DB according to Embodiment 1 of the present invention; FIG. FIG. 3 is a diagram showing an overview of an example data configuration of a will management DB according to Embodiment 1 of the present invention; (a) to (d) are diagrams showing an overview of an example of a user interface displayed on a user terminal according to Embodiment 2 of the present invention. FIG. 10 is a diagram showing an overview of an example of a screen for a user to create a family tree according to Embodiment 2 of the present invention; FIG. FIG. 10 is a diagram showing an overview of an example of a data configuration for forming family tree information to which close relatives subject to asset management belong according to Embodiment 2 of the present invention; FIG. 10 is a diagram showing an overview of an example of the flow of processing for forming family tree information based on information on close relatives according to Embodiment 2 of the present invention; FIG. 10 is a diagram showing an overview of an example of the flow of processing for forming family tree information based on information on close relatives according to Embodiment 2 of the present invention; FIG. 10 is a diagram showing an overview of an example of the flow of processing for displaying a balance sheet as a group of close relatives based on family tree information according to Embodiment 2 of the present invention;

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In principle, the same parts are denoted by the same reference numerals throughout the drawings for describing the embodiments, and repeated descriptions thereof will be omitted. On the other hand, parts that have been described with reference numerals in one drawing may be referred to with the same reference numerals, although they are not shown again in the description of other drawings.

(Embodiment 1)
<System configuration>
FIG. 1 is a diagram showing an overview of a configuration example of an asset management system according to Embodiment 1 of the present invention. The asset management system 1 is configured by, for example, an asset management server implemented in a server device, a virtual server built on a cloud computing service, or the like. One or more user terminals 30 are connected as clients to this asset management server 10 via a network 20 such as the Internet.

The asset management server 10 is a server system having a function of supporting various processes related to the transfer of assets to close relatives, etc., including asset management and inheritance of each of a plurality of users via the user terminal 30 . In addition to the transfer of assets as an inheritance to an heir, there are systems that allow the transfer of assets to a person other than an heir, such as lifetime gifts, death-related gifts, and specific testamentary gifts. include. In the following, these asset transfers may be broadly referred to as “inheritance”. In addition, from the perspective of a potential decedent, the (presumed) heir and persons other than the heir to whom assets may be transferred may be collectively referred to as "close relatives."

The asset management server 10 includes a user management unit 110, an asset management unit 120, an inheritance management unit, and an inheritance management unit 110 implemented as software running on middleware such as an OS (Operating System), a DBMS (DataBase Management System), and a Web server program (not shown). It has parts such as a part 130 and an external service interface (I/F) 140 . These middleware and software are expanded on a memory (not shown) and executed by a CPU (Central Processing Unit) to realize various functions and services as described later. The asset management server 10 also includes a user database (DB) 151, an asset status DB 152, a transfer history DB 153, an inheritance DB 154, a will management DB 155, etc., which are implemented as databases, file tables, etc. on a storage medium such as a hard disk (not shown). , each data store.

The user management unit 110 has a function of managing account information of users who use the asset management server 10 to manage assets and transfer assets by inheritance or the like. Specifically, the account information registered by the user via the user terminal 30 is registered in the user DB 151, and requests for reference or change thereof are accepted, and the corresponding processing is performed on the user DB 151. FIG. In the present embodiment, it is desirable to be able to grasp as much information as possible not only about potential inheritees, but also about close relatives to whom assets are transferred from these people. Therefore, in the present embodiment, it is assumed that close relatives including presumed heirs can also register their account information and manage their assets as users using the asset management system 1 . Information on close relatives seen from a certain user can be managed, for example, by forming a group of close relatives centering on the target user.

The asset management unit 120 provides various functions that contribute to grasping the status of assets owned by the user and managing them. For example, it acquires/collects the status of various assets such as financial assets and registers them in the asset status DB 152, similar to the functions of a general asset management/household account book application such as the conventional technology. In addition, the information is appropriately processed, aggregated, etc., so that it can be browsed through the user terminal 30 . Whether or not to disclose such information so that it can be viewed by other users (parents, spouses, brothers and sisters, etc., close relatives who can be inheritors or heirs to themselves), etc. The user may be allowed to specify access control for For access control, for example, when refusing to disclose information to other users, it is specified whether or not to refuse only the system to refer to it in processing related to inheritance, and what information is to be disclosed to other users. It may also include specification of a range, etc.

In the above example, the asset management function is the same as that of a general asset management/household account book application, but this is only an example. It may be of such a form. For example, the functions may be similar to those of personal bank applications and securities applications. In addition, the functions of the asset management unit 120 in the asset management system 1 of the present embodiment are incorporated into these applications themselves, SNS (Social Networking Service), portal site mail systems, etc., or these services may be configured to provide the asset management function in the present embodiment in cooperation with .

Assets to be managed by acquiring the status are not limited to financial assets such as deposits and savings, stocks, pensions, life insurance, etc., which are similar to general asset management and household account book applications, but also real estate, automobiles, Includes movable properties with high asset value such as ships and precious metals. In addition, debts and liabilities such as housing loans and loans for business funds are also grasped and managed as negative assets. The identification of these assets that may be subject to inheritance and the understanding of their asset status can be achieved, for example, by information processing systems and websites that are publicly disclosed and provided by financial institutions such as banks and various other business operators (Fig. (indicated as an external service 40 ) via an external service interface (I/F) 140 .

For example, it extracts and collects information related to the user's assets from the website of the external service 40 using so-called web scraping technology or the like, either periodically or at any time upon receiving an instruction. Information may be extracted and collected by calling an API (Application Programming Interface) that is open to the public by the information processing system of the external service 40 . Assets that are automatically acquired and collected may be presented as candidates to the user via the user terminal 30, and the user may select assets to be managed from among the candidates. In addition, the user may manually input the assets that could not be grasped automatically. As a result, for example, information on financial assets held in financial institutions can be grasped. In addition, by referring to and analyzing information related to the history of deposits and withdrawals, such as transfer history and tax payment status, it is possible, for example, to grasp the existence of real estate and movable properties that can be managed from information such as destinations and amounts. is also possible.

The asset management unit 120 further includes units such as an asset transfer unit 121, an asset evaluation unit 122, and a prediction processing unit 123 in order to realize various other functions.

The asset transfer unit 121 performs processing related to the actual transfer of assets from the user who will be the inheritee to the next of kin. The close relatives may include not only close relatives who are users of the asset management system 1, but also close relatives who do not have account registration. The transfer of assets can occur either before or after the intended user's death. Before the target user's death, for example, in addition to asset transfer as an advance of inheritance, such as a gift of real estate, etc., support for business funds, marriage funds, house purchase funds, etc. A possible asset transfer can take place. Also, after the death of the target user, asset transfer can be performed as execution of the details of inheritance determined by the inheritance management unit 130, which will be described later.

The asset transfer unit 121 has a function of transferring assets to be transferred from the target user's account to the target close relative's account on the asset status DB 152, for example. For example, for an asset transfer automatically determined by the asset transfer unit 121 or instructed by the user, the external service I/F 140 is used based on the details of the transfer to an external service 40 such as a financial institution. You may make it reflect the content of an asset transfer. For example, it is possible to transfer money between bank accounts, transfer real estate registration (or change the name of registered movable property), and the like.

For an asset transfer actually performed outside the system, such as a transfer of money or movable property, input of the result of the asset transfer may be received from the user and the contents thereof may be reflected in the asset status DB 152 or the like. Note that the details of the executed asset transfers (especially before death) are recorded in the transfer history DB 153 with the reason for the transfer (for example, "marriage funds" or "business funds"). Further, for example, data obtained by scanning documents generated when an asset transfer is actually performed, such as contracts and documents for register transfer, may be recorded as trail data. By referring to these records after the target user dies, unnecessary disputes regarding the transfer of assets during life can be prevented.

The asset evaluation unit 122 has a function of performing a monetary evaluation of assets other than money when assets are registered in the asset status DB 152 or when assets are transferred by the asset transfer unit 121 . For example, via the external service I/F 140, it is possible to access the external service 40, which provides services such as evaluating the present and future values of financial assets, and obtain evaluation results. In addition, it is also possible to access an external service 40 that provides a second-hand market for real estate and movable property, and perform monetary evaluation based on the market price of the same property or product. It is also possible to output the current content of assets to a data file, a PDF (Portable Document Format) file, or the like, and send it by e-mail to an expert for evaluation.

The prediction processing unit 123 has a function of predicting, by simulation or the like, necessary expenses such as living expenses that will be required by the time when the target user is expected to die. For example, as the simplest prediction model, the length of life expectancy is calculated from the current age of the target user and the average life expectancy for each gender, and this is multiplied by assuming that the current necessary expenses per unit period will continue for the life expectancy. , and further multiplied by a desired margin rate. On the other hand, future forecasts of income and expenditure associated with changes in the living environment, such as salary income until retirement, pension income after retirement, financial income, medical expenses, housing expenses, educational expenses, etc. It is possible to make corrections in consideration of characteristics and the like. For the correction, for example, a predetermined model may be automatically applied, or the user may directly specify/input a model, predicted values, and the like. An inquiry may be made to an external expert via the external service I/F 140 .

In addition, the prediction processing unit 123 also calculates the predicted valuation at the predicted death timing for each of the owned assets. This may also be calculated by automatically applying a predetermined model, or the user may directly specify/input the estimated valuation price. An inquiry may be made to an external expert via the external service I/F 140 . The total amount of assets that can be transferred to close relatives through inheritance is assumed to be the sum of the expected valuation of all assets at the expected time of death obtained minus the total amount of necessary expenses up to the expected time of death. . The user can design and manage asset transfer by inheritance or the like by referring to the total transferable asset amount.

The inheritance management unit 130 provides various functions that contribute to the design, management, and execution of asset transfer by inheritance for the target user's assets. That is, during the lifetime of the target user, for example, within the range of the total amount of transferable assets predicted by the asset management unit 120, the design and management of the asset transfer using the lifetime gift of the user and its execution are supported. We also assist in the design of asset transfers through the preparation of wills and the administration of wills. After the death of the target user, the heir or executor will support the understanding and management of the inheritance and will, as well as the design and management of asset transfer by will or division of inheritance, and its execution.

The inheritance management unit 130 further includes units such as a gift management unit 131, a will management unit 132, and an inheritance processing unit 133 in order to realize the above functions.

The gift management unit 131 has a function of registering and managing assets to be transferred as gifts to close relatives. For example, according to an instruction from the target user via the user terminal 30, the asset to be donated due to the conclusion of the contract for lifetime gift or cause-of-death gift and its contents are specified from among the assets registered in the asset status DB 152. and register it in the inheritance DB 154. Note that, in the present embodiment, gifting includes gifting with a burden as well as gifting without a burden. It also includes the case where all or part of it is lent at low interest or no interest.

In the case of lifetime gifts, the target assets are donated to the target's close relatives via the asset transfer section 121 of the asset management section 120 in response to an instruction from the target user or when a specified condition is fulfilled. In the case of death gift, the target asset is donated to the target's close relatives via the asset transfer unit 121 of the asset management unit 120 when the target user dies or when a specified condition is fulfilled after the user's death. . Regardless of whether the person is alive or after death, when the fulfillment of a specified condition is the trigger, if the asset management system 1 can automatically detect the condition according to the content of the condition, the condition is detected. At that time, the asset transfer unit 121 can automatically process a gift or the like. The user who detects that the condition has been fulfilled may detect it by inputting the fact via the user terminal 30, including the case of conditions that cannot be detected automatically.

In the present embodiment, as reference information that helps the user to decide which assets to give to whom and how much, and whether it is better to make a gift while alive, or to make a gift due to death, or a bequest.・It is desirable to have a function to simulate inheritance tax. The gift management unit 131 itself may directly have a means for calculating the gift tax/inheritance tax on the designated property. Alternatively, the external service 40 that provides the simulation service may be accessed via the external service I/F 140 to acquire the simulation result.

Moreover, the simulation is not limited to gift tax/inheritance tax. For example, it may have a function of evaluating and judging the appropriateness of the amount of asset transfer by gift or the like or the validity of the other party's close relatives. For example, even if the gift is within the total transferable assets, the gift may be unnecessary or excessive depending on the asset status of the other party's close relatives. In addition, even if the assets of the other party's close relatives themselves require a gift from the target user, if the circumstances that led to such a situation were due to unplanned wasteful spending, etc. may be inappropriate.

When a user who intends to perform an asset transfer evaluates and judges the validity of the transfer, if the user who is the other party's close relative permits the disclosure of the asset status, the target user is the other party's close relative By referring to the user's asset status, it is possible to make a certain amount of independent judgment. On the other hand, even if it is possible to refer to the asset status of the close relative who is the other party, it may be difficult to objectively judge the appropriateness depending on the knowledge of the target user. In addition, even if some or all of the users in the close relatives group including the other party's close relatives refuse to disclose the asset status and cannot refer to the asset status, the transfer of assets to the close relatives will not be permitted. It may be difficult to determine whether it is appropriate to

Therefore, in the present embodiment, even if other close relatives belonging to the close relatives group do not allow the disclosure of the asset status to themselves, the gift management unit 131 and the like can access the asset status DB 152 and the transfer history DB 153. etc., to comprehensively determine the current asset status of other close relatives and the history of past asset transfers. Then, the appropriateness of asset transfer to the close relative may be evaluated and judged, and the result may be presented to the target user as an opinion or advice.

In a simple model, for example, when a close relative of the other party is planning to purchase a house, etc., the necessary amount is evaluated based on the difference between the planned expenditure amount and the amount of the current assets held, and the necessary amount is larger than the necessary amount. can be determined as unnecessary (or reduced). In addition, if the amount of assets currently owned by the other party's close relatives is small, for example, analysis of the history of consumption behavior, as is done in general household account book analysis services, etc. If so, the gift may be determined to be unnecessary (or reduced).

The target user may actively access the asset management system 1 to examine the appropriateness of the asset transfer as described above. Alternatively, the asset management system 1 detects a situation in which a close relative expressly/implicitly wishes to transfer assets, and notifies the target user to consider it. You can do it.

To detect a situation where a close relative wishes to transfer assets, for example, access the asset management system 1 to input that the close relative needs funds for purchasing a house, starting a business, etc. The asset management system 1 may detect this. When the close relative inputs that they need to provide funds, it may be possible to specify one or more users (for example, users who can be the decedent to themselves) who are candidates for the request. At that time, the close relative may be allowed to refer to the asset status of the user who may be the inheritee of the user. For example, the asset management unit 120 or the like detects that the close relative has performed a bank transaction or various simulations related to the purchase of a house, and the provision of funds is not based on the input or instruction of the close relative. It may be determined automatically that it is in the necessary situation.

The will management unit 132 has a function of supporting the creation and management of a user's will during his lifetime. The target user refers to the total amount of transferable assets predicted by the asset management unit 120 and the contents of individual assets recorded in the asset status DB 152 via the user terminal 30, and decides which asset to whom and how much to transfer. It is possible to decide whether or not to let the deceased, and register it as a will. When the user creates a will, the gift tax/inheritance tax simulation function of the gift management unit 131 and the validity evaluation function of individual asset transfers may be used.

For example, it is desirable to calculate and present the difference between the gift tax and the inheritance tax for each of a plurality of patterns of asset transfer, while setting the case of statutory inheritance as the default as the content of the will. For example, in addition to comparison between asset transfer patterns arbitrarily set by the user, it is also possible to compare these with default asset transfer patterns in accordance with legal inheritance. When the user arbitrarily sets the asset transfer pattern, for example, the user can modify and set the default asset transfer pattern according to the legal inheritance.

In designing the pattern of asset transfer, the will management unit 132 takes various data into consideration and optimizes the weighting according to predetermined conditions, and also calculates and considers the legally reserved portion of each presumed heir. , one or more candidate pattern proposals may be created and presented. In addition, by accepting corrections from the target user based on the selected candidate pattern and presenting the recalculated gift tax and inheritance tax, it is possible to gradually improve the contents of the asset transfer. may

Data to be taken into consideration include, for example, the amount and timing of asset transfers between the target user's relatives during his/her lifetime and the reason for this, the amount and content of assets currently held by each close relative, each close relative's information such as age, family composition, occupation, place of residence, etc. By registering information on the presence or absence of cohabitation with the target user and the presence or absence of nursing care, etc., such information can be taken into account (for example, preferentially transferring the current real estate to close relatives who live together). . It is also possible to output the content of the target user's assets to a data file, PDF file, or the like, and send it by e-mail to an expert to receive advice.

It should be noted that, including the gift described above, it may be possible to target only close relatives whose asset status has been disclosed to the target user as the target of the asset transfer (i.e. Close relatives who do not disclose will be treated in the same way as those who have renounced the inheritance, for example).

The registered will is recorded in the will management DB 155 . In addition, the user can change the contents of the will registered in the will management DB 155 at any time while the user is alive. The contents of the registered will may be freely referenced by close relatives, or access control may be performed so that at least some of the close relatives cannot refer to it confidentially. In this case, for example, to whom and how much information is to be disclosed can be individually set, and the contents thereof can be registered in the will management DB 155 together. Some or all of the relatives who are presumed heirs may be allowed to refer to the entire contents of the will, or may be allowed to refer to only the contents related to the entire inheritance. Each presumed heir may be restricted to refer only to the portion related to his/her own inheritance.

In addition, when the target user registers the contents of the will, means may be provided to prove that the contents have been arbitrarily registered based on the user's free will. For example, as authentication information for proving free will, video and audio of the person at the time of inputting the will are recorded and recorded by a camera and microphone (not shown) provided in the user terminal 30, and the data is managed together with the contents of the will. You may make it register to DB155. Further, biometric information, such as heart rate, from which the mental state at the time of the will can be estimated may be acquired by a sensor or the like (not shown) and registered. Further, image data of a handwritten signature may be acquired and registered by handwriting input on the touch panel of the user terminal 30 or photographing with a camera. Also, it is possible to register the certification information of witnesses and witnesses.

Furthermore, the content of the will may be printed out as a document or output as a PDF file and used as the basis for a notarized will, or if possible, it may be treated as a will as it is by, for example, signing and/or stamping. . Also, if possible, the contents registered in the will management DB 155 may be treated as they are as wills.

The inheritance processing unit 133 has a function of supporting processing related to inheritance by an heir or an executor after the death of the target user. The event of the death of the target user that triggers the start of inheritance can be detected, for example, by the heir or the like specifying information to that effect via the user terminal 30 . Alternatively, it is technically possible to detect by automatically acquiring from a system such as a government office, medical institution, or nursing care facility via the external service I/F 140 .

If the will of the target user is registered in the will management DB 155, for example, the asset transfer may be automatically performed according to the contents of the will via the asset transfer unit 121 of the asset management unit 120. Alternatively, the content of the will can be referred to by heirs, etc., assets can be transferred manually outside the system, and only the result of the transfer can be received and recorded as a history in the transfer history DB 153 or the like.

In addition, if all or part of the assets of the target user are not designated by the will (the will is not registered), the input of the results of the inheritance division consultation etc. from the heir etc. will be accepted, and the contents You may make it automatically perform an asset transfer along. Alternatively, only the result of the asset transfer performed manually outside the system based on the result of inheritance division consultation may be accepted and recorded as a history in the transfer history DB 153 or the like.

In addition, as information that contributes to the heir's consultation on inheritance division, for example, information related to the asset status of the target user (inheritee) may be acquired from the asset status DB 152 and presented. Further, an input indicating that the heir has made limited acceptance or renounced inheritance may be received and reflected in the automatic processing related to inheritance or the content of information provided to the heir. Further, as a premise for holding consultations on division of inheritance, it is also possible to notify users of close relatives that the target user has died and inheritance has started, that consultations on division of inheritance should be held, and the like.

In addition, in order to provide reference information that helps the heir to decide which assets to allocate to whom and how much, simulation of gift tax and inheritance tax is performed in the same way as the gift management unit 131 and will management unit 132 described above. It is desirable to have a function to carry out evaluation and a function to evaluate the validity of individual asset transfers.

In this case, for example, it is desirable to calculate and present the difference between the gift tax and the inheritance tax for each of a plurality of inheritance division patterns, while setting the case according to the legal inheritance as the default. In designing the inheritance division pattern, the inheritance processing unit 133 takes various data into consideration and optimizes weighting according to predetermined conditions, and also calculates and considers the inheritance portion of each heir. One or more candidate pattern plans may be created and presented. Further, it is also possible to gradually improve the contents of inheritance division by receiving corrections from the target user based on the selected candidate pattern and presenting the recalculated inheritance tax accordingly. .

Data to be taken into consideration include, for example, the amount and timing of asset transfers between the decedent and his/her heirs during his/her lifetime, the reason for this, the amount and content of assets currently held by each heir, and the details of each heir's assets. Information such as age, family composition, occupation, and place of residence may be included. By registering information about living together with the decedent and the presence or absence of nursing care, etc., such information can be taken into consideration. It is also possible to output the contents of the assets of the target user (the decedent) to a data file, a PDF file, or the like, and send an e-mail to an expert to receive advice.

The user terminal 30 is an information processing terminal used by a user who uses the asset management service provided by the asset management system 1. For example, a general-purpose information processing terminal such as a PC (Personal Computer), a tablet terminal, or a smartphone is used. can do. Any device having an information processing function is not particularly limited to these information processing terminals, and may be a home appliance such as a television. In the present embodiment, asset transfer due to inheritance or the like is included as a target, so it is thought that the proportion of elderly users among users will be higher than in general services. Therefore, without moving on the spot, users can easily and timely perform processing and operations related to asset transfer, such as making a gift or making a will, by touch operation using mobile terminals such as tablets and smartphones. Usage is mainly assumed.

The user accesses the function of each unit of the asset management server 10 via the network 20 using software such as a client application (not shown) and a web browser installed in the user terminal 30 . In addition to input devices such as a keyboard and a mouse, the interface through which the user operates the application can include operations using a touch panel and operations based on voice recognition via a microphone. As described above, the user's image captured by the camera function can also be used as input data.

<Flow of processing (while alive)>
FIG. 2 is a flow chart showing an overview of an example of the flow of assisting various processes related to inheritance, etc. performed by a target user while he or she is still alive. As a premise for performing the management process while alive, it is assumed that the target user has account information registered in the user DB 151 by registering as a user in the asset management system 1 . It is also assumed that the asset management unit 120 registers and manages information about its own assets in the asset status DB 152 .

The target user accesses the asset management server 10 via the network 20 using the user terminal 30 in order to plan the asset transfer by inheritance or the like. Upon receiving an instruction from the user via the user terminal 30, the asset management unit 120 of the asset management server 10 acquires current asset information related to the target user from the asset status DB 152 and outputs it to the user terminal 30 (S01). ). Not only the contents of the asset status DB 152, but also the contents of past asset transfers recorded in the transfer history DB 153 according to instructions from the user, the contents of inherited (planned) assets already registered in the inherited property DB 154, The contents of the will already registered in the will management DB 155 may be acquired and responded.

If the user receives an instruction via the user terminal 30 to the effect that future forecasting of assets, etc. is necessary in order to grasp the total amount of transferable assets when designing inheritance details (S02: Yes), the asset management unit The prediction processing unit 123 of 120 calculates the expected valuation of all assets at the future expected death time of the target user, and outputs it to the user terminal 30 (S03). Further, the total amount of necessary expenses such as living expenses required by the estimated time of death of the target user is predicted by simulation or the like and output (S04). It is assumed that the total amount of transferable assets is obtained by subtracting the total amount of necessary expenses calculated in step S04 from the sum of the expected valuations of all assets calculated in step S03.

Including the case where no instruction is given in step S02 to the effect that the future prediction of assets, etc. is necessary (S02: No), furthermore, in accordance with instructions from the user, close relatives (close relatives group) who may be subject to asset transfer user) is acquired from the asset status DB 152 and output to the user terminal 30 (S05). At this time, access control is performed so that only the asset statuses of users who are permitted to disclose their asset statuses among the users included in the close relatives group are disclosed to the target users. The target user refers to the various information obtained in the series of processes described above, and uses the gift tax and inheritance tax simulation functions of the inheritance management unit 130 to determine who receives which assets, how much, when and how. We will design the asset formation of close relatives, such as how to relocate.

Then, when receiving an instruction to make a gift from the target user (S06: Yes), the gift management unit 131 of the inheritance management unit 130 prompts the input of the content of the gift contract established between the other party's close relatives. This is received from the user and registered in the inheritance DB 154 (S07). If there are multiple gift contracts, register each of them. The contents of the gift contract include, for example, the other party, the contents of the assets to be transferred (amount, property, equity, etc.), transfer conditions (arrival of a certain date, fulfillment of other conditions, etc.), and whether or not the other party will bear a burden. can be

Then, if it is determined that each gift is a lifetime gift and that the conditions for the transfer are satisfied based on the contents of the transfer conditions (S08: Yes), the asset management Asset transfer unit 121 of unit 120 transfers the asset to be gifted to the other party's close relatives as a gift (S09). As described above, it is also possible to receive an input about the result of a gift made outside the system and register it in the transfer history DB 153 . Transfer terminates the management process for these assets.

If it is determined in step S08 that each gift is a gift while alive but the conditions for transfer have not been met, or that it is a gift due to death (S08: No), the management process for these assets ends. As for a gift that is a lifetime gift but the transfer condition has not been fulfilled, for example, the gift management unit 131 or the like periodically checks whether the condition has been fulfilled. Then, when it is determined that the request has been accomplished, the transfer processing may be performed by the asset transfer unit 121 after notifying the target user and obtaining consent/instruction.

On the other hand, when receiving an instruction to make a will from the target user in step S06 (S06: No), the will management unit 132 of the inheritance management unit 130 accepts input of the contents of the will from the user via the user terminal 30. This is accepted and registered in the will management DB 155 (S10). In addition to information on the details of the transfer of individual assets, the contents of the will also include information related to access control, such as information on whether or not disclosure of the contents of the will is permitted, and information on the subject and scope of disclosure.

In addition to registering the contents of the will, it is desirable to also acquire and record authentication information for proving that the target user has voluntarily created and entered the contents of the will (S11). ). The authentication information may include, for example, video and audio data, signature data, biometric information, etc. at the time of registration of the will, as described above. Further, for example, when receiving an instruction to output the content of the will from the user, this is output as data such as a document or a PDF file (S12). With these processes, the management process for the will ends. Note that the contents of the will can be changed at any time by the target user as long as the user is alive. In that case, the processes after step S10 may be repeated.

<Flow of processing (after death)>
FIG. 3 is a flowchart showing an overview of an example of the flow of supporting various processes related to inheritance and the like to be performed after the death of the target user. As a premise for performing post-death management processing, it is assumed that the event that the target user (inheritee) has died and inheritance has started has been automatically or manually input to the asset management system 1 .

The inheritance management unit 130 of the asset management server 10 refers to the user DB 151 and extracts users belonging to the close relatives group of the target user (inheritee) as potential targets of asset transfer (S21). Here, only users who allow the decedent to disclose their asset status may be extracted as the target close relatives. The extracted users may be notified that the inheritance has started by e-mail, push notification to the user terminal 30, or the like. After that, the inheritance management unit 130 refers to the asset status DB 152 and determines all the assets (legacy) to be transferred (S22).

After that, the inheritance processing unit 133 refers to the inherited property DB 154, acquires the death-cause donation contract registered by the target user (inheritee) before death, and extracts it in step S21. Output so that close relatives can refer to it (S23). For example, the information is displayed on a screen or printed so that each close relative can refer to it via the user terminal 30 . Similarly, the will management DB 155 is referred to, and if there is a will registered by the decedent, it is acquired and output so that close relatives can refer to it (S24).

The close relatives refer to the contents of the cause-of-death donation and the will output in steps S23 and S24, and discuss the division of inheritance. The inheritance processing unit 133 receives the input of the content of the result of the consultation on inheritance division, and registers the information on who to transfer which assets, how much, and how in the inheritance DB 154 (S25). In addition, in order to contribute to the inheritance division discussion, as described above, the inheritance management unit 130 may, for example, acquire information related to the asset status of the decedent from the asset status DB 152 and output it to close relatives. Further, an input indicating that the heir has made limited acceptance or renounced inheritance may be received and reflected in the automatic processing related to inheritance or the content of information provided to the heir.

It is also desirable to be able to simulate gift tax and inheritance tax. In this case, for example, it is desirable to calculate and present the differences in gift tax and inheritance tax for each of a plurality of inheritance division patterns, with the case of following the statutory inheritance as the default. In designing the inheritance division pattern, the inheritance processing unit 133 takes various data into consideration and optimizes weighting according to predetermined conditions, and also calculates and considers the inheritance portion of each heir. One or more candidate pattern plans may be created and presented.

After that, together with the death-related gifts and bequests that have already been registered by the decedent, finalize the close relatives to whom the decedent's assets will be transferred and the content of the asset transfer to each close relative, Register/update in the inheritance DB 154 (S26, S27). Then, according to an instruction from a close relative or executor, or automatically, the asset transfer section 121 of the asset management section 120 transfers the asset according to the registered contents of the inheritance DB 154 (S28). It is also possible to receive an input about the result of the asset transfer performed outside the system and register it in the transfer history DB 153 . With the transfer, asset management for the target user (inheritee) ends.

As described above, for the asset transfer associated with inheritance, the asset management system 1 itself can execute the process (or request the other external service 40 or the like) to perform the process (individually transferable act), and the asset management There are some actions that cannot be processed by the system 1 itself (acts that cannot be independently transferred). A singly transferable act includes, for example, transferring cash from the decedent's account to one or more heirs' accounts. In addition, acts that cannot be transferred independently include, for example, the transfer of the real estate of the decedent to the heir.

With respect to actions that can be transferred independently, for example, an heir (or a legal representative or voluntary representative of the inheritee, an executor, etc.) uses the user terminal 30 to access the asset management system 1 and input an instruction. , may be executed by the asset management system 1 based on the contents thereof. In addition, for actions that cannot be transferred independently, for example, the content of the action is displayed or printed on the user terminal 30 of the heir (or the legal representative or voluntary representative of the decedent, the executor, etc.) in a guide-like manner. You can Moreover, the input of the processing results performed outside the system may be received and the contents thereof may be displayed or printed.

Further, the configuration may be such that the details of the transfer procedure for the independently transferable act and/or the independently transferable act are output to the outside without distinguishing between the independently transferable act and the solely transferable act. The output destination is the user terminal 30 of the heir (or the decedent's legal representative, voluntary representative, executor, etc.), the user terminal 30 of the target person set by the decedent, the external service 40, etc. There may be. The target person may be, for example, a business such as a bank or a securities company that provides inheritance-related services. In this case, for example, the asset management system 1 of the present embodiment can be configured to provide these business operators with information related to asset details, request estimates of fees and the like, and receive the results of the estimates. In addition, since the fee structure of these businesses that provide inheritance-related services is generally based on multiplying a predetermined fee rate according to the amount of inherited property, such calculations should be performed by the asset management system. 1 may be calculated and output.

<Data structure>
FIG. 4 is a diagram showing an overview of an example of the data configuration of the user DB 151 held by the asset management server 10. As shown in FIG. The user DB 151 is a table that holds information related to users who use the asset management system 1 (including those who can be the decedent to whom the asset is transferred and those who are close relatives who can receive the asset transfer). , a user table 151a and a close relatives group table 151b.

The user table 151a shown in FIG. 4A is a master table that holds account information, attribute information, and the like of each user. , address, occupation, health status, inheritance intention for each inheritee, etc.

The user ID item holds ID information for uniquely identifying the target user. The authentication information holds personal authentication information such as a password and biometric information of the target user. The close relatives group ID holds ID information that uniquely identifies the close relatives group related to the target user. The close relatives group is a group of users who are close relatives of the target user who can be subject to property transfer before and after death from the target user. registered in the person group table 151b.

The name item holds information on the name of the target user. The date of birth, sex, address, occupation, and health status items respectively hold information indicating the date of birth, sex, address, occupation, and health status of the target user as attribute information. Occupation and health status may be designated by code values or the like. These pieces of attribute information can be used as parameters that are weighted and taken into account when the inheritance processing unit 133 creates a pattern candidate for inheritance division, for example. Attribute information is not limited to these items, and items holding attribute information may be added or deleted as appropriate.

In the item of inheritance intention for each decedent, if the target user is a close relative who can receive asset transfer, for each possible decedent, whether or not there is an intention to receive inheritance property transfer as the heir. It holds information such as a code value indicating whether or not This information can be preset by the target user. With this information, it is possible to exclude the target user from consideration when a user who may be the decedent of the target user designs an asset transfer by inheritance or when dividing the inheritance after the user's death. becomes.

The close relatives group table 151b shown in FIG. 4(b) is a table that holds, for each user, information related to the configuration of a close relatives group centering on the user. It has items such as ID, relationship, disclosure approval or disapproval, and memo.

The item of close relatives group ID holds ID information that uniquely identifies each close relatives group. The close relatives group is a group of close relatives such as heirs who can be subject to asset transfer from the target user before or after death. The item of close relative user ID holds information of a user ID specifying a close relative belonging to the target close relative group. The value of this close relative user ID is the value registered in the user ID item of the user table 151a.

The relationship item holds information such as a code value indicating the relationship between the target close relative and the user who will be the inheritee in the target close relative group. The item of disclosure permission/refusal holds information such as a code value indicating whether or not the target close relative permits disclosure of the content of his or her assets to the decedent in the target close relative group. . A close relative who has specified that disclosure is not permitted may be treated as having renounced inheritance from the subject decedent. The item of memo holds the contents of the text specified by the decedent in the target close relatives group in a free form as special notes and precautions for the target close relatives. As a result, it is possible to record the personal and subjective evaluation of the decedent with respect to the subject's close relatives.

FIG. 5 is a diagram showing an overview of an example of the data configuration of the asset status DB 152 held by the asset management server 10. As shown in FIG. The asset status DB 152 is a table that holds information on assets held by each user who uses the asset management system 1 . For example, it has items such as user ID, asset ID, asset name, asset type, information acquisition method, appraisal value, appraisal reference date, co-owned share, and co-owner.

The user ID item holds ID information that identifies a user who owns the target asset. The value of this user ID is the value registered in the user ID item of the user table 151a. It should be noted that the user specified by this item is not limited to only the person who performs the asset transfer (possible inheritee), but includes all persons who receive the asset transfer (possible close relatives). The asset ID item holds ID information that uniquely identifies the target asset. The asset name item holds information on the display name of the target asset. The asset type item retains information such as a code value specifying the type of target asset. For the code value, for example, a value that distinguishes bank deposits, cash, land, buildings, automobiles, precious metals, debts, and the like is set.

The information acquisition method item holds information relating to the acquisition method when information relating to the target asset needs to be acquired from the external service 40 via the external service I/F 140 . For example, it holds information such as the URL (Uniform Resource Locator) of the access destination and the ID and password to be entered at the time of access when acquiring by web scraping. When calling an API, information such as the target API and parameters to be specified is retained. A script, a program, or the like for actually executing the acquisition method that specifies these pieces of information may be specified.

The items "assessment amount" and "assessment reference date" hold information on the result of monetary evaluation and the reference date of monetary evaluation for the target asset, respectively. The co-ownership interest and co-owner items respectively indicate the percentage (or amount) of the co-ownership interest of the target user and the other co-owners, if the target asset is shared with other persons other than the target user. Information to be specified (user ID may be used if the user is a user of the asset management system 1) is retained.

FIG. 6 is a diagram showing an overview of an example of the data configuration of the transfer history DB 153 held by the asset management server 10. As shown in FIG. The transfer history DB 153 is a table that holds information on the asset transfer history of each user who uses the asset management system 1 . For example, it has items such as user ID, asset transfer date, grant/acquisition category, transferred asset ID, transfer amount/ratio, counterparty user ID, reason for asset transfer, and the like.

The user ID item holds ID information that identifies the user who has performed the target asset transfer. The value of this user ID is the value registered in the user ID item of the user table 151a. The asset transfer date item retains information on the date on which the target asset transfer was performed. The grant/acquisition classification item holds information such as a code value that classifies whether the target user has provided or acquired the asset for the target asset transfer. The item of transferred asset ID holds ID information that identifies the transferred asset in the target asset transfer. The value of this transfer asset ID is the value registered in the asset ID item of the asset status DB 152 described above.

The transfer amount/ratio item holds information on the appraisal amount of the transferred assets in the target asset transfer, or the ratio when the assets are indivisible. The counterparty user ID item holds ID information that identifies the counterparty user in the target asset transfer. The value of this user ID is the value registered in the user ID item of the user table 151a. The item of the reason for the asset transfer retains information related to the content of the reason for the target asset transfer and accompanying conditions in the form of texts, code values, and the like. For example, it is possible to record the fact that the gift was given as money for marriage or business, or the details of the burden (for example, the obligation to live together, nursing care, etc.) in the case of a gift with a burden. This can be used as reference information when designing asset formation for close relatives through inheritance.

FIG. 7 is a diagram showing an overview of an example of the data structure of the inheritance DB 154 held by the asset management server 10. As shown in FIG. The inherited property DB 154 is a table that holds information on assets (inherited property) transferred to close relatives by inheritance or the like, with each user using the asset management system 1 as an inheritee. For example, it has items such as user ID, transfer asset ID, transfer target person, transfer amount/ratio, transfer classification, transfer conditions, and transfer status.

The user ID item holds ID information that identifies a user who owns assets related to the target inherited property. The value of this user ID is the value registered in the user ID item of the user table 151a. The item of transferred asset ID holds ID information that identifies the asset related to the target inherited property. The value of this transfer asset ID is the value registered in the asset ID item of the asset status DB 152 described above. The transfer target person item holds information specifying a close relative to whom the target inherited property is to be transferred (or a user ID if the user is a user of the asset management system 1).

The transfer amount/proportion item holds information on the appraisal amount when the assets related to the target inherited property are transferred, or information on the ratio when the assets are indivisible. The item of transfer category holds information such as a code value that distinguishes whether the transfer of the target inherited property is by living gift, death gift, testamentary gift, inheritance by division of inheritance, or the like. In the transfer conditions item, if conditions are attached to the transfer of the target inherited property (for example, the other party's marriage, the purchase of a house, the person's own certification for long-term care, etc.), information related to the content is displayed in text, code values, etc. Hold. The transfer status item holds a code value or the like indicating the transfer status of the target inherited property (for example, untransferred, transferred, etc.).

FIG. 8 is a diagram showing an overview of an example of the data configuration of the will management DB 155 held by the asset management server 10. As shown in FIG. The will management DB 155 is a table that holds information related to the contents of wills made by each user who uses the asset management system 1 . For example, it has items such as user ID, will ID, will date and time, will category, authentication date and time, authentication details, disclosure category, disclosure target person, target asset ID, transfer target person, transfer amount/ratio, transfer conditions, and the like.

The user ID item holds ID information that identifies the user who made the target will. The value of this user ID is the value registered in the user ID item of the user table 151a. The will ID item holds ID information that uniquely identifies the target will. The item of will date and time holds information on the date and time when the target will was created (or registered in the will management DB 155).

The will classification item holds information such as a code value that indicates the classification of the target will (a handwritten will, a notarized will, a secret deed will, other non-statutory wills, etc.). In the case of a statutory handwritten will or a notarized will, it is necessary to write it in your own handwriting or by a notary public, and in the case of a secret deed will, it is necessary to output it as a document. Therefore, the contents of the wills registered in the will management DB 155 represent the contents of these wills or serve as the basis of these wills under the current law. On the other hand, even if it does not meet the format of a will in the narrow sense of the current law, it is possible to use it as a will in a broad sense that takes into account the wishes of the decedent during his/her lifetime, for example, in discussions on the division of inheritance.

The authentication date and time item holds information on the date and time when the user who made the will, a notary public, a witness, etc. confirmed or authenticated the target will. In addition, the authentication details item holds information such as texts and code values that specify the details of the authentication performed for the target will. Authentication is not limited to legal authentication performed outside the system by a notary public, a witness, or the like. As described above, for example, when a user registers the contents of a will in the asset management system 1, the asset management system 1 authenticates that the contents are correct and that the registration was made voluntarily by the user. is also possible. In this case, the authentication content may include, for example, video/audio data recorded by the camera or microphone provided in the user terminal 30, biometric information such as heart rate acquired by a sensor, image data of a handwritten signature, and the like.

The item of disclosure category holds information such as a code value designating whether or not to disclose the target will to other close relatives. In addition, the item of disclosure target person is information specifying the target person to be disclosed (or user ID if the user is a user of the asset management system 1). good). With this information, access control to the will can be performed.

The target asset ID item holds ID information that specifies the asset to be transferred in the target will. The value of this target asset ID is the value registered in the asset ID item of the asset status DB 152 described above. A plurality of assets may be registered. The transferee item holds information (or user ID if the user is a user of the asset management system 1) specifying a close relative or the like to whom the target assets are to be transferred. The transfer amount/proportion item holds information on the amount of assets to be transferred by the subject's will, or information on the ratio when the assets are indivisible. The item of transfer conditions is the text or code that indicates the details of the transfer of the target assets, if conditions are attached (for example, if a bequest requires marriage or the start of a business, etc.). Holds information such as values.

Note that the data configuration (items) of each table shown in FIGS. 4 to 8 above is merely an example, and other table configurations and data configurations can be used as long as the configuration is capable of holding and managing similar data. may be

As described above, according to the asset management system 1 according to the first embodiment of the present invention, not only management of personal financial assets but also various processes related to transfer of assets to close relatives including inheritance can be performed. It is possible to support

Specifically, not only personal financial assets but also real estate, movable property, and other assets that can be transferred by inheritance can be grasped and managed automatically or manually. In addition, the total amount of transferable assets is calculated by estimating the appraised value of these assets in the future (estimated time of death) and by estimating the necessary expenses such as living expenses that will be required by that time through simulations, etc. As a result, it becomes easier for users who may become inheritees to plan the asset formation of their close relatives through asset transfers, and it is also possible to encourage early asset transfers to younger generations. It also facilitates the preparation and management of wills.

Information that makes it easy to grasp the user's assets that can be inherited and the contents of the will even when the user dies and inheritance starts, and that the heirs can easily transfer assets including the division of inheritance. and simulation functions.

(Embodiment 2)
In the asset management system 1 according to the second embodiment of the present invention, when a user who intends to transfer assets by inheritance or the like decides which assets to transfer and how much to which relatives, the user's personal assets In addition, it makes it easier to visually grasp the asset status of the entire relative group, including the asset status of other close relatives, and has a user interface that allows you to specify asset transfers with simple operations. be. Since the basic configuration and operation contents of the asset management system 1 are the same as those of the above-described first embodiment, repetitive explanations will be omitted, and the contents of the user interface and the implementation method thereof will be mainly explained.

<Asset management by balance sheet>
FIG. 9 is a diagram showing an overview of an example of a user interface displayed on user terminal 30 in this embodiment. Here, a smart phone is used as an example of the user terminal 30, and an example of a screen displayed by a client application installed in the smart phone is shown on a touch panel display. In FIG. 9, for the target user, assets that can be managed as a close relatives group including some assets of the target user (relatives/family members) (that is, assets that the target user can rely on, the same This shows an example of displaying the status of assets that can be regarded as

In FIG. 9(a), the asset status of the target user's close relatives group on the reference date specified by the user is displayed in the form of a balance sheet with debits (assets) on the left and credits (liabilities + net assets) on the right. are doing. In the present embodiment, the portion corresponding to net assets is the total transferable assets (“inheritable assets” in the figure). In other words, "inheritable assets" are the sum of the assessed value of the assets currently held ("deposits," "stocks," "real estate," etc. ” plus “future living expenses”).

As shown in Embodiment 1, the total amount of transferable assets (inheritable assets) is obtained by subtracting the total amount of necessary expenses until the user's expected death from the sum of the estimated appraisal values of all assets at the time of the user's expected death. It is what I did. Therefore, for example, the appraisal value of assets such as stocks and real estate is desirably the estimated appraisal value at the time of expected death, but may be simplified to the present appraisal value. In addition, "future living expenses" is the total expected expenditure (living expenses, medical expenses, etc.) by the expected time of death minus the total expected income (salaries, stock dividends, etc.).

Furthermore, in the present embodiment, as shown in FIG. 9A, in addition to the target user's deposit ("deposit (principal)"), the wife's deposit ("deposit ( Assets other than those of the target user, such as a deposit (“deposit (from father)”) given (or given) by the father, etc., are captured and displayed. As a result, the user can determine the necessity of asset transfer by visually grasping the overall and visual status of assets within the close relatives group. It should be noted that not only assets but also liabilities can be taken in other than the target user.

In the screen of FIG. 9(a), for example, if the user changes the date in the "reference date" column to an arbitrary date in the future, as shown in FIG. recalculate and update the balance sheet based on the results of the calculation. As shown in the figure, the amount of items corresponding to assets and liabilities fluctuates over time, but the amount of inheritable assets is basically unchanged.

Further, when the user selects each item of assets on the balance sheet on the screen of FIG. 9A, the screen transitions to a screen for managing the selected assets. FIG. 9(c) shows an example of a stock management screen that is displayed when the user selects the asset of "stocks (principal)" in the example of FIG. 9(a). Via this screen, the user can assign (transfer) the subject property (stock) to the next of kin.

In the example of FIG. 9C, a list of information such as the number of stocks held and the market price is displayed for each brand of stock. In addition, for each brand, the setting contents of the information disclosure range in the group of close relatives are also displayed. Then, the user can allocate the target brand to close relatives via a pop-up screen displayed by pressing the button in the "assignment" column of the target brand. At this time, it is desirable that candidates for close relatives to be assigned can be selected from a pull-down menu or the like as shown in FIG. 9(c), for example. A close relative candidate may be, for example, a user belonging to the close relative group shown in the first embodiment, but in the present embodiment, a more detailed relationship unit is obtained by referring to family tree information as described later. can be specified with

When assets are allocated (transferred) to close relatives, their contents are reflected in the balance sheet as shown in FIG. 9(d). The example of FIG. 9(d) shows that part of the "stock (principal)" has been allocated to the child as assets of the group of close relatives ("stock (to child)"). In this way, the user can easily determine to whom and how much of the assets to transfer while visually grasping the status of the assets in the group of close relatives including the inheritable assets.

<Formation of family tree information>
In this embodiment, the user can transfer assets to close relatives such as relatives. It may or may not be allowed. Conversely, the user may or may not consider each close relative as a candidate for asset transfer. In order to be able to flexibly deal with such circumstances, in the present embodiment, users to whom assets may be transferred are uniformly managed as a close relatives group as in the first embodiment. Family tree information is formed and stored so that it can be managed in more detail on a relationship basis.

FIG. 10 is a diagram outlining an example of a screen for the user to create a family tree. Here, for example, using the technique described in Patent Literature 3, the user can compose the family tree by operations such as dragging and dropping icons on the user terminal 30 . It is also possible to set for each close relative whether or not to make a candidate for asset transfer by gift or inheritance, whether to disclose the asset status to other close relatives, and the like.

FIG. 11 is a diagram showing an overview of an example of a data configuration for forming family tree information to which close relatives subject to asset management belong. Here, examples of assets to be managed include financial assets such as stocks held in securities company accounts and deposits held in bank accounts. Specifically, for example, the user DB 151 in FIG. 1 includes a user table 151a and a close relative table 151c. As tables included in the asset status DB 152, there are an account table 152a, an asset table 152b, an asset attribute table 152c, an asset disclosure table 152d, and an asset allocation table 152e.

The user table 151a is a table having master information of each user, and is generally the same as that shown in FIG. 4A. In the example of FIG. 11, for simplification, it has items of user ID and gender. The user ID holds ID information that uniquely identifies each user. The gender item holds information such as a code value indicating the gender of the target user.

The close relatives table 151c is a table for managing relationships between a pair of users who are close relatives. For example, the relationship ID, first user ID, second user ID, relationship, relationship name, reverse record relationship ID, It has each item such as presence or absence of display. The relationship ID item holds ID information that uniquely identifies each relationship (directed graph indicating the relationship between users).

The item of the first user ID holds information of the user ID of a person (for example, “principal”) corresponding to the original node in the directed graph of the target relationship. The item of the second user ID holds the information of the user ID of the person (for example, "wife", "child A", etc.) corresponding to the previous node in the directed graph of the target relationship. The relationship item holds information on a directed graph indicating the relationship of the object. For example, it holds information indicating "couple", "parent and child", etc. when viewed from the user corresponding to the item of the first user ID. The family tree may be represented by a vector or the like on the xy coordinate plane. In this case, the same generation is represented in the x-axis direction, and the upper and lower generations are represented in the y-axis direction. The relationship name item holds information on the display name of the target relationship (“wife”, “child A”, etc.). These pieces of information can be set by, for example, a family tree creation method using the technique described in Patent Document 3.

The reverse record relationship ID item holds information about the relationship ID of the record of the reverse relationship with respect to the directed graph of the target relationship. The display presence/absence item holds information such as a flag and a code value indicating whether or not to display connections related to the target relationship when displaying the family tree. These items are information used for control in processing related to formation of a family tree, which will be described later.

The account table 152a is a table that holds master information of accounts of securities companies and the like that hold stocks that are assets to be managed, and has items such as account IDs and user IDs, for example. The account ID item holds ID information that uniquely identifies the target account. The user ID item holds information on the user ID of the user who holds the target account. The account information is registered by the user using the user terminal 30 .

The asset table 152b is a table that holds information related to assets to be managed, and has items such as asset ID, account ID, brand code, quantity, and asset attribute ID, for example. The asset ID item holds ID information that uniquely identifies the target asset. The account ID item holds account ID information related to the account in which the target asset is held. The item of stock code holds the information of the stock code of the stock that is the target asset. The quantity item holds information on the number of stocks held, which is the target asset. The values of these items can be acquired by, for example, calling an API provided by the website or system of the financial institution through the external service I/F 140 in FIG. The asset attribute ID item retains information of an asset attribute ID related to attributes such as the type of the target asset. This value is registered in an asset attribute table 152c, which will be described later.

The asset attribute table 152c is a table that holds master information related to attributes such as asset types, and has items such as asset attribute IDs and asset attribute names, for example. The asset attribute ID item holds ID information that uniquely identifies the target attribute. The asset attribute name item holds information on the display name of the target attribute. Attributes include, for example, "deposits" and "stocks".

The asset disclosure table 152d is a table that holds information to the effect that information relating to a specific asset is to be disclosed (or not) in a certain relationship, and has, for example, items of asset ID and relationship ID. The asset ID item retains information of an asset ID that identifies an asset to be disclosed (or not disclosed). The item of relationship ID holds information of a relationship ID specifying a relationship to disclose (or not to disclose) the target asset. It is also possible to specify not by relationship but by user to whom disclosure is to be made. The designation to disclose (or not to disclose) is registered by the user using the user terminal 30 and using the screen shown in FIG.

The asset allocation table 152e is a table that holds information related to the details when a specific asset is allocated between users related to a certain relationship. have. The asset ID item holds information of an asset ID that identifies an assigned asset. The item of relationship ID holds information of a relationship ID that specifies a relationship to which asset allocation has been performed. It may be a user ID that identifies a user to whom the assignment is made instead of a relationship. The item of quantity holds information on the quantity of assigned assets. The values of these items are registered by the user using the user terminal 30 and using the screen shown in FIG.

12 and 13 are diagrams outlining an example of the flow of processing for forming family tree information based on information on close relatives. Here, using the user interface shown in FIG. 10, close relative registration information (family tree information) that has already been registered by other close relative users is used to form family tree information related to the person himself/herself. shows an example.

In the family tree formation process, first, a record in which the user (X) is already set as the second user ID (the user at the end of the digraph) is extracted from the close relatives table 151c shown in FIG. 11 (S31 ). On the right side of FIG. 12, as specific examples, records related to directed graphs of spouse (B)→person (X), parent (C)→person (X), and child (A)→person (X) are extracted. This indicates that the The arrows and the x, -x and y, -y symbols in the figure indicate the directed graph with vectors when the family tree is on the xy coordinate plane, and between the same generation is x (right direction in the figure) , -x (left direction in the figure), y (upward direction in the figure) to the upper generation, and -y (downward direction in the figure) to the lower generation.

Next, for each record extracted in step S31, after reversing the relationship, a record with the person (X) as the first user ID is created (S32). In the example of FIG. 12, new records are added for each directed graph of person (X)→spouse (B), person (X)→parent (C), and person (X)→child (A). At this time, the value of the item "reverse record relationship ID" in the record to be added is added as the relationship ID of each record extracted in step S31. Also, the value of the item "reverse record relationship ID" in the original record extracted in step S31 is updated to the relationship ID of the corresponding record to be added in step S32.

After that, for the relationships (directed graph) related to each record created in step S32, the user (X) determines whether or not to display the connections related to the target relationships when displaying the family tree. , through the user terminal 30 (S33). At this time, for example, provisional family tree information related to the record created in step S32 is displayed on the user terminal 30 so that the user can give instructions to it.

After that, contrary to step S31, the second user IDs of records in which the person (X) is set as the first user ID are extracted from the close relatives table 151c (S34). In the example of FIG. 12, spouse (B), parent (C), and child (A) are extracted. Then, a record in which the extracted second user ID is set as the first user ID (original user of the digraph) is extracted (S35). At this time, those for which the person (X) is set as the second user ID are excluded. In the example of FIG. 12, dotted arrows indicate digraphs related to records in which spouse (B), parent (C), and child (A) are set as the first user IDs. Parent (C) -> Grandfather (D), Spouse (B) -> Parent (E), and Spouse (B) -> Child (A) for whom the person (X) is not set as the second user ID. Only each directed graph (the one surrounded by the solid line frame in the drawing) is extracted.

Moving on to FIG. 13, next, the second user ID of the record extracted in step S35 is compared with the second user ID extracted in step S34 to extract non-overlapping IDs (S36). At this time, if there is no unique user ID (S37: No), the family tree formation process is terminated. In the example of FIGS. 12 and 13, the second user IDs of the record extracted in step S35, namely grandfather (D), parent (E), and child (A), and the second user ID extracted in step S34 are Comparing spouse (B), parent (C), and child (A), grandfather (D) and parent (E) are extracted as non-duplicates. Therefore, the family tree formation process does not end.

If a unique user ID is extracted in step S36 (S37: Yes), the user ID is set as the second user ID, and the information of the relationship (directed graph) related to the record with the person (X) as the first user is stored. It is displayed on the family tree (S38). At this time, if the target record does not exist, it is created and then displayed. Then, the user who is the person (X) decides whether or not to actually display the displayed relationship in the family tree, and inputs it via the user terminal 30 (S39). In the example of FIG. 13, the relationship of the person (X)→grandfather (D) and the person (X)→parent (E) are newly displayed in step S38, and the relationship of the person (X)→parent (E) is displayed in step S39. indicates that the decision to hide has been made.

After that, the process returns to step S34 in FIG. 12 and repeats a series of processes until no duplicate IDs are extracted in step S37. Through the above-described processing, it is possible to easily form family tree information relating to the user by using close relative registration information (family tree information) that has already been registered by a user of another close relative.

FIG. 14 is a diagram showing an overview of an example of the flow of processing for displaying a balance sheet as a group of close relatives as shown in FIG. 9 based on family tree information. When the process starts, first, from the close relatives table 151c, the relationship ID of the record in which the person himself/herself is set as the first user ID or the second user ID is extracted (S41). Then, the asset ID of the record in which the relationship ID extracted in step S41 is set is extracted from the asset allocation table 152e (S42). In the asset allocation table 152e, when the allocation is set by the user ID instead of the relationship ID, the record in which the user ID of the principal is set is targeted.

On the other hand, from the close relatives table 151c, the relationship ID of the record in which the person himself/herself is set as the second user ID is extracted (S43). Then, the asset ID of the record in which the relationship ID extracted in step S43 is set is extracted from the asset disclosure table 152d (S44). In the asset disclosure table 152d, when disclosure is set by a user ID instead of a relationship ID, records in which the user's user ID is set are targeted.

After that, the asset attribute ID and brand code of the record in which the asset ID extracted in steps S42 and S44 is set are extracted from the asset table 152b (S45). Then, the asset attribute name of the record in which the asset attribute ID extracted in step S45 is set is obtained from the asset attribute table 152c (S46). In addition, market price information is acquired from the external service 40 via the external service I/F 140 using the issue code extracted in step S45 as a key (S47).

Thereafter, the market price acquired in step S47 is totaled for each asset attribute ID extracted in step S45 and each relationship ID extracted in steps S41 and S43. Then, it is displayed on the user terminal 30 together with the asset attribute name acquired in step S46 in the form of a balance sheet or the like showing the percentage of the total amount (S48). Furthermore, the relationship name corresponding to the relationship ID is also displayed on the user terminal 30 by the following series of processes, and the process ends.

Specifically, it is determined whether or not the target asset is related to the relationship ID of the record in which the person himself/herself is set as the first user ID in the close relatives table 151c (S49). Then, if the person is not set as the first user ID, but is related to the relationship ID of the record set as the second user ID (S49: No), from the close relatives table 151c, the relationship A record whose ID is set to the backward record relationship ID is specified, and the value of the relationship ID of that record is acquired (S50).

After that, in step S49, if the person is associated with the relationship ID of the record set as the first user ID (S49: Yes), the relationship ID is set as the target relationship ID, and the person is the second user ID. (S49: No), the relationship ID obtained in step S50 is set as the target relationship ID. Then, the value of the relationship name of the record in which the target relationship ID is set is acquired from the close relatives table 151c and displayed on the user terminal 30 (S51).

As described above, according to the asset management system 1 according to the second embodiment of the present invention, a user who intends to transfer assets by inheritance or the like decides which assets to transfer and how much to which close relatives. In addition to making it easier to visually grasp the asset status of the entire close family group, including the asset status of other close relatives, as well as the user's individual assets as a balance sheet, the asset transfer can be performed with a simple operation. It is possible to realize a user interface that allows specification of

In addition, it is possible to easily form family tree information for specifying a group of close relatives and manage assets as a group of close relatives based on this information.

Although the invention made by the present inventor has been specifically described above based on the embodiments, the present invention is not limited to the above embodiments, and can be variously modified without departing from the scope of the invention. Needless to say. For example, the above embodiments have been described in detail in order to explain the present invention in an easy-to-understand manner, and are not necessarily limited to those having all the described configurations. Also, part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. . Moreover, it is possible to add, delete, or replace a part of the configuration of each embodiment with another configuration.

For example, in the asset management system 1 according to Embodiments 1 and 2 of the present invention described above, the target is a mechanism or service for individual asset management, but the present invention is not limited to this. For example, the asset management system 1 may have a function of providing information related to personal asset management held by the asset management system 1 to an external third party or the like in a format in which the target user is not specified. A configuration may also be adopted in which a third party who receives the provision can provide some sort of marketing service to the target user via the asset management system 1 . In this case, in order to provide the information related to asset management to the third party, it is preferable to obtain the prior consent/approval from the target user.

Further, each of the above configurations, functions, processing units, processing means, and the like may be realized by hardware, for example, by designing a part or all of them using an integrated circuit. Moreover, each of the above configurations, functions, etc. may be realized by software by a processor interpreting and executing a program for realizing each function. Information such as programs, tables, and files that implement each function can be stored in recording devices such as memories, hard disks, SSDs (Solid State Drives), or recording media such as IC cards, SD cards, and DVDs.

Further, in each of the above drawings, control lines and information lines are those considered to be necessary for explanation, and not all control lines and information lines for implementation are necessarily shown. In fact, it may be considered that almost all configurations are interconnected.

INDUSTRIAL APPLICABILITY The present invention can be used in an asset management system that supports various processes related to asset transfer such as inheritance performed by a potential decedent.

1... asset management system,
10... asset management server, 20... network, 30... user terminal, 40... external service,
110 User management unit 120 Asset management unit 121 Asset transfer unit 122 Asset evaluation unit 123 Prediction processing unit 130 Inheritance management unit 131 Gift management unit 132 Will management unit 133 Inheritance processing unit 140 External service I/F 151 User DB 151a User table 151b Close family group table 152 Asset status DB 153 Transfer history DB 154 Inherited property DB 155 Will Management database

Claims (5)

An asset management system that supports management of assets owned by a user connected via a network using a user terminal,
Assets that record information related to assets held by the user in the asset status recording unit, perform processing related to the transfer of assets between the user and other users, and record the details in the transfer history recording unit. management department and
an inheritance management unit that performs processing related to transfer of at least a portion of assets held by the user, including at least financial assets, before the user is alive or after death ;
The inheritance management department further
a will management unit that receives registration of contents of a will from the first user before the death of the first user and records the contents in a will management information recording unit;
after the death of the first user, outputting the contents of the will of the first user recorded in the will management information recording unit so as to be referable to a second user within a predetermined range; and information on who transfers which assets, how much, and how, as information relating to the transfer of the assets owned by the first user to the second user. an inheritance processing unit that records in the recording unit;
The asset management system, wherein the asset management unit performs processing related to asset transfer based on the information recorded in the inherited property recording unit. In the asset management system according to claim 1,
The asset management unit calculates a first result of predicting the total valuation amount of assets held by the first user at the expected death time and the total amount of funds required by the first user until the expected death time. An asset management system that calculates a total transferable asset amount based on a difference from the predicted second result, and outputs the total amount to the first user. In the asset management system according to claim 2,
The asset management unit creates balance sheet information based on information relating to the first result, the second result, and the total transferable assets of the first user, An asset management system that outputs to one user. In the asset management system according to claim 2,
The asset management unit includes information on assets and/or required funds of other third users within a predetermined range in the assets owned and/or required funds of the first user. , asset management system. In the asset management system according to claim 1,
The asset management unit provides the first user with information on assets held by the second user, regarding the second user to whom assets may be transferred by inheritance from the first user. An asset management system that allows the first user to refer to information related to assets held by the second user only when disclosure is permitted.

Images