Software updating device, software updating method, and software updating system

Abstract

A software updating device 10 for updating software of an apparatus 20 that connects to the software updating device 10 using distributed networking middleware, the software updating device 10 comprising: an update object determination unit 12 that determines, on the basis of the forms of data transmission and reception carried out by respective apparatuses 20, whether the software of the apparatuses 20 can be updated while the distributed networking middleware is operated; and a software update unit 13 that updates the software of the apparatuses 20. This makes it possible to provide a software updating device, a software updating method, and a software updating system that, when updating software of apparatuses that are connected using distributed networking middleware, are capable of updating of the software without introducing redundancy and without stopping the whole system.

Description

Title of Invention: SOFTWARE UPDATING DEVICE, SOFTWARE UPDATING METHOD, AND SOFTWARE UPDATING SYSTEM Technical Field

[0001] The present invention relates to a software update device, a software update method, and a software update system. In particular, the invention relates to, for example, a software update device that is useful when software in a device connected using distributed networking middleware is updated. Background Art

[0002] A software update may be executed on a device connected using distributed networking middleware.

[0003] PTL 1 discloses a remote maintenance device that is connected to a control device in a train operation management system via a communication path and remotely modifies software in the control device. The remote maintenance device includes an information reception unit that receives operation-related information related to train operation, a transmission speed determination unit that determines a load state applied to the control device based on the operation-related information and determines a transmission speed at which modified software is transmitted to the control device according to the load state, and a modified software transmission unit that transmits the modified software to the control device at the transmission speed. PTL 2 discloses a maintenance system that maintains an electronic computer by connecting a maintenance device via a network. In the maintenance system, the electronic computer includes a copying unit that copies, to a maintenance device, a program necessary for executing a service being provided by an own system of the electronic computer, and a transmission unit that transmits hardware structure information of the electronic computer to the maintenance device, and the maintenance device includes a CPU that executes a same command set as that of the computer, and a unit that emulates a hardware structure of the computer on the system of the electronic computer based on the hardware structure information. Citation List Patent Literature

[0004] PTL 1: JP2016-68878A PTL 2: JPHO9-293001A Summary of Invention Technical Problem

[0005] A software update for a device can be executed by stopping an entire system outside service hours or during maintenance hours. In addition, it is possible to execute the update in a state where a service is continued by making elements (devices) constituting the system redundant. However, when stopping the entire system, it is necessary to set a maintenance period in which the entire system can be stopped. In addition, even in a case of an update for a part of devices, it is necessary to stop a device that is not an update target. On the other hand, in order to make the element (device) redundant, it is necessary to prepare a same device (hardware, software) as the element (device) to be updated, which is costly. In particular, a distributed networking middleware such as a data distribution service (DDS) is in an environment in which a data flow cannot be centrally controlled, and thus it is difficult to install a load balancer essential for redundancy, and redundancy is An object of the invention is to provide a software update device, a software update method, and a software update system that can execute a software update without redundancy and without stopping the entire system when software in a device connected using the distributed networking middleware is updated. Solution to Problem

[0006] In order to solve the above-described problem, the invention is a software update device for updating software in a device connected to an own device using distributed networking middleware. The software update device includes: an update target determination unit configured to determine, based on a mode of data transmission and reception executed in the device, whether the software in the device is capable of being updated in a state where the distributed networking middleware is operated; and a software update unit configured to execute a software update for the device. In this case, it is possible to provide the software update device that can execute the software update without redundancy and without stopping an entire system.

[0007] Here, the mode of data transmission and reception may include a data transfer direction of the device. In this case, a mode suitable for causing an influence on the software update system may be included. In addition, the update target determination unit determines that, when the device transmits data in terms of the data transfer direction, the software in the device is not be capable of being updated in the state where the distributed networking middleware is operated. In this case it can be determined that the software cannot be updated for a device in which data transmitted from the device may be lost. Further, the mode of data transmission and reception may include an increase or decrease in input data to the device. In this case, a mode suitable for causing an influence on the software update system may be included. Further, the update target determination unit determines that, when the input data decreases in terms of the increase or decrease in the input data, the software in the device is not be capable of being updated in the state where the distributed networking middleware is operated. In this case, it can be determined that the software cannot be updated for the device requiring a behavior check. In addition, the update target determination unit determines the mode of data transmission and reception according to a specification of a data schema. In this case, it is possible to more easily obtain information on the data transfer direction of the device and the increase or decrease in the input data to the device. Further, the mode of data transmission and reception may include whether data retransmission to the device is possible. In this case, a mode suitable for causing an influence on the software update system may be included. Further, the update target determination unit may determine that, when the data is not be capable of being retransmitted to the device in terms of whether the data retransmission is possible, the software in the device is not be capable of being updated in the state where the distributed networking middleware is operated. In this case it can be determined that the software cannot be updated for a device in which data transmitted to the device may be lost. In addition, the update target determination unit may determine whether the data retransmission is possible according to a specification of the distributed networking middleware. In this case, it is possible to more easily obtain information on whether the data retransmission is possible . In addition, the update target determination unit may determine that the software in the device is capable of being updated in the state in which the distributed networking middleware is operated when the mode of data transmission and reception satisfies a case in which the device receives the data but does not transmit the data in terms of the data transfer direction to the device, a case in which the input data increases in terms of the increase or decrease in the input data to the device, and a case in which the data is capable of being retransmitted to the device in terms of whether the data retransmission to the device is possible. In this case, when the software update for the device is executed while the distributed networking middleware is operated, a device that does not cause an influence on the software update system can be extracted.

[0008] Further, the invention is a software update method of updating software in a device connected to an own device using distributed networking middleware. The software update method includes: by a processor executing a program recorded in a memory, determining, based on a mode of data transmission and reception executed in the device, whether the software in the device is capable of being updated in a state where the distributed networking middleware is operated; and executing a software update for the device. In this case, it is possible to provide the software update method that can execute the software update without redundancy and without stopping an entire system.

[0009] Further, the invention is a software update system. The software update system includes: a device connected via distributed networking middleware; and a software update device configured to update software in the device, in which the software update device includes: an update target determination unit configured to determine, based on a mode of data transmission and reception executed in the device, whether the software in the device is capable of being updated in a state where the distributed networking middleware is operated; and a software update unit configured to execute a software update for the device. In this case, it is possible to provide the software update system that does not cause an influence on a system side even when the software update for the device is executed. Advantageous Effects of Invention

[0010] According to the invention, it is possible to provide a software update device, a software update method, and a software update system that can execute a software update without redundancy and without stopping an entire system when software in a device connected using the distributed networking middleware is updated. Brief Description of Drawings

[0011] [FIG. 1] FIG. 1 is a diagram illustrating an overall configuration of a software update system to which a software update device according to the present embodiment is applied. [FIG. 2] FIG. 2 is a conceptual diagram illustrating DDS . [FIG. 3] FIG. 3 is a diagram illustrating operations of the software update device. [FIG. 4] (a) and (b) of FIG. 4 are each a diagram illustrating data schemas. [FIG. 5] FIG. 5 is a flowchart illustrating operations of the software update device. Description of Embodiments

[0012] Hereinafter, an embodiment of the invention will be described in detail with reference to the drawings.

[0013] <0verall Description of Software Update System 1> FIG. 1 is a diagram illustrating the overall configuration of a software update system 1 to which a software update device 10 according to the present embodiment is applied. As illustrated in FIG. 1, the software update system 1 includes the software update device 10 and a device 20. The software update device 10 is a device that updates software in the device 20. The devices 20 are devices connected to each other using distributed networking middleware. The device 20 is connected to the software update device 10 using the distributed networking middleware. Although only one device 20 is illustrated here, a plurality of devices 20 may be provided. The "distributed networking middleware" is software that enables one or more types of communication and connection between two or more applications and application components in a distributed network. The software in the device 20 is not particularly limited as long as the software is a computer program that executes some processing to operate the device 20. A software update is executed, for example, for a purpose of correcting a bug or a problem of the software or improving a function of the device 20.

[0014] The software update device 10 and the device 20 are each a computer device such as a personal computer (PC), a smartphone, and a tablet. The software update device 10 and the device 20 each include a processor such as a central processing unit (CPU) that is an arithmetic unit, and a main memory and a storage such as a hard disk drive (HDD) that are storage units. Here, the processor executes various types of software such as an OS (basic software) and an application program (application software). The main memory is a storage area for storing various types of software and data used for execution thereof, and the storage is a storage area for storing input data to various types of software and output data from various types of software. The software update device 10 and the device 20 each include a communication interface for communicating with the outside. Further, a display mechanism including a video memory, a display, or the like, and an input mechanism such as a keyboard, a mouse, or a touch panel may be provided.

[0015] The distributed networking middleware is, for example, a data distribution service (DDS). Hereinafter, the distributed networking middleware will be described as the DDS .

[0016] FIG. 2 is a conceptual diagram illustrating the DDS. As illustrated in FIG. 2, in the DDS, "Topic" is published from "DATA WRITER", and "DATA READER" subscribes to the published "Topic" to execute communication. That is, there is a direction in which data is transmitted. In addition, in "Topic", what data is to be transmitted (a type of data (data schema)) is declared in advance. Then, "DATA WRITER" and "DATA READER" having a same "Topic" communicate with each other. Correspondence between "DATA WRITER" and "DATA READER" can be freely set such as one-to-one, one-to-many, many-to-one, or many-to-many. In the DDS, a type of data (data schema) exchanged between the devices 20 is defined, and a direction of the data (Publisher / Subscriber) is defined to execute the communication. The DDS has high real-time response performance and allows a network system to be flexibly reconfigured even when the device 20 is changed. Each DDS domain is completely independent from the others, and data cannot be communicated across different DDS domains. The software update device 10 and the device 20 according to the present embodiment correspond to "DATA WRITER" and "DATA READER" in the DDS.

[0017] The DDS can be used in fields such as power generation control of a dam used in hydroelectric power generation, rotation control of a blade in wind power generation, autonomous traveling of an automobile, air traffic control, operation management of a railway or the like, and control of each device in steelmaking. Hereinafter, a case in which the DDS is used for railway operation management will be described as an example. In this case, the device 20 corresponds to a station control device that controls a railroad crossing device or a switch (point), an operation management console, an operation display panel, or the like.

[0018] <Description of Functional Configuration of Software Update Device 10> Returning to FIG. 1, the functional configuration of the software update device 10 will be described. The software update device 10 includes an information reception unit 11, an update target determination unit 12, a software update unit 13, a software repository 14, and a software transfer unit 15. The information reception unit 11 acquires a device list that is a list of the devices 20, a specification of the DDS, and a specification of the data schema as information for determining whether the software in the device 20 can be updated in a state where the DDS is operated The specification of the DDS and the specification of the data schema will be described in detail later.

[0019] The update target determination unit 12 determines, based on a mode of data transmission and reception executed in the device 20, whether the software in the device 20 can be updated in the state where the DDS is operated. Then, an analysis result display is presented to an administrator of the software update system 1. The administrator refers to the analysis result display, makes a plan for a software update for the device 20, and instructs the software update device 10 to execute the update.

[0020] The software update unit 13 executes the software update for the device 20. At this time, the software update unit 13 executes the software update in the state in which the DDS is operated for the device 20 for which the update target determination unit 12 determines that the software can be updated in the state where the DDS is operated. On the other hand, the software update unit 13 executes the software updates when the DDS is stopped for the device 20 for which the update target determination unit 12 determines that the software cannot be updated in the state where the DDS is operated. Functions of the information reception unit 11, the update target determination unit 12, and the software update unit 13 can be implemented by the processor or the main memory.

[0021] The software repository 14 is a storage unit that stores software to be updated. A function of the software repository 14 can be implemented by the storage such as the hard disk drive (HDD). The software transfer unit 15 is an output unit that transmits the software to be updated to the device 20. A function of the software transfer unit 15 can be implemented by the communication interface.

[0022] <Description of Operation of Software Update Device 10> Next, the operation of the software update device 10 will be described. FIG. 3 is a diagram illustrating operations of the software update device 10. FIG. 3 illustrates a case in which the device 20 is a railroad crossing device, a data transmission device, and a statistical information monitoring device. It is illustrated that data is transmitted and received in the order of the railroad crossing device -> the data transmission device -> the statistical information monitoring device. In this case, the railroad crossing device transmits, for example, the number of times a railroad crossing is opened and closed as data. The data transmission device relays, for example, this data. The statistical information monitoring device monitors, for example, the number of times that railroad crossings at a plurality of railroad crossing devices are opened and closed FIG. 3 illustrates a method in which the software update device 10 determines whether the software in the device 20 can be updated in the state where the DDS is operated. In the present embodiment, the update target determination unit 12 of the software update device 10 determines, based on the mode of data transmission and reception executed in the device 20, whether the software can be updated. Specifically, the mode of data transmission and reception executed in the device 20 includes a data transfer direction of the device 20, an increase or decrease in input data to the device 20, and whether data retransmission to the device 20 is possible.

[0023] The data transfer direction of the device 20 can be determined by whether to execute reception / transmission with respect to the device 20. The update target determination unit 12 then determines that the device 20 needs to receive data but not transmit data in terms of the data transfer direction. That is, if the device 20 is a (receiving) side at which data is received and is not a (transmitting) side at which data is transmitted, there is no influence on the device 20 due to the software update. That is, when data is to be received, the data may be received after the software is updated. Therefore, there is no influence on the software update system 1 . On the other hand, when data is to be transmitted, the data cannot be transmitted while the software is updated, which causes an influence on the software update system 1. In this case, it can also be said that the update target determination unit 12 determines that, when the device 20 transmits data in terms of the data transfer direction, the software in the device 20 cannot be updated in the state where the DDS is operated.

[0024] The increase or decrease in the input data to the device 20 can be determined by whether the input data increases or decreases. The update target determination unit 12 then determines that the input data needs to increase or remain the same in terms of the increase or decrease in the input data. That is, when the input data increases, this increase is data that is irrelevant to the receiving side, and thus does not cause an influence on a behavior of the software after the software update. Therefore, there is no influence on the software update system 1. On the other hand, when the input data decreases, this decrease may be data that is relevant to the receiving side. That is, this decrease may be data used by the device 20 on the receiving side. Therefore, a behavior check test is required. In this case, it can also be said that the update target determination unit 12 determines that, when the input data decreases in terms of the increase or decrease in the input data, the software in the device 20 cannot be updated in the state where the DDS is operated.

[0025] Whether the data retransmission to the device 20 is possible can be determined by whether the data retransmission to the device 20 can be executed. The update target determination unit 12 then determines that it is necessary that the data can be retransmitted to the device 20 in terms of whether the data retransmission is possible. That is, if the data can be retransmitted to the device 20, data that cannot be received during the software update for the device 20 may be received after the software update. Therefore, there is no influence on the software update system 1. On the other hand, when the data cannot be retransmitted to the device 20, the device 20 cannot receive the data. Therefore, the software update system 1 is influenced. In this case, it can also be said that the update target determination unit 12 determines that, when the data cannot be retransmitted to the device 20 in terms of whether the data retransmission is possible, the software in the device 20 cannot be updated in the state where the DDS is operated.

[0026] In FIG. 3, in a case in which the device 20 is the railroad crossing device, since the data transfer direction is only transmission and is not reception, the update target determination unit 12 determines that the software cannot be updated in the state where the DDS is operated. In addition, the increase or decrease in the input data to the device 20 does not change, and there is no problem. However, since the data retransmission to the device 20 is not possible, the update target determination unit 12 also determines in this respect that the software cannot be updated in the state where the DDS is operated.

[0027] In FIG. 3, in a case in which the device 20 is the data transmission device, since the data transfer direction is both reception and transmission, the update target determination unit 12 determines that the software cannot be updated in the state where the DDS is operated. In addition, the increase or decrease in the input data to the device 20 is a decrease, and the update target determination unit 12 also determines in this respect that the software cannot be updated in the state where the DDS is operated. Since the data retransmission to the device 20 is possible, there is no problem in this respect.

[0028] In FIG. 3, in a case in which the device 20 is the statistical information monitoring device, the data transfer direction is only reception and is not transmission The increase or decrease in the input data to the device 20 is an increase because the transmitted data is accumulated. Further, the data retransmission to the device 20 is possible. Therefore, the update target determination unit 12 determines that the software can be updated in the state where the DDS is operated.

[0029] Therefore, the update target determination unit 12 determines that the software in the device 20 can be updated in the state in which the DDS is operated when the mode of data transmission and reception satisfies a case in which the device 20 receives the data but does not transmit the data in terms of the data transfer direction, a case in which the input data increases in terms of the increase or decrease in the input data to the device 20, and a case in which the data can be retransmitted to the device 20 in terms of whether the data retransmission is possible. That is, when all of these three conditions are satisfied, the update target determination unit 12 determines that the software in the device 20 can be updated in the state where the DDS is operated.

[0030] The update target determination unit 12 determines whether the data retransmission is possible according to the specification of the DDS. That is, since whether the data retransmission is to be executed at the time of data transfer between the devices 20 is determined in advance as the specification of the DDS, the update target determination unit 12 can determine whether the data retransmission is possible. More specifically, whether the data retransmission is possible depends on a specification of a DDS framework installed in the device 20. Here, an allowable range in which retransmission can be executed is set, such as within how many seconds after communication is interrupted or how many transmissions in a data history can be transmitted. It is determined according to the allowable range whether retransmitted data can be received after the device 20 whose software is to be updated is restarted. On the other hand, the update target determination unit 12 determines the data transfer direction of the device 20 and the increase or decrease in the input data to the device 20 according to the specification of the data schema.

[0031] (a) and (b) of FIG. 4 are each a diagram illustrating data schemas. The data transfer direction can be determined based on information held in the DDS framework that is installed in the device 20 and illustrated in (a) of FIG. 4. In this case, a Publisher holds a list of Subscribers, and thus the update target determination unit 12 determines the data transfer direction. When a list of transmission destinations is not held in the DDS framework, the update target determination unit 12 associates a Topic to which data from the Publisher is transmitted with a Subscriber that receives the data through a same topic. The update target determination unit 12 then determines the data transfer direction according to Topic of the device 20 and an attribute of the Publisher or the Subscriber.

[0032] The increase or decrease in the input data to the device 20 can be determined based on the specification of the data schema read by the DDS framework of the device 20. The update target determination unit 12 extracts, from a history of the data schema, a difference between items of the data schema during a relevant period, and determines the increase or decrease based on an extraction result.

[0033] Here, when a received data schema VI illustrated in a left diagram of (b) of FIG. 4 is compared with a data schema V2 to be transmitted illustrated in a right diagram of (b) of FIG. 4, the data schema V2 to be transmitted illustrated in the right diagram of (b) of FIG. 4 has an increase in one row of "int data3". Therefore, in this case, the update target determination unit 12 determines, based on a change in an input data schema, that the input data increases.

[0034] FIG. 5 is a flowchart illustrating operations of the software update device 10. First, the information reception unit 11 of the software update device 10 acquires the device list of the devices 20 serving as update targets (S101). Next, the information reception unit 11 acquires a device specification of the update target (S102) . Further, the information reception unit 11 acquires the specification of the DDS and the specification of the data schema of the device 20 serving as the update target (S103) . Then, the update target determination unit 12 acquires, based on the specification of the DDS and the specification of the data schema, whether the data retransmission to the device 20 serving as the update target is possible, the data transfer direction of the device 20 serving as the update target, and the change in the input data schema (8104) . Next, the update target determination unit 12 checks the following conditions for each device 20 serving as the update target (S105). That is, the update target determination unit 12 determines whether the data retransmission to the device 20 is possible (S106) . Further, the update target determination unit 12 determines whether the direction of the data of the device 20 is only reception (input) (S107) . Further, the update target determination unit 12 determines whether the input data increases based on the change in the input data schema (S108). Then, when all of S106 to S108 is Yes, the update target determination unit 12 determines that the software in the device 20 serving as the update target can be updated in the state where the DDS is operated, and displays this device 20 as a candidate of the device 20 serving as the update target (S109). When any one of S106 to S108 is No, the update target determination unit 12 ends a series of processes.

[0035] According to the above-described embodiment, there are provided a software update device, a software update method, and a software update system that can execute the software update without redundancy and without stopping the entire system when the software in the device 20 connected using the distributed networking middleware such as the DDS is updated.

[0036] <Description of Software Update Method> The processing executed by the software update device 10 described above is implemented by cooperation between software and hardware resources. That is, the processor in a computer provided in the software update device 10 loads the software for implementing the above-described functions into the main memory and executes the software to implement the functions. Therefore, the processing executed by the software update device 10 is the software update method of updating the software in the device 20 connected to the software update device 10, which is an own device, using the distributed networking middleware, and can be regarded as a software update method of, by the processor executing the program recorded in the memory, determining, based on the mode of data transmission and reception executed in the device 20, whether the software in the device 20 can be updated in the state where the distributed networking middleware such as the DDS is operated, and executing the software update for the device 20.

[0037] Although the embodiment is described above, the technical scope of the invention is not limited to the scope described in the above embodiment. It is evident from the recitation of the claims that various modifications or improvements made to the above-described embodiment are also included within the technical scope of the invention. Reference Signs List

[0038] 1: software update system 10: software update device 11: information reception unit 12: update target determination unit 13: software update unit 14: software repository 15: software transfer unit 20: device

Claims

1. A software update device for updating software in a device connected to an own device using distributed networking middleware, the software update device comprising:an update target determination unit configured to determine, based on a mode of data transmission and reception executed in the device, whether the software in the device is capable of being updated in a state where the distributed networking middleware is operated; anda software update unit configured to execute a software update for the device.

2. The software update device according to claim 1, whereinthe mode of data transmission and reception includes a data transfer direction of the device.

3. The software update device according to claim 2, whereinthe update target determination unit determines that,when the device transmits data in terms of the data transferdirection, the software in the device is not be capable of being updated in the state where the distributed networking middleware is operated.[Claim 4 JThe software update device according to claim 1, whereinthe mode of data transmission and reception includes an increase or decrease in input data to the device.

5. The software update device according to claim 4, whereinthe update target determination unit determines that, when the input data decreases in terms of the increase or decrease in the input data, the software in the device is not capable of being updated in the state where the distributed networking middleware is operated.

6. The software update device according to any one of claims 2 to 5, whereinthe update target determination unit determines the mode of data transmission and reception according to aspecification of a data schema.

7. The software update device according to claim 1, whereinthe mode of data transmission and reception includes whether data retransmission to the device is possible.

8. The software update device according to claim 7, whereinthe update target determination unit determines that, when the data is not capable of being retransmitted to the device in terms of whether the data retransmission is possible, the software in the device is not capable of being updated in the state where the distributed networking middleware is operated.

9. The software update device according to claim 7 or 8, whereinthe update target determination unit determines whether the data retransmission is possible according to a specification of the distributed networking middleware.

10. The software update device according to claim 1, whereinthe update target determination unit determines that the software in the device is capable of being updated in the state in which the distributed networking middleware is operated when the mode of data transmission and reception satisfies a case in which the device receives the data but does not transmit the data in terms of the data transfer direction to the device, a case in which the input data increases in terms of the increase or decrease in the input data to the device, and a case in which the data is capable of being retransmitted to the device in terms of whether the data retransmission to the device is possible.

11. A software update method of updating software in a device connected to an own device using distributed networking middleware, the software update method comprising:by a processor executing a program recorded in a memory,determining, based on a mode of data transmission and reception executed in the device, whether the software in the device is capable of being updated in a state where thedistributed networking middleware is operated; and executing a software update for the device.

12. A software update system comprising:a device connected via distributed networking middleware; anda software update device configured to update software in the device, whereinthe software update device includes:an update target determination unit configuredto determine, based on a mode of data transmission and reception executed in the device, whether the software in the device is capable of being updated in a state where the distributed networking middleware is operated; anda software update unit configured to execute a software update for the device.INTERNATIONAL SEARCH REPORT International application No. PCT / JP2024 / 007392A. CLASSIFICATION OF SUBJECT MATTER G06F 5 / 65(2018.01)1 FI: G06F8 / 65 According to International Patent Classification (IPC) or to both national classification and IPC B. FIELDS SEARCHED Minimum documentation searched (classification system followed by classification symbols) G06F8 / 65 Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched Published examined utility model applications of Japan 1922-1996 Published unexamined utility model applications of Japan 1971-2024 Registered utility model specifications of Japan 1996-2024 Published registered utility model applications of Japan 1994-2024 Electronic data base consulted during the international search (name of data base and, where practicable, search terms used) C. DOCUMENTS CONSIDERED TO BE RELEVANT Category* Citation of document, with indication, where appropriate, of the relevant passages Relevant to claim No. A JP 2017-117399 A (ICOM INC.) 29 June 2017 (2017-06-29) paragraphs [0033], [0037] 1-12 A WO 2018 / 190015 Al (SONY CORPORATION) 18 October 2018 (2018-10-18) paragraphs [0246]-[0263], fig. 20, 21 1-12 A WO 2018 / 189975 Al (SUMITOMO ELECTRIC INDUSTRIES, LTD.) 18 October 2018 (2018-10-18) paragraphs [0073]-[0086] 1-12 | | Further documents are listed in the continuation of Box C. | J | See patent family annex. * Special categories of cited documents: “A” document defining the general state of the art which is not considered to be of particular relevance “D” document cited by the applicant in the international application ‘4E” earlier application or patent but published on or after the international filing date *4L” document which may throw doubts on priority claim(s) or which is cited to establish the publication date of another citation or other special reason (as specified) “O” document referring to an oral disclosure, use, exhibition or other means “P” document published prior to the international filing date but later than the priority date claimed “T” later document published after the international filing date or priority date and not in conflict with the application but cited to understand the principle or theory underlying the invention “X” document of particular relevance; the claimed invention cannot be considered novel or cannot be considered to involve an inventive step when the document is taken alone “Y” document of particular relevance; the claimed invention cannot be considered to involve an inventive step when the document is combined with one or more other such documents, such combination being obvious to a person skilled in the art document member of the same patent family Date of the actual completion of the international search Date of mailing of the international search report 18 April 2024 07 May 2024 Name and mailing address of the ISA / JP Authorized officer Japan Patent Office (ISA / JP) 3-4-3 Kasumigaseki, Chiyoda-ku, Tokyo 100-8915 Japan Telephone No.Form PCT / ISA / 210 (second sheet) (July 2022)INTERNATIONAL SEARCH REPORT Information on patent family membersInternational application No.Patent document cited in search report Publication date (day / month / year) Patent family member)s) Publication date (day / month / year) JP 2017-117399 A 29 June 2017 (Family: none) WO 2018 / 190015 Al 18 October 2018 US 2020 / 0036774 Al paragraphs [0302]-[0319], fig. 20,21 WO 2018 / 189975 Al 18 October 2018 US 2020 / 0034140 Al paragraphs [0118]-[0131]

Images