Data providing server, data providing method and program

Abstract

To provide data meeting a request of a data requester without providing a dedicated database for each rule of data provision.SOLUTION: A data providing server 2 is provided with: an operation history DB 240 that sequentially stores operation data related to the operation of equipment; a metadata management unit DB 241 for storing metadata with rules defined for data provision; a data request reception unit 202 for receiving a request for data provision from a data requester via a data request terminal 5; a provided data acquisition unit 203 for acquiring provided data, which is data to be provided to the data requester, based on the metadata specified by the data requester in the request and the history of the driving data stored in the driving history DB 240; and a provided data transmission unit 204 for transmitting the acquired provided data to the data request terminal 5.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present disclosure relates to a data providing server, a data providing method, and a program. [Background technology]

[0002] BACKGROUND ART A system is known in which a server collects data on the status of a plurality of pieces of equipment installed in a building or the like, and manages the pieces of equipment based on the collected data (for example, Patent Document 1).

[0003] In such a server, data collected from each piece of equipment is generally managed in a centralized manner in a single database. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Laid-Open No. 2010-181073 Summary of the Invention [Problem to be solved by the invention]

[0005] Incidentally, the data history stored by the server is extremely useful information for marketing research, design, feedback on development of the equipment, or for managing the floor on which the equipment is installed. Therefore, technology is being considered to provide the data history collected by the server to parties who wish to utilize the data (for example, other departments in the same company, hereinafter referred to as data requesters).

[0006] The content of the data desired by each of the above data requesters (for example, history at 1-minute intervals, history at 5-minute intervals, history at 60-minute intervals, etc.), in other words, the rules for providing data to each data requester, can be said to vary depending on the purpose of use of each data requester. In this way, when there are multiple rules for providing data, one idea is for the server to have a dedicated database for each rule for providing data (for example, a database that stores history at 1-minute intervals, a database that stores history at 5-minute intervals, a database that stores history at 60-minute intervals, etc.) in advance, and manage the collected data in each database.

[0007] However, the above-described configuration of providing a dedicated database for each data provision rule increases management costs and makes it difficult to smoothly respond to new data provision rules when they arise. For this reason, there is a need for a meaningful technology proposal for providing data to data requesters.

[0008] The present disclosure has been made in consideration of the above-mentioned situation, and aims to provide a data provision server, a data provision method, and a program that are capable of providing data that meets the requirements of data requesters without having to set up a dedicated database for each data provision rule. [Means for solving the problem]

[0009] In order to achieve the above object, the data providing server according to the present disclosure: an operation history storage means for sequentially storing operation data relating to the operation of the equipment; The driving data stored sequentially in the driving history storage means can be used a metadata storage means for storing metadata in which rules for providing data are defined; A request for providing data is received from a data requester via a terminal, metadata corresponding to the request is acquired from the metadata storage means, and metadata to be used is selected from the metadata acquired from the metadata storage means and sent to the data requester. via the terminal a data request receiving means for allowing the user to specify the data; Metadata specified by the data requester The data provision rules defined byand the driving history storage means sequentially Remembered The aforementioned Driving Day Ta and a provision data acquisition means for acquiring provision data, which is data to be provided to the data requester, based on the and a provision data transmission means for transmitting the acquired provision data to the terminal. [Effects of the Invention]

[0010] According to the present disclosure, it is possible to provide data that meets the requirements of a data requester without providing a dedicated database for each rule of data provision. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 shows an overall configuration of a data providing system according to a first embodiment. [Figure 2] FIG. 1 is a block diagram showing a hardware configuration of a data providing server according to a first embodiment. [Figure 3] FIG. 1 is a block diagram showing a hardware configuration of a communication device according to a first embodiment. [Figure 4] FIG. 1 is a block diagram showing a hardware configuration of a data request terminal according to a first embodiment. [Figure 5] FIG. 1 is a block diagram showing a functional configuration of a data providing server according to a first embodiment. [Figure 6] FIG. 1 is a diagram showing an example of an operation history DB according to the first embodiment. [Figure 7] FIG. 1 shows an example of a metadata management DB according to the first embodiment. [Figure 8] FIG. 10 is a diagram showing an example of a data request acceptance screen according to the first embodiment. [Figure 9] FIG. 10 is a diagram showing an example of a data request acceptance screen according to the first embodiment. [Figure 10] FIG. 10 is a diagram showing an example of a data request acceptance screen according to the first embodiment. [Figure 11] FIG. 10 is a diagram showing an example of a data request acceptance screen according to the first embodiment. [Figure 12]FIG. 10 is a diagram showing an example of a data request acceptance screen according to the first embodiment. [Figure 13] 1 is a flowchart showing a procedure for data provision processing according to the first embodiment. [Figure 14] FIG. 10 is a diagram showing an example of a data request acceptance screen according to a modification of the first embodiment. [Figure 15] FIG. 10 is a block diagram showing a configuration of a data providing server according to a modification of the first embodiment. [Figure 16] FIG. 10 is a diagram showing the overall configuration of a data providing system according to a second embodiment. [Figure 17] FIG. 10 is a block diagram showing the functional configuration of a data providing server according to a second embodiment. [Figure 18] FIG. 10 is a diagram showing an example of an operation history DB according to the second embodiment. [Figure 19] FIG. 10 is a diagram showing an example of a metadata management DB according to the second embodiment. [Figure 20] FIG. 10 is a diagram showing an example of a data request acceptance screen according to the second embodiment. [Figure 21] FIG. 10 is a diagram showing an example of a data request acceptance screen according to the second embodiment. [Figure 22] FIG. 10 is a diagram showing an example of a data request acceptance screen according to the second embodiment. [Figure 23] FIG. 10 is a diagram showing an example of a data request acceptance screen according to the second embodiment. [Figure 24] 10 is a flowchart showing the procedure of a data providing process according to the second embodiment. [Figure 25] FIG. 10 is a diagram showing an example of a data request acceptance screen in a modified example of the second embodiment. [Figure 26] FIG. 10 is a block diagram showing the configuration of a data providing server according to a modification of the second embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0012] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings.

[0013] Fig. 1 is a diagram showing the overall configuration of a data providing system 1 in embodiment 1. The data providing system 1 is a system that manages the history of driving data related to the operation of each device 3 collected from each device 3, and provides data based on the managed history of driving data to a data requester in response to a request from the data requester. As shown in Fig. 1, the data providing system 1 includes a data providing server 2, a plurality of devices 3, a plurality of communication devices 4, and a plurality of data request terminals 5.

[0014] <Data providing server 2> The data providing server 2 is an example of a data providing server according to the present disclosure. The data providing server 2 is a so-called cloud server, and is connected to a network N. The network N is a network such as a LAN (Local Area Network), a CAN (Campus Area Network), a MAN (Metropolitan Area Network), a WAN (Wide Area Network), or the Internet.

[0015] 2, the data providing server 2 includes, as its hardware configuration, a communication interface 20, a CPU (Central Processing Unit) 21, a ROM (Read Only Memory) 22, a RAM (Read Only Memory) 23, and an auxiliary storage device 24. These components are interconnected via a bus 25.

[0016] The communication interface 20 is a wired or wireless LAN interface for communicating with other devices, such as the communication devices 4 and the data request terminals 5, via the network N. The CPU 21 controls the data providing server 2 in an integrated manner. The functions of the data providing server 2 realized by the CPU 21 will be described in detail later. The ROM 22 stores a BIOS (Basic Input Output System) and firmware, as well as data used when these programs are executed. The RAM 23 is used as a working area for the CPU 21.

[0017] The auxiliary storage device 24 is configured with a readable / writable nonvolatile semiconductor memory, an HDD (Hard Disk Drive), etc. Examples of the readable / writable nonvolatile semiconductor memory include an EEPROM (Electrically Erasable Programmable Read-Only Memory), a flash memory, etc. The auxiliary storage device 24 stores various programs, including a data management program for collecting operating data from each device 3 and managing the history of the collected operating data, and a data providing program for providing data based on the history of the collected operating data to a data requester, as well as data used when these programs are executed.

[0018] The above-mentioned data management program and data providing program can be downloaded from another server to the data providing server 2 via the network N. In addition, by connecting a computer-readable recording medium, such as a CD-ROM (Compact Disc Read Only Memory), a DVD (Digital Versatile Disc), a magneto-optical disk, a USB (Universal Serial Bus) memory, an HDD, an SSD (Solid State Drive), or a memory card, on which these programs are stored, to the data providing server 2, the data providing server 2 can also import these programs.

[0019] <Device 3> Each device 3 is a facility device installed in a building and detects the number of people on the floor on which it is installed. Each device 3 is equipped with, for example, an infrared camera, acquires a thermal image of the entire area of ​​the floor on which it is installed, and detects the number of people on that floor (hereinafter referred to as the number of people) by analyzing the acquired thermal image. Note that each device 3 may also be equipped with, for example, a visible camera configured with an image sensor such as a CCD (Charge-Coupled Device) or a CMOS (Complementary Metal Oxide Semiconductor), and detect the number of people on that floor by analyzing the image of the floor captured by the visible camera.

[0020] Each device 3 periodically (for example, every minute) detects the number of people in the room, and transmits operating data including the current date and time, the detected number of people in the room, and the device ID (identification) of the device 3 to the data providing server 2 via the communication device 4 connected to the device 3. The device ID is, for example, the serial number of the device 3.

[0021] <Communication Device 4> Each communication device 4 is a communication adapter for communicatively connecting a corresponding device 3 to the network N. As shown in Fig. 3, the communication device 4 includes, as its hardware configuration, a first communication interface 40, a second communication interface 41, a CPU 42, a ROM 43, a RAM 44, and an auxiliary storage device 45. These components are connected to each other via a bus 46.

[0022] The first communication interface 40 is an interface for electrically connecting to the device 3 so as to be able to communicate with it. In this embodiment, the first communication interface 40 is a serial interface such as UART. The second communication interface 41 is a wireless LAN interface for connecting to the network N and communicating with the data providing server 2.

[0023] The CPU 42 performs overall control of the communication device 4. The ROM 43 stores the BIOS and firmware, as well as data used when these programs are executed. The RAM 44 is used as a working area for the CPU 42. The auxiliary storage device 45 is composed of, for example, a readable / writable nonvolatile semiconductor memory such as an EEPROM or flash memory. The auxiliary storage device 45 stores a program for communicating with the device 3, a program for communicating with the data providing server 2, and data used when these programs are executed.

[0024] <Data request terminal 5> The data requesting terminal 5 is a computer device used by a data requester, and is an example of a terminal according to the present disclosure. A data requester is a person who requests data based on the operation data history of each device 3 managed by the data providing server 2. For example, data requesters include managers of buildings in which the devices 3 are installed, relevant parties (personnel in the sales department, quality control department, development department, etc.) of manufacturers and sales companies of facility equipment (air conditioners, lighting devices, etc.) installed in the building in which the devices 3 are installed, and relevant parties of companies other than the manufacturers and sales companies of the facility equipment.

[0025] 4, the data request terminal 5 includes, as its hardware configuration, a display 50, an operation reception unit 51, a communication interface 52, a CPU 53, a ROM 54, a RAM 55, and an auxiliary storage device 56. These components are interconnected via a bus 57.

[0026] The display 50 includes a display device such as a liquid crystal display, an organic EL (Electro Luminescence) display, a plasma display, a CRT display, etc. Under the control of the CPU 53, the display 50 displays various screens etc. in response to user operations.

[0027] The operation reception unit 51 is configured to include one or more input devices such as a push button, keyboard, mouse, keypad, touch panel, touchpad, etc., and receives operation input from the user and outputs a signal related to the received operation to the CPU 53.

[0028] The communication interface 52 is a wired or wireless LAN interface for communicating with other devices, for example, the data providing server 2, via the network N. The CPU 53 performs overall control of the data request terminal 5. The ROM 54 stores BIOS and firmware, as well as data used when these programs are executed. The RAM 55 is used as a working area for the CPU 53.

[0029] The auxiliary storage device 56 is composed of a readable / writable nonvolatile semiconductor memory, a HDD, etc. Examples of the readable / writable nonvolatile semiconductor memory include an EEPROM, a flash memory, etc. The auxiliary storage device 56 stores various programs including a program for receiving data provided from the data providing server 2, and data used when these programs are executed.

[0030] <Functional configuration of data providing server 2> Fig. 5 is a block diagram showing the functional configuration of the data providing server 2. As shown in Fig. 5, the data providing server 2 functionally includes a driving data acquisition unit 200, a metadata registration unit 201, a data request reception unit 202, a provided data acquisition unit 203, and a provided data transmission unit 204. These functional units of the data providing server 2 are realized by the CPU 21 executing the above-mentioned data management program and data providing program stored in the auxiliary storage device 24.

[0031] The operating data acquiring unit 200 periodically (for example, every minute) acquires operating data from each device 3. The operating data acquiring unit 200 periodically transmits a notification requesting operating data to each device 3. When each device 3 receives such a notification via the connected communication device 4, it transmits operating data including the current date and time, the detected number of occupants, and the device ID of the device 3 to the data providing server 2 via the connected communication device 4, as described above.

[0032] The driving data acquisition unit 200 receives and acquires driving data sent from each device 3, and stores the acquired driving data in a driving history DB 240 (see FIG. 6). The driving history DB 240 is an example of a driving history storage means according to the present disclosure. The driving history DB 240 is a database that sequentially stores driving data sent from each device 3, and is stored in the auxiliary storage device 24. The driving history DB 240 stores a history of driving data for each device 3 for a predetermined period (for example, one year).

[0033] The metadata registration unit 201 generates metadata based on data (hereinafter referred to as provisional metadata) that defines rules for providing new data and that has been input to the data providing server 2, and registers the generated metadata in the metadata management DB 241. The metadata management DB 241 is an example of a metadata storage means according to the present disclosure. The metadata management DB 241 is a database for managing metadata, and is stored in the auxiliary storage device 24. Metadata is data that defines rules for providing data to data requesters. As shown in FIG. 7, the metadata includes a meta number, a device ID, a time interval, etc.

[0034] The meta number is an identification number assigned to new metadata. The device ID is the device ID of the sender of the driving data to be provided. The time interval is an example of the main content of the data provision rules, and in this example, it is the time interval (unit: minutes) of the history of the driving data to be provided. When signing a contract with a new data requester, the operator of the data provision system 1 inquires of the data requester about the rules for the data they wish to provide. If metadata corresponding to the rules for the data desired by the data requester has not yet been registered, provisional metadata is generated in which the rules for the data provision are defined.

[0035] For example, a person involved with the data providing server 2 can input the above-mentioned provisional metadata generated by the operator of the data providing system 1 into the data providing server 2 by operating an operation reception unit (not shown) provided in the data providing server 2 (e.g., comprising one or more input devices such as a keyboard, mouse, push button, touch panel, touchpad, etc.).

[0036] Furthermore, a person involved with the data providing server 2 can input the generated provisional metadata to the data providing server 2 by inserting a recording medium such as a USB memory, HDD, SSD, or memory card, on which the generated provisional metadata is stored, into an external memory interface (not shown) provided in the data providing server 2. Alternatively, the data providing server 2 may acquire the provisional metadata through wired or wireless communication with another device such as a server.

[0037] When provisional metadata is input to the data providing server 2 as described above, the metadata registration unit 201 assigns a meta number to the provisional metadata to generate new metadata, and registers the generated metadata in the metadata management DB 241.

[0038] The data request receiving unit 202 is an example of a data request receiving means according to the present disclosure, and receives a request for data provision from a data requester. In particular, when the data requester accesses the data providing server 2 via a data requesting terminal 5 to request data provision, the data request receiving unit 202 transmits screen data for receiving the data provision request to the data requesting terminal 5. Upon receiving the screen data, the data requesting terminal 5 displays a data request receiving screen on the display 50, as shown in FIG.

[0039] 8, the data requester operates the data request terminal 5 to input the installation location of the device 3 that is the target of the request and the target date and time that is the target of the request. In this embodiment, the device 3 with the device ID "XXYYZZ" is installed on the second floor of building A, and the device 3 with the device ID "SSTTUU" is installed on the third floor of building A. A table (not shown) that associates each device 3 with its installation location is stored in the auxiliary storage device 24.

[0040] When the data requester operates the data request terminal 5 to input the installation location and target date and time on the data request acceptance screen shown in Figure 8 and presses the OK button (see Figure 9), the data request acceptance unit 202 of the data providing server 2 transmits screen data to the data request terminal 5 for accepting the specification of the requested metadata from the data requester.

[0041] Specifically, the data request receiving unit 202 identifies the device 3 corresponding to the input installation location ("Building A, 2nd floor" in FIG. 9) (here, the device 3 with device ID "XXYYZZ"). Next, the data request receiving unit 202 acquires all metadata corresponding to the identified device 3 from the metadata management DB 241 (here, the metadata with meta numbers "1" and "2" are acquired). Then, the data request receiving unit 202 transmits screen data to the data requesting terminal 5 for displaying the contents of each piece of acquired metadata in a selectable manner by the data requester. Upon receiving this screen data, the data requesting terminal 5 displays a list of selectable metadata contents on a data request receiving screen, as shown in FIG. 10.

[0042] On the data request acceptance screen shown in FIG. 10, when the data requester operates the data request terminal 5 to select the content of the requested metadata, i.e., the time interval of the requested operating data, and presses the OK button (see FIG. 11), the data request acceptance unit 202 supplies the request content accepted from the data requester, i.e., the device ID (here, "XXYYZZ") of the device 3 corresponding to the installation location, the target date and time, and the time interval (here, 5 minutes) to the provided data acquisition unit 203.

[0043] In addition, when the data requester operates the data request terminal 5 to input "Building A, 3rd floor" as the installation location, input the target date and time, and press the OK button on the data request acceptance screen shown in Figure 8, the metadata contents as shown in Figure 12 will be displayed in a selectable manner on the data request acceptance screen displayed on the display 50 of the data request terminal 5.

[0044] The provided data acquisition unit 203 is an example of a provided data acquisition means according to the present disclosure. The provided data acquisition unit 203 acquires data (hereinafter referred to as provided data) to be provided to a data requester based on the content of a data provision request received from the data requester and the driving data history stored in the driving history DB 240.

[0045] In detail, first, the provided data acquisition unit 203 generates a query for acquiring the desired target data from the driving history DB 240 based on the request content received from the data requester. For example, in the case of Fig. 11, the provided data acquisition unit 203 generates a query for acquiring driving data every five minutes from 7:00 on February 1st to 23:59 on February 1st for device 3 with device ID "XXYYZZ" from the driving history DB 240. Then, the provided data acquisition unit 203 uses the generated query to acquire the target data, i.e., the provided data, from the driving history DB 240. The provided data acquisition unit 203 supplies the acquired provided data to the provided data transmission unit 204.

[0046] The provided data transmitting unit 204 is an example of a provided data transmitting means according to the present disclosure. The provided data transmitting unit 204 transmits the provided data acquired by the provided data acquiring unit 203 to the data requesting terminal 5 that has requested the provided data.

[0047] 13 is a flowchart showing the procedure of the data providing process executed by the data providing server 2. The data providing process is executed every time an access for the purpose of requesting data provision is received from a data requester via any of the data request terminals 5.

[0048] (Step S101) The data providing server 2 transmits screen data for displaying a data request acceptance screen on the data request terminal 5 to the data request terminal 5. Upon receiving the screen data, the data request terminal 5 displays a data request acceptance screen such as that shown in Fig. 8 on the display 50. Thereafter, the processing of the data providing server 2 proceeds to step S102.

[0049] (Step S102) The data providing server 2 determines whether or not the user of the data request terminal 5, i.e., the data requester, has completed input of the installation location and target date and time. If the installation location and target date and time have already been input when the OK button on the data request acceptance screen is pressed (see FIG. 9), the data providing server 2 determines that input of the installation location and target date and time has been completed. If input of the installation location and target date and time has not been completed, the data providing server 2 continues to execute the processing of step S102. On the other hand, if input of the installation location and target date and time has been completed, the processing of the data providing server 2 transitions to step S103.

[0050] (Step S103) The data providing server 2 acquires metadata corresponding to the installation location input by the data requester. In detail, the data providing server 2 identifies the device 3 corresponding to the input installation location, and acquires all metadata corresponding to the identified device 3 from the metadata management DB 241. Thereafter, the processing of the data providing server 2 proceeds to step S104.

[0051] (Step S104) The data providing server 2 transmits screen data for selecting metadata to the data requesting terminal 5. In particular, the data providing server 2 transmits screen data for displaying the contents of each acquired metadata on a data request acceptance screen in a manner selectable by the data requester to the data requesting terminal 5. Thereafter, the processing of the data providing server 2 proceeds to step S105.

[0052] (Step S105) The data providing server 2 determines whether or not the data requester has completed the selection of metadata. If any metadata content has already been selected when the OK button provided in the area displaying a list of metadata content on the data request acceptance screen is pressed (see FIG. 11), the data providing server 2 determines that the selection of metadata has been completed. If the selection of metadata has not been completed, the data providing server 2 continues to execute the processing of step S105. On the other hand, if the selection of metadata has been completed, the processing of the data providing server 2 transitions to step S106.

[0053] (Step S106) The data providing server 2 generates a query for acquiring target data corresponding to the request content received from the data requester via the data request receiving screen from the driving history DB 240. After that, the processing of the data providing server 2 proceeds to step S107.

[0054] (Step S107) The data providing server 2 uses the generated query to acquire target data from the driving history DB 240. For example, in the case of Fig. 11, for device 3 with device ID "XXYYZZ", driving data every five minutes from 7:00 on February 1st to 23:59 on February 1st is acquired as target data. Thereafter, the processing of the data providing server 2 proceeds to step S108.

[0055] (Step S108) The data providing server 2 transmits the acquired target data to the data request terminal 5 as provided data.

[0056] As described above, according to the data providing system 1 of the first embodiment, the data providing server 2 holds metadata that defines rules for providing data to data requesters. When the data providing server 2 receives a request for data provision from a data requester, it acquires provision data based on the metadata specified by the data requester and the driving data history stored in the driving history DB 240, and provides the acquired provision data to the data requester.

[0057] This makes it possible to provide data that meets the needs of data requesters without having to set up a dedicated database for each data provision rule, thereby reducing management costs and enabling smooth response to new data provision rules.

[0058] Furthermore, since the contents of such metadata can be easily made public, the metadata can be used as a catalog for sales promotion of the data providing service.

[0059] (Variation 1) The device 3 may be an indoor unit, a lighting device, or other facility device installed in a building such as a building or a store, or may be a home appliance installed in a residence such as an air conditioner, a lighting device, a television, or a refrigerator.

[0060] (Variation 2) Furthermore, multiple devices 3 may be installed at an installation location specified by the data requester. In this case, once the data requester has completed inputting the installation location and target date and time (see FIG. 9), the data providing server 2 may present the data requester with a list of information indicating all devices 3 installed at the installation location (for example, the names of the devices 3) via the data request terminal 5, and allow the data requester to select the device 3 that is the subject of the request.

[0061] (Variation 3) Furthermore, the metadata may correspond not only to one device 3 but also to a plurality of devices 3. In this case, the metadata may include the device ID of each device 3.

[0062] (Variation 4) Furthermore, if available metadata is predetermined in a contract with a data requester, when receiving a data provision request from the data requester, the data providing server 2 may accept a designation from the data requester only of metadata available to the data requester. In this case, a table (not shown) associating data requesters with available metadata is stored in the auxiliary storage device 24.

[0063] For example, if the data requester can only use metadata with meta numbers "1" and "2" in FIG. 7, when the data providing server 2 receives a data provision request from the data requester via the data requesting terminal 5, the data providing server 2 transmits screen data to the data requesting terminal 5 for accepting input of the target date and time and selection of the target metadata from the data requester. The data requesting terminal 5, having received such screen data, displays a data request acceptance screen such as that shown in FIG. 14 on the display 50. The data providing server 2 may also include the contents of metadata that the data requester cannot use in the screen data it transmits to the data requesting terminal 5. In this case, however, the data providing server 2 displays the contents of the metadata that the data requester cannot use on the data requesting terminal 5 in a manner that prevents the data requester from selecting the contents of the metadata that the data requester cannot use.

[0064] (Variation 5) In addition, depending on the user authority determined in the contract with the data requester, the longest range of target dates and times that the data requester can specify (e.g., one day, one week, one month, one year, etc.) may be determined, and the longest retroactive period that the data requester can specify as the starting point of the target dates and times (e.g., one day ago, one week ago, one month ago, one year ago, etc.) may be determined.

[0065] (Variation 6) In addition, all or part of the functional units (see FIG. 5) of the data providing server 2 may be realized by dedicated hardware, such as a single circuit, a composite circuit, a programmed processor, an ASIC (Application Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array), or a combination thereof.

[0066] (Variation 7) The data providing server 2 may also be configured with a plurality of separate computer devices. For example, the data providing server 2 may be configured with a first device 7 and a second device 8 as shown in Fig. 15. The first device 7 and the second device 8 each have a hardware configuration as shown in Fig. 2 and are connected to each other via a LAN, for example, so as to be able to communicate with each other.

[0067] The first device 7 includes a driving data acquisition unit 200 and a driving history DB 240, receives and acquires driving data sent from each device 3, and stores the acquired driving data in the driving history DB 240. The second device 8 includes a metadata registration unit 201, a data request reception unit 202, a provided data acquisition unit 203, a provided data transmission unit 204, and a metadata management DB 241, and acquires provided data that meets a request from a data requester from the driving data history stored in the driving history DB 240 included in the first device 7 and the metadata stored in the metadata management DB 241, and provides the provided data to the data requester.

[0068] The technical ideas according to the above-described modifications may be realized independently or in appropriate combination.

[0069] (Embodiment 2) Next, a description will be given of embodiment 2 of the present disclosure. In the following description, components and the like common to embodiment 1 will be given the same reference numerals and descriptions thereof will be omitted.

[0070] 16 is a diagram showing the overall configuration of a data providing system 1A in embodiment 2. The data providing system 1A includes a data providing server 2A, a plurality of devices 6, a plurality of communication devices 4, and a plurality of data request terminals 5. The data providing system 1A differs from the data providing system 1 in that the data providing server 2A is provided instead of the data providing server 2, and the device 6 is provided instead of the device 3.

[0071] <Data providing server 2A> The data providing server 2A is an example of a data providing server according to the present disclosure. Like the data providing server 2 in the first embodiment, the data providing server 2A is a so-called cloud server, and is connected to a network N. The hardware configuration of the data providing server 2A is the same as that of the data providing server 2 (see FIG. 2). However, the functions of the data providing server 2A differ from those of the data providing server 2. Details of the functions of the data providing server 2A will be described later.

[0072] <Equipment 6> Each device 6 is an air conditioner installed in a building, and more specifically, an indoor unit that conditions the air on the floor where it is installed. Each device 6 periodically (for example, every minute) transmits operating data to the data providing server 2A via a communication device 4 connected to the device 6. The operating data transmitted by each device 6 includes the current date and time, operating mode, intake temperature, intake humidity, air volume, outside temperature, and the device ID of the device 6.

[0073] The operation mode indicates, for example, any one of cooling, heating, ventilation, dehumidification, and stop. The intake temperature is the indoor air temperature measured by a temperature sensor provided in the device 6. The intake humidity is the indoor humidity measured by a humidity sensor provided in the device 6. The air volume is an indicator of the volume of air sent into the room, and indicates, for example, any one of strong, normal, and weak. The outdoor temperature is the outdoor air temperature measured by a temperature sensor provided in an outdoor unit (not shown) connected to the device 6.

[0074] <Functional configuration of data provision server 2A> 17 is a block diagram showing the functional configuration of the data providing server 2A. As shown in FIG. 17, the data providing server 2A functionally includes a driving data acquisition unit 200A, a metadata registration unit 201A, a data request reception unit 202A, a provided data acquisition unit 203A, and a provided data transmission unit 204. These functional units of the data providing server 2A are realized by the CPU 21 executing a data management program stored in the auxiliary storage device 24, which is for collecting driving data from each device 6 and managing the history of the collected driving data, and a data providing program for providing data based on the history of the collected driving data to a data requester.

[0075] The operating data acquiring unit 200A periodically (for example, every minute) acquires operating data from each device 6. The operating data acquiring unit 200A periodically transmits a notification requesting operating data to each device 6. When each device 6 receives such a notification via the communication device 4 to which it is connected, it transmits operating data including the current date and time, operating mode, intake temperature, intake humidity, air volume, outside temperature, and the device ID of the device 6 to the data providing server 2A via the communication device 4, as described above.

[0076] The driving data acquisition unit 200A receives and acquires driving data sent from each device 6, and stores the acquired driving data in a driving history DB 240A (see FIG. 18). The driving history DB 240A is an example of a driving history storage means according to the present disclosure. The driving history DB 240A is a database that sequentially stores driving data sent from each device 6, and is stored in the auxiliary storage device 24. The auxiliary storage device 24 stores a history of driving data for each device 6 for a predetermined period (for example, one year).

[0077] The metadata registration unit 201A generates metadata based on provisional metadata that defines new data provision rules input to the data providing server 2A, and registers the generated metadata in the metadata management DB 241A. The metadata management DB 241A is an example of a metadata storage means according to the present disclosure. The metadata management DB 241A is a database for managing metadata, and is stored in the auxiliary storage device 24. In this embodiment, as shown in FIG. 19, the metadata includes a meta number, a device ID, an item, processing details, etc.

[0078] An item is any of the items constituting the operation data. The processing content indicates the content when processing the data value of the item in the operation data of the device 6 in question for provision to the data provider. For example, the metadata with meta number "1" in FIG. 19 indicates that 4°C is to be subtracted from the intake temperature obtained from the operation history DB 240A. This is because the data requester wishes to obtain the air temperature in the activity space of the occupants more accurately, since the intake temperature is higher than the air temperature in the activity space of the occupants during heating.

[0079] Furthermore, the metadata with meta number "2" indicates that the intake temperature history obtained from the operation history DB 240A is to be converted into a 15-minute moving average value. Furthermore, the metadata with meta number "3" indicates that, for the outside temperature obtained from the operation history DB 240A, if the operation mode in the operation data including that outside temperature indicates stop, the value of that outside temperature is to be converted to NULL.

[0080] The data request receiving unit 202A is an example of a data request receiving means according to the present disclosure, and receives a request for data provision from a data requester. In particular, when the data requester accesses the data providing server 2A via a data requesting terminal 5 to request data provision, the data request receiving unit 202A transmits screen data for receiving the data provision request from the data requester to the data requesting terminal 5. Upon receiving the screen data, the data requesting terminal 5 displays a data request receiving screen on the display 50, as shown in FIG.

[0081] 8, the data requester operates the data request terminal 5 to input the installation location of the device 6 that is the target of the request and the target date and time that is the target of the request. In this embodiment, it is assumed that four devices 6 with device IDs "AC0001," "AC0002," "AC0003," and "AC0004" are installed on the second floor of building A. A table (not shown) that associates each device 6 with its installation location is stored in the auxiliary storage device 24.

[0082] When a data requester operates the data requesting terminal 5, inputs the installation location and target date and time, and presses the OK button on the data request acceptance screen shown in Fig. 8 (see Fig. 9), the data request acceptance unit 202A of the data providing server 2A identifies the device 6 corresponding to the input installation location. The data request acceptance unit 202A then transmits screen data to the data requesting terminal 5 for displaying information indicating each identified device 6 in a selectable manner by the data requester. Upon receiving this screen data, the data requesting terminal 5 displays a list of information indicating the devices 6 on the data request acceptance screen in a selectable manner, as shown in Fig. 20.

[0083] 20, "indoor unit 01" is the name given to the device 6 with device ID "AC0001", "indoor unit 02" is the name given to the device 6 with device ID "AC0002", "indoor unit 03" is the name given to the device 6 with device ID "AC0003", and "indoor unit 04" is the name given to the device 6 with device ID "AC0004". Note that the names may include information about the specific installation location of the device 6 on the floor.

[0084] On the data request acceptance screen shown in Figure 20, when a data requester operates the data request terminal 5 to select the device 6 to be requested and presses the OK button (see Figure 21), the data request acceptance unit 202A of the data providing server 2A sends screen data to the data request terminal 5 for accepting the specification of the metadata to be requested from the data requester.

[0085] Specifically, the data request receiving unit 202A acquires all metadata corresponding to the selected device 6 (in FIG. 21, "indoor unit 01," i.e., the device 6 with device ID "AC0001") from the metadata management DB 241A (here, metadata with meta numbers "1," "2," and "3" are acquired). Then, the data request receiving unit 202A transmits screen data to the data requesting terminal 5 for displaying the contents of each acquired piece of metadata in a selectable manner by the data requester. Upon receiving this screen data, the data requesting terminal 5 displays a list of selectable metadata contents on a data request receiving screen, as shown in FIG. 22.

[0086] On the data request acceptance screen shown in FIG. 22, when the data requester operates the data request terminal 5 to select the content of the requested metadata, i.e., the requested operating data item and processing content, and presses the OK button (see FIG. 23), the data request acceptance unit 202A supplies the request content accepted from the data requester, i.e., the target date and time, the device ID of the selected device 6 (here, "AC0001"), the operating data item (here, suction temperature), and the processing content (here, subtract 4°C), to the provided data acquisition unit 203A.

[0087] The provided data acquisition unit 203A is an example of a provided data acquisition means according to the present disclosure. The provided data acquisition unit 203A acquires provided data to be provided to a data requester based on the content of a data provision request received from the data requester and the driving data history stored in the driving history DB 240A.

[0088] In detail, first, the provided data acquiring unit 203A generates a query for acquiring the desired target data from the operation history DB 240A based on the request content received from the data requester. For example, in the case of Fig. 23, the provided data acquiring unit 203A generates a query for acquiring, from the operation history DB 240A, the suction temperature of all operation data from 7:00 on February 1st to 23:59 on February 1st for device 6 with device ID "AC0001". Then, the provided data acquiring unit 203A uses the generated query to acquire the target data from the operation history DB 240A.

[0089] The provided data acquiring unit 203A then processes the acquired target data based on the processing content received from the data requester, and acquires the processed data as the provided data. For example, in the case of Fig. 23, the provided data acquiring unit 203A acquires, as the provided data, data obtained by subtracting 4°C from the intake temperature values ​​of all operating data from 7:00 on February 1st to 23:59 on February 1st. The provided data acquiring unit 203A supplies the acquired provided data to the provided data transmitting unit 204.

[0090] The provided data transmitting unit 204 is an example of a provided data transmitting means according to the present disclosure. The provided data transmitting unit 204 transmits the provided data acquired by the provided data acquiring unit 203A to the data requesting terminal 5 that has requested the provided data.

[0091] 24 is a flowchart showing the procedure of the data provision process executed by the data provision server 2 A. The data provision process is executed every time an access for the purpose of requesting data provision is received from a data requester via any of the data request terminals 5.

[0092] (Step S201) The data providing server 2A transmits screen data for displaying a data request acceptance screen on the data requesting terminal 5 to the data requesting terminal 5. Upon receiving the screen data, the data requesting terminal 5 displays a data request acceptance screen such as that shown in Fig. 8 on the display 50. Thereafter, the processing of the data providing server 2A proceeds to step S202.

[0093] (Step S202) The data providing server 2A determines whether or not the user of the data request terminal 5, i.e., the data requester, has completed input of the installation location and target date and time. If the installation location and target date and time have already been input when the OK button on the data request acceptance screen is pressed (see FIG. 9), the data providing server 2A determines that input of the installation location and target date and time has been completed. If input of the installation location and target date and time has not been completed, the data providing server 2A continues to execute the processing of step S202. On the other hand, if input of the installation location and target date and time has been completed, the processing of the data providing server 2A transitions to step S203.

[0094] (Step S203) The data providing server 2A identifies all devices 6 corresponding to the installation locations input by the data requester. After that, the process of the data providing server 2A proceeds to step S204.

[0095] (Step S204) The data providing server 2A transmits screen data for device selection to the data requesting terminal 5. In particular, the data providing server 2A transmits screen data for displaying each of the identified devices 6 on a data request acceptance screen in a manner that allows the data requester to select the devices 6, to the data requesting terminal 5. Thereafter, the processing of the data providing server 2A proceeds to step S205.

[0096] (Step S205) The data providing server 2A determines whether or not the selection of device 6 has been completed by the data requester. If the name of any device 6 has already been selected when the OK button provided in the area displaying the list of device 6 names on the data request acceptance screen is pressed (see FIG. 21), the data providing server 2A determines that the selection of device 6 has been completed. If the selection of device 6 has not been completed, the data providing server 2A continues to execute the processing of step S205. On the other hand, if the selection of device 6 has been completed, the processing of the data providing server 2A transitions to step S206.

[0097] (Step S206) The data providing server 2A acquires metadata corresponding to the device 6 selected by the data requester. In particular, the data providing server 2A acquires all metadata corresponding to the selected device 6 from the metadata management DB 241A. Thereafter, the processing of the data providing server 2A transitions to step S207.

[0098] (Step S207) The data providing server 2A transmits screen data for selecting metadata to the data requesting terminal 5. In particular, the data providing server 2A transmits screen data for displaying the contents of each acquired metadata on a data request acceptance screen in a manner selectable by the data requester to the data requesting terminal 5. Thereafter, the processing of the data providing server 2A transitions to step S208.

[0099] (Step S208) The data providing server 2A determines whether or not the data requester has completed the selection of metadata. If any metadata content has already been selected when the OK button provided in the area displaying a list of metadata content on the data request acceptance screen is pressed (see FIG. 23), the data providing server 2A determines that the selection of metadata has been completed. If the selection of metadata has not been completed, the data providing server 2A continues to execute the processing of step S208. On the other hand, if the selection of metadata has been completed, the processing of the data providing server 2A transitions to step S209.

[0100] (Step S209) The data providing server 2A generates a query for acquiring target data from the driving history DB 240A according to the request content received from the data requester via the data request receiving screen. After that, the processing of the data providing server 2A proceeds to step S210.

[0101] (Step S210) The data providing server 2A uses the generated query to acquire target data from the operation history DB 240A. For example, in the case of Fig. 23, for device 6 with device ID "AC0001", the suction temperature in all operation data from 7:00 on February 1st to 23:59 on February 1st is acquired as target data. Thereafter, the processing of the data providing server 2A transitions to step S211.

[0102] (Step S211) The data providing server 2A acquires the provided data by processing the acquired target data based on the processing content received from the data requester. After that, the process of the data providing server 2A proceeds to step S212.

[0103] (Step S212) The data providing server 2A transmits the acquired provided data to the data request terminal 5.

[0104] As described above, according to the data providing system 1A of the second embodiment, the data providing server 2A holds metadata that defines rules for providing data to data requesters. When the data providing server 2A receives a request for data provision from a data requester, it acquires provision data based on the metadata specified by the data requester and the driving data history stored in the driving history DB 240A, and provides the acquired provision data to the data requester.

[0105] This makes it possible to provide data that meets the needs of data requesters without having to set up a dedicated database for each data provision rule, thereby reducing management costs and enabling smooth response to new data provision rules.

[0106] Furthermore, since the contents of such metadata can be easily made public, the metadata can be used as a catalog for sales promotion of the data providing service.

[0107] In addition, the target data acquired from the driving history DB240A can be processed and provided to the data requester, thereby expanding the content of the service.

[0108] (Variation 1) The processing content of the metadata shown in Fig. 19 is merely an example. As the processing content, for example, various statistical calculations such as the average value, maximum value, minimum value, median value, etc. for each specified time period can be set, and various conditions other than statistical calculations can also be set.

[0109] (Variation 2) Furthermore, the device 6 may be a facility device other than an indoor unit installed in a building such as a building, a store, etc. Alternatively, the device 6 may be a home appliance installed in a house such as an air conditioner, a lighting device, a television, or a refrigerator.

[0110] (Variation 3) Furthermore, the metadata may correspond not only to one device 6 but also to a plurality of devices 6. In this case, the metadata may include the device ID of each device 6.

[0111] (Variation 4) Furthermore, if the available metadata is predetermined by a contract with a data requester, when the data providing server 2A receives a request for data provision from the data requester, the data providing server 2A may accept a designation from the data requester only for metadata available to the data requester. In this case, a table (not shown) associating data requesters with available metadata is stored in the auxiliary storage device 24.

[0112] For example, if the data requester can only use the metadata with meta numbers "1" and "2" in FIG. 19, when the data providing server 2A receives a data provision request from the data requester via the data requesting terminal 5, the data providing server 2A transmits screen data to the data requesting terminal 5 for accepting input of the target date and time and selection of the target metadata from the data requester. The data requesting terminal 5, upon receiving such screen data, displays a data request acceptance screen such as that shown in FIG. 25 on the display 50. Note that the data providing server 2A may also include the contents of metadata that the data requester cannot use in the screen data transmitted to the data requesting terminal 5. In this case, however, the data providing server 2A displays the contents of the metadata that the data requester cannot use on the data requesting terminal 5 in a manner that prevents the data requester from selecting the contents of the metadata that the data requester cannot use.

[0113] (Variation 5) In addition, depending on the user authority determined in the contract with the data requester, the longest range of target dates and times that the data requester can specify (e.g., one day, one week, one month, one year, etc.) may be determined, and the longest retroactive period that the data requester can specify as the starting point of the target dates and times (e.g., one day ago, one week ago, one month ago, one year ago, etc.) may be determined.

[0114] (Variation 6) In addition, all or part of the functional units of the data providing server 2A (see FIG. 17) may be realized by dedicated hardware, such as a single circuit, a composite circuit, a programmed processor, an ASIC, an FPGA, or a combination thereof.

[0115] (Variation 7) The data providing server 2A may also be configured with a plurality of separate computer devices. For example, the data providing server 2A may be configured with a first device 7A and a second device 8A as shown in Fig. 26. The first device 7A and the second device 8A each have the hardware configuration shown in Fig. 2 and are connected to each other via a LAN, for example, so as to be able to communicate with each other.

[0116] The first device 7A includes a driving data acquisition unit 200A and a driving history DB 240A, receives and acquires driving data sent from each device 6, and stores the acquired driving data in the driving history DB 240A. The second device 8A includes a metadata registration unit 201A, a data request reception unit 202A, a provided data acquisition unit 203A, a provided data transmission unit 204, and a metadata management DB 241A, and acquires provided data that meets a request from a data requester from the driving data history stored in the driving history DB 240A included in the first device 7A and the metadata stored in the metadata management DB 241A, and provides the provided data to the data requester.

[0117] The technical ideas according to the above-described modifications may be realized independently or in appropriate combination.

[0118] The present disclosure is not limited to the above-described embodiments and their modifications, and various modifications are of course possible within the scope of the gist of the present disclosure. [Explanation of symbols]

[0119] 1,1A Data providing system, 2,2A Data providing server, 3,6 Equipment, 4 Communication device, 5 Data request terminal, 7,7A First device, 8,8A Second device, 20,52 Communication interface, 21,42,53 CPU, 22,43,54 ROM, 23,44,55 RAM, 24,45,56 Auxiliary storage device, 25,46,57 Bus, 40 First communication interface, 41 Second communication interface, 50 Display, 51 Operation reception unit, 200,200A Operation data acquisition unit, 201,201A Metadata registration unit, 202,202A Data request reception unit, 203,203A Provided data acquisition unit, 204 Provided data transmission unit, 240,240A Operation history DB, 241,241A Metadata management DB

Claims

1. an operation history storage means for sequentially storing operation data relating to the operation of the equipment; a metadata storage means for storing metadata defining rules for providing data that can be handled by the driving data sequentially stored in the driving history storage means; a data request receiving means for receiving a request for data provision from a data requester via a terminal, for acquiring metadata corresponding to the request from the metadata storage means, and for allowing the data requester to specify, via the terminal, metadata to be used from among the metadata acquired from the metadata storage means; a provision data acquisition means for acquiring provision data, which is data to be provided to the data requester, based on rules for providing data defined by metadata specified by the data requester and the driving data sequentially stored in the driving history storage means; a provision data transmitting means for transmitting the acquired provision data to the terminal.

2. The data providing server of claim 1 , wherein the metadata includes a time interval of the history of the driving data.

3. The data providing server according to claim 1 , wherein the metadata includes details of processing the driving data history.

4. Available metadata is predefined for each data requester, 4. The data providing server according to claim 1, wherein said data request accepting means accepts from said data requester a designation of only metadata that can be used by said data requester.

5. an operation history storage means for sequentially storing operation data relating to the operation of the equipment; a metadata storage means for storing metadata defining rules for providing data that can be handled by the driving data sequentially stored in the driving history storage means, Accept a request for data provision from a data requester via a terminal, acquiring metadata corresponding to the request from the metadata storage means, and having the data requester specify via the terminal the metadata to be used from among the metadata acquired from the metadata storage means; Acquire provision data to be provided to the data requester based on rules for providing data defined by metadata specified by the data requester and the driving data sequentially stored in the driving history storage means; a data providing method for transmitting the acquired provided data to the terminal;

6. an operation history storage means for sequentially storing operation data relating to the operation of the equipment; a metadata storage means for storing metadata defining rules for providing data that can be handled by the driving data sequentially stored in the driving history storage means, a data request receiving means for receiving a request for data provision from a data requester via a terminal, for obtaining metadata corresponding to the request from the metadata storage means, and for allowing the data requester to specify, via the terminal, metadata to be used from among the metadata obtained from the metadata storage means; provided data acquisition means for acquiring provided data to be provided to the data requester based on rules for providing data defined by metadata designated by the data requester and the driving data sequentially stored in the driving history storage means; a program that causes the computer to function as a provided data transmission means that transmits the acquired provided data to the terminal;

Images