JP2009116703A - Information processing apparatus, information processing method and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an information processing apparatus, an information processing method and a program which can suitably construct a system for monitoring information of equipment. <P>SOLUTION: The information processing apparatus includes: an acquisition target receiving means for receiving the specification of equipment whose information is to be obtained out of data composing the information by an application for providing the information of the equipment connected to a network to a user; a URI generation means for generating an URI of data to be obtained based on the specification by the application; a data acquisition means for transmitting an acquisition request of data corresponding to the URI and acquiring the data by receiving a response to the acquisition request; and a recording means for recording the obtained data in a storage area which can be referred to by the application. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to an information processing device, an information processing method, and a program, and more particularly, to an information processing device, an information processing method, and a program that acquire information about devices connected to a network.

Various network devices such as a printer, a copier, a FAX, a router, and a PC (Personal Computer) are connected to a network in an office in a company. 2. Description of the Related Art Conventionally, there are systems that remotely monitor the operating status of dispersed network devices and display the information. According to such a system, the administrator can easily monitor a plurality of network devices without going to the place where each device is installed.
JP 2006-260422 A

  As a method for constructing such a system, it is conceivable to use commercially available package software. In this case, the system can be constructed relatively easily by installing the package software on a computer for monitoring a device such as a PC (Personal Computer). However, since the functions of commercially available packaged software are built in advance, the user is forced to make a certain degree of compromise regarding the difference between the desired function and the actually provided function.

  On the other hand, it is conceivable to create from scratch with specifications desired by the user without using package software. In this case, there is a high possibility that a system closer to the user's request is constructed. However, there is a problem that design and manufacturing work is required even for primitive processing such as communication control, which is very expensive in terms of time and cost.

  The present invention has been made in view of the above points, and an object of the present invention is to provide an information processing apparatus, an information processing method, and a program capable of appropriately constructing a system for monitoring device information.

  Therefore, in order to solve the above-described problem, the present invention provides a device that acquires information about a device connected to a network to a user, data to be acquired from the data that constitutes the device, An acquisition target reception unit that receives the designation of the data, a URI generation unit that generates a URI for the data that is the acquisition target based on the designation by the application, and a data acquisition request corresponding to the URI. Data acquisition means for acquiring the data by receiving a response and recording means for recording the acquired data in a storage area that can be referred to by the application.

  In such an information processing apparatus, a system for monitoring device information can be appropriately constructed.

  ADVANTAGE OF THE INVENTION According to this invention, the information processing apparatus, the information processing method, and program which can be made to construct | assemble the system which monitors the information of an apparatus appropriately can be provided.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a diagram illustrating a configuration example of a device management system according to an embodiment of the present invention. In FIG. 1, the device management system 1 includes one or more network devices to be monitored or managed and one or more computers to be monitored or managed. The devices 20a, 20b, and 20c (hereinafter collectively referred to as “device 20”) are network devices to be monitored. The management devices 10a and 10b (hereinafter collectively referred to as “management device 10”) are computers on the monitoring side. As illustrated, the device 20 and the management apparatus 10 are connected by a network 30 (regardless of wired or wireless) such as a LAN (Local Area Network), a WAN (Wide Area Network), or the Internet. .

  FIG. 2 is a diagram illustrating a hardware configuration example of the management apparatus according to the embodiment of the present invention. The management device 10 in FIG. 2 includes a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, a display device 106, and an input device 107 that are mutually connected by a bus B. And is configured to have.

  A program for realizing processing in the management apparatus 10 is provided by a recording medium 101 such as a CD-ROM. When the recording medium 101 on which the program is recorded is set in the drive device 100, the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100. The auxiliary storage device 102 stores the installed program and also stores necessary files and data.

  The memory device 103 reads the program from the auxiliary storage device 102 and stores it when there is an instruction to start the program. The CPU 104 realizes functions related to the management apparatus 10 according to a program stored in the memory device 103. The interface device 105 is used as an interface for connecting to a network. The display device 106 displays a GUI (Graphical User Interface) or the like by a program. The input device 107 includes a keyboard and a mouse, and is used for inputting various operation instructions.

  The program need not be installed from the recording medium 101 and may be downloaded from another computer via a network.

  FIG. 3 is a class diagram for explaining a software configuration example of the management apparatus according to the first embodiment. In FIG. 1, a management apparatus 10 includes a device management client 11 and an application 12.

  The device management client 11 is a middleware that provides a higher-level application (application 12) with a mechanism for collecting data (parameters) constituting the device 20 information (device information), updating the device 20 data, and the like. Alternatively, it is a framework and includes a virtual device class 111, a device information class 112, a data class 113, a data A class 114, a data B class 115, and the like.

  The virtual device class 111 is a class that represents the virtual device 20 and is instantiated for each device 20. For example, the virtual device class 111 receives an acquisition request for data constituting the device information, and acquires the data from the device 20 by REST (Representational State Transfer) based on HTTP (HyperText Transfer Protocol). That is, a URI (Uniform Resource Identifier) is assigned as unique address information to each data constituting the device information in the device 20, and access (operation) is performed for each data based on the URI.

  The device information class 112 is a class that represents device information, and aggregates the data class 113. The data class 113 is an abstract class that represents each piece of data constituting the device information. Actual data is held in a subclass of data class 113. For example, in FIG. 3, the data A class 114 and the data B class 115 are illustrated as subclasses of the data class 113. The data A class 114 and the data B class 115 are mounted according to the characteristics of the corresponding data. Thus, there are subclasses of the data class 113 according to the type of data. Therefore, when new data needs to be acquired or updated, the types of data that can be handled can be expanded by defining a class corresponding to the data as a subclass of the data class 113.

  Each class is loaded into the memory device 103 as an object by being instantiated. The object realizes its function by causing the CPU 104 to execute processing defined in the class.

  The application 12 is a software program that uses the device management client 11, and operates a virtual device class 111 instance (hereinafter referred to as a “virtual device object 111I”) to provide services such as acquisition or update of device information. Provide to users.

  On the other hand, the device 20 includes a device management server 21. The device management server 21 controls the execution (acquisition, update, etc.) of the device information data specified in the REST-based HTTP request from the management device 21, and returns the operation result included in the HTTP response. To do.

  Hereinafter, a processing procedure of the device management system 1 will be described. FIG. 4 is a sequence diagram for explaining the processing procedure of the device management system according to the first embodiment. FIG. 4 illustrates an example in which the value of data A is acquired from the device 20a (device A).

  When operating the device information, the application 12 first generates a virtual device object 111Ia corresponding to the device 20a to be operated (S101). At the time of generation, the virtual device object 111Ia has a boat for communicating with the URL of the device 20a (for example, “http: // deviceA”) and the device management server 21 (hereinafter referred to as “device management server 21a”). A number (eg, “80”) is set.

  Subsequently, the application 12 sets user account information (user name and password) in the virtual device object 111Ia (S102). Subsequently, the application 12 sets SSL authentication information for performing SSL (Secure Socket Layer) communication with the device 20a in the virtual device object 111Ia (S103).

  Subsequently, the application 12 generates an object for designating data to be acquired. First, the application 12 generates an instance (device information object 112I) of the device information class 112 for collecting data (S104). Subsequently, the application 12 specifies an identifier (for example, a data name) of the data A to be acquired and requests the device information object 112I to generate an object corresponding to the data A (S105). In response to the request, the device information object 112I generates an instance of the data A class 114 (hereinafter referred to as “data A object 114Ia”) (S106). At this time, the data A object 114Ia and the device information object 112I are bidirectionally associated. Specifically, the reference information, ID, or pointer of the other object is set for both objects.

  Subsequently, the application 12 requests the virtual device object 111Ia to acquire data using the data A object 114Ia as an argument (S107). The virtual device object 111Ia requests the device information object 112I to generate the URI of the data A related to the data A object 114Ia specified as the argument (S108). In the request, the URL and boat number (http: // deviceA: 80) of the device 20a set in the virtual device object 111Ia are specified. The device information object 112I is acquired based on the association set in the data A object 114Ia specified as the argument.

  The device information object 112I adds a URI (for example, “sample”) with a relative path indicating “device information” in the device 20 after the URL and boat number of the specified device 20a, and a URI (http: // deviceA: 80 / sample /) is generated. Subsequently, the device information object 112I requests the data A object 114Ia to generate a URI for the data A using the URI for the device information as an argument (S109). The data A object 114Ia adds a URI (for example, “a1”) based on a relative path to the data A to the URI (http: // deviceA: 80 / sample) for the data A after adding a URI for the device information. / a1) is generated, and the URI is returned to the device information object 112I (S110). The device information object 112I returns the URI for the returned data A to the virtual device object 111Ia (S111). The URI based on the relative path for the device information and the URI based on the relative path for the data A may be implemented as definitions of the respective classes (device information class 112 and data A class 114) (that is, hard-coded). Or may be set by the generation source when each object is generated.

  The virtual device object 111Ia that has obtained the URI of the data A transmits an HTTP request (here, strictly, an HTTPS request because SSL communication is performed) to the device management server 21a using the URI as a parameter of the GET method ( S112). The device management server 21a obtains data corresponding to the URI specified in the HTTP request from the storage device of the device 20a, includes XML (eXtensible Markup Language) data representing the data in the HTTPS response, and includes a virtual device object. It returns to 111Ia (S113).

  FIG. 5 is a diagram illustrating an example of XML data included in the HTTPS response. In the figure, data 510 conforms to a format called Atom, and one piece of data is represented by an entry element surrounded by <entry> tags. A title element 511 indicates a data name. The id element 512 indicates an ID that uniquely identifies data. The updated element 513 indicates the date and time when the data was updated. The portion indicated by 514 includes the data value (substance).

  Subsequently, in response to the reception of the HTTPS response, the virtual device object 111Ia sets the XML data 510 included in the HTTPS response in the data A object 114Ia that is a storage area that can be referred to by the application 12 (S114). The data A object 114Ia sets the information included in the XML data 510 as its attribute (member variable) by analyzing the XML data 510 and performing type conversion of the entity of the data A. For example, the update date and time, the value of data A, and the like are set as attribute values corresponding to each.

  When a response to the request in step S107 is made by the virtual device object 111I (S115), the application 12 can acquire the data A set in the data A object 114Ia by operating the data A object 114Ia. (S116). In addition, when the application 12 acquires the data A again in order to grasp the latest state (latest value) of the data A, the same processing as the above-described steps S107 to S116 is repeated (S117 to S126).

  As described above, the device management client 11 in the first embodiment provides a higher-order application 12 with a mechanism for acquiring device information. Therefore, it is not necessary for the application 12 to be aware of communication control, data URI, and the like. Therefore, the application 12 having a GUI or a function according to the user can be more easily implemented, and the construction cost of a system for monitoring or managing a device can be reduced.

  By the way, in the first embodiment, in order to grasp the latest data state, the application 12 needs to request the device management client 11 to acquire data again (step S117). In the second embodiment, an example in which the device management client 11 realizes the grasp of the latest state of data will be described.

  FIG. 6 is a class diagram for explaining a software configuration example of the management apparatus according to the second embodiment. In FIG. 6, the same parts as those in FIG. 3 are denoted by the same reference numerals, and the description thereof is omitted.

  In FIG. 6, the device management client 11 includes an update timing class 116. The update timing class 116 performs control for causing the virtual device object 111I to periodically acquire device information.

  FIG. 7 is a sequence diagram for explaining the processing procedure of the device management system according to the second embodiment. In FIG. 4, steps S201 to S206 are the same as steps S101 to S106 in FIG.

  Subsequent to step S206, the application 12 generates an instance (update timing object 116I) of the update timing class 116 (S207). At the time of generation, the application 12 sets a data acquisition cycle (for example, 30 minutes), a virtual device object 111Ia, and a data A object 114Ia in the update timing object 116I. Accordingly, the update timing object 116I recognizes that the data A is acquired from the device 20a every 30 minutes.

  Subsequently, when the application 12 requests the update timing object 116I to start monitoring (S208), the update timing object 116I executes acquisition of data A. Specifically, the update timing object 116I makes the same request to the virtual device object 111Ia as the request made by the application 12 in step S107 of FIG. 4 (S209). In response to the request, in steps S210 to S215, processing similar to that in steps S108 to S113 in FIG. 4 is executed, and XML data related to data A is acquired from the device management server 21a.

  When a response to the request in step S109 is made from the virtual device object 111I (S216), the update timing object 116I acquires the update date and time from the data A object 114Ia (S217, S218). The update date and time acquired here is set in the data A object 114Ia when the data A was previously acquired. Subsequently, in the update timing object 116I, the data A is set in the data A object 114Ia by comparing the update date and time included in the XML data 510 with the update date and time acquired from the data A object 114Ia. It is determined whether or not the status has been updated (S219).

  When the update date and time included in the XML data 510 is newer (later), that is, when the data A is updated, the update timing object 116I sets the XML data 510 to the data A object 114Ia (S220). ). On the other hand, when both update dates and times are the same, that is, when data A is not updated, step S220 is not executed.

  The update timing object 116I repeatedly performs the request in step S209 at the set cycle. Therefore, when the processing of steps S209 to S220 is periodically executed and data A is updated, the updated value is reflected in the data A object 114Ia. Thereafter, when the application 12 requests the update timing object 116I to end monitoring (S221), the update timing object 116I stops the periodic acquisition of data A.

  As described above, according to the device management client 11 in the second embodiment, data to be monitored periodically is acquired. Therefore, even if the application 12 is not conscious, the data in the latest state can be appropriately held on the management apparatus 10 side.

  Next, an example of acquiring a plurality of data (data A and data B) will be described as a third embodiment. The points not particularly mentioned in the third embodiment may be the same as those in the second embodiment.

  FIG. 8 is a sequence diagram for explaining a processing procedure of the device management system according to the third embodiment. In FIG. 7, steps S301 to S306 are the same as steps S201 to S206 in FIG.

  When the generation of the data A object 114Ia is completed, the application 12 further specifies an identifier (for example, a data name) of the data B and requests the device information object 112I to generate an object corresponding to the data B (S307). . In response to the request, the device information object 112I generates an instance of the data B class 115 (data B object 115Ia) by the same processing as step S306 (S308).

  Subsequently, the application 12 generates an update timing object 116I (S309). At the time of generation, the application 12 sets the data acquisition period (for example, 30 minutes), the virtual device object 111Ia, and the data A object 114Ia in the update timing object 116I. Accordingly, the update timing object 116I recognizes that the data A is acquired from the device 20a every 30 minutes. Subsequently, the application 12 requests the update timing object 116I to add a monitoring target using the virtual device object 111Ia and the data B object 115Ia as arguments (S310). Accordingly, the update timing object 116I recognizes that not only the data A but also the data B is acquired every 30 minutes.

  Subsequently, when the application 12 requests the update timing object 116I to start monitoring (S311), the update timing object 116I uses the data A object 114Ia and the data B object 115Ia as arguments, and acquires data from the virtual device object 111Ia. (S312). Subsequently, in steps S313 to S315, the same processes as in S214 to S216 of FIG. 7 are executed. However, in the HTTPS request in step S313, the A data URI and the B data URI are arranged as arguments of the GET method (for example, two URIs separated by a delimiter such as a comma). Is done. Therefore, the HTTPS response in step 314 includes XML data 510 corresponding to data A (hereinafter referred to as “XML data 510a”) and XML data 510 corresponding to data B (hereinafter referred to as “XML data 510b”). ing.

  In FIG. 8, the data A URI generation process and the data B URI generation process performed between step S312 and step S313 are omitted. The generation process may be performed in substantially the same manner as in the first and second embodiments. That is, the virtual device object 111Ia transmits the URL of the device 20a and the port number http: // deviceA: 80) to the device information object 112I. In the device information object 112I, the result (http: // deviceA: 80 / sample /) of adding the URI of the device information by the relative path to the URL and the port number of the device 20a is the data A object 114Ia and the data B object 115Ia. To communicate. The data A object 114Ia generates the URI (http: // deviceA: 80 / sample / a1) of the data A based on the absolute path by adding the URI of the data A based on the relative path, and converts the URI of the data A into the device information object 112I. Return to Further, the data B object 115Ia generates the URI of the data B by the absolute path (http: // deviceA: 80 / sample / b1) by adding the URI of the data B by the relative path, and uses the URI of the data B as the device information. Return to object 112I. The device information object 112I returns the URI of data A and the URI of data B to the virtual device object 111I. A character string in which these two URIs are connected by a delimiter is specified as a parameter of the GET method in the HTTPS request in step S313.

  In steps S316 to S319, processing similar to that in steps S217 to S220 of FIG. In steps S320 to S323, the same processing as that in steps S217 to S220 in FIG.

  The update timing object 116I repeatedly performs the request in step S312 with the set cycle. Therefore, when the processing of steps S312 to S323 is periodically executed and the data A is updated, the updated value is reflected in the data A object 114Ia, and when the data B is updated, the data B object 115Ia is updated. The updated value is reflected in. Thereafter, when the application 12 requests the update timing object 116I to end monitoring (S324), the update timing object 116I stops the acquisition of the data A and the data B periodically.

  As described above, according to the device management client 11 in the third embodiment, a plurality of data can be appropriately operated.

  Next, the example which acquires each data A from the some apparatus 20 (apparatus 20a, apparatus 20b) is demonstrated as 4th Embodiment. Points not particularly mentioned in the fourth embodiment may be the same as those in the third embodiment.

  FIG. 9 is a sequence diagram for explaining the processing procedure of the device management system according to the fourth embodiment. In FIG. 8, steps S401 to S403 are the same as steps S301 to S303 in FIG. 8, and a description thereof will be omitted here. Subsequently, in steps S404 to S406, a virtual device object 111Ib corresponding to the device 20b is generated by the same procedure as in steps S401 to S403. The virtual device object 111Ib has a boat number (for example, a communication number) (for example, “http: // deviceB”) and a device management server 21 (hereinafter, “device management server 21b”). , “80”) is set.

  Subsequently, in steps S407 to S409, a device information object 112I is generated by the same procedure as steps S304 to S306 in FIG. 8, and a data a object 114Ia corresponding to the data A of the device 20a is further generated. Further, in steps S410 and S411, a data A object 114Ib corresponding to the data A of the device 20b is generated by the same procedure as in steps S408 and S409.

  Subsequently, the application 12 generates an update timing object 116I (S412). At the time of generation, the application 12 sets the data acquisition period (for example, 30 minutes), the virtual device object 111Ia, and the data A object 114Ia in the update timing object 116I. Accordingly, the update timing object 116I recognizes that the data A is acquired from the device 20a every 30 minutes. Subsequently, the application 12 requests the update timing object 116I to add a monitoring target using the virtual device object 111Ib and the data A object 114Ib as arguments (S413). As a result, the update timing object 116I recognizes that the data A is also acquired from the device 20b every 30 minutes.

  Subsequently, when the application 12 requests the update timing object 116I to start monitoring (S414), the update timing object 116I requests the virtual device object 111Ia to acquire data using the data A object 114Ia as an argument (S415). ). Subsequently, in steps S416 to S422, XML data 510 relating to data A is acquired from the device management server 21a of the device 20a by the same procedure as steps S214 to S220 in FIG. 7, and the XML data 510 is stored in the data A object 114Ia. Is set.

  Subsequently, when the update timing object 116I requests the virtual device object 111Ib to acquire data using the data A object 114Ib as an argument (S423), in steps S424 to S430, the device 20b is processed in the same procedure as steps S416 to S422. XML data 510 relating to data A is acquired from the device management server 21b, and the XML data 510 is set in the data A object 114Ib.

  The update timing object 116I repeatedly performs the requests in steps S415 and S423 at the set cycle. Therefore, when the processing of steps S415 to S422 and steps S24 to S430 is periodically executed and the data A of the device 20a is updated, the updated value is reflected in the data A object 114Ia, and the data A of the device 20b is updated. Is updated, the updated value is reflected in the data A object 114Ib. Thereafter, when the application 12 requests the update timing object 116I to end the monitoring (S431), the update timing object 116I stops the periodic acquisition of data A from the devices 20a and 10b.

  Note that the URI A generation process of the data A of the device 20a and the URI generation process of the data A of the device 20b are obvious from the description of the embodiment before the fourth embodiment, and therefore will be described here. Is omitted.

  As described above, according to the device management client 11 in the fourth embodiment, it is possible to appropriately operate the data of the plurality of devices 20.

  Next, an example in which two pieces of data (data A and data B) in the device 20a are acquired at different timings (cycles) will be described as a fifth embodiment. The points not particularly mentioned in the fifth embodiment may be the same as those in the third embodiment.

  FIG. 10 is a sequence diagram for explaining the processing procedure of the device management system according to the fifth embodiment. In FIG. 8, steps S501 to S508 are the same as steps S301 to S308 in FIG. 8, and a description thereof will be omitted here.

  Subsequently, the application 12 generates an update timing object 116Ia as an instance of the update timing class 116 related to the data A (S509). At the time of generation, the application 12 sets a data acquisition period (for example, 30 minutes), a virtual device object 111Ia, and a data A object 114Ia in the update timing object 116Ia. Thereby, the update timing object 116Ia recognizes that the data A is acquired from the device 20a every 30 minutes.

  Subsequently, the application 12 generates an update timing object 116Ib as an instance of the update timing class 116 related to the data B (S510). At the time of generation, the application 12 sets the data acquisition cycle (for example, 5 minutes), the virtual device object 111Ia, and the data B object 115Ia in the update timing object 116Ib. Thereby, the update timing object 116Ib recognizes that the data B is acquired from the device 20a every 5 minutes.

  Subsequently, the application 12 requests the update timing objects 116Ib and 116Ia to start monitoring (S511, S512). The update timing object 116Ib requests the virtual device object 111Ia to acquire data using the data B object 115Ia as an argument (S521). Subsequently, in steps S522 to S528, XML data 510 relating to data B is acquired from the device management server 21a of the device 20a by the same procedure as in steps S214 to S220 in FIG. 7, and the XML data 510 is stored in the data B object 115Ia. Is set.

  On the other hand, the update timing object 116Ia requests the virtual device object 111Ia to acquire data using the data A object 114Ia as an argument (S531). Subsequently, in steps S532 to S538, XML data 510 relating to data A is acquired from the device management server 21a of the device 20a by the same procedure as steps S214 to S220 in FIG. 7, and the XML data 510 is stored in the data A object 114Ia. Is set.

  The update timing objects 116Ib and 116Ia repeatedly perform the request in step S521 or S531 at the period set for each. Therefore, when the processing of steps S521 to S528 and steps S531 to S538 is periodically executed and the data B of the device 20a is updated, the updated value is reflected in the data B object 115Ia, and the data A is updated. If updated, the updated value is reflected in the data A object 114Ia. In the example of FIG. 10, since the cycle set in the update timing object 116Ib is shorter, the data B is acquired with a shorter cycle than the data A (S541 to S548).

  Thereafter, when the application 12 requests the update timing objects 116Ia and 116Ib to end monitoring (S551, S552), the update timing objects 116Ia and 116b stop the acquisition of the periodic data A and data B from the device 20a.

  As described above, according to the device management client 11 in the fifth embodiment, a plurality of data can be appropriately operated at different timings (cycles).

  In addition, you may make it acquire the data in a different apparatus 20 with a different period by combining 4th Embodiment and 5th Embodiment.

  As mentioned above, although the Example of this invention was explained in full detail, this invention is not limited to such specific embodiment, In the range of the summary of this invention described in the claim, various deformation | transformation・ Change is possible.

It is a figure which shows the structural example of the apparatus management system in embodiment of this invention. It is a figure which shows the hardware structural example of the management apparatus in embodiment of this invention. It is a class diagram for demonstrating the software structural example of the management apparatus in 1st embodiment. It is a sequence diagram for demonstrating the process sequence of the apparatus management system in 1st embodiment. It is a figure which shows the example of the XML data contained in an HTTPS response. It is a class diagram for demonstrating the software structural example of the management apparatus in 2nd embodiment. It is a sequence diagram for demonstrating the process sequence of the equipment management system in 2nd embodiment. It is a sequence diagram for demonstrating the process sequence of the equipment management system in 3rd embodiment. It is a sequence diagram for demonstrating the process sequence of the equipment management system in 4th embodiment. It is a sequence diagram for demonstrating the process sequence of the equipment management system in 5th embodiment.

Explanation of symbols

1 device management system 10, 10a, 10b management device 11 device management client 12 application 20, 20a, 20b, 20c device 30 network 100 drive device 101 recording medium 102 auxiliary storage device 103 memory device 104 CPU
105 interface device 106 display device 107 input device 111 virtual device class 112 device information class 113 data class 114 data A class 115 data B class 116 update timing class B bus

Claims (9)

From an application that provides information on devices connected to the network to the user, an acquisition target reception unit that receives designation of a device from which the information is acquired and data to be acquired from data constituting the information;
URI generation means for generating a URI for the data to be acquired based on the designation by the application;
A data acquisition means for acquiring the data by transmitting a data acquisition request corresponding to the URI and receiving a response to the acquisition request;
An information processing apparatus, comprising: a recording unit that records the acquired data in a storage area that can be referred to by the application.   The information processing apparatus according to claim 1, further comprising an update unit that receives a setting of a cycle for acquiring the data from the application and causes the data acquisition unit to acquire the data at a set cycle. The data acquisition means acquires information indicating when the data is updated in the device together with the data,
The recording means records the acquired data in the storage area when the acquired data is updated later than when the data already recorded in the storage area is updated. The information processing apparatus according to claim 2. The acquisition target receiving unit receives a plurality of data designations,
4. The information according to claim 2, wherein the updating unit receives the setting of the cycle for each piece of data and causes the data acquisition unit to acquire the data at a cycle set for each piece of data. Processing equipment. An information processing method executed by a computer,
An acquisition target reception procedure for receiving designation of a device for acquiring the information and data to be acquired from the data constituting the information, from an application that provides the user with information on the devices connected to the network;
A URI generation procedure for generating a URI for data to be acquired based on the designation by the application;
A data acquisition procedure for acquiring the data by transmitting a data acquisition request corresponding to the URI and receiving a response to the acquisition request;
And a recording procedure for recording the acquired data in a storage area that can be referred to by the application.   6. The information processing method according to claim 5, further comprising an update procedure that accepts setting of a cycle for acquiring the data from the application and causes the data acquisition procedure to acquire the data at a set cycle. The data acquisition procedure acquires information indicating when the data is updated in the device together with the data,
The recording procedure is to record the acquired data in the storage area when the acquired data is updated later than when the data already recorded in the storage area is updated. The information processing method according to claim 6. The acquisition target acceptance procedure accepts designation of a plurality of the data,
8. The information according to claim 6, wherein the update procedure accepts the setting of the cycle for each piece of data and causes the data acquisition procedure to acquire the data at a cycle set for each piece of data. Processing method.   A program for causing a computer to execute the information processing method according to any one of claims 5 to 8.

Images