Patent Description:
In various production sites, FA (Factory Automation) systems for automating production processes have been pervasive. Each of such FA systems includes various industrial drive devices. Examples of the industrial drive devices include: a movable table for moving a workpiece; a conveyor for conveying a workpiece; an arm robot for moving a workpiece to a predetermined target location; and the like. These drive devices are controlled by industrial controllers such as PLCs (Programmable Logic Controllers) and robot controllers.

In recent years, controllers to which software can be installed from external devices have been pervasive. Such controllers are disclosed in <CIT> (Patent Literature <NUM>), <CIT> (Patent Literature <NUM>), <CIT> (Patent Literature <NUM>), and <CIT> (Patent Literature <NUM>).

Further prior art documents are <CIT> and <CIT>.

<CIT> discloses a method of binding a software to a device. Accordingly, during a setup of the software in the device, a unique identifier is derived from contents stored in the device and the derived unique identifier is encrypted. The derived unique identifier is then stored in a configuration of the software. During a next invocation of the software in the device, a new unique identifier is derived from the contents stored in the device. The newly derived unique identifier is then matched with the stored unique identifier. The execution of the software is terminated if the matching fails.

Moreover, <CIT> discloses techniques to facilitate protection of control system content used in an industrial automation environment. In at least one implementation, the control system content for use in the industrial automation environment is received, wherein the control system content comprises controller program code that directs an industrial controller to drive a machine system. Content protection instructions for the control system content are also received, wherein the content protection instructions comprise restrictions on execution of the control system content. An execution license that includes process-related constraints for the control system content is generated based on the content protection instructions. The execution license is applied to the control system content to generate protected content, wherein use of the control system content is granted subject to the process-related constraints of the execution license.

In recent years, since various types of software have been developed, management of software licenses has become complicated. If a license is not managed appropriately, purchased software may be copied in an unauthorized manner, which may lead to unauthorized use of the software in a different controller not having the license. Therefore, a mechanism for preventing such unauthorized use is desired.

The present disclosure has been made to solve the above-described problem, and an object thereof in a certain aspect is to provide a mechanism by which unauthorized use of software downloaded to a controller can be prevented. This object is achieved by the subject-matter of the independent claims. Further modifications and embodiments of the invention are the subject-matter of the dependent claims.

A controller as defined by claim <NUM> is for controlling a control target and includes: an obtaining unit that obtains, from an external device, software to be used by the controller; and a processor that executes the software. The software includes: a generation module that generates an execution right for the software from first unique information for uniquely identifying the controller or the external device; and a check module that generates second unique information from the execution right at a predetermined timing after the generation of the execution right, and that prohibits use of the software when the second unique information does not coincide with the first unique information.

Accordingly, use of the obtained software is prohibited based on the license information, whereby unauthorized use of the software is prevented.

In one example, the external device includes a communication device that communicates with the controller. The obtaining unit downloads the software from the communication device communicatively connected to the controller.

Accordingly, unauthorized use of the software downloaded from the communication device is prevented.

In one example, the external device includes a memory card that is electrically connectable to the controller. The obtaining unit obtains the software from the memory card electrically connected to the controller.

Accordingly, unauthorized use of the software obtained from the memory card is prevented.

In one example, the processor deletes the execution right when transferring the obtained software from the controller to the external device.

Accordingly, a plurality of pieces of the license information of the software do not exist, whereby unauthorized use of the software is prevented more securely.

In one example, the processor deletes the generation module and the check module when transferring the obtained software from the controller to the external device.

Accordingly, since the generation module and the check module are deleted, a resource of the controller can be effectively used.

In one example, the software obtainable from the external device includes at least one of a program to be operated on firmware of the controller, a program to be added to the firmware, and data usable by the controller.

Accordingly, unauthorized use of the program to be operated on the firmware and the program to be added to the firmware is prevented.

A method as defined in claim <NUM> is for managing a license of software used by a controller for controlling a control target and includes: obtaining, from an external device, software to be used by the controller, and first license information for the software; and executing the software. The executing includes: generating an execution right for the software from first unique information for uniquely identifying the controller or the external device; and generating second unique information from the execution right at a predetermined timing after the generation of the execution right, and prohibiting use of the software when the second unique information does not coincide with the first unique information.

A program as defined in claim <NUM> is for managing a license of software used by a controller for controlling a control target and causes the controller to perform: obtaining, from an external device, software to be used by the controller for controlling the control target; and executing the software. The executing includes: generating an execution right for the software from first unique information for uniquely identifying the controller or the external device; and generating second unique information from the execution right at a predetermined timing after the generation of the execution right, and prohibiting use of the software when the second unique information does not coincide with the first unique information.

In a certain aspect, unauthorized use of software downloaded to a controller can be prevented.

The following describes embodiments according to the present invention with reference to figures. In the description below, the same reference characters are given to the same parts and components. Their names and functions are also the same. Hence, they are not described in detail repeatedly.

An implementation of the present invention will be described with reference to <FIG> shows an overview of an FA system <NUM>.

FA system <NUM> is a system for controlling a control target such as a facility or a device to automate a production process. FA system <NUM> includes one or more controllers <NUM>, one or more external devices <NUM>, and one or more drive devices <NUM>.

Controller <NUM> includes an obtaining unit <NUM>, a processor <NUM>, and a storage device <NUM> as hardware configurations. Storage device <NUM> stores package software <NUM> downloaded from external device <NUM>, and unique information 143A of controller <NUM>.

External device <NUM> provides various types of software executable by controller <NUM>. Examples of such an external device <NUM> include a below-described development assistance device 200A (see <FIG>), a below-described server 200B (see <FIG>), a below-described memory card 200C (see <FIG>), and the like.

Obtaining unit <NUM> is appropriate hardware having a function of obtaining software from external device <NUM>. As an example, obtaining unit <NUM> includes: a communication interface for communicating with external device <NUM>; a memory card interface to which a memory card such as an SD card is connectable; or the like.

In the example of <FIG>, the software downloaded from external device <NUM> is shown as package software <NUM>. Package software <NUM> represents a unit of a program for sale with a package of various functions. Examples of package software <NUM> include: a function to be added to controller <NUM>; data; and the like.

Processor <NUM> executes various types of programs of controller <NUM> to control a drive device <NUM> serving as a control target. As an example, the programs executed by processor <NUM> include various types of programs, such as downloaded package software <NUM>.

Downloaded package software <NUM> includes a generation module <NUM>, a check module <NUM>, and other function modules. Each of the other function modules is a function module usable by the user. Generation module <NUM> and check module <NUM> are accompanied with the function module.

Generation module <NUM> generates execution right <NUM> for package software <NUM> from unique information 143A (first unique information) for uniquely identifying controller <NUM>. Execution right <NUM> corresponds to an authority to execute package software <NUM>. That is, controller <NUM> holding execution right <NUM> can execute package software <NUM>. Unique information 143A includes: format, production information (such as manufacturing number), and name of controller <NUM> or processor <NUM>; and other information for uniquely identifying controller <NUM>, for example.

Any method is employed to generate execution right <NUM>. As an example, generation module <NUM> generates execution right <NUM> by encrypting unique information 143A in accordance with a predetermined encryption method. In this case, generation module <NUM> generates execution right <NUM> using a predetermined encryption key. Alternatively, generation module <NUM> may generate, as execution right <NUM>, a result obtained by substituting unique information 143A for a predetermined, reversibly computable formula. Generated execution right <NUM> is stored into storage device <NUM>.

Check module <NUM> generates unique information (second unique information) from execution right <NUM> at a predetermined timing after the generation of execution right <NUM>, such as a time at which controller <NUM> is activated or a time at which package software <NUM> is executed. In the description below, for the ease of description, the unique information held in advance in controller <NUM> will be referred to as "unique information 143A", and the unique information generated from execution right <NUM> after the generation of execution right <NUM> will be referred to as "unique information 143B". Check module <NUM> prohibits use of package software <NUM> when unique information 143B does not coincide with original unique information 143A.

More specifically, check module <NUM> includes a decryption module 156A and a comparison module 156B. Decryption module 156A decrypts execution right <NUM> in accordance with a predetermined decryption method using a predetermined decryption key, thereby generating unique information 143B.

Comparison module 156B compares unique information 143B generated at the time at which controller <NUM> is activated or the time at which package software <NUM> is used, with original unique information 143A. When unique information 143B coincides with unique information 143A, comparison module 156B permits use of downloaded package software <NUM>. On the other hand, when unique information 143B does not coincide with unique information 143A, comparison module 156B prohibits use of downloaded package software <NUM>.

The expression "coincide" herein can include not only a case where the whole of unique information 143B coincides with the whole of unique information 143A, but also a case where a predetermined portion of unique information 143B coincides with a predetermined portion of unique information 143A. The expression "not coincide" indicates a case where the condition for "coincide" is not satisfied.

As described above, permission/prohibition of use of package software <NUM> is switched based on a result of the comparison between original unique information 143A and unique information 143B generated at the time at which package software <NUM> is executed or the like. Accordingly, for example, use of package software <NUM> can be prevented when package software <NUM> is transferred in an unauthorized manner to a controller different from the one to which package software <NUM> is downloaded. Moreover, since the mechanism for checking a license is included in package software <NUM>, controller <NUM> does not need to have a license check function in advance.

With reference to <FIG>, an exemplary device configuration of FA system <NUM> will be described. <FIG> is a schematic view schematically showing the device configuration of FA system <NUM>.

FA system <NUM> includes one or more controllers <NUM> and one or more external devices <NUM>. In the example of <FIG>, FA system <NUM> includes two controllers 100A, 100B. As examples of external device <NUM> that can be connected to controller <NUM>, development assistance device 200A, server 200B, and memory card 200C are shown.

In the description below, controllers 100A, 100B will be also collectively referred to as controller <NUM>. Controller <NUM> has a plurality of physical communication ports. Different networks can be connected to the respective communication ports. In the example of <FIG>, controller <NUM> has two communication ports P1, P2. A network NW1 is connected to communication port P1. A network NW2 is connected to communication port P2.

For network NW1, EtherNet/IP (registered trademark), EtherNet (registered trademark), or the like is employed, for example. As an example, various types of communication devices each having a function of communicating with controller <NUM> can be connected to network NW1, such as development assistance device 200A and server 200B.

Development assistance device 200A is a PC (Personal Computer), a tablet terminal, a smartphone, or the like, for example. A program development tool can be installed in development assistance device 200A. The program development tool is an application for assisting development of a control program for controller <NUM>. As an example, the program development tool is "Sysmac Studio" provided by OMRON. The user can design a control program for controller <NUM> on the program development tool, and can install the designed control program to controller <NUM>. The created control program is sent to controller <NUM> as a file of a code in an executable form compiled by development assistance device 200A.

Server 200B is a device that provides various types of package software <NUM> executable by controller <NUM>. Examples of package software <NUM> to be provided include: a function of connecting to an external database; various types of functions for NC (Numerical Control) control; various types of functions for robotic control; various types of functions for AI (Artificial Intelligence); various types of data usable by controller <NUM> (for example, various types of data obtained through a learning process of AI); various types of functions of controlling specific drive devices <NUM> (for example, an oscillation control function); and the like. It should be noted that package software <NUM> is not limited to be provided from server 200B, and is provided from any external device <NUM>. As an example, package software <NUM> may be provided from memory card 200C.

For network NW2, it is preferable to employ a field network that performs constant-cycle communication to ensure a time of arrival of data. As the field network that performs such constant-cycle communication, EtherCAT (registered trademark), CompoNet (registered trademark), or the like has been known. In accordance with the control program created on development assistance device 200A, controller <NUM> controls drive device <NUM> serving as a control target.

Drive device <NUM> represents a group of devices for performing predetermined operations onto a workpiece directly or indirectly. In the example of <FIG>, drive device <NUM> includes a robot controller 300A, a servo driver 300B, an arm robot 301A controlled by robot controller 300A, a servo motor 301B controlled by servo driver 300B, and the like. Moreover, drive device <NUM> may also include: a visual sensor for capturing an image of a workpiece; other devices to be used in a production process; and the like.

With reference to <FIG>, the following describes an exemplary manner of sales of package software <NUM>. <FIG> shows a mechanism for selling package software <NUM> by way of downloading.

The example of <FIG> shows server 200B from which package software <NUM> is provided, and development assistance device 200A to which package software <NUM> is provided. As an example, server 200B is placed in a company "A", which is a seller of package software <NUM>. Development assistance device 200A is placed in a company "B", which is a purchaser of package software <NUM>.

In a step (<NUM>), a user of development assistance device 200A accesses a web site or the like of server 200B to select a piece of package software for download from pieces of package software for sale. The pieces of package software for sale include: a program to be operated on firmware of controller <NUM>; a firmware program to be added to the firmware; and the like. The package software to be operated on the firmware is operated depending on a basic function provided from the firmware.

The user of development assistance device 200A selects package software <NUM> for purchase and then performs a purchasing procedure. When the purchasing procedure is completed, server 200B installs purchased package software <NUM> into development assistance device 200A. On this occasion, in a step (<NUM>), server 200B transmits, to development assistance device 200A, a license right <NUM> for permitting use of package software <NUM>.

In a step (<NUM>), development assistance device 200A installs, into controller <NUM>, package software <NUM> and license right <NUM> that are installed from server 200B.

It is assumed that in a step (<NUM>), development assistance device 200A receives a validation manipulation for validating the license right for package software <NUM>. Based on this, development assistance device 200A transmits a validation command to controller <NUM>. Based on reception of the validation command, controller <NUM> generates execution right <NUM> from unique information 143A of controller <NUM>.

In a step (<NUM>), based on the validation process for package software <NUM> being completed normally, development assistance device 200A transmits, to server 200B, an indication that a right of use of package software <NUM> is exercised. On this occasion, information about the user who exercises the right of use is transmitted to server 200B, and is registered into server 200B.

With reference to <FIG> and <FIG>, the following describes a control flow for implementing the sale by way of downloading as shown in <FIG>. <FIG> is a sequence diagram showing a data flow among controller <NUM>, development assistance device 200A, and server 200B.

It is assumed that in a step S10, the user of development assistance device 200A accesses the web site of server 200B and performs a manipulation to purchase package software <NUM>. On this time, the user inputs various types of information (hereinafter, also referred to as "purchasing information") in order to purchase package software <NUM>. The purchasing information includes: information for specifying package software <NUM> for purchase; various types of information about the purchaser (for example, the name, address, and the like); and various types of information about controller <NUM> to which package software <NUM> is to be downloaded. The purchasing information thus input is transmitted to server 200B.

In a step S14, server 200B issues license right <NUM> for package software <NUM> based on the purchasing information received from development assistance device 200A. Issued license right <NUM> is transmitted to development assistance device 200A together with purchased package software <NUM>.

It is assumed that in a step S20, development assistance device 200A receives a manipulation for downloading package software <NUM> downloaded from server 200B. Based on this, development assistance device 200A transmits package software <NUM> and license right <NUM> to designated controller <NUM>.

In a step S26, controller <NUM> performs a deploy process to deploy package software <NUM> to internal storage device <NUM> (see <FIG>). On this occasion, controller <NUM> updates a software management table for deploying and managing the package software in the internal storage device. <FIG> shows a data structure of a software management table <NUM>.

Software management table <NUM> is a database for managing pieces of package software downloaded to controller <NUM>. Software management table <NUM> includes: a list table <NUM> for pieces of package software; and pieces of detailed information <NUM> to <NUM> of the pieces of package software.

List table <NUM> for the pieces of package software includes: a column 160A that defines an abbreviation of each piece of package software; a column 160B that defines a version of the package software; a column 160C that defines a classification of the package software; a column 160D that defines an add-on type of the package software; a column 160E that defines a manner of provision of the package software; a column 160F that defines a full name of the package software; and a column 160F that defines a provider of the package software.

Each record of list table <NUM> for the pieces of package software is associated with the detailed information of the package software. As an example, the detailed information of each piece of package software <NUM> is associated using the information of column 160A of list table <NUM> as a key. In the example of <FIG>, detailed information <NUM> is associated with a package name shown as "ECAT". The pieces of detailed information <NUM>, <NUM> are associated with a package name shown as "AI".

Detailed information <NUM> includes: a column 161A that defines the abbreviation of the package software; a column 161B that indicates a type of supported language; a column 161C that defines the full name of the package software; and a column 161D that defines the provider of the package software.

Detailed information <NUM> includes: a column 162A that defines the abbreviation of the package software; a column 162B that indicates the type of supported language; a column 162C that defines the full name of the package software; and a column 162D that defines the provider of the package software.

In detailed information <NUM>, various types of methods (processes) included in the package software are defined. Detailed information <NUM> includes: a column 163A that indicates a name of a method; a column 163B indicating an invoke type of the package software; a column 163C that defines a deploy method of the package software; and a column 163D that defines a rollback method of the package software.

With reference to <FIG> again, in a step S28, controller <NUM> serves as generation module <NUM> (see <FIG>) to generate execution right <NUM> from its unique information 143A. Generation module <NUM> generates execution right <NUM> from unique information 143A in accordance with a predetermined encryption method. As an example, generation module <NUM> generates execution right <NUM> using a predetermined encryption key. Generated execution right <NUM> is stored in storage device <NUM> of controller <NUM>.

In a step S30, controller <NUM> determines whether or not a predetermined timing has come. Examples of the predetermined timing include: a time at which controller <NUM> is activated; a time at which package software <NUM> is executed; and any predetermined timing after the generation of execution right <NUM>. When it is determined that the predetermined timing has come (YES in step S30), controller <NUM> switches the control to a step S32. Otherwise (NO in step S30), controller <NUM> performs the process of step S30 again.

In step S32, controller <NUM> serves as check module <NUM> (see <FIG>) to generate unique information 143B from execution right <NUM> generated in step S28. As an example, controller <NUM> decrypts execution right <NUM> in accordance with a decryption method corresponding to the encryption method used to generate execution right <NUM> from unique information 143A in step S28, thereby generating unique information 143B.

In a step S40, controller <NUM> serves as check module <NUM> (see <FIG>) to determine whether or not unique information 143B generated in step S32 coincides with original unique information 143A. When it is determined that generated unique information 143B coincides with original unique information 143A (YES in step S40), controller <NUM> switches the control to a step S42. Otherwise (NO in step S40), controller <NUM> switches the control to a step S44.

In step S42, controller <NUM> permits use of downloaded package software <NUM>. Any means can be employed to permit use of package software <NUM>. As an example, a flag indicating prohibition/permission of use is managed by controller <NUM>, and controller <NUM> rewrites the flag to indicate permission.

In step S44, controller <NUM> prohibits use of downloaded package software <NUM>. Any means can be employed to prohibit use of package software <NUM>. As an example, a flag indicating prohibition/permission of use is managed by controller <NUM>, and controller <NUM> rewrites the flag to indicate prohibition.

With reference to <FIG> and <FIG>, the following sequentially describes hardware configurations of controller <NUM> and external device <NUM>.

First, the hardware configuration of controller <NUM> will be described with reference to <FIG> is a schematic view showing an exemplary hardware configuration of controller <NUM>.

Controller <NUM> includes: a communication interface 101A; a memory card interface 101B; processor <NUM>, such as a CPU (Central Processing Unit) or a MPU (Micro-Processing Unit); a chip set <NUM>; a main memory <NUM>; nonvolatile storage device <NUM>; an internal bus controller <NUM>; and a field bus controller <NUM>.

Processor <NUM> reads out control program <NUM> stored in storage device <NUM>, expands it in main memory <NUM>, and executes it, thereby implementing appropriate control over a drive device <NUM> or the like to be controlled. Control program <NUM> includes various types of programs for controlling controller <NUM>. As an example, control program <NUM> includes a system program <NUM> as firmware, package software <NUM>, a user program <NUM>, and the like. System program <NUM> includes an instruction code for providing a basic function of controller <NUM> such as a data input/output process or execution timing control. User program <NUM> is downloaded from external device <NUM>. User program <NUM> is appropriately designed for a control target on external device <NUM>, and includes: a sequence program 145A for performing sequence control; and a motion program 145B for performing motion control.

Chip set <NUM> implements a process as a whole of controller <NUM> by controlling each component.

Storage device <NUM> stores various types of data in addition to control program <NUM>. As an example, storage device <NUM> stores: license right <NUM> for package software <NUM>; unique information 143A for uniquely identifying controller <NUM>; software management table <NUM> (see <FIG>) described above; and the like. License right <NUM> includes execution right <NUM> for package software <NUM>. Execution right <NUM> is generated at a predetermined timing, such as a time at which package software <NUM> is downloaded (deployed), for example.

Internal bus controller <NUM> is an interface for exchanging data with various types of devices coupled to controller <NUM> through an internal bus. As an example of such devices, an I/O unit <NUM> is connected thereto.

Field bus controller <NUM> is an interface for exchanging data between controller <NUM> and various types of drive devices <NUM> coupled thereto through a field bus. As examples of such devices, robot controller 300A and servo driver 300B are connected thereto. In addition, a drive device such as a visual sensor may be connected thereto.

Each of internal bus controller <NUM> and field bus controller <NUM> can provide an appropriate command to a device connected thereto, and can obtain appropriate data managed by the device. Moreover, internal bus controller <NUM> and/or field bus controller <NUM> function also as interface(s) for exchanging data with robot controller 300A or servo driver 300B.

Communication interface 101A represents an example of obtaining unit <NUM> (see <FIG>). Communication interface 101A controls exchange of data via various types of wired/wireless networks. Controller <NUM> communicates with external device <NUM>, such as development assistance device 200A and server 200B, through communication interface 101A. Controller <NUM> can download package software <NUM> or the like from external device <NUM> through communication interface 101A.

Memory card interface 101B represents an example of obtaining unit <NUM> (see <FIG>). Memory card interface 101B is an interface for electrically connecting memory card 200C (for example, an SD card), which is an exemplary external storage medium. Memory card 200C is attachable/detachable to/from memory card interface 101B. Memory card interface 101B can write data in memory card 200C, and read data from memory card 200C. Controller <NUM> can download package software <NUM> or the like from memory card 200C through memory card interface 101B. Moreover, memory card 200C stores: license right <NUM> for package software <NUM>; unique information 243A for uniquely identifying memory card 200C; and the like.

Next, the hardware configuration of external device <NUM> will be described with reference to <FIG> is a schematic view showing the hardware configuration of external device <NUM>.

As an example, external device <NUM> includes a computer configured in accordance with a general-purpose computer architecture. External device <NUM> is development assistance device 200A or server 200B described above, for example. External device <NUM> includes: a control device <NUM> such as a CPU or an MPU; a main memory <NUM>; a nonvolatile storage device <NUM>; a communication interface <NUM>; an I/O (Input/Output) interface <NUM>; and a display interface <NUM>. These components are communicatively connected to one another through an internal bus <NUM>.

Control device <NUM> expands, into main memory <NUM>, a development assistance program 208A stored in storage device <NUM>, and executes it, thereby implementing various types of processes in the program development tool. Development assistance program 208A is a program for providing a development environment for user program <NUM>. In addition to development assistance program 208A, storage device <NUM> stores various types of data, such as package software <NUM> for distribution.

Communication interface <NUM> exchanges data with another communication device through a network. Examples of the other communication device include controller <NUM>, and an external device such as a server. External device <NUM> may be configured such that various types of programs, such as development assistance program 208A, can be downloaded from the other communication device through communication interface <NUM>.

I/O interface <NUM> is connected to a manipulation unit <NUM>, and accepts, from manipulation unit <NUM>, a signal indicating a user's manipulation. Typically, manipulation unit <NUM> includes a keyboard, a mouse, a touch panel, a touchpad, or the like, and receives a manipulation from a user.

Display interface <NUM> is connected to a display unit <NUM>, and sends, to display unit <NUM>, an image signal for displaying an image in accordance with a command from control device <NUM> or the like. Display unit <NUM> includes an LCD (Liquid Crystal Display), an organic EL (Electro Luminescence) display, or the like, and presents various types of information to a user. Various types of screens provided by the program development tool can be displayed on display unit <NUM>. It should be noted that in the example of <FIG>, external device <NUM> and display unit <NUM> are represented as separated components; however, external device <NUM> and display unit <NUM> may be configured in one piece.

The following describes a control structure of controller <NUM> with reference to <FIG>. <FIG> is a flowchart showing a process for downloading package software <NUM> from development assistance device 200A. <FIG> is a flowchart showing a process for validating use of package software <NUM> by generating execution right <NUM>. <FIG> is a flowchart showing a check process for execution right <NUM>. <FIG> is a flowchart showing an execution process for downloaded package software <NUM>.

The processes shown in <FIG> are implemented by processor <NUM> of controller <NUM> executing the program. In another aspect, part or whole of the processes may be performed by a circuit element or other hardware.

The following sequentially describes the flowcharts shown in <FIG>.

First, with reference to <FIG>, the following describes the download process for downloading package software <NUM> from development assistance device 200A.

In a step S110, processor <NUM> determines whether or not a download instruction for package software <NUM> is received from development assistance device 200A. The download instruction is issued when the user performs a download manipulation onto development assistance device 200A, for example. When it is determined that the download instruction for package software <NUM> is received from development assistance device 200A (YES in step S110), processor <NUM> switches the control to a step S120. Otherwise (NO in step S110), the download process shown in <FIG> is ended.

In step S120, processor <NUM> determines whether or not package software <NUM> for download is compatible with controller <NUM> to which package software <NUM> is to be downloaded. More specifically, processor <NUM> receives, from external device <NUM>, software information about package software <NUM> for download. The software information includes format information of a controller <NUM> compatible therewith, for example. Controller <NUM> compares the format information defined in the package information with the format information of controller <NUM>, and determines whether or not these pieces of format information coincide with each other. When these pieces of format information coincide with each other, processor <NUM> determines that package software <NUM> for download is compatible with controller <NUM>.

When it is determined that package software <NUM> for download is compatible with controller <NUM> (YES in step S120), processor <NUM> switches the control to a step S122. Otherwise (NO in step S120), processor <NUM> switches the control to a step S126.

In step S122, processor <NUM> receives package software <NUM> and license right <NUM> for package software <NUM> from development assistance device 200A.

In a step S124, processor <NUM> saves received package software <NUM> and license right <NUM> into storage device <NUM> of controller <NUM>.

In step S126, processor <NUM> outputs an error indicating that package software <NUM> for download is not compatible with controller <NUM>. The error may be output in any manner. As an example, the error may be output as an error log, or may be output by way of an error sound, a message, or the like.

Next, with reference to <FIG>, the following describes the validation process for validating use of package software <NUM>. Execution of the validation process is started at an appropriate timing. As an example, execution of the validation process is started based on development assistance device 200A receiving a validation command. The validation command is issued to a designated controller <NUM> based on a user performing a validation manipulation onto development assistance device 200A, for example. When execution of the validation process is started, processes shown in <FIG> are sequentially executed.

In a step S180, processor <NUM> of controller <NUM> determines whether or not there is license right <NUM> for package software <NUM>. Typically, processor <NUM> determines whether or not there is license right <NUM>, based on whether or not license right <NUM> is stored in storage device <NUM> of controller <NUM>. When it is determined that there is license right <NUM> for package software <NUM> (YES in step S180), processor <NUM> switches the control to a step S182. Otherwise (NO in step S180), processor <NUM> switches the control to a step S184.

In step S182, processor <NUM> serves as generation module <NUM> (see <FIG>) to generate execution right <NUM> for package software <NUM> from unique information 143A of controller <NUM>.

In step S184, processor <NUM> outputs an error indicating that there is no license right for package software <NUM>. The error may be output in any manner. As an example, the error may be output as an error log, or may be output by way of an error sound, a message, or the like.

Next, with reference to <FIG>, the following describes the check process for the execution right generated in <FIG>. The check process is a process for validating or invalidating use of package software <NUM>. Execution of the check process is started at an appropriate timing. As an example, execution of the check process is started at a time at which controller <NUM> is activated, a time at which package software <NUM> is executed, or the like. When execution of the check process for license is started, processes shown in <FIG> are sequentially executed.

More specifically, in a step S210, processor <NUM> determines whether or not there is execution right <NUM> for package software <NUM>. When it is determined that there is execution right <NUM> for package software <NUM> (YES in step S210), processor <NUM> switches the control to a step S212. Otherwise (NO in step S210), processor <NUM> switches the control to a step S224.

In step S212, processor <NUM> serves as decryption module 156A (see <FIG>) to generate unique information 143B of controller <NUM> from execution right <NUM>. Unique information 143B includes the manufacturing number of controller <NUM> or processor <NUM>, a controller name, a MAC address, or other information for uniquely identifying controller <NUM>, for example.

In a step S220, processor <NUM> serves as comparison module 156B (see <FIG>) to determine whether or not unique information 143B generated in step S212 coincides with original unique information 143A stored in controller <NUM>. When it is determined that unique information 143B coincides with original unique information 143A of controller <NUM> (YES in step S220), processor <NUM> switches the control to a step S222. Otherwise (NO in step S220), processor <NUM> switches the control to step S224.

In step S222, processor <NUM> permits use of package software <NUM>. As an example, a flag indicating prohibition/permission of use is managed in storage device <NUM> of controller <NUM>, and processor <NUM> rewrites the flag to indicate permission.

In step S224, processor <NUM> prohibits use of package software <NUM>. As an example, a flag indicating prohibition/permission of use is managed in storage device <NUM> of controller <NUM>, and processor <NUM> rewrites the flag to indicate prohibition.

Next, with reference to <FIG>, the following describes the execution process for downloaded package software <NUM>.

In a step S310, processor <NUM> determines whether or not an execution instruction for package software <NUM> is received. When it is determined that the execution instruction for package software <NUM> is received (YES in step S310), processor <NUM> switches the control to a step S320. Otherwise (NO in step S310), processor <NUM> performs the process of step S310 again.

In step S320, processor <NUM> determines whether or not use of package software <NUM> for execution is permitted. As an example, when a flag indicating prohibition/permission of use of package software <NUM> indicates permission, processor <NUM> determines that use of package software <NUM> is permitted. When it is determined that use of package software <NUM> for execution is permitted (YES in step S320), processor <NUM> switches the control to a step S322. Otherwise (NO in step S320), processor <NUM> switches the control to a step S324.

In step S322, processor <NUM> executes package software <NUM>.

In step S324, processor <NUM> does not execute package software <NUM> and outputs an error indicating that execution of package software <NUM> is prohibited. The error may be output in any manner. As an example, the error may be output as an error log, or may be output by way of an error sound, a message, or the like.

In the description above, it is assumed that package software <NUM> is sold by way of downloading; however, the manner of sales of package software <NUM> is not limited to this. As an example, package software <NUM> stored in memory card 200C may be sold.

The following describes another exemplary manner of sales of package software <NUM> with reference to <FIG> shows a mechanism for selling package software <NUM> by way of memory card 200C.

In the example of <FIG>, companies "A" to "C" are shown. Company "A" has a server 200B for managing package software <NUM>. Company "B" sells memory card 200C having package software <NUM> stored therein. Company "C" purchases package software <NUM>.

As a more specific manner of sales, in a step (<NUM>), memory card 200C having package software <NUM> for sale stored therein is manufactured by company "B".

In a step (<NUM>), company "B" makes registration of package software <NUM> to company "A". On this occasion, package information about package software <NUM> for sale is transmitted to server 200B of company "A". Based on the received package information, server 200B performs a registration process for package software <NUM>.

In a step (<NUM>), a purchaser of company "C" accesses a web site or the like of company "B", selects package software <NUM> for purchase, and performs a purchasing procedure. When the purchasing procedure is completed, company "B" prepares memory card 200C having purchased package software <NUM> stored therein. On this occasion, license right <NUM> for package software <NUM> is issued and is saved in memory card 200C. Company "B" sends, to company "C", memory card 200C having package software <NUM> and license right <NUM> stored therein.

In a step (<NUM>), the purchaser connects purchased memory card 200C to controller <NUM>, and installs package software <NUM> and license right <NUM> thereto from memory card 200C.

With reference to <FIG>, the following describes the download process for downloading package software <NUM> in the present modification. <FIG> is a flowchart showing a process for downloading package software <NUM> from memory card 200C.

The process shown in <FIG> is implemented by processor <NUM> of controller <NUM> executing the program. In another aspect, part or whole of the process may be performed by a circuit element or other hardware.

In a step S150, processor <NUM> determines whether or not memory card 200C is connected to controller <NUM>. When it is determined that memory card 200C is connected to controller <NUM> (YES in step S150), processor <NUM> switches the control to step S160. Otherwise (NO in step S150), processor <NUM> ends the download process shown in <FIG>.

In a step S160, processor <NUM> determines whether or not a download instruction for package software <NUM> is received from development assistance device 200A. The download instruction is issued when the user performs a download manipulation onto development assistance device 200A, for example. When it is determined that the download instruction for package software <NUM> is received from development assistance device 200A (YES in step S160), processor <NUM> switches the control to a step S170. Otherwise (NO in step S160), the download process shown in <FIG> is ended.

In step S170, processor <NUM> determines whether or not package software <NUM> for download is compatible with controller <NUM> to which package software <NUM> is to be downloaded. More specifically, processor <NUM> obtains, from memory card 200C, software information about package software <NUM> for download. The software information includes format information of a controller <NUM> compatible therewith, for example. Controller <NUM> compares the format information defined in the package information with the format information of controller <NUM>, and determines whether or not these pieces of format information coincide with each other. When these pieces of format information coincide with each other, processor <NUM> determines that package software <NUM> for download is compatible with controller <NUM> to which package software <NUM> is to be downloaded.

When it is determined that package software <NUM> for download is compatible with controller <NUM> (YES in step S170), processor <NUM> switches the control to a step S172. Otherwise (NO in step S170), processor <NUM> switches the control to a step S176.

In step S172, processor <NUM> obtains package software <NUM> and license right <NUM> for package software <NUM> from memory card 200C.

In step S174, processor <NUM> saves obtained package software <NUM> and license right <NUM> into storage device <NUM> of controller <NUM>.

In step S176, processor <NUM> outputs an error indicating that package software <NUM> for download is not compatible with controller <NUM>. The error may be output in any manner. As an example, the error may be output as an error log, or may be output by way of an error sound, a message, or the like.

With reference to <FIG> and <FIG>, the following describes the deploy process for deploying package software <NUM> in controller <NUM>. <FIG> schematically shows a flow of the deploy process for package software <NUM>. <FIG> shows continuation of the deploy process shown in <FIG>.

Processor <NUM> of controller <NUM> includes a package management module <NUM> for managing the downloaded package software. In memory card 200C, package software <NUM> for download is indicated as package software "X".

In a step (<NUM>), a certain invoker outputs a deploy command for package software "X" to package management module <NUM>. Examples of the invoker include: an updater of the firmware; external device <NUM> (for example, development assistance device 200A); a process in controller <NUM>; a library in controller <NUM>; and the like.

In a step (<NUM>), package management module <NUM> executes a deploy method of package software "X" on memory card 200C. The deploy method is defined in "Package_X. db" in advance, and package management module <NUM> searches for this method from "Package_X. db" and executes it.

In steps (<NUM>) and (<NUM>), deploy method 141A starts a check as to whether or not format information of processor <NUM> of controller <NUM> is compatible with package software "X".

More specifically, deploy method 141A makes reference to unique information 143A of processor <NUM> to obtain the format information of processor <NUM>. Deploy method 141A compares the format information of processor <NUM> with the compatible format information of package software "X", so as to check whether or not package software "X" can be deployed in controller <NUM>. When the obtained format of processor <NUM> coincides with the compatible format of package software "X", deploy method 141A determines that package software "X" can be deployed in controller <NUM>. Otherwise, the deploy method determines that package software "X" cannot be deployed in controller <NUM>.

In steps (<NUM>) and (<NUM>), deploy method 141A checks a dependency relation between package software <NUM> for download and a package software (hereinafter, also referred to as "existing package software") already downloaded in controller <NUM>.

More specifically, deploy method 141A makes reference to list table <NUM> for pieces of package software to obtain a list of pieces of existing package software. Then, deploy method 141A checks a dependency relation between package software <NUM> for download and each piece of existing package software. When package software <NUM> for download is in such a relation that package software <NUM> cannot coexist with the existing package software, it is determined that package software "X" cannot be deployed in controller <NUM>.

In a step (<NUM>), deploy method 141A deploys various types of files (for example, an so file) in processor <NUM>.

In a step (<NUM>), deploy method 141A deploys the DB file "Package_X. db" in processor <NUM>. In the DB file "Package_X. db", information of deploy method 141A is described. Examples of the DB file are the above-described pieces of detailed information <NUM> to <NUM>.

In a step (<NUM>), based on the deployment of the various types of files being completed, deploy method 141A resisters package software "X" to package management module <NUM>.

In a step (<NUM>), package management module <NUM> adds, to list table <NUM> for pieces of package software, the information of the newly deployed package software "X".

In a step (<NUM>), package management module <NUM> saves, in a change history <NUM>, a record of package change/addition.

It should be noted that in <FIG> and <FIG>, explanation has been made with respect to the deploy process in the case where package software <NUM> is downloaded from memory card 200C; however, the deploy process shown in <FIG> and <FIG> can be also applied to a case where package software <NUM> is downloaded from an external device <NUM> other than memory card 200C.

Package software <NUM> downloaded to controller <NUM> can be transferred to external device <NUM>. On this occasion, license right <NUM> including execution right <NUM> for package software <NUM>, and the various types of function modules for checking the license are deleted from controller <NUM>. Accordingly, a plurality of execution rights <NUM> and license rights <NUM> never exist, whereby license right <NUM> can be managed uniquely.

The following describes the transfer process for package software <NUM> with reference to <FIG> shows a state in which package software <NUM> is transferred between controller <NUM> and memory card 200C.

<FIG> shows a state before downloading package software <NUM> to controller <NUM>. Controller <NUM> has its unique information 143A stored therein. Memory card 200C stores: package software <NUM> for download; license right <NUM> including execution right <NUM> therefor; generation module <NUM>; check module <NUM>; and unique information 243A of memory card 200C.

<FIG> shows a state when downloading package software <NUM> from memory card 200C to controller <NUM>. Based on package software <NUM> being transferred, package software <NUM>, license right <NUM> including execution right <NUM> therefor, generation module <NUM>, and check module <NUM> are deleted from memory card 200C. A function of transferring package software <NUM> from memory card 200C to controller <NUM> is incorporated in package software <NUM> itself, for example. The function of transferring is performed by processor <NUM> of controller <NUM>.

<FIG> shows a state when transferring package software <NUM> from controller <NUM> to memory card 200C. Based on package software <NUM> being transferred, package software <NUM>, license right <NUM> including execution right <NUM> therefor, generation module <NUM>, and check module <NUM> are deleted from controller <NUM>. A function of transferring package software <NUM> from controller <NUM> to memory card 200C is incorporated in package software <NUM> itself, for example. The function of transferring is performed by processor <NUM> of controller <NUM>.

It should be noted that in <FIG>, explanation has been made with respect to the transfer process for package software <NUM> between controller <NUM> and memory card 200C; however, the transfer function can be also applied to transfer of package software <NUM> between controller <NUM> and an external device <NUM> other than memory card 200C.

The above description is directed to the example in which package software <NUM> is sold by way of downloading, and the example in which package software <NUM> stored in memory card 200C is sold; however, the manner of sales of package software <NUM> is not limited to these. As an example, package software <NUM> may be sold by way of BTO.

The following describes still another exemplary manner of sales of package software <NUM> with reference to <FIG> shows a mechanism for selling package software <NUM> by way of BTO.

In the example of <FIG>, companies "A" to "C" are shown. Company "A" has server 200B for managing package software <NUM>. Company "B" is a company that sells package software <NUM>. Company "C" is a company that purchases package software <NUM>, controller <NUM>, and the like from company "B" and other companies and that sells a system in which these are combined.

As a more specific manner of sales, in a step (<NUM>), a designer of company "B" uses development assistance device 200A to design package software <NUM> for sale.

In a step (<NUM>), company "B", which sells package software <NUM>, registers package software <NUM> for sale to company "A". On this occasion, package information about package software <NUM> for sale is transmitted to server 200B of company "A". Based on the received package information, server 200B performs a registration process for package software <NUM>.

In a step (<NUM>), a purchaser of company "C" accesses a web site or the like of company "B", selects package software <NUM> for download, and performs a purchasing procedure. On this occasion, unique information of controller <NUM> to which package software <NUM> is to be downloaded is input. When the purchasing procedure is completed, license right <NUM> is generated from the unique information for uniquely identifying controller <NUM> to which package software <NUM> is to be downloaded, and is transmitted to company "C" together with purchased package software <NUM>.

In a step (<NUM>), purchased package software <NUM> and license right <NUM> are installed in controller <NUM>.

In a step (<NUM>), company "C" sells, to other companies, controller <NUM> having package software <NUM> and license right <NUM> installed therein.

As described above, controller <NUM> generates execution right <NUM> for package software <NUM> from unique information 143A of controller <NUM> at a time at which package software <NUM> is downloaded or the like. Then, controller <NUM> generates unique information 143B from execution right <NUM> at the time at which package software <NUM> is executed, the time at which controller <NUM> is activated, or the like. When generated unique information 143B does not coincide with original unique information 143A, controller <NUM> prohibits use of package software <NUM>.

Accordingly, package software <NUM> cannot be used when package software <NUM> is transferred in an unauthorized manner to a controller different from one to which package software <NUM> is downloaded, for example. Moreover, since the mechanism for checking a license is included in package software <NUM>, controller <NUM> does not need to have a license check function in advance.

The embodiments disclosed herein are illustrative and non-restrictive in any respect. The scope of the present invention is defined by the terms of the claims, rather than the embodiments described above, and is intended to include any modifications within the scope of the claims.

Claim 1:
A controller for controlling a control target (<NUM>), the controller (<NUM>) comprising:
an obtaining unit (<NUM>) that is configured to obtain, from an external device (<NUM>) including a communication device that is configured to communicate with the controller (<NUM>), software (<NUM>) to be used by the controller (<NUM>), by downloading the software (<NUM>) from the communication device communicatively connected to the controller (<NUM>); and
a processor (<NUM>) that is configured to execute the software (<NUM>), wherein
the software (<NUM>) includes
a generation module (<NUM>) that is configured to generate an execution right (<NUM>) for the software (<NUM>) from first unique information for uniquely identifying the controller (<NUM>) or the external device (<NUM>), and
a check module (<NUM>) that is configured to generate second unique information from the execution right (<NUM>) at a predetermined timing after the generation of the execution right (<NUM>), and that is configured to prohibit use of the software (<NUM>) when the second unique information does not coincide with the first unique information,
wherein the processor (<NUM>) is further configured to delete the execution right (<NUM>) when transferring the obtained software (<NUM>) from the controller (<NUM>) to the external device (<NUM>) to delete the generation module (<NUM>) and the check module (<NUM>) when transferring the obtained software (<NUM>) from the controller (<NUM>) to the external device (<NUM>).