JP7547528B2 - Asset Management Systems - Google Patents

Description

The present invention relates to a technology for asset management, and in particular to a technology that is effective when applied to an asset management system that supports various processes related to asset transfers, such as inheritance, carried out by potential decedents.

As IT technology advances, systems have been proposed for managing personal financial situations, such as creating and managing a user's household accounting book and managing bank account information. In recent years, systems have also been proposed that allow users to easily collect and view information using their own mobile devices, such as smartphones.

For example, Japanese Patent Application Laid-Open No. 2001-306798 (Patent Document 1) describes technology relating to a household accounting data creation system that collects income and expenditure information, including debit card transaction information and financial institution account information, from a host computer and generates household accounting data for a household based on this information.

In addition, Japanese Patent Laid-Open Publication No. 2005-38130 (Patent Document 2) describes a technology in which an aggregation website acquires and consolidates deposit and withdrawal details from multiple financial institutions, making it easy to import the deposit and withdrawal details into a household accounting application all at once.

Money Forward (registered trademark, non-patent document 1), a household accounting application, works in conjunction with Internet services provided by multiple financial institutions such as banks, securities companies, and credit card companies, and can obtain information related to multiple accounts held by the user to automatically create a household accounting book and check the status of assets.

On the other hand, for example, Japanese Patent Application Laid-Open No. 2015-132882 (Patent Document 3) describes a technology that improves operability when creating a family tree to be used when calculating inheritance tax by accepting input from the user of icons of potential legal heirs, the placement of additional icons, and input of information on spouses and children.

JP 2001-306798 A JP 2005-38130 A JP 2015-132882 A

"Fully automated household accounting book Money Forward", [online], Money Forward, Inc., [searched June 14, 2016], Internet <URL: https://moneyforward.com/>

Conventional technology makes it possible to grasp, create, and manage financial assets that are primarily needed by individuals to live their daily lives now and in the future. However, conventional technology only manages the financial assets of the individual. Therefore, no consideration is given at all to asset management within a certain group of close relatives or kin, such as the distribution of surplus assets to close relatives of the individual, mainly through inheritance, or the asset creation of these individuals.

The object of the present invention is to provide an asset management system that not only manages an individual's financial assets, but also supports various processes related to the 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 this specification and the accompanying drawings.

The following is a brief summary of the representative inventions disclosed in this application.

The asset management system according to a representative embodiment of the present invention is an asset management system that supports the management of assets owned by a user who connects via a network using a user terminal, and has an asset management unit that records information related to the assets owned by the user in an asset status recording unit, and also processes the transfer of assets between the user and other users and records the details of the transfer in a transfer history recording unit, and an inheritance management unit that processes the transfer of at least a portion of the assets owned by the user during or after the user's lifetime.

The inheritance management unit further includes a gift management unit that receives registration of the contents of gifts made during the first user's lifetime or gifts causa de novo to other second users within a predetermined range during the first user's lifetime and records the contents in the inheritance property record unit, a will management unit that receives registration of the contents of a will from the first user during the first user's lifetime and records the contents in the will management information record unit, and an inheritance processing unit that makes the contents of the will of the first user recorded in the will management information record unit accessible to second users within a predetermined range after the death of the first user, receives information related to the transfer of assets held by the first user to the second user and records the contents in the inheritance property record unit, and when the contents related to the transfer of assets recorded in the inheritance property record unit satisfy the conditions for transfer, the asset management unit performs processing related to the transfer of the assets.

The effects achieved by the representative inventions disclosed in this application can be briefly explained as follows:

In other words, a representative embodiment of the present invention will not only enable management of an individual's financial assets, but will also be able to assist with various processes related to the transfer of assets to close relatives, including inheritance.

1 is a diagram showing an overview of a configuration example of an asset management system according to a first embodiment of the present invention; 1 is a flowchart outlining an example of a flow for supporting various processes relating to inheritance and the like carried out by a target user during his or her lifetime in embodiment 1 of the present invention. 11 is a flowchart outlining an example of a flow for supporting various processes relating to inheritance, etc., carried out after the death of a target user in embodiment 1 of the present invention. 3A and 3B are diagrams outlining an example of a data structure of a user DB in the first embodiment of the present invention. 1 is a diagram showing an overview of an example of a data configuration of an asset status DB in the first embodiment of the present invention. FIG. FIG. 2 is a diagram showing an overview of an example of the data configuration of a transfer history DB in the first embodiment of the present invention. 1 is a diagram showing an overview of an example of the data structure of an inheritance property DB in embodiment 1 of the present invention. FIG. A diagram showing an overview of an example of the data structure of a will management DB in embodiment 1 of the present invention. 13A to 13D are diagrams outlining examples of user interfaces displayed on a user terminal in accordance with a second embodiment of the present invention. FIG. 11 is a diagram outlining an example of a screen on which a user creates a family tree in accordance with a second embodiment of the present invention. A diagram showing an overview of an example of a data structure for forming family tree information to which close relatives who are the subject of asset management belong in embodiment 2 of the present invention. A diagram outlining an example of the process flow for forming family tree information based on information on close relatives in embodiment 2 of the present invention. A diagram outlining an example of the process flow for forming family tree information based on information on close relatives in embodiment 2 of the present invention. FIG. 13 is a diagram outlining an example of a process flow for displaying a balance sheet for a group of close relatives based on family tree information in accordance with the second embodiment of the present invention.

The following describes in detail an embodiment of the present invention with reference to the drawings. In all the drawings used to explain the embodiment, the same parts are generally given the same reference numerals, and repeated explanations will be omitted. However, there are cases where a part that has been described with a reference numeral in one drawing will be referred to with the same reference numeral when explaining other drawings, although it will not be shown again.

(Embodiment 1)
<System Configuration>
1 is a diagram showing an overview of a configuration example of an asset management system according to a first embodiment of the present invention. The asset management system 1 is configured by an asset management server implemented in, for example, a server device or a virtual server constructed on a cloud computing service. 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 that has the function of supporting various processes related to asset management for each of multiple users and transfer of assets to close relatives, including inheritance, via user terminals 30. Here, the various processes related to asset transfer include not only the transfer of assets to heirs as inheritance, but also systems that allow assets to be transferred to people other than heirs, such as gifts made during one's lifetime, gifts causa mortis, and specific bequests. Below, these asset transfers may be broadly referred to as "inheritance." Furthermore, from the perspective of a potential heir, (presumptive) heirs and people other than heirs who may receive assets may be collectively referred to as "close relatives."

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

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 due to inheritance, etc. Specifically, the user management unit 110 registers account information registered by users via the user terminal 30 in the user DB 151, and also accepts requests for reference, modification, etc., and performs the corresponding processing on the user DB 151. In this embodiment, it is desirable to know as much as possible about not only those who may become heirs, but also about close relatives to whom assets are transferred from these people. Therefore, in this embodiment, it is assumed that account information is registered for close relatives, including presumed heirs, and assets can be managed by the asset management system 1 as a user. Information about close relatives from the perspective of a certain user can be managed, for example, by forming a group of close relatives centered on the target user.

The asset management unit 120 provides various functions that help the user understand and manage the status of assets held by the user. For example, similar to the functions of a general asset management/household accounting application such as the prior art, the status of various assets such as financial assets is acquired and collected, and registered in the asset status DB 152. In addition, this information is appropriately processed and aggregated, etc., so that it can be viewed via the user terminal 30. The user may be able to specify access control such as whether or not to disclose this information so that it can be viewed by other users other than the user (parents, spouse, siblings, close relatives who may be the deceased or heirs of the user, etc.). Access control may include, for example, specification of whether or not to refuse only the system from accessing the information in inheritance-related processing when refusing disclosure to other users, and specification of the content and scope of disclosure to other users.

In the above, the asset management function is described as being similar to the functions of a general asset management/household accounting application, but this is merely an example, and any form that can provide the asset management function may be used. For example, it may be similar to the functions of a banking application or a securities application for individuals. Furthermore, the functions of the asset management unit 120 in the asset management system 1 of this embodiment may be incorporated into these applications themselves, or even into an SNS (Social Networking Service) or a portal site mail system, or may be configured to provide the asset management function of this embodiment in cooperation with these services.

The assets whose status is acquired and managed are not limited to financial assets such as savings, stocks, pensions, and life insurance, as in general asset management and household accounting applications, but also include movable assets with high asset value, such as real estate, automobiles, ships, and precious metals. In addition, debts and liabilities such as mortgages and business loans are also tracked and managed as negative assets. Identification of these assets that may be subject to inheritance and understanding of their asset status are automatically acquired via an external service interface (I/F) 140 from information processing systems and websites (shown as external services 40 in the figure) that are published and provided to the outside by financial institutions such as banks and various other businesses.

For example, periodically or whenever instructed, information on the user's assets is extracted and collected from the website of the external service 40 using so-called web scraping technology. Information may be extracted and collected by calling an API (Application Programming Interface) that the information processing system of the external service 40 makes public. The automatically acquired and collected assets may be presented to the user via the user terminal 30 as candidates, and the user may select the assets to be managed from the candidates. In addition, the user may manually input assets that could not be automatically identified. This makes it possible to identify, for example, information on financial assets held at financial institutions. 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 also possible to identify the existence of real estate or movable assets that may be subject to management, for example, from information such as the destination and amount.

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

The asset transfer unit 121 performs processing related to the actual transfer of assets from the deceased user to close relatives. 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 registered accounts. Asset transfers can occur either during the target user's lifetime or after death. During the target user's lifetime, in addition to asset transfers as an advance on inheritance, such as gifts of real estate, etc., asset transfers that are not inheritance but may be taken into consideration at the time of actual inheritance, such as assistance with business funds, wedding funds, and home purchase funds, may occur. In addition, after the target user's death, asset transfers can occur as the execution of the inheritance details confirmed 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 relative's account on the asset status DB 152, for example. For example, when the asset transfer unit 121 automatically determines an asset transfer or when an asset transfer is instructed by the user, the asset transfer unit 121 may use the external service I/F 140 to reflect the content of the asset transfer in an external service 40 such as a financial institution, based on the content of the transfer. For example, money transfer between bank accounts, transfer of real estate registration (or change of name of registered movable property), etc. can be performed.

For asset transfers that are actually performed outside the system, such as the transfer of money or movable property, the results of the asset transfer may be input from the user, and the details may be reflected in the asset status DB 152, etc. The details of the asset transfers that have been performed (particularly those performed during the user's lifetime) are recorded in the transfer history DB 153 along with the reason for the transfer (e.g., "wedding funds" or "business funds"). In addition, scanned data of documents generated when the asset transfer was actually performed, such as contracts and documents for transfer of registration, may be recorded as evidentiary data. By referring to these records after the death of the target user, unnecessary disputes regarding the transfer of assets during the user's lifetime can be prevented.

The asset evaluation unit 122 has a function of performing monetary evaluation of assets other than money when registering assets in the asset status DB 152 or transferring assets by the asset transfer unit 121. For example, it can access an external service 40 that provides a service for evaluating the current and future value of financial assets via the external service I/F 140 and obtain the evaluation results. It can also access an external service 40 that provides a secondhand market for real estate and movable property and perform monetary evaluation from the market price for the same property or product. It can also output the current asset contents to a data file, a PDF (Portable Document Format) file, etc., and send it by email to an expert for evaluation.

The prediction processing unit 123 has a function of predicting the necessary expenses such as living expenses that will be required by the time the target user is expected to die by simulation or the like. For example, as the simplest prediction model, the remaining lifespan can be calculated from the target user's current age and average lifespan by gender, and the current necessary expenses per unit period can be multiplied assuming that they will continue for the remaining lifespan, and then multiplied by the desired margin rate. In addition, corrections can be made in consideration of, for example, salary income until retirement, pension income thereafter, financial income, medical expenses, housing expenses, education expenses, and other future predictions of income and expenses due to changes in living environment, as well as the characteristics of the residential area. For this correction, for example, a predetermined model may be automatically applied, or the user may directly specify and input the model, predicted values, etc. External experts may be contacted via the external service I/F 140.

The prediction processing unit 123 also calculates the estimated valuation of each of the assets held at the expected time of death. Again, this may be calculated by automatically applying a predetermined model, or the user may directly specify/input the estimated valuation. An external expert may also be consulted via the external service I/F 140. The total amount of assets that can be transferred to next of kin through inheritance is assumed to be the sum of the estimated 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 use this total amount of transferable assets as a reference when designing and managing asset transfers through inheritance, etc.

The inheritance management unit 130 provides various functions that contribute to the design, management, and execution of asset transfers through inheritance for the target user's assets. In other words, during the target user's lifetime, for example, it supports the design, management, and execution of asset transfers using gifts made by the user during their lifetime within the range of the total amount of transferable assets predicted by the asset management unit 120. It also supports the design of asset transfers through the creation of a will, and the management of the will. After the target user's death, it supports the understanding and management of the inheritance and will by the heirs and executors, as well as the design, management, and execution of asset transfers through wills or estate division.

To realize the above functions, the inheritance management unit 130 further includes a gift management unit 131, a will management unit 132, an inheritance processing unit 133, and other units.

The gift management unit 131 has a function to register and manage assets that are the subject of asset transfer by gift to a close relative. For example, in response to an instruction from the target user via the user terminal 30, the unit 131 identifies the assets that have become the subject of gift due to the establishment of a contract for gift during life or gift causa mortis among the assets registered in the asset status DB 152 and their contents, and registers them in the inheritance property DB 154. Note that in this embodiment, gifts include gifts with encumbrances as well as gifts without encumbrances. It also includes cases where all or part of the assets are loaned at low or no interest.

In the case of a gift made during one's lifetime, the assets of the target are donated to the target's next of kin via the asset transfer section 121 of the asset management section 120, triggered by an instruction from the target user or the fulfillment of a specified condition. In the case of a gift made posthumously, the assets of the target are donated to the target's next of kin via the asset transfer section 121 of the asset management section 120, triggered by the death of the target user or the fulfillment of a specified condition after the death. When the fulfillment of a specified condition is triggered, whether during one's lifetime or after death, if the condition can be automatically detected by the asset management system 1 depending on the content of the condition, the asset transfer section 121 can automatically perform a gift or other process when the condition is detected. In the case of a condition that cannot be automatically detected, the user who detects that the condition has been fulfilled may input that fact via the user terminal 30 to detect the fulfillment.

In this embodiment, it is desirable to have a function for simulating gift and inheritance taxes, as reference information to assist the user in making decisions such as which assets to donate to whom and how much, and whether it is better to donate during one's lifetime, or to make a posthumous gift or bequest. The gift management unit 131 itself may directly have a means for calculating the gift and inheritance taxes for specified assets. Alternatively, the configuration may be such that an external service 40 that provides a simulation service is accessed via the external service I/F 140, and the simulation results are obtained.

In addition to simulating gift tax and inheritance tax, the system may also have a function to evaluate and determine the amount of asset transfer by gift, etc., and the appropriateness of the recipient's close relative. For example, even if the gift is within the total amount of transferable assets, the gift may be unnecessary or excessive depending on the asset situation of the recipient's close relative. Also, even if the asset situation of the recipient's close relative requires a gift from the target user, the circumstances that led to such a situation may be due to unplanned wasteful spending, making the gift inappropriate.

When a user who is about to transfer assets evaluates and judges the appropriateness of such transfer, if the other party (close relative) allows disclosure of their asset status, the target user can make a certain degree of independent judgment by referring to the asset status of the other party (close relative). On the other hand, even if the target user is able to refer to the asset status of the other party (close relative), it may be difficult to judge the appropriateness objectively depending on the target user's knowledge, etc. In addition, if some or all of the users in the close relative group, including the other party (close relative), refuse to disclose their asset status and it is not possible to refer to their asset status, it may be difficult to judge the appropriateness of transferring assets to the close relative and whether there are other more appropriate recipients.

In this embodiment, even if another close relative user belonging to the close relative group does not permit the disclosure of his/her asset status, the gift management unit 131 etc. may systematically refer to the asset status DB 152, transfer history DB 153 etc. to make a comprehensive judgment on the current asset status and past asset transfer history of the other close relative user. Then, the appropriateness of the asset transfer to the close relative may be evaluated and determined, and the result may be presented to the target user as an opinion or advice.

In a simple model, for example, if the other party, a close relative, is planning to purchase a house or the like, the amount needed can be evaluated based on the difference between the planned expenditure and the value of the current assets, and it can be determined that a gift greater than the needed amount is unnecessary (or should be reduced). Also, if the other party, a close relative, currently has a small amount of assets, an analysis of the consumption behavior history, such as that performed in general household accounting analysis services, can be performed, and if it is determined that there is a lot of unnecessary waste, it can be determined that a gift is unnecessary (or should be reduced).

The target user may actively access the asset management system 1 to consider the appropriateness of the asset transfer as described above. Alternatively, the asset management system 1 may detect a situation in which a close relative explicitly or implicitly wishes to transfer assets, and may notify the target user to prompt the user to consider the matter, which may then be used as an opportunity for the target user to make a decision.

The situation in which a close relative wishes to transfer assets may be detected, for example, by the close relative accessing the asset management system 1 and inputting that the close relative needs funds for purchasing a house or starting a business, and the asset management system 1 detects this. When the close relative inputs that he or she needs funds, one or more users (for example, users who may be his or her heirs) who are candidates for the request may be specified. In this case, the close relative may be able to refer to the asset status of the users who may be his or her heirs. Rather than being based on input or instructions from the close relative, for example, the asset management unit 120 may detect that the close relative has conducted bank transactions related to the purchase of a house or various simulations, and automatically determine that the close relative needs funds.

The will management unit 132 has a function of supporting the creation and management of a will during the user's lifetime. The target user can refer to the total amount of transferable assets predicted by the asset management unit 120 and the details of each asset recorded in the asset status DB 152 via the user terminal 30, decide which assets to transfer and to whom, and how much, and register it as a will. When the user creates a will, it may be possible to use a gift tax/inheritance tax simulation function such as that of the gift management unit 131 described above, and a function for evaluating the appropriateness of individual asset transfers.

For example, it is desirable to calculate and present the difference in gift tax and inheritance tax for multiple asset transfer patterns, with the default being the case where the will follows legal inheritance shares. For example, in addition to comparing asset transfer patterns set by the user, it is also possible to compare these with the default asset transfer pattern when following legal inheritance shares. When the user sets an asset transfer pattern of their own volition, for example, the user can modify the default asset transfer pattern based on the default asset transfer pattern that follows legal inheritance shares.

In addition, when designing a pattern for asset transfer, the will management unit 132 may take into consideration various data and optimize the pattern by weighting or other factors according to predetermined conditions, while calculating and taking into account the reserved share of each presumptive heir, and create and present one or more candidate pattern proposals. In addition, the content of the asset transfer may be gradually improved by accepting modifications from the target user based on the selected candidate pattern and presenting recalculated gift tax and inheritance tax in response to the modifications.

Data to be taken into consideration may include, for example, the amount and timing of asset transfers between the target user and each close relative during the user's lifetime, as well as the reasons for such transfers, the amount and type of assets currently held by each close relative, and information such as the age, family structure, occupation, and place of residence of each close relative. By registering information on whether the target user lives together with the user or is providing care, this information can also be taken into consideration (for example, preferentially transferring the current real estate to a close relative who lives together). It is also possible to output the target user's asset content to a data file, PDF file, etc., and send it by email to an expert to receive advice.

In addition, the relatives who are eligible for asset transfer, including the above-mentioned gifts, may be limited to those who have disclosed their asset status to the target user (in other words, relatives who do not disclose their asset status may be treated the same as those who have renounced inheritance, for example).

The registered will is recorded in the will management DB 155. Furthermore, the user can change the contents of the will registered in the will management DB 155 at any time while alive. The contents of the registered will may be freely accessible to close relatives, or access control may be implemented so that the contents cannot be accessed by at least some close relatives as they are kept secret. In this case, for example, it is possible to individually set who will be disclosed and to what extent, and to register the contents together in the will management DB 155. Some or all close relatives who are presumptive heirs may be able to access the entire contents of the will, or may be able to access only the contents related to the entire inheritance. Each presumptive heir may be restricted to only being able to access the parts related to their own inheritance.

In addition, a means may be provided that allows the target user to prove that they have voluntarily registered the contents of their will based on their own free will when registering the contents of their will. For example, as authentication information to prove free will, the image and voice of the person at the time of entering the will may be recorded using a camera or microphone (not shown) equipped in the user terminal 30, and the data may be registered in the will management DB 155 together with the contents of the will. In addition, biometric information that can infer the mental state at the time of the will, such as heart rate, may be obtained using a sensor (not shown) and registered. In addition, image data of a handwritten signature may be obtained by handwriting input on a touch panel equipped in the user terminal 30 or by taking a picture with a camera, and registered. In addition, it may be possible to register identification information of witnesses and witnesses.

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

The inheritance processing unit 133 has a function of supporting the inheritance-related processing by the heir or executor after the death of the target user. The death of the target user, which is the trigger for the start of the 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 it by automatically acquiring information from the systems of government offices, medical institutions, nursing facilities, etc. via the external service I/F 140.

If the will of the target user is registered in the will management DB 155, the asset transfer may be automatically performed in accordance with the contents of the will via the asset transfer unit 121 of the asset management unit 120, for example. Alternatively, the contents of the will may be made available to the heirs, etc., and the asset transfer may be performed manually outside the system, with only the results being accepted as input and recorded as history in the transfer history DB 153, etc.

In addition, if all or part of the target user's assets have not been designated in a will (if the will has not been registered), the system may accept input of the results of estate division negotiations, etc. from the heirs, etc., and automatically transfer assets in accordance with the contents of those inputs. Alternatively, the system may accept input only of the results of asset transfers that have been manually performed outside the system based on the results of estate division negotiations, etc., and record the results as history in the transfer history DB153, etc.

In addition, as information that helps the heirs to hold inheritance division negotiations, for example, information related to the asset status of the target user (deceased) may be obtained from asset status DB152 and presented. Also, input that the heir has made a limited acceptance or renounced the inheritance may be accepted and reflected in the automatic processing related to the inheritance or in the content of the information provided to the heirs. Furthermore, as a prerequisite for holding inheritance division negotiations, close relatives may be notified that the inheritance has begun due to the death of the target user, and that inheritance division negotiations should be held.

In addition, in order to provide reference information that will help the heirs decide which assets to allocate to whom and in what amounts, it is desirable for the system to have a function for simulating gift and inheritance taxes, as well as a function for evaluating the appropriateness of individual asset transfers, similar to the gift management unit 131 and will management unit 132 described above.

In this case, it is desirable to calculate and present the difference in gift tax and inheritance tax for each of multiple patterns of estate division, with the case following the statutory inheritance shares as the default. In addition, when designing the pattern of estate division, the inheritance processing unit 133 may take into consideration various data, optimize weighting etc. according to predetermined conditions, calculate and take into account the reserved share of each heir, and create and present one or more candidate pattern proposals. In addition, it may be possible to gradually improve the content of the estate division by accepting modifications from the target user based on the selected candidate pattern and presenting the recalculated inheritance tax in response to the modifications.

Data to be taken into consideration may include, for example, the amount and timing of asset transfers between the decedent and the heirs during their lifetime, as well as the reasons for such transfers, the amount and type of assets currently held by each heir, and information such as the age, family structure, occupation, and place of residence of each heir. By registering information on whether or not the heirs are living together with the decedent or providing care, this information can also be taken into consideration. It is also possible to output the asset details of the target user (decedent) to a data file, PDF file, etc., and send it by email 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, and can be, for example, a general-purpose information processing terminal such as a PC (Personal Computer), tablet terminal, or smartphone. It is not limited to these information processing terminals as long as it is a device with an information processing function, and can be a home appliance such as a television. In this embodiment, since it covers asset transfer due to inheritance, etc., it is expected that the proportion of elderly users will be higher compared to general services. Therefore, it is mainly expected that the device will be used with touch operations on a portable terminal such as a tablet terminal or smartphone, so that the user can perform processes and operations related to asset transfer such as gifts and the creation of wills in a timely and easy manner without having to move around the site.

The user accesses the functions of each part of the asset management server 10 via the network 20 using software such as a client application or a web browser (not shown) installed on the user terminal 30. The interface by which the user operates the application etc. can include input devices such as a keyboard and a mouse, as well as operation using a touch panel and operation using voice recognition via a microphone. As mentioned above, an image of the user captured by the camera function can also be used as input data.

<Processing procedure (while alive)>
2 is a flowchart outlining an example of a flow for supporting various processes related to inheritance, etc., performed by a target user while alive. As a prerequisite for performing management processes 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 information related to the user's own assets is registered and managed in the asset status DB 152 by the asset management unit 120.

In order to design an asset transfer due to inheritance or the like, the target user uses the user terminal 30 to access the asset management server 10 via the network 20. Upon receiving instructions from the user via the user terminal 30, the asset management unit 120 of the asset management server 10 acquires information on the current assets of the target user from the asset status DB 152 and outputs it to the user terminal 30 (S01). In response to instructions from the user, the asset management unit 120 may acquire 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, the contents of inherited (planned) assets already registered in the inherited property DB 154, and the contents of wills already registered in the will management DB 155.

When the user receives an instruction via the user terminal 30 that a future prediction of assets, etc. is necessary to grasp the total amount of transferable assets when designing inheritance details (S02: Yes), the prediction processing unit 123 of the asset management unit 120 calculates the predicted valuation of all assets at the predicted future time of death of the target user and outputs it to the user terminal 30 (S03). Furthermore, the total amount of necessary expenses such as living expenses that will be required by the predicted time of death of the target user is predicted by simulation or the like and output (S04). The total amount of transferable assets is assumed to be the sum of the predicted valuation of all assets calculated in step S03 minus the total amount of necessary expenses calculated in step S04.

In cases where no instruction was given in step S02 that future predictions of assets, etc. are necessary (S02: No), and in response to instructions from the user, the assets of close relatives (users belonging to the close relatives group) who may be the subject of asset transfer are obtained 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 status of users in the close relatives group who have allowed disclosure of their asset status is disclosed to the target user. The target user refers to the various information obtained in the above series of processes and uses the gift tax and inheritance tax simulation functions of the inheritance management unit 130 to design the asset formation of close relatives, such as to whom, how much, when and how to transfer which assets.

If an instruction to make a gift is received from the target user (S06: Yes), the gift management unit 131 of the inheritance management unit 130 receives input from the user of the contents of the gift contract concluded with the recipient's close relative, and registers this in the inheritance property DB 154 (S07). If there are multiple gift contracts, each of these is registered. The contents of the gift contract may include, for example, the recipient, the contents of the assets to be transferred (amount, property, share, etc.), the transfer conditions (the arrival of a certain date or the fulfillment of other conditions, etc.), whether or not the recipient will bear any costs, etc.

If it is determined based on the contents of the transfer conditions, etc. that each gift is a gift made during one's lifetime and that the conditions for transfer have been met (S08: Yes), the asset transfer unit 121 of the asset management unit 120 transfers the assets to be donated to the recipient, that is, a close relative, as a gift based on instructions from the user (S09). As described above, the system may also accept input regarding the results of gifts made outside the system and register them in the transfer history DB 153. The management process for these assets ends with the transfer.

If it is determined in step S08 that each gift is a gift made during one's lifetime but the conditions for transfer have not been met, or that the gift is a gift made posthumously (S08: No), the management process for these assets is terminated. Note that, for gifts made during one's lifetime but for which the conditions for transfer have not been met, the gift management unit 131 or the like periodically checks whether the conditions have been met. Then, if it is determined that the conditions have been met, the target user may be notified and consent/instructions obtained, and the asset transfer unit 121 may then carry out the transfer process.

On the other hand, if an instruction to make a will is received from the target user in step S06 (S06: No), the will management unit 132 of the inheritance management unit 130 accepts input of the will contents from the user via the user terminal 30 and registers them in the will management DB 155 (S10). In addition to information on the transfer of individual assets, the will contents also include information related to access control, such as whether or not the will contents are to be disclosed, and information on the target and scope of disclosure if it is to be made.

In addition to registering the contents of the will, it is also desirable to obtain and record authentication information to prove that the target user has created and entered the contents of the will of their own free will (S11). The authentication information may include, for example, as described above, video and audio data, signature data, biometric information, etc., at the time of will registration. Furthermore, for example, if an instruction is received from the user to output the contents of the will, this is output as data such as written document or a PDF file (S12). With these processes, the management process for the will is completed. Note that the contents of the will can be changed at any time by the target user while they are alive. In that case, the processes from step S10 onwards can be repeated.

<Processing procedure (after death)>
3 is a flowchart outlining an example of a flow for supporting various processes related to inheritance, etc., performed after the death of a target user. As a prerequisite for performing management processes after death, it is assumed that the event of the death of the target user (decedent) and the start of inheritance has been automatically or manually input into 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 who belong to the close relatives group of the target user (decedent) as potential targets for asset transfer (S21). Here, only users who have permitted 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 begun by email or a push notification to the user terminal 30. The inheritance management unit 130 then refers to the asset status DB 152 and determines all assets (inheritance) that are subject to asset transfer (S22).

Then, the inheritance processing unit 133 refers to the inheritance property DB 154, and if there is a contract for a gift causa mortis registered by the target user (decedent) during his/her lifetime, it acquires this, and outputs it so that the next of kin extracted in step S21 can refer to it (S23). For example, it outputs it on a screen or prints it out so that each next of kin can refer to it via the user terminal 30. Similarly, it refers to the will management DB 155, and if there is a will registered by the deceased, it acquires this, and outputs it so that the next of kin can refer to it (S24).

The next of kin conducts the estate division negotiations by referring to the contents of the posthumous gift and the will output in steps S23 and S24. The inheritance processing unit 133 accepts the input of the contents of the results of the estate division negotiations and registers information in the inheritance property DB 154 regarding to whom, how much, and how the assets will be transferred (S25). Note that, as described above, in order to contribute to the estate division negotiations, the inheritance management unit 130 may, for example, obtain information on the asset status of the deceased from the asset status DB 152 and output it to the next of kin. In addition, the inheritor may accept input that the heir has made a qualified acceptance or renounced the inheritance, and reflect this in the automatic processing of the inheritance or in the content of the information provided to the heir.

It is also desirable to be able to perform simulations of gift tax and inheritance tax. In this case, for example, it is desirable to calculate and present the difference in gift tax and inheritance tax for multiple patterns of inheritance division, with the case following the statutory inheritance share as the default. In addition, when designing patterns of inheritance division, the inheritance processing unit 133 may take into account various data and perform optimization such as weighting according to predetermined conditions, and create and present one or more candidate pattern proposals while also calculating and taking into account the reserved share of each heir, etc.

After that, in addition to any gifts causa mortis or bequests already registered by the decedent, the details of the asset transfer to the next of kin and each next of kin to whom the decedent's assets are to be transferred are finally determined and registered/updated in the inheritance property DB 154 (S26, S27). Then, in response to instructions from the next of kin or executor, etc., the asset transfer unit 121 of the asset management unit 120 transfers the assets in accordance with the registered details in the inheritance property DB 154 (S28). The system may also accept input regarding the results of asset transfers performed outside the system and register them in the transfer history DB 153. With the transfer, asset management for the target user (decedent) is completed.

As described above, there are two types of asset transfers associated with inheritance: those that the asset management system 1 itself can process (or request other external services 40, etc.) (independently transferable actions) and those that the asset management system 1 itself cannot process (independently non-transferable actions). An example of an independently transferable action is a cash transfer from the account of the deceased to the account of one or more heirs. An example of an independently non-transferable action is the transfer of real estate of the deceased to an heir.

For independently transferable acts, for example, an heir (or a legal representative or voluntary representative of the decedent, an executor, etc.) may use a user terminal 30 to access the asset management system 1 and input instructions, and the asset management system 1 may execute the instructions based on the contents of the instructions. For independently non-transferable acts, for example, the contents of the act may be displayed or printed as a guide on the user terminal 30 of the heir (or a legal representative or voluntary representative of the decedent, an executor, etc.). The system may also accept input of the results of processing performed outside the system, and display or print the contents.

In addition, the configuration may be such that the procedure contents of the transfer of the separately transferable act and/or the separately non-transferable act are output to the outside without distinguishing between the separately transferable act and the separately non-transferable act. The output destination may be the user terminal 30 of the heir (or the legal representative or optional representative of the decedent, the executor, etc.), as well as the user terminal 30 of the target person set by the decedent or an external service 40. The target person may be, for example, a business operator such as a bank or a securities company that provides inheritance-related services. In this case, for example, the asset management system 1 of this embodiment may be configured to provide information related to the asset contents to these businesses, request an estimate of fees, etc., and accept the estimate result. Furthermore, since the remuneration system of these businesses that provide inheritance-related services generally involves multiplying a predetermined remuneration rate according to the amount of inherited property, such calculations may be calculated and output in the asset management system 1.

<Data structure>
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. The user DB 151 is a table that holds information related to users (including those who may be the decedents who transfer assets, as well as those who may be close relatives who may receive the assets) who use the asset management system 1, and has, for example, two tables, a user table 151a and a close relatives group table 151b.

The user table 151a shown in FIG. 4(a) is a master table that holds the account information and attribute information of each user, and includes items such as user ID, authentication information, close relative group ID, name, date of birth, gender, address, occupation, health status, and inheritance intentions of each deceased person.

The user ID field holds ID information for uniquely identifying the target user. The authentication information holds personal authentication information such as the password and biometric information related to the target user. The close relatives group ID holds ID information for uniquely identifying the close relatives group related to the target user. The close relatives group is a group consisting of close relatives of the target user who may be the recipients of asset transfers from the target user during or after their death, with the members registered in the close relatives group table 151b shown in Figure 4(b).

The name field holds information on the name of the target user. The date of birth, gender, address, occupation, and health status fields hold information indicating the date of birth, gender, address, occupation, and health status as attribute information of the target user, respectively. Occupation and health status may be specified by code values, etc. These pieces of attribute information may be used as parameters that are weighted and taken into consideration when the inheritance processing unit 133 creates candidate patterns for dividing the estate. Furthermore, attribute information is not limited to these items, and items holding attribute information may be added, deleted, etc. as appropriate.

The item "Inheritance intention for each decedent" holds information such as a code value indicating whether or not the potential decedent intends to receive the transfer of inherited assets as an heir in the event that the target user becomes a close relative who may receive the asset transfer. This information can be set in advance by the target user. This information makes it possible for the potential decedent to exclude the target user from consideration when designing the transfer of assets through inheritance or when dividing the estate after the death of the user.

The close relatives group table 151b shown in FIG. 4(b) is a table that holds, for each user, information related to the composition of a close relatives group centered on that user, and has items such as a close relatives group ID, close relatives user ID, relationship, disclosure permission, and memos.

The close relatives group ID field holds ID information that uniquely identifies each close relatives group. A close relatives group is a group consisting of close relatives such as heirs who may be the subject of asset transfers from the target user during their lifetime or after their death. The close relatives user ID field holds user ID information that identifies close relatives who belong to the target close relatives group. The value of this close relatives user ID is the value registered in the user ID field of the user table 151a described above.

The relationship field holds information such as a code value indicating the relationship between the target relative and the user who will be the deceased in the target relative group. The disclosure permission field holds information such as a code value indicating whether the target relative allows the deceased in the target relative group to disclose details of his or her own financial situation. A relative who specifies that they do not allow disclosure may be treated as having renounced inheritance from the target deceased. The notes field holds the content of text specified in free form by the deceased in the target relative group as special notes or cautions regarding the target relative. This makes it possible to record the deceased's personal and subjective evaluation of the target relative.

Figure 5 is a diagram outlining an example of the data configuration of the asset status DB 152 held by the asset management server 10. 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, valuation amount, valuation base date, shared ownership, and co-owner.

The User ID field holds ID information that identifies the user who owns the target asset. The value of this user ID is the value registered in the User ID field of the above user table 151a. Note that the users identified by this field are not limited to those who transfer assets (potential heirs), but also include all those who receive the asset transfer (potential relatives). The Asset ID field holds ID information that uniquely identifies the target asset. The Asset Name field holds information on the display name of the target asset. The Asset Type field holds information such as a code value that identifies the type of the target asset. For example, the code value is set to a value that distinguishes between savings, cash, land, buildings, automobiles, precious metals, debt, etc.

The information acquisition method item holds information related to the acquisition method when information related to the target asset needs to be acquired from the external service 40 via the external service I/F 140. For example, when acquiring information by web scraping, it holds information such as the URL (Uniform Resource Locator) of the access destination and the ID and password entered when accessing. When calling an API, it holds information such as the target API and the parameters to be specified. This information may also specify a script or program for actually executing the specified acquisition method.

The valuation amount and valuation base date items respectively hold the results of the monetary valuation of the target asset and information on the base date of the monetary valuation. The co-ownership interest and co-owner items respectively hold the percentage (or amount) of the target user's co-ownership interest when the target asset is shared with someone other than the target user, and information identifying the other co-owner (which may be a user ID if the other co-owner is a user of the asset management system 1).

Figure 6 is a diagram outlining an example of the data structure of the transfer history DB 153 held by the asset management server 10. The transfer history DB 153 is a table that holds information on the history of asset transfers for 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, other party user ID, and reason for asset transfer.

The User ID field holds ID information that identifies the user who performed the target asset transfer. The value of this User ID will be the value registered in the User ID field of the above user table 151a. The Asset Transfer Date field holds information on the date on which the target asset transfer was performed. The Donation/Acquisition Classification field holds information regarding the target asset transfer, such as a code value that classifies whether the target user donated or acquired the asset. The Transferred Assets ID field holds ID information that identifies the assets transferred in the target asset transfer. The Transferred Assets ID value will be the value registered in the Assets ID field of the above asset status DB 152.

The Transfer Amount/Ratio field holds the appraised value of the assets transferred in the target asset transfer, or the ratio in cases where the assets are indivisible. The Other Party User ID field holds ID information that identifies the other party in the target asset transfer. The value of this user ID is the value registered in the User ID field of the above user table 151a. The Reason for Asset Transfer field holds information related to the reason for the target asset transfer and the contents of the accompanying conditions, etc., in the form of text or code values. For example, it is possible to record the fact that the asset was donated as wedding funds or business funds, and the contents of the burden in the case of a gift with burdens (for example, the obligation to live together or caregiving, etc.). This can be used as reference information when designing asset formation for close relatives through inheritance.

Figure 7 is a diagram outlining an example of the data configuration of the inherited property DB 154 held by the asset management server 10. The inherited property DB 154 is a table that holds information on assets (inherited property) that are transferred to close relatives through inheritance or the like, with each user who uses the asset management system 1 as the deceased. For example, it has items such as user ID, transferred asset ID, transferee, transfer amount/ratio, transfer category, transfer conditions, transfer status, etc.

The User ID field holds ID information identifying the user who holds the assets related to the target inheritance. The value of this user ID is the value registered in the User ID field of the above user table 151a. The Transferred Assets ID field holds ID information identifying the assets related to the target inheritance. The value of this Transferred Assets ID is the value registered in the Assets ID field of the above asset status DB 152. The Transferee field holds information identifying the close relative to whom the target inheritance is transferred (this may be a user ID if the user is a user of the asset management system 1).

The Transfer Amount/Ratio field holds the assessed amount at the time the assets related to the target inheritance are transferred, or information on the ratio in cases where the assets are indivisible. The Transfer Category field holds information such as a code value that classifies whether the transfer of the target inheritance is due to a gift made during one's lifetime, a gift causa de mortis, a bequest, or inheritance through estate division. The Transfer Condition field holds information related to the details of conditions attached to the transfer of the target inheritance (for example, the other party's marriage or purchase of a home, or one's own certification of need for nursing care, etc.) as text or a code value. The Transfer Status field holds a code value that indicates the status of the transfer of the target inheritance (for example, not transferred, transferred, etc.).

Figure 8 is a diagram outlining an example of the data configuration of the will management DB 155 held by the asset management server 10. The will management DB 155 is a table that holds information related to the contents of wills 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 content, disclosure category, disclosure recipient, target asset ID, transferee, transfer amount/ratio, transfer conditions, etc.

The User ID field holds ID information that identifies the user who made the will in question. The value of this user ID is the value registered in the User ID field of the above-mentioned user table 151a. The Will ID field holds ID information that uniquely identifies the will in question. The Will date and time field holds information on the date and time when the will in question was created (or registered in the will management DB 155).

The will category item holds information such as a code value indicating the category of the will in question (holographic will, notarized will, secret will, other non-statutory will, etc.). In the case of a statutory holographic will or notarized will, it must be written by hand or by a notary, and in the case of a secret will, it must be output in writing. Therefore, under current law, the content of the will registered in the will management DB 155 indicates the content of these wills or serves as the basic information for these wills. On the other hand, even if it does not meet the format of a will in the narrow sense of the current law, it can be used as a will in the broad sense that takes into consideration the wishes of the deceased during their lifetime in estate division negotiations, for example.

The authentication date and time field holds information on the date and time when the will was confirmed or authenticated by the user who made the will, a notary public, a witness, etc. The authentication content field holds information such as text and code values that specify the content of the authentication performed on the will. Authentication is not limited to legal authentication performed outside the system by a notary public or a witness, etc. As described above, for example, when a user registers the content of a will in the asset management system 1, the asset management system 1 can also certify that the content is correct and that it was registered of the user's own free will. The authentication content in this case can include, for example, video and audio data recorded by a camera and microphone equipped in the user terminal 30, biometric information such as heart rate obtained by a sensor, image data of a handwritten signature, etc.

The disclosure category item holds information such as a code value that specifies whether or not the will in question should be disclosed to other close relatives, etc. The disclosure recipient item holds information that identifies the recipient to whom the will is to be disclosed (this may be a user ID if the recipient is a user of the asset management system 1) if the recipient is to be restricted when the will in question is to be disclosed. This information makes it possible to control access to the will.

The target asset ID field holds ID information that identifies the assets to be transferred in the target will. The value of this target asset ID is the value registered in the asset ID field of the asset status DB 152 described above. It may be possible to register multiple assets. The transferee field holds information that identifies the close relative to whom the target assets are transferred (this may be a user ID if the person is a user of the asset management system 1). The transfer amount/proportion field holds the amount of assets to be transferred by the target will, or information on the proportion of the assets if they are indivisible. The transfer conditions field holds information such as text or code values that indicate the contents of conditions attached to the transfer of the target assets (for example, if a bequest requires marriage or starting a business).

Note that the data configurations (items) of each table shown in Figures 4 to 8 above are merely examples, and other table and data configurations may be used as long as they are capable of holding and managing similar data.

As described above, the asset management system 1 according to the first embodiment of the present invention is capable of not only managing an individual's financial assets, but also supporting various processes related to the transfer of assets to close relatives, including inheritance.

Specifically, it is possible to automatically or manually grasp and manage not only an individual's financial assets, but also real estate, movable property, and other assets that may be subject to transfer through inheritance. In addition, it is possible to predict the future (anticipated time of death) assessed value of these assets, and calculate the total amount of transferable assets by predicting the necessary expenses, such as living expenses, that will be required up to that time through simulations, etc. This makes it easier for users who may become heirs to plan asset formation for close relatives through asset transfer, and also makes it possible to encourage early asset transfer to younger generations. It also makes it easier to create and manage wills.

And when a user dies and inheritance begins, it will be easy to understand the user's assets that could become an inheritance and the contents of the will, and it will be possible to provide information and simulation functions that will make it easy for heirs to transfer assets, including dividing the inheritance.

(Embodiment 2)
In the asset management system 1 according to the second embodiment of the present invention, when a user who wishes to transfer assets due to inheritance or the like decides which assets to transfer to which relative and how much, the system has a user interface that allows the user to visually grasp not only the user's personal assets but also the asset status of the entire relative group, including the asset status of other relatives, and allows the user to specify the asset transfer with a simple operation. The basic configuration and operation of the asset management system 1 are the same as those of the first embodiment described above, so a repeated explanation will be omitted and the contents of the user interface and the method of realizing it will be mainly explained.

<Asset management through balance sheets>
Fig. 9 is a diagram outlining an example of a user interface displayed on the user terminal 30 in this embodiment. Here, a smartphone is used as the user terminal 30, and an example of a screen displayed on a display consisting of a touch panel by a client application installed on the smartphone is shown. Fig. 9 shows an example of displaying, in the form of a balance sheet, the status of assets that can be managed as a close relatives group including some assets of the close relatives (relatives and family) of the target user (i.e., assets that the target user can "rely on", assets that can be considered as the same "wallet").

In Figure 9(a), the asset status of the target user's close relatives group on a 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. In this embodiment, the portion equivalent to net assets is the total amount of transferable assets (in the figure, "inheritable assets"). In other words, "inheritable assets" is the total assessed value of currently held assets (in the figure, "deposits," "stocks," "real estate," etc.) minus liabilities (in the figure, the total amount of "mortgage" and "car loan" plus "future living expenses")).

As shown in the first embodiment, the total amount of transferable assets (inheritable assets) is the sum of the estimated valuation of all assets at the time of the user's expected death minus the total amount of necessary expenses up to the time of expected death. Therefore, for example, the valuation of assets such as stocks and real estate is preferably the estimated valuation at the time of expected death, but it may be simplified to the valuation at the current time. Furthermore, "future living expenses" is the total amount of expected expenses (living expenses, medical expenses, etc.) up to the time of expected death minus the total amount of expected income (salary, stock dividends, etc.).

Furthermore, in this embodiment, as shown in FIG. 9(a), in addition to the target user's own deposits ("Deposits (Self)"), assets of the close relatives group are also imported and displayed, such as the wife's deposits ("Deposits (Wife)") and deposits donated (given) by the father ("Deposits (from Father)"), as assets of those other than the target user. This allows the user to visually grasp the overall asset situation within the close relatives group and decide whether or not to transfer assets. Note that not only assets but also liabilities other than those of the target user can be imported in the same way.

On the screen of FIG. 9(a), for example, if the user changes the date in the "Base Date" column to any future date, the asset status on the changed base date is recalculated and the balance sheet is updated based on the calculation results, as shown in FIG. 9(b). Note that the amounts of items equivalent to assets and liabilities fluctuate over time as shown in the figure, but the amount of inheritable assets basically remains constant.

In addition, when the user selects an asset item on the balance sheet on the screen of FIG. 9(a), the screen transitions to a screen for managing the selected asset. FIG. 9(c) shows an example of a screen for managing stocks that is displayed when the user selects the asset "Stocks (owner)" in the example of FIG. 9(a). Via this screen, the user can allocate (transfer) the target asset (stocks) to a close relative.

In the example of FIG. 9(c), information such as the number of shares held and current value is displayed in a list for each stock. The settings for the disclosure range of information for the close relatives group are also displayed for each stock. The user can then assign the target stock to a close relative via a pop-up screen that is displayed by pressing a button in the "assign" column for the target stock. At this time, it is desirable to allow candidates for close relatives to be selected from a pull-down menu or the like as shown in FIG. 9(c). Candidates for close relatives may be, for example, users who belong to the close relatives group shown in embodiment 1, but in this embodiment, more detailed relationship units can be specified by referring to family tree information as described below.

When assets are allocated (transferred) to a close relative, the details are reflected in the balance sheet, as shown in Figure 9(d). The example in Figure 9(d) shows that a portion of "Stocks (self)" has been allocated to a child as an asset of the close relatives group ("Stocks (to child)"). In this way, the user can visually grasp the asset status of the close relatives group, including inheritable assets, and easily decide to whom and how much assets to transfer.

<Creating genealogical information>
In this embodiment, the user can transfer assets to close relatives such as family members, but when deciding to do so, as described above, each close relative may or may not permit the user to disclose their asset status. Conversely, the user may or may not select each close relative as a candidate for asset transfer. In order to flexibly respond to such circumstances, in this embodiment, family tree information is formed and held so that users who may be the target of asset transfer can be managed in more detail by relationship, rather than managing them uniformly as a close relative group as in the first embodiment.

Figure 10 is a diagram outlining an example of a screen on which a user creates a family tree. Here, using technology such as that described in Patent Document 3, the user can create a family tree by dragging and dropping icons on the user terminal 30. In addition, it is also possible to set for each individual relative whether or not they are a candidate for asset transfer through donation or inheritance, whether or not to disclose their asset status to other relatives, etc.

Figure 11 is a diagram outlining an example of a data structure for forming family tree information including close relatives who are the subject of asset management. In this example, the assets to be managed are financial assets such as stocks held in a securities account and deposits held in a bank account. Specifically, for example, the tables contained in the user DB 151 in Figure 1 include a user table 151a and a close relatives table 151c. In addition, the tables contained in the asset status DB 152 include 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 that holds master information for each user, and is generally similar to that shown in FIG. 4(a) above. In the example of FIG. 11, it is simplified to have the fields User ID and Gender. The User ID holds ID information that uniquely identifies each user. The Gender field holds information such as a code value that indicates the gender of the target user.

The close relatives table 151c is a table that manages the relationships between a pair of users who are close relatives, and has fields such as relationship ID, first user ID, second user ID, relationship, relationship name, reverse record relationship ID, and whether to display. The relationship ID field holds ID information that uniquely identifies each relationship (a directed graph showing the relationship between users).

The first user ID field holds information on the user ID of the person (e.g., "self") who is the original node in the directed graph of the target relationship. The second user ID field holds information on the user ID of the person (e.g., "wife", "child A", etc.) who is the previous node in the directed graph of the target relationship. The relationship field holds information on the directed graph indicating the target relationship. For example, it holds information indicating "couple" or "parent and child" from the perspective of the user corresponding to the first user ID field. It may be expressed by vectors or the like when the family tree is on an 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 field holds information on the display name of the target relationship (e.g., "wife", "child A", etc.). This information can be set, for example, by a family tree creation method using a technology such as that described in Patent Document 3.

The reverse record relationship ID field holds information about the relationship ID of the record with the reverse relationship to the directed graph related to the target relationship. The display/non-display field holds information such as a flag or code value indicating whether or not to display the connection related to the target relationship when displaying the family tree. These fields are information used to control the process related to the formation of the family tree, which will be described later.

The account table 152a is a table that holds master information for accounts of securities companies and the like that hold stocks, which are assets to be managed, and has items such as an account ID and a user ID. The account ID item holds ID information that uniquely identifies the target account. The user ID item holds user ID information related to 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 the assets to be managed, and has items such as an asset ID, an account ID, a stock code, a quantity, and an asset attribute ID. 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 stock code item holds stock code information of the target asset, that is, the stock. The quantity item holds information on the number of shares held, that is, the target asset. The values of these items can be obtained, for example, by calling an API provided by the financial institution's website or system, etc., via the external service I/F 140 in FIG. 1. The asset attribute ID item holds asset attribute ID information related to attributes such as the type of the target asset. This value is registered in the asset attribute table 152c described later.

The asset attribute table 152c is a table that holds master information related to attributes such as asset type, and has items such as asset attribute ID and asset attribute name. 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 on whether or not information on a specific asset will be disclosed in a certain relationship, and has items for asset ID and relationship ID, for example. The asset ID item holds asset ID information that specifies the target asset to be disclosed (or not). The relationship ID item holds relationship ID information that specifies the relationship to disclose (or not) the target asset. It may be specified on a user-by-user basis to which disclosure will be made, rather than on a relationship-by-relationship basis. The user uses the user terminal 30 to register the specification of whether or not to disclose using a screen such as that shown in FIG. 9 above.

The asset allocation table 152e is a table that holds information related to the allocation of specific assets between users related to a certain relationship, and has items such as an asset ID, relationship ID, and quantity. The asset ID item holds asset ID information that identifies the allocated asset. The relationship ID item holds relationship ID information that identifies the relationship in which the asset allocation was made. It may be a user ID that identifies the user to whom the allocation was made, rather than a relationship. The quantity item holds information on the quantity of the allocated asset. The values of these items are registered by the user using the user terminal 30, using a screen such as that shown in FIG. 9 above.

Figures 12 and 13 are diagrams outlining an example of the process flow for forming family tree information based on information about close relatives. Here, an example is shown in which family tree information for an individual is formed using close relative registration information (family tree information) that has already been registered by users of other close relatives using a user interface such as that shown in Figure 10.

In the family tree formation process, first, records in which the user (X) has already been set as the second user ID (user at the end of the digraph) are extracted from the close relatives table 151c shown in FIG. 11 (S31). The right side of FIG. 12 shows, as specific examples, records related to the digraphs of spouse (B) → person (X), parent (C) → person (X), and child (A) → person (X) that have been extracted. Note that the arrows and the symbols x, -x, y, and -y in the figure represent digraphs as vectors when the family tree is on an xy coordinate plane, with x (rightward in the figure) and -x (leftward in the figure) representing connections between the same generation, y (upward in the figure) representing connections to upper generations, and -y (downward in the figure) representing connections to lower generations.

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

Then, for the relationships (directed graphs) related to each record created in step S32, the user (X) decides whether or not to display the lines related to the relationships when displaying the family tree, and inputs this via the user terminal 30 (S33). At this time, for example, provisional family tree information related to the records created in step S32 is displayed on the user terminal 30, and the user can give instructions on this.

After that, in the reverse of step S31, the second user IDs of the 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, records in which the extracted second user IDs are set as the first user ID (the original user of the digraph) are extracted (S35). At this time, records in which the person (X) is set as the second user ID are excluded. In the example of FIG. 12, the digraphs related to the records in which spouse (B), parent (C), and child (A) are set as the first user ID are indicated by dotted arrows. Of these, only the digraphs (enclosed in a solid line frame in the figure) of parent (C) → grandfather (D), spouse (B) → parent (E), and spouse (B) → child (A) in which the person (X) is not set as the second user ID are extracted.

Moving on to FIG. 13, the second user IDs of the records extracted in step S35 are compared with the second user IDs extracted in step S34 to extract non-overlapping ones (S36). At this time, if there are no non-overlapping user IDs (S37: No), the family tree formation process ends. In the example of FIG. 12 and FIG. 13, when the second user IDs of the records extracted in step S35, grandfather (D), parent (E), and child (A), are compared with the second user IDs of the spouse (B), parent (C), and child (A) extracted in step S34, grandfather (D) and parent (E) are extracted as non-overlapping ones. 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 information on the relationship (directed graph) related to the record in which the person (X) is the first user 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 each of the displayed relationships on the family tree, and inputs this via the user terminal 30 (S39). In the example of FIG. 13, the relationships from the person (X) to grandfather (D) and from the person (X) to parent (E) are newly displayed in step S38, and it is shown that a decision has been made in step S39 to hide the relationship from the person (X) to parent (E).

Then, return to step S34 in FIG. 12 and repeat the series of processes until no unique IDs are extracted in step S37. Through the above process, family tree information relating to the individual can be easily created using the registration information (family tree information) of close relatives that have already been registered by other close relative users.

Figure 14 is a diagram outlining an example of the process flow for displaying a balance sheet for a group of close relatives as shown in Figure 9 based on family tree information. When the process starts, first, the relationship ID of the record in which the person himself/herself is set as the first user ID or second user ID is extracted from the close relatives table 151c (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). If the allocation is set by user ID rather than relationship ID in the asset allocation table 152e, the record in which the person's user ID is set is targeted.

On the other hand, the relationship ID of the record in which the person himself/herself is set as the second user ID is extracted from the close relatives table 151c (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). If disclosure is set by user ID instead of relationship ID in the asset disclosure table 152d, the record in which the person himself/herself's user ID is set is targeted.

Then, the asset attribute ID and stock 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, current price information is obtained from the external service 40 via the external service I/F 140 using the stock code extracted in step S45 as a key (S47).

Then, the current values obtained in step S47 are tallied for each asset attribute ID extracted in step S45 and each relationship ID extracted in steps S41 and S43. Then, the current values are displayed on the user terminal 30 together with the asset attribute names obtained in step S46 in a format such as a balance sheet that shows the percentage of the total amount (S48). Furthermore, the relationship names corresponding to the relationship IDs are also displayed on the user terminal 30 by the following series of processes, and the process ends.

Specifically, it is determined whether the target asset is related to the relationship ID of a record in the close relatives table 151c in which the person is set as the first user ID (S49). Then, if the asset is related to the relationship ID of a record in which the person is set as the second user ID rather than the first user ID (S49: No), a record in the close relatives table 151c in which the relationship ID is set as the reverse record relationship ID is identified, and the value of the relationship ID of that record is obtained (S50).

After that, if the relationship ID is related to the record in which the person is set as the first user ID in step S49 (S49: Yes), the relationship ID is set as the target relationship ID, and if the relationship ID is related to the record in which the person is set as 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 obtained from the close relatives table 151c and displayed on the user terminal 30 (S51).

As described above, the asset management system 1, which is the second embodiment of the present invention, allows a user who wishes to transfer assets due to inheritance or the like to decide which assets to transfer to which relative and how much, to visually grasp the asset status of the entire relative group, including not only the user's personal assets but also the asset status of other relatives, in the form of a balance sheet, and realizes a user interface that allows the user to specify asset transfers with simple operations.

It also makes it easy to create family tree information to identify groups of close relatives and to manage assets as groups of close relatives based on this information.

The invention made by the inventor has been specifically described above based on the embodiments, but it goes without saying that the present invention is not limited to the above embodiments and can be modified in various ways without departing from the gist of the invention. For example, the above embodiments have been described in detail to clearly explain the invention, and the invention is not necessarily limited to having all of the configurations described. It is also possible to replace part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. It is also possible to add, delete, or replace part of the configuration of each embodiment with other configurations.

For example, the asset management system 1 in the above-mentioned first and second embodiments of the present invention has been described with reference to a mechanism or service for an individual to manage assets, but is not limited to this. For example, the asset management system 1 may have a function for providing information related to an individual's asset management held by the asset management system 1 to an external third party in a format that does not identify the target user. The third party who receives the information may be able to provide some kind of marketing service to the target user via the asset management system 1. Note that in this case, it is desirable to provide the asset management information to a third party only after obtaining prior consent and approval from the target user.

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

In addition, in each of the above figures, the control lines and information lines shown are those considered necessary for explanation, and do not necessarily show all of the control lines and information lines in the actual implementation. In reality, it can be assumed that almost all components are interconnected.

The present invention can be used in asset management systems that support various processes related to asset transfers, such as inheritances, carried out by potential decedents.

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 relatives group table, 152: Asset status DB, 153: Transfer history DB, 154: Inherited property DB, 155: Will management DB

Claims (4)

An asset management system that supports management of assets owned by a user who connects via a network using a user terminal, comprising:
a user management unit that manages account information of the user who makes the gift during his/her lifetime and other users who are his/her heirs or close relatives;
an asset management unit that records information on assets held by the user and information on assets held by the other users in an asset status recording unit, and also performs processing related to asset transfer between the user and the other users and records the details of the transfer in a transfer history recording unit;
an inheritance management unit that processes the transfer of at least a portion of the assets, including at least financial assets, held by the user during the user's lifetime or after the user's death;
The inheritance management department further
Accepting registration of the contents of the inter vivos gift including the transfer conditions from the first user, and recording the contents in the inheritance property record unit;
When the transfer conditions are fulfilled, the first user is notified that the transfer conditions have been fulfilled regarding the contents of the gift during one's lifetime, including the transfer conditions recorded in the inheritance property record unit;
When the transfer conditions are fulfilled and an instruction is received from the first user, the asset management unit performs a process for transferring assets in the inter vivos gift from the first user to the other user based on the content of the inter vivos gift including the transfer conditions recorded in the inheritance property recording unit ;
In the user terminal, assets held by the first user and at least a part of assets held by the other users are displayed on the same screen, and further, assets transferred from the first user to the other users among the assets held by the other users are displayed in an identifiable manner.
Asset management system. 2. The asset management system according to claim 1,
An asset management system in which the inheritance management unit periodically checks whether the transfer conditions recorded in the inheritance property recording unit have been fulfilled, and if it determines that the transfer conditions have been fulfilled, notifies the first user that the transfer conditions have been fulfilled. 2. The asset management system according to claim 1,
An asset management system in which the inheritance management unit determines that the transfer conditions recorded in the inheritance property recording unit have been fulfilled when it receives input from a user who detects that the transfer conditions have been fulfilled. 2. The asset management system according to claim 1,
An asset management system in which the inheritance management unit registers the contents of a gift contract, including the contents of the assets to be transferred, between the first user making the gift during one's lifetime and another user who will be the heir , as the contents of the gift during one's lifetime to be registered in the inheritance property recording unit.

Images