Information processing system and program

Abstract

To identify a second information processing device which is paired with a first information processing device from among a plurality of second information processing devices in response to a re-pair formation request from the first information processing device whose pair with the second information processing is eliminated in the case of managing the second information processing device to be a synchronous partner of data held by the first information processing device.SOLUTION: A real device 10 and a virtual device 20 form a synchronous pair of data by holding one of a key pair. A server 30 instructs each virtual device 20 to perform existence confirmation of a real device 10 to be paired in response to a re-pair formation request from a real device 10 that eliminates a key pair due to maintenance or the like, also acquires an existence confirmation result from each virtual device 20, and identifies, a virtual device 20 whose existence cannot be confirmed as a result of referring to the existence confirmation result as the real device 10 which makes the re-pair formation request.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to an information processing system and a program. [Background technology]

[0002] Recently, a technology has been developed that provides cloud services by linking a real multifunction device with a digital replica of the multifunction device on the cloud (hereinafter referred to as a "virtual device"). A user can use services such as image processing provided by the multifunction device by accessing the virtual device on the cloud without directly accessing the multifunction device.

[0003] In order for the virtual device to provide the same services as the multifunction device, the multifunction device and the virtual device are sequentially synchronized to maintain the same data or a state in which the data is associated with each other. The synchronization is initiated in response to an update request from the multifunction device to the virtual device.

[0004] In such a service system, a technique is known in which the authenticity of a device is confirmed using a public key and a private key to prevent "spoofing" by a fake device. More specifically, a multifunction device (hereinafter also referred to as a "real device") holds its own private key and causes a virtual device to hold its own public key, and these public and private keys (hereinafter referred to as a "key pair") are linked together. Usually, a different key pair is generated for each device to minimize the scope of impact in the event of a leak.

[0005] However, unlike inexpensive small devices, MFPs are often used for a long time as equivalent devices through maintenance such as resetting to the factory settings, replacing the board, and replacing with the same model even if a malfunction or breakdown occurs. In this case, for example, when the board on which the private key is stored is replaced, the pairing of the real device and the virtual device based on the key pair is dissolved. Therefore, after the maintenance work, the real device transmits the public key of a new key pair to the server on the cloud that manages the virtual device, and requests the re-formation of the pair based on the key pair. Then, the real device re-forms the pair with the virtual device that holds the public key of the new key pair, and then synchronizes data with the virtual device that re-forms the pair. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] JP 2019-160082 A Summary of the Invention [Problem to be solved by the invention]

[0007] In the case where there are a plurality of second information processing devices to which data held by a first information processing device is synchronized, when one of the plurality of second information processing devices is dissolved from its pair with the first information processing device, it may be convenient to identify the second information processing device that was paired with the first information processing device. For example, when the first information processing device that has dissolved its pair re-forms a pair with the second information processing device, it is considered to be more efficient to transfer and take over the synchronized data and the like held by the second information processing device that was paired until just before to the second information processing device that is to be re-formed, rather than providing all the data and environmental setting contents to be synchronized to the second information processing device that is to be re-formed.

[0008] The present invention aims to, when managing a second information processing device with which data held by a first information processing device is synchronized, identify from among multiple second information processing devices the second information processing device that was paired with the first information processing device in response to a re-pairing request from the first information processing device whose pairing with the second information processing device has been dissolved. [Means for solving the problem]

[0009] The information processing system of the present invention includes a processor that manages a second information processing device that is paired with a first information processing device that holds data and is a synchronization partner of the data, and in response to a re-grouping request from the first information processing device that has been dissolved from its pair with the second information processing device, the processor requests a plurality of the second information processing devices to confirm the survival of the first information processing device that is paired with the second information processing device, receives survival confirmation results returned from each of the second information processing devices in response to the survival confirmation request, and, when the first information processing device that made the re-grouping request is the requesting device and the second information processing device that was paired with the requesting device is the immediately preceding pairing partner device, refers to the received survival confirmation result and identifies the second information processing device whose survival could not be confirmed as the immediately preceding pairing partner device.

[0010] The processor is also characterized in that it selects the second information processing device that will newly form a pair with the request source device as a new paired device in accordance with a predetermined condition.

[0011] The processor is further characterized in that, when selecting the second information processing device other than the immediately preceding partner device as the new partner device, the processor transfers the data held by the immediately preceding partner device to the new partner device.

[0012] The processor may also select the immediately preceding partner device as the new partner device.

[0013] In addition, when the processor receives multiple survival confirmation results indicating that survival could not be confirmed, the processor selects the immediately preceding partner device from among the multiple second information processing devices that sent the survival confirmation results indicating that survival could not be confirmed, by referring to characteristic information indicating the characteristics of the requesting device or by inquiring of an administrator of the requesting device.

[0014] The processor, when referring to the characteristic information, acquires the characteristic information by making a request to the requesting device, and selects the immediately preceding pairing device based on the result of comparing the acquired characteristic information with pairing partner characteristic information held by each of the second information processing devices that transmitted the survival confirmation result indicating that survival could not be confirmed, the pairing partner characteristic information indicating the characteristics of the first information processing device that is paired with the second information processing device.

[0015] The processor is also characterized in that, when inquiring of the administrator, it acquires pairing partner characteristic information indicating the characteristics of the first information processing device that is paired with each of the multiple second information processing devices that have sent the survival confirmation result indicating that survival could not be confirmed, and presents the acquired multiple pairing partner characteristic information to the administrator of the requesting device.

[0016] The second information processing device is also characterized in that it is formed on a cloud.

[0017] The first information processing device and the second information processing device each hold one of a pair of information that can prove that they form a pair.

[0018] The program of the present invention enables a computer that manages a second information processing device that is paired with a first information processing device that holds data and is a synchronization partner of the data to realize the following functions: in response to a re-grouping request from the first information processing device that has been dissolved from its pair with the second information processing device, requesting multiple second information processing devices to confirm the survival of the first information processing device that is paired with the second information processing device, receiving the survival confirmation results returned from each of the second information processing devices in response to the survival confirmation request, and, when the first information processing device that made the re-grouping request is the requesting device and the second information processing device that was paired with the requesting device is the immediately preceding pairing partner device, referring to the received survival confirmation result and identifying the second information processing device whose survival could not be confirmed as the immediately preceding pairing partner device. Effect of the Invention

[0019] According to the invention described in claim 1, when managing a second information processing device with which data held by a first information processing device is synchronized, in response to a re-pairing request from a first information processing device whose pairing with the second information processing device has been dissolved, it is possible to identify the second information processing device that was paired with the first information processing device from among a plurality of second information processing devices.

[0020] According to the invention as recited in claim 2, the second information processing device that meets the predetermined condition can be selected as the new paired partner device.

[0021] According to the invention as recited in claim 3, the data to be synchronized that was held by the immediately preceding partner device can be handed over to the new partner device.

[0022] According to the invention as recited in claim 4, it becomes unnecessary to migrate data to be synchronized.

[0023] According to the invention as recited in claim 5, processing can be performed so as to narrow down to only one immediately preceding paired device.

[0024] According to the invention as recited in claim 6, the second information processing device paired with the first information processing device having a common characteristic with the request issuing device can be selected as the immediately preceding paired counterpart device.

[0025] According to the seventh aspect of the present invention, the characteristics of the first information processing device can be provided to the manager when the immediately preceding pairing partner device is selected.

[0026] According to the invention as recited in claim 8, it is possible to achieve synchronization with another external information processing device.

[0027] According to the invention as recited in claim 9, it is possible to guarantee a synchronization partner for data.

[0028] According to the invention described in claim 10, when managing a second information processing device with which data held by a first information processing device is synchronized, in response to a re-pairing request from a first information processing device whose pairing with the second information processing device has been dissolved, the second information processing device that was paired with the first information processing device can be identified from among a plurality of second information processing devices. [Brief description of the drawings]

[0029] [Figure 1] 1 is an overall configuration diagram of a service system according to a first embodiment. [Diagram 2] 1 is a diagram showing an example of a block configuration of a service system in a first embodiment. [Diagram 3] FIG. 4 is another overall configuration diagram of the service system in the first embodiment. [Figure 4] FIG. 11 is a sequence diagram showing a process performed to re-form a data synchronization set in the first embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0030] Hereinafter, preferred embodiments of the present invention will be described with reference to the drawings.

[0031] Embodiment 1 FIG. 1 is an overall configuration diagram of a service system in this embodiment. The service system in this embodiment is one form of an information processing system according to the present invention. FIG. 1 shows a configuration in which a multifunction device 10 installed in an on-premise environment and a virtual multifunction device 20 formed on a cloud 2 are connected via a network 4 such as the Internet. The multifunction device 10 as the first information processing device is an actual device physically installed in the on-premise environment, and therefore will be referred to as the "actual device 10" in the following description. On the other hand, the multifunction device 20 as the second information processing device is an actual multifunction device formed on the cloud 2, and therefore will be referred to as the "virtual device 20" in the following description.

[0032] The real device 10 holds the data to be synchronized. The virtual device 20 is a device with which the data of the real device 10 is synchronized, and is positioned as a digital copy of the real device 10. The server 30 formed on the cloud 2 manages the virtual devices 20 in units of tenants 6.

[0033] A "tenant" 6 is a unit for managing the cloud services provided by the service system and the users who use those cloud services. In a tenant 6, a user of the tenant is called a "user" and a user with management authority is called an "administrator." Administrators are classified according to their authority for each scope of management, such as the entire tenant, part of the tenant, or a service.

[0034] FIG. 1 shows real devices 10a, 10b, and 10c and corresponding virtual devices 20a, 20b, and 20c. In this embodiment, the real device 10 and the virtual device 20 are described as having a one-to-one relationship, but a plurality of real devices 10 may be associated with one virtual device 20. FIG. 1 shows three pairs of devices, but in this embodiment, two or more pairs may be formed. When it is not necessary to distinguish between the real devices 10a, 10b, and 10c, they are collectively referred to as "real devices 10" as described above. The same applies to the virtual devices 20a, 20b, and 20c.

[0035] The multifunction device 10 in this embodiment is a form of an image forming device equipped with various functions such as a printing function, a copying function, a scanning function, etc., and is a device that has an information processing device (also called a "computer"). The multifunction device 10 in this embodiment can be realized with a general-purpose hardware configuration that has existed for a long time. That is, the multifunction device 10 is equipped with a CPU, a ROM, a RAM, a storage unit such as a hard disk drive (HDD) that stores image data, a mailbox, etc., an operation panel as a user interface, a network 4 such as the Internet, a scanner, a print engine, etc. required to provide various functions. During the life cycle of the multifunction device 10, events such as return due to expiration of a lease contract, and replacement / disposal due to breakdown or maintenance occur.

[0036] Moreover, the multifunction device 10 in this embodiment includes an HSM (Hardware Security Module) such as a TPM (Trusted Platform Module) as a means for storing keys. The HSM is a hardware device with enhanced tamper resistance that keeps the encryption process secure by generating, protecting, and managing keys used for encrypting and decrypting data and creating digital signatures and certificates, and is fixed to a board. In this embodiment, as authentication keys, a private key and a public key (also called an "owner authentication key") in a public key cryptosystem, and a private key and a public key (also called a "device authentication key") that are assigned at the time of shipment and are used to verify the authenticity of the origin of the multifunction device 10 are used. The owner authentication key is prepared for each multifunction device 10. The device authentication key may be prepared for each multifunction device 10, or may be shared for each tenant 6, for example. The private key of the owner authentication key and the private key of the device authentication key are stored in the HSM.

[0037] The virtual device 20 is a form of a virtual image forming device realized by one or more computers, and is a device having an information processing device. The server 30 is a form of a virtual server computer realized by one or more computers. Although the virtual device 20 and the server 30 are virtual, they have a CPU, ROM, RAM, storage means, and communication means. Although the virtual device 20 and the server 30 are illustrated as a single device for convenience, they may be configured by combining multiple devices.

[0038] In order for the real device 10 and the virtual device 20 to provide the same services to the user, data must be synchronized between the real device 10 and the virtual device 20. "Data synchronization" basically means that the same data is held by both devices. Also, a portion of the software (called a "subset") that exists in the virtual device 20 may also exist in the multifunction device 10. Thus, the term "data synchronization" is not intended to be interpreted restrictively as meaning that the data held by each device is completely identical. In this embodiment, "data synchronization" refers to the multifunction devices 10 and 20 working together to provide the services that each device should provide using data.

[0039] Furthermore, "data" includes applications, data used by applications, various setting values ​​for the multifunction devices 10 and 20, etc. In other words, in this embodiment, electronic data referenced when the multifunction devices 10 and 20 operate is collectively referred to as "data." Note that when the data is an application, synchronization becomes necessary due to version upgrades, addition of functions, etc.

[0040] Fig. 2 is a diagram showing an example of a block configuration of a service system in this embodiment. Each of the multiple real devices 10a, 10b, and 10c shown in Fig. 1 similarly has the function blocks shown in Fig. 2. The same is true for the virtual device 20. Note that, for example, the real device 10 naturally provides multiple functions such as a printing function and a scanning function, but components that are not used in the description of this embodiment, such as these functions, are omitted from the diagram.

[0041] The real device 10 includes a key management unit 11 , a synchronization processing unit 12 , a re-assembly request processing unit 13 , a survival confirmation response unit 14 , a control unit 15 , and a synchronization data storage unit 16 .

[0042] The key management unit 11 is realized by the above-mentioned HSM, and holds and manages an owner authentication key and a device authentication key. The synchronization data storage unit 16 stores data to be synchronized, and the synchronization processing unit 12 performs synchronization processing to synchronize data with the virtual device 20 that is the data synchronization partner. The re-association request processing unit 13 makes a re-association request to the server 30 to form a pair with the virtual device 20 in response to a re-registration request from the user after the pair with the virtual device 20 is dissolved. The survival confirmation response unit 14 replies to the effect that the virtual device 20 is alive in response to an inquiry for survival confirmation from the virtual device 20 that forms the pair. The control unit 15 controls the execution of the above-mentioned components 11 to 14 in the real device 10.

[0043] Each of the components 11 to 15 in the real device 10 is realized by the cooperative operation of a computer mounted on the real device 10 and a program running on a CPU mounted on the computer. The synchronous data storage unit 16 is realized by an HDD mounted on the real device 10. Alternatively, a RAM or an external storage means may be used via a network.

[0044] The virtual device 20 includes a key management unit 21, a synchronization processing unit 22, a survival confirmation control unit 23, a data transfer processing unit 24, a control unit 25, and a synchronization data storage unit .

[0045] The key management unit 21 holds and manages the public key of the owner authentication key. The synchronization data storage unit 26 stores data synchronized with the real device 10, and the synchronization processing unit 22 performs synchronization processing to synchronize data with the real device 10 that is the data synchronization partner. The survival confirmation control unit 23 confirms the survival of the paired real device 10 in response to an instruction from the server 30, and returns the survival confirmation result to the server 30. When the server 30 newly forms a self-device in response to a re-grouping request from the real device 10, the data transfer processing unit 24 takes over the data by acquiring the data to be synchronized that was held by the virtual device 20 that was paired with the real device 10 immediately before in response to a transfer instruction from the server 30. The control unit 25 controls the execution of the above-mentioned components 21 to 24 in the virtual device 20.

[0046] Each of the components 21 to 25 in the virtual device 20 is realized by the cooperative operation of a computer installed in the virtual device 20 and a program running on a CPU installed in the computer. The synchronous data storage unit 26 is realized by an HDD installed in the virtual device 20. Alternatively, a storage means in the RAM or the cloud 2 may be used.

[0047] The server 30 includes a key management unit 31, a synchronization control unit 32, a reassembly request receiving unit 33, a survival confirmation control unit , a virtual device management unit 35, and a data migration control unit .

[0048] The key management unit 31 holds and manages the public key and device authentication key of the owner authentication key sent from each real device 10. The synchronization control unit 32 controls synchronization processing performed between the real device 10 and the virtual device 20. In response to a re-assembly request from the real device 10, the survival confirmation control unit 23 requests each of the virtual devices 20 included in the tenant 6 to which the real device 10 belongs to confirm the survival of the real device 10 paired with the virtual device 20, and collects the survival confirmation results returned from each virtual device 20 in response to the survival confirmation request. The virtual device management unit 35 manages the virtual devices 20 to be managed for each tenant 6. When a new virtual device 20 is formed by the virtual device management unit 35 in response to a re-assembly request from the real device 10, the data transfer control unit 36 ​​controls the transfer of data to be synchronized that is held by the virtual device 20 that was previously paired with the real device 10, to the new virtual device 20.

[0049] Each of the components 31 to 36 in the server 30 is realized by the cooperative operation of a computer forming the server 30 and a program that runs on a CPU installed in the computer.

[0050] Furthermore, the programs used in the present embodiment can be provided not only by communication means, but also by being stored in a computer-readable recording medium such as a USB memory. The programs provided from the communication means or recording medium are installed in a computer, and various processes are realized by the computer's CPU sequentially executing the programs.

[0051] Next, the operation of this embodiment will be described. In this embodiment, a case will be described in which three synchronous pairs of virtual devices 20 belonging to one tenant 6 and real devices 10 corresponding to each virtual device 20 are formed as shown in FIG.

[0052] As described above, each of the multifunction devices 10 and 20 provides the same services. To this end, under the control of the synchronization control unit 32 in the server 30, the synchronization processing units 12 and 22 of the multifunction devices 10 and 20 cooperate to perform synchronization processing, which is started when the multifunction device 10 inquires of the multifunction device 20 at a predetermined timing. In this embodiment, it is assumed that data synchronization has already been achieved between the multifunction devices 10 and 20.

[0053] Suppose that, while this data is synchronized, some kind of failure occurs in a real device 10, causing the board to be replaced. As described above, the real device 10 and the virtual device 20 corresponding to this real device 10 form a pair by each holding one of the owner authentication keys (i.e., a key pair of a private key and a public key) as a pair of information that can prove that they form a pair, but the fact that the HSM-equipped board that stores the private key of the owner authentication key has been replaced is equivalent to the dissolution of the synchronized pair.

[0054] Fig. 3 is a configuration diagram of the entire service system, similar to Fig. 1, but in Fig. 3, the actual device 10c is shown as actual device 10d due to the replacement of the board. Even if the configuration of the main body of the multifunction device 10 other than the board is the same as before the board replacement, the multifunction device 10 is recognized as a different multifunction device 10 in terms of management by key pair, as in the case where the entire main body of the multifunction device 10 is replaced, due to the loss of the private key of the owner authentication key that can prove the pair. In the following explanation, the multifunction device 10 in which the private key of the owner authentication key has been lost will be referred to as "actual device 10c", and the multifunction device 10 that will use a new owner authentication key will be referred to as "actual device 10d".

[0055] In this embodiment, since it is assumed that the board of the real device 10c is replaced, the data to be synchronized that was held in the real device 10c is handed over to the real device 10d as is. If the main body of the device is replaced, the data to be synchronized that was held in the real device 10c needs to be transferred to the real device 10d in advance.

[0056] The real device 10c is set to a state in which it can operate as the real device 10d by maintenance work, but the real device 10d has lost the private key of the owner authentication key. At this point, the pair with the synchronization partner remains dissolved. Therefore, the real device 10d needs to form a pair with the virtual device 20 with which it will synchronize data again.

[0057] As described above, in Fig. 3, the real device 10c and the real device 10d are illustrated as different multifunction devices 10 for convenience of explanation, but since they are essentially the same multifunction device 10, it is expressed as forming a pair again with the virtual device 20. If a new multifunction device 10 is installed in the tenant, a new pair is formed.

[0058] Hereinafter, in this embodiment, a process performed by the real device 10d to form a pair again will be described with reference to a sequence diagram shown in Fig. 4. In Fig. 4, the virtual device 20 may be denoted by the symbol "DS" for convenience.

[0059] The administrator of the real device 10d performs a predetermined operation to request the real device 10d to re-register the virtual device 20 that forms a synchronous pair.

[0060] When the real device 10d receives a re-registration request from the administrator (step S101), the key management unit 11 creates a new key pair, i.e., an owner authentication key, and registers it in the HSM of the board (step S102). The public key of the device authentication key is set in advance in the HSM of the new board. Next, the re-assembly request processing unit 13 transmits a re-assembly request including the public key of the owner authentication key and the public key of the device authentication key to the server 30 (step S103). The re-assembly request includes information indicating that the request is different from a request for forming a new pair.

[0061] Incidentally, as mentioned above, the real device 10c is illustrated as the real device 10d after the board has been replaced. For convenience of explanation, different reference symbols ("10c" and "10d") are used to make it easier to distinguish between the real device 10 before and after the replacement, but the real device 10c and the real device 10d are essentially the same MFP 10, so from the standpoint of the real device 10c, it can be said that a re-assembly request has been made to the server 30. If the real device 10d is a MFP 10 different from the real device 10c, such as a new MFP 10, then as mentioned above, a new assembly request will be made, and the virtual device 20d does not need to take over the data of the virtual device 20c.

[0062] When the reassembly request receiving unit 33 in the server 30 receives the reassembly request from the real device 10d, the reassembly request receiving unit 33 authenticates the real device 10d by the public key of the device authentication key and identifies the tenant 6 to which the real device 10d belongs. If the authentication is not successful, the reassembly request receiving unit 33 does not accept the reassembly request. Next, the survival confirmation control unit 34 requests all virtual devices 20 belonging to the identified tenant 6 to confirm the survival of the real devices 10 that form the pair (step S301).

[0063] In response to a request from the server 30, the survival confirmation control unit 23 in each virtual device 20 confirms survival by transmitting predetermined survival confirmation information to the paired real device 10 (step S201). "Surviving" here means existing as a data synchronization target. The virtual device 20 can confirm the survival of the paired real device 10 by confirming that the paired real device 10 is connected to a network and data can be synchronized.

[0064] When the survival confirmation response unit 14 in each real device 10 receives predetermined survival confirmation information from the paired virtual device 20, it responds by returning predetermined information indicating that the real device is alive (step S151).

[0065] The survival confirmation control unit 23 in each virtual device 20 can confirm that the paired real device 10 exists normally by receiving a response from the paired real device 10 in response to the survival confirmation. On the other hand, if the paired real device 10 does not return predetermined information, it means that the paired real device 10 is not normal, that is, its survival could not be confirmed. The survival confirmation control unit 23 returns the result of the survival confirmation carried out as described above to the server 30 (step S202).

[0066] The survival confirmation control unit 34 in the server 30 receives and collects the survival confirmation results sent from all virtual devices 20 in response to a survival confirmation request.

[0067] 1, the virtual devices 20a, 20b, and 20c should be able to confirm the survival of the paired real devices 10a, 10b, and 10c if they are still alive. However, the real device 10c exists as a real device 10d due to a board replacement as shown in FIG. 3. Furthermore, the virtual device 20c does not hold the public key of the owner authentication key held by the real device 10d. Therefore, the virtual device 20c cannot confirm the survival of the real device 10c after the board replacement, let alone the real device 10d.

[0068] By referring to the survival confirmation results from each virtual device 20, the survival confirmation control unit 34 can determine that the real devices 10a and 10b are alive and the real device 10c is not alive. In other words, if the real device 10 that issued the re-assembly request is called the "request source device" and the virtual device 20 that was paired with the request source device is called the "previously paired other device", the real device 10d, which issued the re-assembly request as described above, corresponds to the "request source device". In addition, the real device 10c, although it is given a different reference number from the real device 10d, is actually substantially the same multifunction device 10 as the real device 10d that issued the re-assembly request, and therefore corresponds to the "request source device". On the other hand, the virtual device 20c, for which the survival of the paired real device 10c could not be confirmed, corresponds to the "previously paired other device". That is, as described later and shown in Fig. 3, the virtual device 20d will be newly paired with the real device 10d, and in this embodiment, the virtual device 20 that will be newly paired with the requesting device in response to the re-pairing request will be referred to as the "newly paired device." In this embodiment, the virtual device 20d corresponds to the "newly paired device."

[0069] As described above, the survival confirmation control unit 34 identifies the virtual device 20c that was synchronized with the real device 10c as the immediately preceding paired device, and also identifies it as the handover source of the data to be synchronized (step S302).

[0070] Thereafter, the virtual device management unit 35 creates a new virtual device 20d that is paired with the real device 10d (step S303), and as described above, identifies the virtual device 20d as the new paired device and becomes the transfer destination of the data to be synchronized from the virtual device 20c.

[0071] When the transfer source and transfer destination of the data to be synchronized are determined in this manner, the data transfer control unit 36 ​​instructs the virtual device 20c and the virtual device 20d to transfer the data (step S304).

[0072] The data transfer processing unit 24 in the virtual device 20c and the data transfer processing unit 24 in the virtual device 20d operate in cooperation with each other under the control of the data transfer control unit 36, and transfer the data to be synchronized stored in the synchronization data storage unit 26 of the virtual device 20c to the virtual device 20d. As a result, the data to be synchronized is stored in the synchronization data storage unit 26 of the virtual device 20d.

[0073] In this manner, data synchronization between the pair of real device 10c and virtual device 20c is taken over by the pair of real device 10d and virtual device 20d.

[0074] Embodiment 2 In the above-mentioned first embodiment, the virtual device 20d is newly created as a new pair of devices in response to a re-grouping request from the real device 10d, and a synchronous pair is formed between the real device 10d and the virtual device 20d instead of the pair of the real device 10c and the virtual device 20c. Thus, in the first embodiment, the virtual device 20d is unconditionally created in response to the re-grouping request, but it is not necessary to create a new virtual device 20d. Specifically, the server 30 may form a pair of the existing virtual device 20c and the real device 10d. Since the virtual device 20c, which is the immediately previous pair of devices, already holds the data to be synchronized, if it is further utilized as the new pair of devices, there is no need to newly create the virtual device 20d, and there is also no need to perform a process of transferring data to be synchronized between the virtual devices 20. In other words, the server 30 may select the request source device, i.e., the virtual device 20c, as the new pair of devices in response to a predetermined condition.

[0075] The device selected as the new pairing device is the existing virtual device 20c, which is the request source device described here, or the newly created virtual device 20d described in the above embodiment 1. When selecting the existing virtual device 20c as the new pairing device, the virtual device management unit 35 does not need to create a new virtual device 20d in step S303 shown in Fig. 4, but can simply select the virtual device 20c as the new pairing device and have the virtual device 20c hold and manage the public key of the owner authentication key. Then, the data transfer process (step S211) controlled by the data transfer processing unit 24 becomes unnecessary.

[0076] When the virtual device 20c is selected as the newly paired device, it is possible to reduce resource consumption that would be required when creating a new virtual device 20d in the cloud 2. In addition, since the data migration process of the synchronization target is not required, it is possible to avoid the burden, time, cost, etc. of the process associated with the data migration.

[0077] On the other hand, when a virtual device 20d is newly created and selected as the new pairing device, by preserving the virtual device 20c for a predetermined period of time, recovery is possible even if the link between the real device 10d and the virtual device 20d is incorrectly established.

[0078] As described above, the server 30 selects the virtual device 20c or the virtual device 20d as a new paired device to be paired with the real device 10d as the request source device according to a predetermined condition. The predetermined condition may be, for example, the operating environment and processing capacity of the virtual device 20, or an instruction from the administrator of the real device 10d. More specifically, for example, if the amount of data to be transferred is equal to or greater than a predetermined threshold, the virtual device 20c is continued to be used to avoid transferring a huge amount of data. Alternatively, the selection may be made according to the object to be replaced in the real device 10c and the reason for the replacement. For example, if the board is replaced, the virtual device 20c is continued to be used, and if the multifunction device 10 or almost the entire device is replaced, a new virtual device 20d is created.

[0079] Embodiment 3 In the above-mentioned first embodiment, the server 30 receives a survival confirmation result from each virtual device 20 in response to a survival confirmation request, and identifies a virtual device 20 for which survival confirmation has not been obtained among the plurality of virtual devices 20 as a previously paired device (steps S301-302 in FIG. 4). As in the above example, the virtual device 20c that was paired with the real device 10c that has become the real device 10d due to the board replacement is always disconnected from the real device 10c, so it is natural that the survival of the real device 10c cannot be confirmed.

[0080] However, for example, when the virtual device 20 attempts to access the paired real device 10 in response to a survival confirmation request from the server 30, it may not be possible to confirm the survival of the real device 10 because, for example, the specification is such that the real device 10 is connected only when synchronizing data, or the real device 10 is in a powered off state, undergoing maintenance, etc. In this case, the server 30 receives multiple survival confirmation results indicating that the survival could not be confirmed, and therefore cannot identify one virtual device 20c that should be the immediately preceding paired device.

[0081] Therefore, in this embodiment, it is possible to cope with a case where survival confirmation results indicating that survival could not be confirmed in response to a survival confirmation request are received from a plurality of virtual devices 20.

[0082] The block configuration of each of the devices 10, 20, and 30 in this embodiment may be the same as that in the first embodiment. Also, the flow of the process performed to re-form a synchronous pair between the real device 10 and the virtual device 20 may be the same as that shown in the sequence diagram in Fig. 4. However, since this embodiment is a process for a case where multiple survival confirmation results indicating that survival could not be confirmed in response to a survival confirmation request are received, the content of the process for identifying the immediately preceding paired device in step S302 is slightly different from that in the first embodiment.

[0083] That is, when multiple survival confirmation results indicating that survival could not be confirmed are received, the virtual device management unit 35 inquires of the administrator of the real device 10d, in other words, the real device 10c as the request source device, for characteristic information indicating the characteristics of the real device 10d. Note that since the real devices 10c and 10d are substantially the same multifunction machine 10, the administrator is the same person. Note that the inquiry may be made by displaying a predetermined message on the operation panel of the real device 10d, or may be sent to a terminal device used by the administrator and displayed. In response to the inquiry from the server 30, the administrator of the real device 10 replies with characteristic information indicating the characteristics of the real device 10c.

[0084] As described above, the real device 10d is a multifunction device 10 formed by replacing the board of the real device 10c, and is therefore substantially the same multifunction device 10. Therefore, it is basically the same model, and there is a high possibility that the functions provided and the configuration of the connected options are the same. Therefore, the administrator of the real device 10d provides information on these hardware configurations and the like to the server 30 as characteristic information of the real device 10c. In addition, information that does not change before and after maintenance work such as replacing the board, such as the purchase date of the real device 10, may be used as characteristic information.

[0085] In addition, for each virtual device 20 (hereinafter referred to as the "previous pairing partner device candidate") that has returned a survival confirmation result to the server 30 indicating that the real device 10d was not alive, before or after the inquiry to the real device 10d, the server 30 acquires, as pairing partner characteristic information, characteristic information indicating the characteristics of the real device 10 held by the virtual device 20.

[0086] When the server receives the characteristic information from the real device 10d, the server compares the characteristic information with the pairing partner characteristic information acquired from each of the previous pairing partner device candidates. As described above, the characteristic information acquired from the real device 10d is highly likely to be almost identical to the pairing partner characteristic information acquired from the virtual device 20c that was paired with the real device 10c. Therefore, the virtual device management unit 35 can specify the virtual device 20c as the previous pairing partner device.

[0087] In addition, since the actual devices 10a, 10b, and 10c belong to the same tenant, it is possible that the same model has been selected, and it is possible that the paired device characteristic information cannot be reliably identified by simply comparing the characteristic information as described above.

[0088] In this case, the survival confirmation control unit 34 may instruct the immediately preceding paired device candidate to perform survival confirmation again. However, in this case, even if the device is not connected to the paired actual device 10, the instruction is to forcibly connect and perform survival confirmation. This makes it possible to narrow down the immediately preceding paired device more than when survival confirmation is simply performed as in step 301.

[0089] Even so, there is a possibility that it is not possible to narrow down to just one immediately preceding pairing partner device. The virtual device management unit 35 may inquire of the administrator of the real device 10d, who was also the administrator of the real device 10c, about the virtual device 20 that was paired with the real device 10c. When inquiring of the administrator, the virtual device management unit 35 may present the pairing partner characteristic information acquired from each immediately preceding pairing partner device candidate by transmitting it to the administrator as described above. By referring to the transmitted pairing partner characteristic information, the administrator can easily select the immediately preceding pairing partner device from the immediately preceding pairing partner device candidates.

[0090] In this embodiment, taking into consideration the work of the administrator, the administrator is queried only when the immediately preceding group's partner device cannot be selected from the immediately preceding group's partner device candidates based on the characteristic information alone, but the administrator may also be queried when multiple immediately preceding group's partner device candidates have been presented.

[0091] According to this embodiment, even if there are a plurality of candidates for the immediately preceding paired device as a result of the survival check, it is possible to more appropriately select the virtual device 20 that corresponds to the immediately preceding paired device.

[0092] In the above embodiments, the first information processing device and the second information processing device have been described using a multifunction device as an example, but they may also be other devices such as a printer, or an information processing device that requires data synchronization such as a PC, or an equipment equipped with such an information processing device.

[0093] Moreover, the processes explained in each of the first to third embodiments may be appropriately combined and carried out as necessary.

[0094] In the above embodiments, the term "processor" refers to a processor in a broad sense, including general-purpose processors (e.g., CPU: Central Processing Unit, etc.) and dedicated processors (e.g., GPU: Graphics Processing Unit, ASIC: Application Specific Integrated Circuit, FPGA: Field Programmable Gate Array, programmable logic device, etc.).

[0095] In addition, the operations of the processor in the above embodiments may be performed not only by one processor, but also by multiple processors located at physically separate locations working together. The order of the operations of the processor is not limited to the order described in the above embodiments, and may be changed as appropriate.

[0096] (Additional Note) (((1))) a processor that is paired with a first information processing device that holds data and manages a second information processing device that is a synchronization partner of the data; The processor, in response to a re-pairing request from the first information processing device that has been dissolved from its pair with the second information processing device, requesting a plurality of the second information processing devices to confirm the existence of the first information processing device that is paired with the second information processing device; receiving a live confirmation result returned from each of the second information processing devices in response to the live confirmation request; when the first information processing device which has made the re-grouping request is a request source device and the second information processing device which has been paired with the request source device is a previous pairing partner device, referring to the received survival confirmation result, the second information processing device whose survival has not been confirmed is specified as the previous pairing partner device; An information processing system comprising: (((2))) The information processing system according to (((1))), wherein the processor selects the second information processing device that will newly form a pair with the request source device as a new paired device in accordance with a predetermined condition. (((3))) The information processing system described in (((2))) is characterized in that when the processor selects the second information processing device other than the immediately preceding partner device as the new partner device, it transfers the data held by the immediately preceding partner device to the new partner device. (((4))) The information processing system according to (((2))), wherein the processor selects the immediately preceding partner device as the new partner device. (((5))) The information processing system described in any one of (((1))) to (((4))) is characterized in that when the processor receives multiple survival confirmation results indicating that survival could not be confirmed, it selects the immediately preceding partner device from among the multiple second information processing devices that sent the survival confirmation results indicating that survival could not be confirmed by referring to characteristic information indicating the characteristics of the requesting device or by inquiring to an administrator of the requesting device. (((6))) The processor, When referring to the characteristic information, the characteristic information is acquired by making a request to the request source device; selecting the immediately preceding pairing partner device according to a result of comparing the acquired characteristic information with pairing partner characteristic information held by each of the second information processing devices that have transmitted the survival confirmation result indicating that survival could not be confirmed, the pairing partner characteristic information indicating characteristics of the first information processing device that is paired with the second information processing device; The information processing system according to (((5))) is characterized in that (((7))) The processor, When making an inquiry to the administrator, from each of the second information processing devices that have transmitted the survival confirmation result indicating that survival could not be confirmed, paired partner characteristic information indicating characteristics of the first information processing device that is paired with the second information processing device is acquired; presenting the acquired plurality of pieces of partner characteristic information to an administrator of the request source device; The information processing system according to (((5))) is characterized in that (((8))) The information processing system according to any one of ((1))) to (((7))), wherein the second information processing device is formed on a cloud. (((9))) An information processing system described in any one of ((1))) to (((8))), characterized in that the first information processing device and the second information processing device each hold one of a pair of information that can prove that they form a group. (((10))) A computer that manages a second information processing device that is paired with a first information processing device that holds data and is a synchronization partner of the data, a function of requesting a plurality of the second information processing devices to confirm the existence of the first information processing device paired with the second information processing device in response to a re-pairing request from the first information processing device that has been dissolved from the pairing with the second information processing device; a function of receiving a live confirmation result returned from each of the second information processing devices in response to the live confirmation request; a function of referring to the received survival confirmation result and identifying the second information processing device, whose survival has not been confirmed, as the immediately preceding pairing partner device, when the first information processing device which has made the re-grouping request is a request source device and the second information processing device which has formed a pair with the request source device is a immediately preceding pairing partner device; A program to achieve this.

[0097] According to the invention described in (((1))), in managing a second information processing device with which data held by a first information processing device is synchronized, in response to a request for re-pairing from a first information processing device whose pairing with the second information processing device has been dissolved, it is possible to identify from among a plurality of second information processing devices the second information processing device that had been paired with the first information processing device. According to the invention described in (((2))), a second information processing device that meets a predetermined condition can be selected as a new pairing partner device. According to the invention described in (((3))), the data to be synchronized that was held by the immediately preceding partner device can be handed over to the new partner device. According to the invention described in (((4))), there is no need to migrate data to be synchronized. According to the invention described in (((5))), it is possible to narrow down the processing to only one immediately preceding paired device. According to the invention described in (((6))), a second information processing device paired with a first information processing device having characteristics in common with the request issuing device can be selected as a immediately preceding paired other device. According to the invention described in (((7))), it is possible to provide the administrator with the characteristics of the first information processing device when the immediately preceding paired partner device is selected. According to the invention described in ((8)), it is possible to achieve synchronization with another external information processing device. According to the invention described in (((9))), it is possible to guarantee a synchronization partner for data. According to the invention described in (((10))), in managing a second information processing device with which data held by a first information processing device is synchronized, in response to a request for re-pairing from a first information processing device whose pairing with the second information processing device has been dissolved, it is possible to identify the second information processing device that was paired with the first information processing device from among a plurality of second information processing devices. [Explanation of symbols]

[0098] 2 cloud, 4 network, 6 tenant, 10, 10a, 10b, 10c, 10d real devices (multifunction peripherals), 11, 21, 31 key management units, 12, 22 synchronization processing units, 13 reassembly request processing units, 14 survival confirmation response units, 15, 25 control units, 16, 26 synchronization data storage units, 20, 20a, 20b, 20c, 20d virtual devices (multifunction peripherals), 23 survival confirmation control units, 24 data migration processing units, 30 server, 32 synchronization control units, 33 reassembly request receiving units, 34 survival confirmation control units, 35 virtual device management units, 36 data migration control units.

Claims

1. a processor that manages a second information processing device that is paired with a first information processing device that holds data and is a synchronization partner of the data; The processor, in response to a re-pairing request from the first information processing device that has been dissolved from the pair with the second information processing device, requesting a plurality of the second information processing devices to confirm the existence of the first information processing device that is paired with the second information processing device; receiving a live confirmation result returned from each of the second information processing devices in response to the live confirmation request; when the first information processing device which has made the re-grouping request is a request source device and the second information processing device which has been paired with the request source device is a previous pairing partner device, referring to the received survival confirmation result, the second information processing device whose survival could not be confirmed is specified as the previous pairing partner device; An information processing system comprising:

2. 2. The information processing system according to claim 1, wherein the processor selects the second information processing device that will newly form a pair with the request issuing device as a new paired device in accordance with a predetermined condition.

3. The information processing system described in claim 2, characterized in that when the processor selects the second information processing device other than the immediately preceding partner device as the new partner device, it transfers the data held by the immediately preceding partner device to the new partner device.

4. 3. The information processing system according to claim 2, wherein the processor selects the immediately preceding partner device as the new partner device.

5. The information processing system described in claim 1, characterized in that when the processor receives multiple survival confirmation results indicating that survival could not be confirmed, it selects the immediately preceding partner device from among the multiple second information processing devices that sent the survival confirmation results indicating that survival could not be confirmed by referring to characteristic information indicating the characteristics of the requesting device or by inquiring to the administrator of the requesting device.

6. The processor, When referring to the characteristic information, the characteristic information is acquired by making a request to the request source device; selecting the immediately preceding pairing partner device according to a result of comparing the acquired characteristic information with pairing partner characteristic information held by each of the second information processing devices that have transmitted the survival confirmation result indicating that survival could not be confirmed, the pairing partner characteristic information indicating characteristics of the first information processing device that is paired with the second information processing device; 6. The information processing system according to claim 5.

7. The processor, When making an inquiry to the administrator, from each of the second information processing devices that have transmitted the survival confirmation result indicating that survival could not be confirmed, paired partner characteristic information indicating characteristics of the first information processing device that is paired with the second information processing device is acquired; presenting the acquired plurality of pieces of partner characteristic information to an administrator of the request source device; 6. The information processing system according to claim 5.

8. The information processing system according to claim 1 , wherein the second information processing device is formed on a cloud.

9. 2. The information processing system according to claim 1, wherein the first information processing device and the second information processing device each hold one of a pair of information that can prove that they form a pair.

10. A computer that manages a second information processing device that is paired with a first information processing device that holds data and is a synchronization partner of the data, a function of requesting a plurality of the second information processing devices to confirm the existence of the first information processing device paired with the second information processing device in response to a re-pairing request from the first information processing device that has been dissolved from the pair with the second information processing device; a function of receiving a live confirmation result returned from each of the second information processing devices in response to the live confirmation request; a function of referring to the received survival confirmation result and specifying the second information processing device, the survival of which could not be confirmed, as the immediately preceding pairing partner device, when the first information processing device which has made the re-grouping request is a request source device and the second information processing device which has been paired with the request source device is a immediately preceding pairing partner device; A program to achieve this.

Images