Personal property security management device, personal property security management system and personal property security management method

Abstract

To provide a personal property security management device, a personal property security management system and a personal property security management method which facilitate post-installation of a security management function in security management of a personal property, and integrate the security management of the personal property.SOLUTION: A personal property security management system has a plurality of device management servers 201-1 to 201-N, and one security management server 202. The security management server 202 registers a token for security management in association with each piece of personal property identification information and registers a financial institution ID for identifying a loan source in association with each piece of the personal property identification information, and if the personal property identification information received from the device management servers is not registered, newly issues a token for security registration and registers the newly registered token in association with the personal property identification information.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a movable property security management device, a movable property security management system, and a movable property security management method.

Background Art

[0002] Generally, as a method of corporate financing, there is movable property security financing in which a company finances by using movable property such as machinery and equipment it owns as collateral. In financial institutions, in this way, the collateral of movable property is secured and the risk of non-recovery is reduced.

[0003] In this case, a mechanism for managing the collateralized movable property is required. For example, a method has been proposed for monitoring the collateralized movable property to detect abnormalities in the movable property (Patent Document 1). Furthermore, in a system for supporting the business of movable property security financing, a proposal has been made to grasp and manage the status of movable property security items and to perform real-time notification of changes in the collateral content and enforcement of the security right with respect to the movable property security items (Patent Document 2).

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Patent Document 2

Summary of the Invention

Problems to be Solved by the Invention

[0005] In Patent Documents 1 and 2 described above, when attempting to implement the function of security management in an existing IoT management service, i.e., a device management server, there is a problem that it is difficult to add the function of security management retroactively.

[0006] Furthermore, if there are multiple IoT management services, there will be multiple device management servers to manage them, which will be dispersed. As a result, there is a problem that financial institutions cannot use the guarantee management function in a unified manner.

[0007] The present invention has been made in view of such a background, and an object thereof is to provide a movable property guarantee management device, a movable property guarantee management system, and a movable property guarantee management method that can easily retrofit a guarantee management function in the guarantee management of movable property and can unify the guarantee management of movable property.

Means for Solving the Problems

[0008] To solve the above-described problems and achieve the above object, an embodiment of the present invention is a movable property guarantee management device that communicates with one or more movable property management devices that register movable property identification information unique to the movable property to be guarantee-managed and performs guarantee management of the movable property to be financed from a financing source, the movable property guarantee management device including: a guarantee registration unit that registers by associating guarantee registration information assigned to the movable property identification information for each of the movable property identification information; a guarantee management unit that registers by associating financial institution information for identifying a financing source for each of the movable property identification information registered in the guarantee registration unit; a guarantee registration issuance unit that receives the movable property identification information unique to the movable property from the movable property management device and newly generates and issues guarantee registration information when the received movable property identification information does not exist in either the guarantee registration unit or the guarantee management unit; and a registration unit that registers by associating the received movable property identification information with the guarantee registration information issued by the guarantee registration issuance unit in the guarantee management unit.

[0009] In addition, another embodiment of the present invention is a movable property security management system having one or more movable property management devices and a movable property security management device that performs security management of movable property to be financed from a financier through communication with each of the movable property management devices. Each of the movable property management devices has a movable property management unit that registers movable property identification information unique to the movable property to be security-managed. The movable property security management device includes a security registration unit that registers by associating security registration information assigned to the movable property identification information for each of the movable property identification information, a security management unit that registers by associating financial institution information for identifying the financier for each of the movable property identification information registered in the security registration unit, a security registration issuing unit that receives the movable property identification information unique to the movable property registered in the movable property management unit from the movable property management device and, when the received movable property identification information does not exist in either the security registration unit or the security management unit, newly generates and issues security registration information, and a registration unit that registers by associating the received movable property identification information with the security registration information issued by the security registration issuing unit in the security management unit.

[0010] Furthermore, another embodiment of the present invention is a method for managing movable property security in a system having one or more movable property management devices and a movable property security management device that performs security management of movable property to be financed from a financier through communication with each of the movable property management devices. Each of the movable property management devices registers movable property identification information unique to the movable property to be security-managed in a first memory. The movable property security management device has a second memory that registers by associating security registration information assigned to the movable property identification information for each of the movable property identification information and also registers by associating financial institution information for identifying the financier for each of the movable property identification information. In the movable property security management device, a first step of receiving the movable property identification information unique to the movable property registered in the first memory from the movable property management device and, when the received movable property identification information does not exist in the second memory, newly generating and issuing security registration information, and a second step of registering by associating the received movable property identification information with the security registration information issued in the first step in the second memory are included.

Effect of the Invention

[0011] According to the present invention, it is easy to retrofit the security management function in the security management of movable property, and it is possible to unify the security management of movable property.

Brief Description of the Drawings

[0012]

Figure 1

Figure 2

Figure 3A

Figure 3B

Figure 4

Figure 5

Figure 6A

Figure 6B

Figure 7A

Figure 7B

Figure 8

Figure 9

Figure 10

Figure 11A

Figure 11B

Figure 12

Figure 13

Mode for Carrying Out the Invention

[0013] Hereinafter, embodiments of the present invention will be described with reference to the drawings. Note that the following description and drawings are merely examples for explaining the present invention, and for the sake of clarity of explanation, appropriate omissions and simplifications have been made. Also, the present invention can be implemented in various other forms. Also, unless otherwise particularly limited, each component may be singular or plural.

[0014] In the following description, the same or similar configurations may be denoted by the same reference numerals and redundant descriptions may be omitted. Also, in the following description, various types of information may be described using expressions such as "information" and "table", but the various types of information may be expressed in other data structures. Also, as expressions for identification information, there are expressions such as "identification information", "identifier", "name", "ID", and "number", and these can be mutually replaced. Also, in the following description, "table" will be denoted as "TBL" respectively.

[0015] First, the outline of this embodiment will be described with reference to FIG. 1. FIG. 1 is an explanatory diagram for explaining the mechanism of the movable property security management system according to this embodiment.

[0016] As shown in FIG. 1, for example, the movable property security management system of this embodiment is composed of a group of equipment management servers 201 (equipment management servers 201-1 to 201-N which are movable property management devices) for managing one or more pieces of movable property (such as equipment) and one security management server 202 corresponding to the movable property security management device. Here, the equipment management servers 201-1 to 201-N correspond to, for example, equipment leasing companies or operators, and the security management server 202 corresponds to, for example, financial institutions or operators. However, the parties constituting the movable property security management system are not limited to this.

[0017] The security management function is not implemented in each of the equipment management servers 201-1 to 201-N (N is a natural number). One security management server 202 connects a plurality of different equipment management servers 201-1 to 201-N through a network, and realizes the centralization of security management by entrusting the security management of each of the equipment management servers 201-1 to 201-N to that one security management server 202.

[0018] As a result, for retrofitting the security management function, since it is a system separate from each of the equipment management servers 201-1 to 201-N, that is, the security management server 202 is in charge, even if the number of equipment management servers increases or the number of equipment subject to security management increases, the security management server 202 only absorbs the processing such as addition to the equipment subject to security management, and the synergy of security management becomes easy.

[0019] As a representative example, an external equipment management client terminal (hereinafter referred to as "equipment management client") 204 is connected to the equipment management server 201-1 through a network, and in addition, equipment DV1 to DVM (M is a natural number) which are movable property are also connected through the network in the same way. For the sake of simplicity in the following description, each equipment management server shall have the same configuration and use the same reference numerals as in FIG. 1.

[0020] The device management client 204 executes processes such as registering a device to be managed and transferring the ownership of a device by an operator's operation between the device management client 204 and the device management server 201-1.

[0021] In addition, an external collateral management client terminal (hereinafter referred to as "collateral management client") 203 is connected to the collateral management server 202. The collateral management client 203 executes processes necessary for collateral management by an operator's operation between the collateral management client 203 and the collateral management server 202.

[0022] Next, the configuration of this embodiment will be described. FIG. 2 is a configuration diagram showing the hardware configuration of the movable property collateral management system according to this embodiment, FIG. 3A is a block diagram showing the functional configuration of the device management server of the movable property collateral management system according to this embodiment, FIG. 3B is a block diagram showing the functional configuration of the collateral management server of the movable property collateral management system according to this embodiment, and FIG. 4 is an explanatory diagram for explaining an example of a table of the movable property collateral management system according to this embodiment.

[0023] First, the hardware configuration of this embodiment will be described with reference to FIG. 2. Each device of the device management server group 201 has the same hardware configuration, and since the collateral management server 202 also has the same configuration, the device management server 201-1 will be used as a representative example for explanation.

[0024] As shown in FIG. 2 for example, the device management server 201-1 generally includes a CPU 301 that controls the entire device, a memory 302 that stores programs such as the processes according to this embodiment (flowcharts described later) for the CPU 301 to execute and stores various data during execution, a keyboard 307, a pointing device 308, an input I / F 303 that transmits the input operations of the keyboard 307 and the pointing device 308 internally, a communication I / F 304 connected to the network NW to control communication with the collateral management server 202, an auxiliary storage device 305 which is a memory for registering and managing various data and TBLs, a display 309 for displaying various information and data, an output I / F 306 that sends display data to the display 309 internally, a bus 310 connected to each unit within the device to control communication of data, signals, etc. within the device, and the like.

[0025] Note that the configuration of the collateral management server 202 is the same. The communication I / F 304 is connected to the network NW to control communication with each device management server 201-1 to 201-N.

[0026] Also, the collateral management client 203 and the device management client 204 shown in FIG. 1 have the same hardware configuration as that in FIG. 2. The collateral management client 203 and the collateral management server 202 are connected by a network. Similarly, the device management client 204 and the device management server are connected by a network.

[0027] For each of the above-mentioned networks, it may be a wired communication network or a wireless communication network, and the Internet or a dedicated line can be selected as appropriate freely.

[0028] Next, the device management server 201-1 will be described with reference to FIG. 3A. As shown in FIG. 3A for example, the device management server 201-1 includes a processing unit 401A having a collateral registration token acquisition unit 403, a device management data inquiry unit 404, a device stop relay unit 405, a device ownership transfer unit 406, etc., and a storage unit 402A having device management data 407 including a device management TBL 408.

[0029] Here, the processing unit 401A has a function of processing according to a program stored in the memory 302 by the CPU 301. Also, the storage unit 402A has the function of the auxiliary storage device 305.

[0030] In the processing unit 401A, the collateral registration token acquisition unit 403 is responsible for the process of registering the devices to be collateralized, and the device management data inquiry unit 404 is responsible for the process of monitoring the devices to be collateralized. The device stop relay unit 405 is responsible for the process of preserving the devices to be collateralized, and the device ownership transfer unit 406 is responsible for the process of transferring the ownership of the devices to be collateralized. This processing unit 401A executes processing in cooperation with each part of the collateral management server 202.

[0031] As shown in, for example, FIG. 4(a), the device management TBL 408 is configured to register and store, in association with the device ID assigned to each device to be collateralized, the device-owning company ID that identifies the company that owns the device, the location information indicating the location of the device, the location acquisition time indicating the time when the location information was acquired, and the current value of the device (collateral) as a set. Note that each data in the device management TBL 408 is also monitoring data.

[0032] For example, the device ID "M111111" is a set with the device-owning company ID "X", the location information "139°xx’, 35°xx’", the location acquisition time "2023 / 11 / 11 11:11:11", and the current value of "13,500,000 yen".

[0033] Next, the collateral management server 202 will be described with reference to FIG. 3B. As shown in, for example, FIG. 3B, the collateral management server 202 includes a processing unit 401B having a collateral registration token issuance unit 410, a collateral monitoring unit 411, a collateral preservation unit 412, a collateral registration unit 413, a collateral release unit 414, a collateral registration confirmation unit 415, a collateral right transfer token issuance unit 416, a device collateral right transfer unit 417, etc., and a storage unit 402B including collateral management data 418 such as a collateral registration token TBL 419, a collateral right transfer token TBL 420, and a collateral management TBL 421.

[0034] Here, the processing unit 401B has a function of processing according to a program stored in the memory 302 by the CPU 301. Also, the storage unit 402B has the function of the auxiliary storage device 305.

[0035] In the processing unit 401B, the collateral registration token issuance unit 410 is responsible for the process of issuing a collateral registration token (for example, character string data randomly generated), which is collateral registration information for registering a device to be collateralized as collateral, and the collateral monitoring unit 411 is responsible for the process of monitoring the device to be collateralized. The collateral preservation unit 412 is responsible for the process of preserving the device to be collateralized, and the collateral registration unit 413 is responsible for the process of registering the device to be collateralized as collateral.

[0036] Then, the collateral release unit 414 is responsible for the process of releasing the collateral of the device to be collateralized, and the collateral registration confirmation unit 415 is responsible for the process of confirming the collateral status of the device to be collateralized. The collateral right transfer token issuance unit 416 is responsible for the process of issuing a collateral right transfer token (for example, character string data randomly generated), which is collateral right transfer information of the device to be collateralized, and the device collateral right transfer unit 417 is responsible for the process of transferring the collateral right of the device to be collateralized. This processing unit 401B executes processing in cooperation with each part of the device management servers 201-1 to 201-N. Note that unique device management IDs are assigned to each of the device management servers 201-1 to 201-N, and the processing unit 401B executes processing in cooperation with the device management server determined by the device management ID. For example, the device management IDs of the device management servers 201-1 to 201-N are assigned as S001 to S00N.

[0037] Furthermore, as shown in FIG. 4(b) for example, the collateral registration token TBL 419 is configured to register and store the collateral registration token described later as a set associated with the device management ID and the device ID registered in the device management TBL 408.

[0038] For example, the device management ID "S001" and the device ID "M111111" form a set with the collateral registration token "T-4035-9924-1032". Here, the device management ID and the device ID serve as movable property identification information.

[0039] The security right transfer token TBL420 is configured to register and store, as a set, a security right transfer token described later in association with a device management ID and a device ID registered in the device management TBL408, as shown in FIG. 4(c), for example.

[0040] For example, the device management ID "S001" and the device ID "M111119" form a set with the security right transfer token "T-1025-6307-0770".

[0041] The security management TBL421 is configured to register and store, as a set, a financial institution ID for identifying a financial institution in association with a device management ID and a device ID registered in the device management TBL408, as shown in FIG. 4(d), for example.

[0042] For example, the device management ID "S001" and the device ID "M111113" form a set with the financial institution ID "A".

[0043] The processing of the present embodiment will be described below. First, the security registration of the present embodiment will be described with reference to FIGS. 5, 6A, and 6B. FIG. 5 is an explanatory diagram for explaining an example of a sequence related to the security registration of the movable property security management system according to the present embodiment, FIG. 6A is a flowchart for explaining an example of an operation related to the security registration of the movable property security management system according to the present embodiment, and FIG. 6B is a flowchart for explaining another example of an operation related to the security registration of the movable property security management system according to the present embodiment. In the following description, as in the example shown in FIG. 1, the device management client 204, the security management server 202, the security management client 203, the device management server 201-1, and the device DV1 will be described using the respective reference numerals.

[0044] First, the sequence of the security registration will be described with reference to FIG. 5. In the security registration, at step S501, the device management client 204 that has logged in with the device owner enterprise ID transmits a security registration token issuance command to the device management server 201-1 in response to an operator's operation.

[0045] Subsequently, in step S502, the collateral registration token acquisition unit 403 of the device management server 201-1 acquires the device ID paired with the device-owning enterprise ID from the device management TBL 408 (device management data 407) stored in the storage unit 402A, and transmits the pair of the device management ID and the device ID to the collateral management server 202.

[0046] Furthermore, in step S503, the collateral registration token issuance unit 410 of the collateral management server 202 attempts to generate and store a collateral registration token (see FIG. 6A described later). If it can generate and store the collateral registration token, it returns the pair of the device management ID, the device ID, and the collateral registration token to the device management server 201-1.

[0047] Then, in step S504, the collateral registration token acquisition unit 403 of the device management server returns the pair of the device management ID, the device ID, and the collateral registration token received to the device management client 204.

[0048] Subsequently, in step S505, the device management client 204 that has logged in with the device-owning enterprise ID displays the pair of the device management ID, the device ID, and the collateral registration token.

[0049] Furthermore, in step S506, when the collateral management client 203 that has logged in with the financial institution ID receives the input of the pair of the device management ID, the device ID, and the collateral registration token, it transmits the pair to the collateral management server 202.

[0050] Then, in step S507, the collateral registration unit 413 of the collateral management server 202 confirms the match of the collateral registration token and associates the device with the financial institution (see FIG. 6B described later).

[0051] Here, the "generation and storage of the token for collateral registration" in step S503 described above will be specifically explained with reference to FIG. 6A. The processing here is executed by the program (memory 302) of the collateral management server 202. In the following description, the generation of the token for collateral registration is borne by the collateral registration token issuance unit 410, the confirmation of collateral for each table is borne by the collateral registration confirmation unit 415, and the collateral registration for each table is borne by the collateral registration unit 413.

[0052] First, when a pair of device management ID and device ID is received from the device management server 202-1, a registered record in the collateral registration token TBL419 is referred to (step S601), and it is checked whether the received pair is registered (stored) (step S602). As a result, if the pair is registered (YES route in step S602), this process ends.

[0053] On the other hand, if the pair is not yet registered (NO route in step S602), a registered record in the collateral management TBL421 is further referred to (step S603), and it is checked whether the received pair is registered (stored) (step S604). As a result, if the pair is registered (YES route in step S604), this process ends.

[0054] Also, if the pair is not yet registered (NO route in step S604), a token for collateral registration is generated by the collateral registration token issuance unit 410 (step S605). A new pair combining the device management ID and device ID received in step S601 with the token for collateral registration generated in step S605 is generated as a record (step S606).

[0055] Then, the pair of device management ID, device ID, and token for collateral registration generated in step S606 is inserted as a new record into the collateral registration token TBL419 and stored (registered) (step S607). In this way, this process ends.

[0056] For example, when a pair of device management ID "S001" and device ID "M111111" is received, as shown in Fig. 4(b), since the pair is already registered in the collateral registration token TBL419, this process ends. On the other hand, when a pair of device management ID "S001" and device ID "M*******" is received, as is clear from Fig. 4(b) and (d), there is no registration in the collateral registration token TBL419 but the registration in the collateral management TBL421 can be confirmed, so this process ends here.

[0057] Also, when a pair of device management ID "S001" and device ID "M111112" is received and is not registered in the collateral registration token TBL419 and is not registered in the collateral management TBL421 either, a new record is registered in the collateral registration token TBL419 in step S607.

[0058] In this way, it is possible to ensure exclusivity with others so that only one of the collateral registration token and the collateral registration exists.

[0059] Furthermore, the "association between the device and the financial institution" in step S507 described above will be specifically explained with reference to Fig. 6B. The process here is also executed by the program (memory 302) of the collateral management server 202. Here too, the generation of the collateral registration token is borne by the collateral registration token issuance unit 410, the collateral confirmation for each table is borne by the collateral registration confirmation unit 415, and the collateral registration for each table is borne by the collateral registration unit 413.

[0060] As a premise, it is assumed that the collateral management client 203 has received a set of device management ID, device ID, and collateral registration token from the device management client 204 in advance after step S505 as shown in Fig. 5.

[0061] In the guarantee management server 202, when a set of device management ID, device ID, and guarantee registration token is input from the guarantee management client 203 (step S611), the guarantee registration token TBL419 is referred to in order to check whether the input set exists in the record (step S612).

[0062] And when the input set does not match the set (record) in the guarantee registration token TBL419 (NO route in step S613), this process ends. On the other hand, when they match (YES route in step S613), the record of the matching set is deleted (step S614).

[0063] At this time, when the record cannot be deleted (NO route in step S615), this process ends as a deletion failure. On the other hand, when the deletion is successful (YES route in step S615), as a deletion success, the input set is inserted as a new record into the guarantee management TBL421 associated with the financial institution ID and stored (registered) (step S616). In this way, this process ends.

[0064] For example, when a set of device management ID "S002", device ID "M222222", and guarantee registration token "T8515-0745-6283" is input, it is possible to check for a match with the registration record in the guarantee registration token TBL419 shown in FIG. 4(b). In this case, the record deletion in the guarantee registration token TBL419 is executed, and as shown in FIG. 4(d), a set in which the financial institution ID "A" is associated with the device management ID "S002" and the device ID "M222222" is registered as a new record in the guarantee management TBL421.

[0065] Here too, it is possible to ensure exclusivity with others so that either the guarantee registration token or the guarantee registration exists uniquely. In particular, even if step S507 is executed by a plurality of financial institutions simultaneously, only the first-come financial institution can insert a record.

[0066] Furthermore, the collateral monitoring of this embodiment will be described with reference to FIGS. 7A and 7B. FIG. 7A is an explanatory diagram for explaining an example of a sequence related to collateral monitoring of the movable property collateral management system according to this embodiment, and FIG. 7B is an explanatory diagram for explaining another example of a sequence related to collateral monitoring of the movable property collateral management system according to this embodiment.

[0067] In the sequence of collateral monitoring, in step S701 (see FIG. 7A), the collateral management client 203 that has logged in with the financial institution ID inputs a set of the device management ID and the device ID and transmits it to the collateral management server 202. Here, it is to inquire whether the device DVm (m is a natural number) is in what situation and whether it can be monitored.

[0068] Subsequently, in step S702, the collateral monitoring unit 411 of the collateral management server 202 confirms that a set of the device management ID, the device ID, and the financial institution ID is stored in the collateral management TBL 421, and transmits the device ID to the device management server 201-n (n is a natural number) of the device management ID.

[0069] Then, in step S703, the device management data inquiry unit 404 of the device management server 201-n acquires the monitoring data (such as the position information of the device by GPS, the position acquisition time, the current value, etc.) of the device ID stored in the device management TBL 408 and returns it to the collateral management server 202.

[0070] In the subsequent step S704, the collateral monitoring unit 411 of the collateral management server 202 returns the received monitoring data to the collateral management client 203. As a result, in step S705, the collateral management client 203 that has logged in with the financial institution ID displays the monitoring data.

[0071] In this way, collateral monitoring becomes possible.

[0072] Regarding abnormality detection, as shown in FIG. 7B, first, in step S706, the collateral monitoring unit 411 of the collateral management server 202 transmits the device ID to the device management server 201-n with the device management ID for the pair of the device management ID and the device ID stored in the collateral management TBL 421 at regular intervals (for example, at the time set daily).

[0073] Then, in step S707, the device management data inquiry unit 404 of the device management server 201-n acquires the monitoring data (such as the position information of the device by GPS, the position acquisition time, the current value, etc.) of the device ID stored in the device management TBL 408 and returns it to the collateral management server 202.

[0074] Furthermore, in step S708, if the collateral monitoring unit 411 of the collateral management server 202 detects an abnormality in the received monitoring data, for the financial institution ID that is paired with the device management ID and the device ID in the collateral management TBL 421, it notifies the collateral management client 203 logged in with the financial institution ID of the set of the device management ID, the device ID, and the monitoring data in which the abnormality is detected.

[0075] Here, as examples of abnormality detection for each monitoring data, for the GPS position information, when detecting an abnormality in the case of outside Japan, for the position acquisition time, when detecting an abnormality in the case of before a certain period, and for the current value, when detecting an abnormality in the case of below a certain amount, there are three cases.

[0076] Then, in step S709, the collateral management client 203 logged in with the financial institution ID displays the set of the notified device management ID, the device ID, and the monitoring data in which the abnormality is detected.

[0077] In this way, it becomes possible to grasp abnormality detection in a timely and non-delayed manner through regular collateral monitoring.

[0078] Furthermore, the collateral preservation and release of this embodiment will be described with reference to FIGS. 8 and 9. FIG. 8 is an explanatory diagram for explaining an example of a sequence related to collateral preservation of the movable property collateral management system according to this embodiment, and FIG. 9 is an explanatory diagram for explaining an example of a sequence related to collateral release of the movable property collateral management system according to an embodiment of the invention.

[0079] First, collateral preservation will be described with reference to FIG. 8. First, in step S801, the collateral management client 203 that has logged in with the financial institution ID inputs a set of the device management ID and the device ID and transmits it to the collateral management server 202. Subsequently, in step S802, the collateral preservation unit 412 of the collateral management server 202 confirms that a set of the device management ID, the device ID, and the financial institution ID is stored in the collateral management TBL 421, and transmits the device ID to the device management server 201-n of the device management ID.

[0080] Then, in step S803, the device stop relay unit 405 of the device management server 201-n transmits a stop operation command to the device Dvm of the device ID. In the subsequent step S804, the device Dvm of the device ID receives the stop operation command and stops operating.

[0081] In this way, it becomes possible to stop the operation of the device (collateral) for the purpose of collateral preservation.

[0082] Next, collateral release will be described with reference to FIG. 9. First, in step S901, the collateral management client 203 that has logged in with the financial institution ID inputs a set of the device management ID and the device ID and transmits it to the collateral management server 202. In the subsequent step S902, the collateral release unit 414 of the collateral management server 202 deletes the record of the set of the device management ID, the device ID, and the financial institution ID from the collateral management TBL 421.

[0083] In this way, for example, it becomes possible to release the collateral when the money is recovered from the business operator for the financing.

[0084] Furthermore, the collateral transfer of this embodiment will be described with reference to FIGS. 10, 11A, and 11B. FIG. 10 is an explanatory diagram for explaining an example of a sequence related to collateral transfer of the movable property collateral management system according to this embodiment, FIG. 11A is a flowchart for explaining an example of operations related to collateral transfer of the movable property collateral management system according to this embodiment, and FIG. 11B is a flowchart for explaining another example of operations related to collateral transfer of the movable property collateral management system according to this embodiment.

[0085] Regarding the sequence, first, in step S1001, the collateral management client 203 that has logged in with the financial institution ID (for example, "A") inputs a pair of device management ID and device ID and transmits it to the collateral management server 202.

[0086] Next, in step S1002, the collateral right transfer token issuance unit 416 of the collateral management server 202 attempts to generate and store a collateral right transfer token based on the processing of FIG. 11A described later. If this collateral right transfer token issuance unit 416 can generate and store the collateral right transfer token, it returns a set of device management ID, device ID, and collateral right transfer token to the collateral management client 203.

[0087] Then, in step S1003, the collateral management client 203 that has logged in with the financial institution ID "A" displays a set of device management ID, device ID, and collateral right transfer token. Next, in step S1004, the collateral management client 203 that has logged in with the financial institution ID (for example, "B") inputs a set of device management ID, device ID, and collateral right transfer token and transmits it to the collateral management server 202.

[0088] Then, in step S1005, the device collateral right transfer unit 417 of the collateral management server 202 confirms the match of the collateral right transfer token and changes the association between the device and the financial institution based on the processing of FIG. 11B described later.

[0089] Next, the process of step S1002 described above will be explained with reference to FIG. 11A. Here, the generation and storage of the security transfer token by the security transfer token issuance unit 416 of the security management server 202 are the main processes.

[0090] First, when a set of device management ID, device ID, and financial institution ID is input from the security management client 203 (step S1101), the security management TBL 421 shown in FIG. 4(d) is referred to for checking whether there is a matching set (step S1102). As a result, if no match is confirmed (NO route in step S1103), this process ends.

[0091] On the other hand, if a match is confirmed (YES route in step S1103), further reference is made to the security transfer token TBL 420 shown in FIG. 4(c) (step S1104), and it is checked whether there is a set that matches the input set (step S1105).

[0092] As a result, if a match is confirmed (YES route in step S1105), this process ends. On the other hand, if no match is confirmed (NO route in step S1105), a security transfer token is generated (step S1106). In the example of FIG. 4(c), since there are sets of device management ID "S001" and device ID "M111119" and device management ID "S002" and device ID "M222228", this process will end. On the other hand, if it is assumed that there is no set of device management ID "S003" and device ID "M333336", a security transfer token will be generated.

[0093] In this way, the set of the input set and the security transfer token generated in step S1106 is inserted and stored (registered) in the security transfer token TBL 420 shown in FIG. 4(c) as a new record (step S1107).

[0094] Furthermore, the process of step S1005 described above will be explained with reference to FIG. 11B. Here, the verification of the token for security right transfer by the equipment security right transfer section 417 of the security management server 202 and the change of the association between the equipment and the financial institution are processed.

[0095] First, when a set of equipment management ID, equipment ID, and token for security right transfer is input from the security management client 203 (step S1111), the security right transfer token TBL420 is referred to for verifying whether there is a matching set (step S1112). As a result, if no match is confirmed (NO route in step S1113), this process ends.

[0096] For example, when a set of equipment management ID "S005", equipment ID "M666669", and token for security right transfer "T-3033-2107-1230" is input and the set does not exist in the security right transfer token TBL420, this process ends.

[0097] On the other hand, if a match is confirmed (YES route in step S1113), the record of the matching set is deleted from the security right transfer token TBL420 (step S1114). As a result, if the record deletion fails (NO route in step S1115), this process ends.

[0098] For example, when a set of equipment management ID "S001", equipment ID "M111119", and token for security right transfer "T-1025-6307-0770" is input, as shown in FIG. 4(c), a record exists in the security right transfer token TBL420, so the set will be deleted.

[0099] On the other hand, if the record deletion is successful (YES route in step S1115), the financial institution ID of the record corresponding to the set input in the security management TBL421 is updated (step S1116).

[0100] In this way, it becomes possible to ensure exclusivity regarding the update of the security registration with the security transfer token.

[0101] Also, by executing step S1116 after the success of step S1115, it is possible to guarantee that even if step S1005 is executed by a plurality of financial institutions simultaneously, step S1116 is executed only by the first-arriving financial institution.

[0102] Furthermore, the transfer of ownership in this embodiment will be described with reference to FIGS. 12 and 13. FIG. 12 is an explanatory diagram for explaining an example of a sequence regarding the transfer of ownership of the movable property security management system according to this embodiment, and FIG. 13 is a flowchart for explaining an example of an operation regarding the transfer of ownership of the movable property security management system according to this embodiment.

[0103] In the sequence regarding the transfer of ownership, first, in step S1201, the device management client 204 that has logged in with the device owning company ID transmits the device ID and the device owning company ID of the transfer destination of ownership to the device management server 201-n. Subsequently, in step S1202, the device ownership transfer unit 406 of the device management server 201-n transmits a set of the device management ID and the device ID to the security management server 202.

[0104] Then, in step S1203, the security registration confirmation unit 415 of the security management server 202 attempts to confirm the presence or absence of the security registration and delete the security registration token based on the process of FIG. 13 described later, and returns the security registration confirmation result to the device management server 201-n.

[0105] Subsequently, in step S1204, if the received security registration confirmation result is "no security registration", the device ownership transfer unit 406 of the device management server 201-n updates the device owning company ID associated with the device ID in the device management TBL 408 to the device owning company ID of the transfer destination of ownership. As a result, the procedure for changing the ownership to another company is completed.

[0106] Next, step S1203 described above will be explained with reference to FIG. 13. Here, the explanation will focus on the confirmation of the existence of collateral registration by the collateral registration confirmation unit 415 of the collateral management server 202 and the deletion of the collateral registration token.

[0107] First, when a pair of device management ID and device ID is input by the device management server 201-n (device ownership transfer unit 406) (step S1301), the collateral registration token TBL419 is referred to and it is confirmed whether the pair exists therein (step S1302).

[0108] And when it is confirmed that a matching pair exists (YES route in step S1303), the record of the matching pair is deleted from the collateral registration token TBL419 (step S1304). At that time, if the deletion fails (NO route in step S1305), it is considered that the deletion has failed, and the collateral registration confirmation result is notified to the device management server 201-n as "collateral registration exists" indicating the existence of collateral ownership (step S1309). The device management server 201-n can display the existence of collateral registration to the device management client 204 by receiving this notification.

[0109] On the other hand, in step S1305, if the deletion is successful (YES route), it is considered that the deletion has succeeded, and the collateral registration confirmation result is notified to the device management server 201-n as "collateral registration does not exist" (step S1306).

[0110] Also, in step S1303, when it is confirmed that no matching pair exists (NO route in step S1303), the collateral management TBL421 is referred to and it is confirmed whether a record of the pair input in step S1301 exists therein (step S1307).

[0111] And, if it is confirmed that there is a matching pair (YES route in step S1308), the security registration confirmation result is notified to the device management server 201-n as "security registration exists" (step S1309). On the other hand, if it is confirmed that there is no matching pair (NO route in step S1308), the security registration confirmation result is notified to the device management server 201-n as "no security registration", which indicates the absence of security ownership (step S1306). By receiving this notification, the device management server 201-n can cause the device management client 204 to display "no security registration".

[0112] In this way, it is possible to ensure the exclusivity that only one of the security registration token and the security registration can exist.

[0113] Also, by executing step S1302 after step S1301 and further determining the presence or absence of security registration according to the success or failure of deletion in step S1304, it is possible to ensure that step S1203 is not executed simultaneously with step S507.

[0114] As described above, according to the present embodiment, in the security management of movable property, it is not related to the number of connected device management servers for managing devices, nor is it related to the number of devices managed by each device management server. Therefore, it is possible to realize the security management of movable property with a single security management server. As a result, post-processing such as additional registration, monitoring, preservation, release, transfer of security rights and ownership rights of movable property to be managed as a function becomes easy, and the security management of movable property can be unified by the security management server without being dispersed.

[0115] In the above-described embodiment, the security target of movable property financing is a device (for example, machinery, equipment, vehicle, etc.). However, since assets that can be relatively easily evaluated and transferred are used as the security target, it can also be applied to inventory owned by commercial enterprises and retailers, intellectual property rights such as patents, trademarks, and copyrights as intangible movable property, accounts receivable rights based on accounts receivable and contracts, equipment lease contracts, etc.

[0116] Also, the mechanism of the above-described embodiment can be used for companies and organizations to track and manage various types of assets. For example, it can also be applied when managing IT assets, office furniture and equipment, fixed assets, etc. It can also be applied to inventory tracking and management. In retail, manufacturing, logistics, etc., efficient management and circulation of inventory become possible.

[0117] Furthermore, it can also be used for the management and evaluation of assets based on lease contracts. For example, in lease contracts for office equipment and vehicles, it is possible to track contract conditions and deadlines. It can also be applied to the tracking of assets and resources related to projects in a company. For example, it is possible to manage the equipment and materials required in construction projects and manufacturing projects.

[0118] Also, in the above-described embodiment, token-based collateral management was performed. However, it is not limited to tokens as long as security is ensured equivalently to tokens and it cannot be rewritten, and it can be generated for collateral registration and collateral transfer with the positioning of unique identification information.

[0119] Also, each of the above components, functional units, processing units, processing means, etc. may be realized in hardware by designing part or all of them, for example, by using an integrated circuit. Also, each of the above components, functions, etc. may be realized in software by a processor interpreting and executing a program that realizes each function. Information such as programs, tables, and files that realize each function can be placed in a recording device such as a memory, hard disk, SSD (Solid State Drive), or in a recording medium such as an IC card, SD card, or DVD.

[0120] Furthermore, the arrangement forms of the various functional units, various processing units, and various storage units of the information collection system 10 described above are merely examples. The arrangement forms of the various functional units, various processing units, and various storage units can be changed to an optimal arrangement form from viewpoints such as the performance of the hardware and software provided by these devices, processing efficiency, and communication efficiency.

[0121] In addition, the configuration (such as a schema) of the storage unit for storing the various types of data described above can be flexibly changed from viewpoints such as efficient utilization of resources, improvement of processing efficiency, improvement of access efficiency, and improvement of search efficiency.

Explanation of Reference Numerals

[0122] Device Management Servers 201-1 to 201-N Collateral Management Server 202 Collateral Management Client 203 Device Management Client 204 CPU 301 Memory 302 Input I / F 303 Communication I / F 304 Auxiliary Storage Device 305 Output I / F 306 Keyboard 307 Pointing Device 308 Display 309 Processing Units 401A, 401B Storage Units 402A, 402B Collateral Registration Token Acquisition Unit 403 Device Management Data Inquiry Unit 404 Device Stop Relay Unit 405 Device Ownership Transfer Unit 406 Device Management Data 407 Device Management TBL 408 Collateral Registration Token Issuing Unit 410 Collateral Monitoring Unit 411 Collateral Preservation Unit 412 Collateral Registration Unit 413 Collateral Release Unit 414 Collateral Registration Confirmation Unit 415 416 Security Right Transfer Token Issuance Department 417 Equipment Security Right Transfer Department 418 Security Management Data 419 Security Registration Token TBL 420 Security Right Transfer Token TBL 421 Security Management TBL

Claims

1. A movable property security management device that communicates with one or more movable property management devices for registering movable property identification information unique to the movable property to be secured and performs security management of the movable property to be financed from a financing source, a security registration unit that registers by associating security registration information assigned to the movable property identification information for each movable property identification information, a security management unit that registers by associating financial institution information for identifying the financing source for each movable property identification information registered in the security registration unit, a security registration issuing unit that receives movable property identification information unique to the movable property from the movable property management device, and newly generates and issues security registration information when the received movable property identification information does not exist in either the security registration unit or the security management unit, a registration unit that registers by associating the received movable property identification information with the security registration information issued by the security registration issuing unit in the security management unit, A movable property security management device characterized by comprising the above.

2. In the movable property security management device according to Claim 1, the registration unit receives a set of movable property identification information unique to the movable property and security registration information from the movable property management device, and when a set that matches the received set exists in the security registration unit, deletes the matching set from the security registration unit and registers the received set in the security management unit by associating financial institution information of the financing source therewith. A movable property security management device characterized by this.

3. In the movable property security management device according to Claim 1, each of the movable property management devices registers monitoring data of the movable property, and further, is connected to an external client, receives movable property identification information unique to the movable property from the client, and when a set of the received movable property identification information and financial institution information exists by referring to the security management unit, has a monitoring unit that acquires and monitors the monitoring data from the movable property management device. A movable property security management device characterized by this.

4. In the movable property security management device according to Claim 1, each of the movable property management devices registers monitoring data of the movable property, and further, has a monitoring unit that acquires and monitors the monitoring data from the movable property management device based on each registered movable property identification information in the security management unit at predetermined intervals. A movable property security management device characterized by this.

5. In the movable property security management device according to claim 1, further comprising a security guarantee unit connected to an external client, receiving movable property identification information unique to the movable property from the client, and when the received movable property identification information exists with reference to the security management unit, executing preservation of the movable property corresponding to the movable property identification information on the movable property management device. The movable property security management device is characterized by having such a security guarantee unit.

6. In the movable property security management device according to claim 1, further comprising a security release unit connected to an external client, receiving movable property identification information unique to the movable property from the client, and when the received movable property identification information exists, deleting the movable property identification information from the security management unit to release the movable property security. The movable property security management device is characterized by having such a security release unit.

7. In the movable property security management device according to claim 1, the security registration information is character string data randomly generated. The movable property security management device is characterized by this.

8. In the movable property security management device according to claim 1, further comprising a security transfer registration unit that associates and registers security transfer information for identifying a movable property for which a security right is transferred for each movable property identification information registered in the security registration unit, and a security transfer information issuance unit connected to an external client, receiving a set of movable property identification information unique to the movable property and financial institution information from the client, and when the received set exists in the security management unit and does not exist in the security transfer registration unit, newly generating and issuing security transfer information. The security transfer registration unit registers the issued security transfer information in association with the received set. The movable property security management device is characterized by this.

9. In the movable property security management device according to claim 8, the security transfer information is character string data randomly generated. The movable property security management device is characterized by this.

10. In the movable property security management device according to claim 8, the registration unit is connected to another external client, receives a set of movable property identification information unique to the movable property and financial institution information from the other client, and when a set that matches the received set exists in the security transfer registration unit, deletes the matching set and registers the received set in the security management unit with the financial institution information of the financing source associated therewith. The movable property security management device is characterized by this.

11. In the movable property security management device according to claim 1, when receiving movable property identification information unique to movable property from the movable property management device, if the received movable property identification information exists in the security registration section, deleting the received movable property identification information from the security registration section and notifying the movable property management device of a security registration absence indicating the absence of security ownership. On the other hand, when the received movable property identification information does not exist in the security registration section and the received movable property identification information exists in the security management section, having a security registration confirmation section that notifies the movable property management device of a security registration presence indicating the existence of security ownership. A movable property security management device characterized by this.

12. A movable property security management system having one or more movable property management devices and a movable property security management device that performs security management of movable property to be financed from a financing source through communication with each of the movable property management devices, Each of the movable property management devices, has a movable property management section that registers movable property identification information unique to the movable property to be security managed, The movable property security management device, has a security registration section that registers by associating security registration information assigned to the movable property identification information for each of the movable property identification information, a security management section that registers by associating financial institution information for identifying the financing source for each of the movable property identification information registered in the security registration section, receives movable property identification information unique to the movable property registered in the movable property management section from the movable property management device, and when the received movable property identification information does not exist in either the security registration section or the security management section, newly generates and issues security registration information as a security registration issuing section, and a registration section that registers by associating the received movable property identification information with the security registration information issued by the security registration issuing section in the security management section, A movable property security management system characterized by this.

13. A movable property security management method for a system having one or more movable property management devices and a movable property security management device that performs security management of movable property to be financed from a financing source through communication with each of the movable property management devices, Each of the movable property management devices registers movable property identification information unique to the movable property to be security managed in a first memory, and the movable property security management device has a second memory that registers by associating security registration information assigned to the movable property identification information for each of the movable property identification information and registers by associating financial institution information for identifying the financing source for each of the movable property identification information. In the movable property security management device, a first step of receiving movable property identification information unique to the movable property registered in the first memory from the movable property management device, and newly generating and issuing security registration information when the received movable property identification information does not exist in the second memory; A second step of registering the received movable property identification information and the security registration information issued in the first step in the second memory in association with each other; A movable property security management method characterized by including the above.

Images