JP2011242994A - Driver control system, and driver control method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce an operation load during installing a driver.SOLUTION: In this driver control system, a server PC100 includes: a specifying part 261 for specifying a plug-in archive in which plug-in is archived, and plug-in list information showing the plug-in; and a transmitting part 203 for transmitting to a client PC110 a printer driver 250, the specified plug-in archive and the plug-in list information, and the client PC110 includes: a receiving part 1003 for receiving the printer driver 250, the plug-in archive, and the plug-in list information; an installing part 1004 for installing the printer driver 250; a storing part 1005 for storing the plug-in archive and the plug-in list information; and a control part 1002 for controlling the printer driver 250 which accesses the plug-in archived in the plug-in archive according to the plug-in list information.

Description

  The present invention relates to a driver control system that performs processing using a driver, and a driver control method.

  Conventionally, printers have different functions depending on the model. With the diversification of user demands, needs for selling printers after customizing them so that only necessary functions can be used are increasing. In order to meet such needs, printers capable of adding functions as plug-ins have been proposed. When a function is added to the printer, it is necessary to expand the function so that the added function can be used for a printer driver for controlling the printer.

  In addition to the printer driver function expansion accompanying the printer function expansion, there is a request for function expansion for the printer driver alone.

  In order to perform such function expansion, recompiling the printer driver and re-installing it in the customer's environment reduces the convenience for the user. Therefore, a technique for adding a function to a printer driver as a plug-in is already known as a technique for expanding functions without performing recompilation or reinstallation.

  In recent years, server PCs tend to manage printer drivers and install them on client PCs. In such an environment, as a technique for extending the function of each client PC with a plug-in, a technique for adding a function other than the printer driver configuration file as a plug-in or rewriting the configuration file to expand the function (for example, Patent Document 1) has been proposed. This makes it possible to expand the function of the printer driver without performing reinstallation or the like.

  However, in the technique of adding files other than the configuration file of the printer driver as a plug-in, the printer driver managed by the server PC is installed from the client PC (for example, point-and-print proposed by Microsoft (registered trademark)) When the plug-in is added to the server PC side in advance, the plug-in is not installed on the client PC side. For this reason, the extended function cannot be used in the client PC.

  Further, as shown in Patent Document 1, in the technique of rewriting a configuration file and extending the function, for example, when the OS on the client PC side is Windows (registered trademark), a catalog indicating that the driver configuration has not changed. (cat) Since the integrity of the file is lost, the security is not guaranteed from the OS. In particular, when the OS is Windows (registered trademark) Vista (registered trademark), the expanded function is lost when the rewritten configuration file is written back to the state before being rewritten by the function of the driver store. There was a problem.

  The present invention has been made in view of the above, and provides a driver control system and a driver control method capable of inheriting an extended function added as a plug-in to a client PC when a driver is installed. For the purpose.

  In order to solve the above-described problems and achieve the object, a driver control system according to the present invention is a driver control system including a client to which a driver is to be installed and a server that manages the driver. The server includes a specifying unit that specifies a predetermined file in which the plug-ins of the driver are collectively archived and list information indicating the plug-ins stored in the file as a transmission target, and the driver And transmitting means for transmitting the file and the list information specified by the specifying means to the client, wherein the client receives the driver, the file, and the list information from the server. , Receiving means for installing the driver received by the receiving means Control for controlling the driver that calls the plug-in archived in the file according to the list information, installation means, storage means for storing the file and list information received by the receiving means in a storage means And means.

  The driver control method according to the present invention is a driver control method executed by a client to which a driver is to be installed and a server that manages the driver. In the server, the specifying means includes the driver A specifying step for specifying a predetermined file in which the plug-ins of the archive are collectively archived and list information indicating the plug-ins stored in the file as transmission targets; and a transmitting means, the driver, and the specifying Transmitting the file identified by the step and the list information to the client. In the client, the receiving means receives the driver, the file, and the list information from the server. , And receiving the driver received in the receiving step. An installation step for installing, a storage unit for storing the file and the list information received in the reception step in a storage unit, and a control unit for storing the plug-ins archived in the file in the list. And a control step of controlling the driver to be called according to the information.

  According to the present invention, there is an effect of reducing an operation burden when installing a driver plug-in.

FIG. 1 is a block diagram illustrating a configuration of a print control system according to the first embodiment. FIG. 2 is a diagram showing functional blocks of the server PC. FIG. 3 is a diagram illustrating an example of function information used in the printer driver. FIG. 4 is a diagram illustrating an example of screen layout information used in the printer driver. FIG. 5 is a diagram illustrating an example of settings stored in the registry for performing point-and-print. FIG. 6 is a diagram showing an initial state of plug-in list information. FIG. 7 is a diagram illustrating an example of plug-in list information in which two plug-ins are added. FIG. 8 is a diagram showing an example of a plug-in archive in which two plug-ins are added. FIG. 9 is a sequence diagram illustrating a procedure of driver installation processing in the server PC according to the present embodiment. FIG. 10 is a diagram showing functional blocks of the client PC according to the present embodiment. FIG. 11 is a diagram showing an example of a print setting screen generated only from the screen layout information of the driver setting directory. FIG. 12 is a diagram illustrating an example of function information of the “borderline” plug-in. FIG. 13 is a diagram illustrating an example of screen layout information of the “borderline” plug-in. FIG. 14 is a diagram illustrating an example of function information of the “stamp” plug-in. FIG. 15 is a diagram illustrating an example of screen layout information of the “stamp” plug-in. FIG. 16 is a flowchart illustrating the procedure of driver installation processing in the print control system. FIG. 17 is a flowchart illustrating a procedure of the above-described processing in the specifying unit. FIG. 18 is a flowchart showing the procedure of setting screen display processing in the client PC. FIG. 19 is a diagram illustrating an example of a setting screen displayed by the display unit 1007 for a printer driver to which a plug-in is added. FIG. 20 is a flowchart illustrating a procedure of print control processing in the client PC. FIG. 21 is a diagram showing the configuration of the plug-in installer package. FIG. 22 is a diagram illustrating an example of plug-in information included in the plug-in installer package. FIG. 23 is a flowchart illustrating a processing procedure when installing a plug-in in the server PC according to the present embodiment. FIG. 24 is a diagram illustrating a hardware configuration of the server PC and the client PC.

  Exemplary embodiments of a driver control system and a driver control method according to the present invention will be explained below in detail with reference to the accompanying drawings.

(First embodiment)
FIG. 1 is a block diagram illustrating a configuration of a print control system according to the first embodiment. As shown in FIG. 1, a server PC 100, a client PC 110, and a printer 150 are connected to the print control system via a network 160. The server PC 100 is a PC that can perform driver installation control on the client PC 110. For this installation control, for example, point and print may be used.

  FIG. 2 is a diagram illustrating functional blocks of the server PC 100 according to the present embodiment. As shown in FIG. 2, the server PC 100 is equipped with an OS 201, and the OS 201 controls an application (not shown) and hardware installed in the server PC 100.

  The OS 201 includes a printer driver 250, a control unit 202, a transmission unit 203, a writing unit 204, a registry 210, a DEVMODE 211, a driver setting directory 212, and a plug-in directory 213. In this embodiment, an example in which MS-Windows (registered trademark) is installed as the OS 201 will be described.

  That is, in the present embodiment, driver installation using point-and-print provided by MS-Windows (registered trademark) will be described as an example. However, another OS may be used as long as it has a function that realizes installation equivalent to the point-and-print.

  The printer driver 250 includes a drawing driver 251, a point-and-print library 252, a setting management unit 253, a UI driver 254, and a plug-in management unit 255. The printer driver 250 is a driver for controlling the printer 150 and can be provided from the server PC 100 to the client PC 110.

  The drawing driver 251 is a configuration module of the printer driver 250 necessary for controlling the printer 150 from the OS (the OS 201 of the server PC 100 or the OS of the client PC). Then, the drawing driver 251 performs drawing processing and generates drawing data.

  The point-and-print library 252 includes a specifying unit 261, and is a dynamic link library (module group) that is called when a point-and-print is performed from the client PC 110 to the server PC 100. . When the point-and-print library 252 according to the present embodiment is called at the time of point-and-print, it performs different control depending on whether it is called by either the client PC 110 or the server PC 100. Thereby, control is performed between the client PC 110 and the server PC 100 to transmit a file other than the configuration file of the printer driver 250.

  The identification unit 261 identifies a file to be transmitted to the client PC 110 when called from the server PC 100 side during point-and-print. The identifying unit 261 according to the present embodiment recognizes a predetermined file (hereinafter, referred to as a plug-in archive) in which plug-ins of the printer driver 250 are archived together and a plug-in stored in the plug-in archive. Are identified as files to be transmitted to the client PC 110.

  In addition, the identification unit 261 identifies a path as a plug-in storage destination when called on the client PC 110 side during point-and-print.

  That is, the point-and-print library 252 is included in the printer driver 250 and is called by the server PC 100 and the client PC 110 at the time of point-and-printing, thereby realizing installation of a plug-in of the printer driver 250. As a control for realizing this installation, the server PC 100 side specifies a file to be transmitted.

  The setting management unit 253 is a module that manages the functions and settings of the printer driver 250. The settings managed by the setting management unit 253 are, for example, the current set value, the value range of each function, and the prohibition between the functions. These functions and settings are written out and read out from the registry 210 and the DEVMODE 211.

  The UI driver 254 is a configuration module of a printer driver necessary for controlling the printer 150 from the OS 201, and functions as a GUI (Graphic User Interface) that displays a setting screen, an initial setting screen at the time of installation, and the like.

  The plug-in management unit 255 is a module that performs control related to plug-ins. The plug-in management unit 255 according to the present embodiment merges the settings for the printer driver 250 main body and the settings for the plug-in so that the calling side is not aware of the configuration of the plug-in.

  In addition, the plug-in management unit 255 calls a corresponding process of the drawing extension module included in the installed plug-in according to each print command, and realizes control (for example, drawing control) performed for each plug-in.

  Specifically, when performing control by the printer driver 250, the plug-in management unit 255 performs control using each plug-in archived in a plug-in archive in accordance with plug-in list information.

  Next, configurations other than the printer driver 250 will be described. The control unit 202 controls various drivers such as the printer driver 250 installed in the OS 201.

  The writing unit 204 performs information writing control. For example, when the writing unit 204 adds a plug-in to the printer driver 250, the writing unit 204 performs writing to add the plug-in to the plug-in archive in response to a call from the installer of the plug-in, and the plug-in archive Plug-in information for recognizing plug-ins to be added to is written in the plug-in list information. The plug-in information according to the present embodiment includes a plug-in name and version information of the plug-in.

  The transmission unit 203 performs control to transmit information to the client PC 110. The transmission target includes a driver such as the printer driver 250, a plug-in archive in which plug-ins added to the driver are archived, plug-in list information, and the like.

  The version information is used based on whether or not a plug-in is added. For example, when a new plug-in is added, if a plug-in with the same name has already been added, the version information is confirmed, and the installation is continued only when the version information is new.

  The driver setting directory 212 is a directory in which setting information referred to when the printer driver 250 performs processing is stored. The driver setting directory 212 holds function information and screen layout information.

  The function information indicates information describing the function name of each function of the printer driver 250, the type of user interface (whether it is an option, a character string, or a numerical value), a value range, and a prohibition between functions. In the present embodiment, it is assumed that the function information is described in the XML format.

  FIG. 3 is a diagram illustrating an example of function information used in the printer driver 250. As shown in FIG. 3, an “item” tag is defined for each function that can be used by the printer driver 250.

  That is, information indicating the setting for each function is stored in each “item” tag. The “item” tag has “name” and “type” attributes. The attribute “name” indicates the name of each function setting. The attribute type indicates the format of the input setting value.

  A tag whose attribute “name” is “layout” indicates that the aggregation setting is held. A tag whose attribute “name” is “booklet” indicates that bookbinding settings are held. A tag whose attribute “name” is “papersize” indicates that the print paper setting is held. A tag whose attribute “name” is “copies” indicates that the number of copies setting is retained. A tag whose attribute “name” is “userid” indicates that the ID setting for each user is held.

  A value set as the attribute “type” will be described. “Pickone” indicates an option format. “String” indicates a character string input format. “Number” indicates a numeric input format.

  Further, the “item” tag can hold a “constraint” tag 301 as in the aggregation setting of FIG. A “constraint” tag 301 represents prohibition information for setting an “item” tag that is a parent tag. The attribute “fixvalue” is an attribute indicating whether or not to forcibly change when the prohibition condition matches the “constraint” tag.

  Further, the “constraint” tag can hold the “condition” tag 302 as in the aggregation setting of FIG. The “condition” tag holds the prohibition condition of the “constraint” tag that is the parent tag. For example, the attribute “expression” indicates the prohibition condition. Specifically, “layout” matches the prohibition condition when “on” is set in “booklet”, and is forcibly changed to a setting value of “off”.

  The “pickone” tag holds information for each option when the “type” of the “item” tag that is the parent tag is an option format. The attribute “name” in the “pickone” tag is a set value that represents an option of the tag. In the example shown in FIG. 3, although not described, it can have a “constraint” tag. Thus, the “pickone” tag itself, that is, the option itself, can also hold prohibition information.

  Next, each setting value of the attribute “name” of the “pickone” tag will be described. In the tag “layout”, “off” is function off, “2in1” is 2in1 printing, “4in1” is 4in1 printing, “on” is function on, “a3” is A3 paper, “a4” is A4 paper Shows options.

  The “range” tag defines a selectable range when the “type” of the parent tag “item” tag is a numeric format. The attribute “min” in the “range” tag holds a settable minimum value, and “max” holds a settable maximum value.

  The “string” tag defines a selectable character string when the “type” of the parent tag “item” tag is a character string format. The attribute “min” in the “string” tag holds the minimum number of characters, and the attribute “max” holds the maximum number of characters. The attribute “chartype” holds the character type. For example, when the attribute “chartype” is “alphanumeric”, it indicates that a numerical value and an alphabetic character string can be input.

  The screen layout information describes information for specifying the layout (UI type, coordinates, function name to be associated) of the setting screen when the setting screen related to the printer driver 250 is displayed.

  FIG. 4 is a diagram illustrating an example of screen layout information used in the printer driver 250. The example shown in FIG. 4 is an example in which screen layout information is described in the JSON format.

  As shown in FIG. 4, the screen layout information describes information (referred to as layout data) for specifying a layout for each UI component. The layout data for each UI component has an attribute “type”, an attribute “name”, and an attribute “axis”.

  The attribute “type” indicates the type of UI component. When “ComboBox” is set in the “type” value, the combo box component is set. When “CheckBox” is set, the check box component is set. When “SpinBox” is set, the spin box component is set. When “EditBox” is set, it is displayed in the edit box component.

  The attribute “name” indicates the name of the setting. If "layout" is set as the value of the attribute "name", aggregation settings are set, if "booklet" is set, bookbinding settings, if "papersize" is set, print paper settings, "copies" When “is set, it indicates that the number of copies is set, and when“ userid ”is set, the ID is set for each user.

  The attribute “axis” indicates the coordinates of the display position. An attribute “x” held by the attribute “axis” designates a horizontal coordinate from the upper left origin of the dialog box, and an attribute “y” designates a vertical coordinate.

  For example, it is described that the aggregation setting set in the column 401 is displayed at the horizontal position “25” and the vertical position “30” by the combo box component.

  The registry 210 is a database that stores the OS 201 of the server PC 100 and the settings of applications that run on the OS 201. The registry 210 according to the present embodiment holds settings necessary for transmitting a file other than the driver configuration file when performing point-and-print. Examples of this necessary setting include a path indicating a directory in which a plug-in file to be transmitted is stored, and a file name for specifying a file to be transmitted.

  FIG. 5 is a diagram illustrating an example of settings stored in the registry 210 for performing point-and-print. With this setting, files other than the driver configuration file can be transmitted at the point-and-print time.

  As a registry key, for example, the key “CopyFiles \ arbitrary name” exists under “\ HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Print \ Printers \ driver name”, and the subkeys shown in FIG. Assume that it is stored. In this embodiment, it is assumed that it is stored under “\ HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Print \ Printers \ DriverA \ CopyFiles \ Plugin”. Next, the meaning of the subkey will be described.

  “Dierectory” holds a path indicating a directory in which a file to be transmitted to the client PC 110 is placed. The path indicating this directory can be changed by calling GenerateCopyFilePathsAPI of the point-and-print library 252. In “Dierectory” according to the present embodiment, “C: \ Documents and Settings \ All Users \ Application Data \ DriverA \ Plugin” representing the plug-in directory 213 is held.

  “Files” holds a list of files to be transmitted among the files stored in the directory (plug-in directory 213) indicated by “Directory”. “Files” according to the present embodiment holds plug-in list information “plugin_info.json” and a file name indicating the plug-in archive “plugin_archive.zip”.

  “Module” holds a file name indicating a library (dynamic link library) to be called when the point-and-print process is performed. “Module” according to the present embodiment holds a file name “ppmodule.dll” indicating the point-and-print library 252.

  The library to be called (point and print library 252) is a dynamic link library in which APIs of GenerateCopyFilePaths () and SpoolerCopyFileEvent () are implemented.

  GenerateCopyFilePaths is an API called by each of the server PC 100 and the client PC 110, and corresponds to the specifying unit 261 in FIG. This GenerateCopyFilePaths (specifying unit 261) is called when specifying the path of the source or destination directory.

  SpoolerCopyFileEvent is an API that runs on the client PC 110 and notifies events such as point-and-print connection start / end. Specific notification control is omitted.

  The DEVMODE 211 is a structure provided by the OS 201 in order to save the settings of the printer driver 250. For example, the DEVMODE 211 holds the current setting value set for the printer driver 250 and the like.

  The plug-in directory 213 is a directory for storing printer driver 250 plug-ins. The plug-in directory 213 according to the present embodiment stores plug-in list information and plug-in archives.

  Immediately after installation of the printer driver 250, the printer driver 250 generates a plug-in directory 213 in a predetermined path. Then, the printer driver 250 generates initial plug-in list information and an initial plug-in archive in the plug-in directory 213 (which may be a copy or the like).

  Thereafter, when a plug-in is added to the printer driver 250, information about the plug-in is added to the plug-in list information and the plug-in archive in the directory. Thereby, the function of the printer driver 250 can be expanded.

  Specifically, when a plug-in is added to the printer driver 250, plug-in information for recognizing the plug-in is added to the plug-in list information, and a plug-in archive in which the plug-in is added is added. Is generated. In this embodiment, it is assumed that the addition of the plug-in is performed by an external tool or the like without involving the printer driver 250 itself.

  Next, the initial state of plug-in list information will be described. FIG. 6 is a diagram showing an initial state of plug-in list information. As shown in FIG. 6, the plug-in list information does not store any information in the initial state. That is, immediately after installation of the printer driver 250, there is no usable plug-in. Each time a plug-in is added, the name of the added plug-in and information related to the plug-in are written by the writing unit 204. In the present embodiment, the JSON (Java (registered trademark) Script Object Notation) format is used as the format of the plug-in list information, but other formats may be used.

  It is also assumed that the plug-in archive is in an initial state and no information is stored. In the present embodiment, the plug-in archive is an archive file in which the plug-ins are collectively ZIP-compressed. In other words, the plug-in archive is an empty ZIP file in the initial state where no plug-in is added, and a ZIP file in which plug-ins that have been added so far are generated each time a plug-in is added.

  Next, plug-in list information to which plug-ins have been added and plug-in archives will be described. In the description, it is assumed that two plug-ins, a borderline plug-in and a stamp plug-in, are added.

  FIG. 7 is a diagram illustrating an example of plug-in list information in which two plug-ins are added. As shown in FIG. 7, the plug-in list information functions as a table in the JSON format. In the plug-in list information, the name of the plug-in is an object that functions as a key. The value corresponding to the key is set as the referable information corresponding to the plug-in. The example shown in FIG. 7 is an example in which a plug-in version is described as referenceable information.

  FIG. 8 is a diagram showing an example of a plug-in archive in which two plug-ins are added. As shown in FIG. 8, the plug-in archive has the same directory as the name of the plug-in described in the plug-in list information. That is, the plug-in archive includes two items, a Borderline directory 801 and a Stamp directory 802. Then, the printer driver 250 identifies the directory in which the plug-in module is stored in the plug-in archive based on the plug-in name written in the plug-in list information.

  Each directory in the plug-in archive in FIG. 8 stores three modules: function information, screen layout information, and a drawing extension module. The function information and screen layout information are information in the same format as the function information and screen layout information of the printer driver 250 stored in the driver setting directory 212. Specifically, the function information stored in each directory in the plug-in archive defines a function added by the plug-in. Further, the screen layout information stored in each directory in the plug-in archive describes the screen layout related to the plug-in.

  The drawing extension module is a module that performs drawing processing by the function provided by the plug-in. For example, the drawing extension module of the borderline plug-in provides a function for drawing a page separator line at the time of aggregation. Further, the drawing extension module of the stamp plug-in provides a function for performing stamp printing. These plug-in drawing extension modules are implemented with APIs corresponding to drawing drivers, such as job start / end, page start / end, and drawing of various drawing objects.

  Note that the addition of the plug-in according to the present embodiment is normally performed by a plug-in installer or the like. However, the addition of a plug-in is not limited to that using an installer, and information on the plug-in to be added may be written and controlled with respect to the plug-in list information. Further, a plug-in file may be added to the plug-in archive in accordance with a user operation.

  In the present embodiment, an example in which no plug-in is installed in the initial state has been described. However, the present invention is not limited to an example in which the plug-in is not installed. From the beginning, the plug-in list information in which the plug-in is described and the plug-in in which the plug-in is archived so that no inconsistency occurs between the plug-in list information. In-archive may be created in advance as an initial state. As a result, the plug-in can be used immediately after the printer driver 250 is installed.

  Next, driver installation processing in the server PC 100 according to the present embodiment will be described. FIG. 9 is a sequence diagram illustrating the above-described processing procedure in the server PC 100 according to the present embodiment. In the sequence shown in FIG. 9, the printer driver 250 is installed as an example.

  First, when receiving an installation request for the printer driver 250, the OS 201 installs a configuration file for the printer driver (step S901). That is, the OS 201 copies the configuration file of the printer driver 250 to the installation directory that is the storage destination of all drivers. The copied configuration file is a configuration included in the printer driver 250 of FIG.

  Thereafter, the OS 201 sends a driver installation event to the UI driver 254 of the printer driver 250 in which the configuration file has been installed (step S902).

  The UI driver 254 requests the plug-in management unit 255 to perform initial plug-in settings (step S903).

  In accordance with the request, the plug-in management unit 255 generates a path for the plug-in directory 213 (step S904). In the present embodiment, a path of a predetermined folder (for example, a path of ComonApplicationData) using a command (for example, SHGetSpecialFolderPath) for specifying a folder path of an API (for example, Windows (registered trademark) API) that the OS 201 has. To get. Then, the plug-in management unit 255 generates, as a plug-in directory 213, a path in which “driver name \ Plugin” is linked to the acquired path of the predetermined folder. The generated plug-in directory 213 is subsequently used for storing plug-ins.

  For example, when the driver name to be installed is “DriverA”, the plug-in management unit 255 generates “C: \ Documents and Settings \ All Users \ Application Data \ DriverA \ Plugin” as the path of the plug-in directory 213.

  Next, the plug-in management unit 255 generates plug-in list information in the initial state for the generated path of the plug-in directory 213 (step S905). Note that the plug-in information in the initial state may be copied as the configuration file of the printer driver 250.

  Further, the plug-in management unit 255 generates an initial plug-in archive for the generated path of the plug-in directory 213 (step S906). The plug-in archive in the initial state may be copied as a configuration file of the printer driver 250.

  Normally, the plug-in is empty in the initial state, but if you want to distribute the driver package including the plug-in from the beginning, the plug-in list information shown in FIG. 7 or the plug-in archive shown in FIG. The plug-in may be included. With such a configuration, the plug-in function can be used immediately after the driver is installed.

  This is because, first of all, the installation of the printer driver 250 is performed regardless of the inside of the plug-in list information and the plug-in archive. Secondly, after the printer driver 250 is installed, all information necessary for operating the plug-in is stored in the plug-in list information in the plug-in directory and the plug-in archive. Therefore, even if it is first included in the plug-in list information and the plug-in archive, it functions without any problem.

  Then, the plug-in management unit 255 sets information necessary for using the plug-in in the registry 210 (step S907). An example of the necessary information is information for transmitting a file related to the plug-in of the printer driver 250 during the point-and-print by the client PC 110, and is the information shown in FIG.

  The printer driver 250 is installed in the server PC 100 by the above processing procedure. Next, the client PC 110 that is the installation destination of the printer driver 250 from the server PC 100 will be described.

  FIG. 10 is a diagram showing functional blocks of the client PC 110 according to the present embodiment. As shown in FIG. 10, the client PC 110 has an OS 1001 installed therein, and the OS 1001 controls an application (not shown) and hardware installed in the client PC 110.

  The OS 1001 includes a printer driver 250, a control unit 1002, a reception unit 1003, an installation unit 1004, a storage unit 1005, a development unit 1006, a display unit 1007, a registry 1010, a DEVMODE 1011, and a driver setting directory 1012. And a plug-in directory 1013. In this embodiment, an example in which MS-Windows (registered trademark) is installed as the OS 1001 will be described. As described above, the type of the OS 1001 installed in the client PC 110 may be the same OS as that of the server PC 100, or another OS may be installed.

  The registry 1010 is a database that stores the settings of the OS 1001 of the client PC 110 and the applications that run on the OS 1001.

  The DEVMODE 1011 is a structure provided by the OS 201 in order to save the settings of the printer driver 250.

  The control unit 1002 controls drivers (for example, including the printer driver 250) installed in the OS 1001. Each driver controlled by the control unit 1002 calls the plug-in archived in the plug-in archive according to the plug-in list information. Therefore, the functions of each installed plug-in can be used based on the control by the control unit 1002.

  The receiving unit 1003 receives information from the server PC 100. Examples of information received include a driver to be installed, a plug-in archive used by the printer driver, and plug-in list information used by the printer driver.

  The installation unit 1004 performs installation control of the driver received by the reception unit 1003. The installation unit 1004 according to the present embodiment installs a printer driver by point-and-print.

  The installation unit 1004 stores setting information used by the driver in the driver setting directory 1012 when the driver is installed.

  The driver setting directory 1012 is a directory that stores setting information to be referred to when the printer driver 250 performs processing. The driver setting directory 1012 stores function information and screen layout information. The function information and screen layout information are the same as the function information and screen layout information stored in the driver setting directory 212 of the server PC 100.

  The printer driver 250 is a driver installed by the installation unit 1004. Since the printer driver 250 is installed from the server PC 100, the printer driver 250 has the same configuration as that installed in the server PC 100.

  A display unit 1007 displays a setting screen related to the printer driver 250 and the like. For example, the display unit 1007 displays a setting screen generated according to the screen layout information stored in the driver setting directory 212 and the screen layout information for each plug-in. When no plug-in is added, the display unit 1007 displays a setting screen generated only from the screen layout information stored in the driver setting directory 212.

  FIG. 11 is a diagram illustrating an example of a print setting screen generated only from the screen layout information of the driver setting directory 1012. In the example of the print setting screen illustrated in FIG. 11, items usable in the configuration module of the printer driver 250 are displayed. The settings for each item displayed on the print setting screen shown in FIG. 11 are managed by the setting management unit 253 that has read the function information.

  The “OK” button in FIG. 11 is a button for saving the print setting change, and the “Cancel” button is a button for canceling the print setting change. These “OK” button and “Cancel” button are not displayed according to the screen layout information, but are implemented regardless of the screen layout information.

  If a plug-in is added to the printer driver 250 in the server PC 100, the client PC 110 that has installed the printer driver 250 from the server PC 100 does not display the print setting screen shown in FIG. Display the print setting screen including information.

  The plug-in directory 1013 is a directory for storing printer driver 250 plug-ins. The plug-in list information and plug-in archive stored in the plug-in directory 1013 are the same as the plug-in list information and plug-in archive stored in the plug-in directory 213.

  The expansion unit 1006 expands the archive. The expansion unit 1006 according to the present exemplary embodiment expands each plug-in from the plug-in archive compressed in the ZIP format in the plug-in directory 1013.

  Further, when expanding the plug-in archive, the expansion unit 1006 expands screen layout information, function setting information, and a drawing extension module for each plug-in as a configuration file of each plug-in.

  The drawing extension module is an executable file having an API for the processing of the plug-in.

  The screen layout information for each plug-in is described by an array structure of GUI types, function names, and coordinate information. Further, the function information for each plug-in includes a setting for using the function. Next, function information and screen layout information of each plug-in will be described.

  FIG. 12 is a diagram illustrating an example of function information of the “borderline” plug-in. Since the “borderline” plug-in is a function for drawing a separator line at the time of aggregation, in the example shown in FIG. 12, when the aggregation setting is “off”, the “borderline” function is set to be forcibly turned off.

  FIG. 13 is a diagram illustrating an example of screen layout information of the “borderline” plug-in. As shown in FIG. 13, it is defined that a check box is displayed in order to make a setting relating to “borderline”, and that the check box is displayed at x coordinate = “170” and y coordinate = “30”. With this setting, a user interface (UI) by a check box is displayed on the right side of the aggregation setting.

  FIG. 14 is a diagram illustrating an example of function information of the “stamp” plug-in. The “stamp” plug-in has a function that stamps the input character string. In the example shown in FIG. 14, a font size range and the like are set.

  FIG. 15 is a diagram illustrating an example of screen layout information of the “stamp” plug-in. As shown in FIG. 13, it is defined that an edit box is displayed in order to make a setting relating to “stamp”, and that the edit box is displayed at x-coordinate = “170” and y-coordinate = “120”. By this setting, an edit box user interface (UI) is displayed at the lower right of the screen.

  The printer driver 250 controlled by the control unit 1002 controls printing using the plug-in developed by the development unit 1006. The printer driver 250 according to the present embodiment calls the API of the developed plug-in drawing extension module and performs control using the plug-in.

  When called from the installation unit 1004 of the client PC 110 for point-and-print, the specifying unit 261 specifies a path for storing the plug-in archive and plug-in list information. The identifying unit 261 according to the present embodiment identifies the plug-in directory 1013 as a storage destination path.

  The storage unit 1005 stores the plug-in archive and plug-in list information received by the receiving unit 1003 in the plug-in directory 1013. The storage unit 1005 stores a plug-in archive and plug-in list information for the path specified by the specifying unit 261.

  Next, driver installation processing in the print control system according to the present embodiment will be described. FIG. 16 is a flowchart showing a procedure of the above-described processing in the print control system according to the present embodiment. In the example illustrated in FIG. 16, a procedure for installing the printer driver 250 from the server PC 100 to the client PC 110 is used.

  First, the user designates a printer installed on the server PC 100 side from the client PC 110 and executes Point and Print (step S1601). As a result, the installation unit 1004 included in the OS 1001 of the client PC 110 requests the OS 201 of the server PC 100 to install a driver based on point-and-print (step S1602).

  Accordingly, the transmission unit 203 of the OS 201 in the server PC 100 transmits the configuration file of the printer driver 250 main body to the reception unit 1003 included in the OS 1001 of the client PC 110 (step S1603). Then, the installation unit 1004 of the client PC 110 performs installation control of the printer driver 250 based on the received configuration file (step S1606). As a result, the printer driver 250 is installed in the client PC 110. Further, the point and print library 252 which is one of the configuration files of the printer driver 250 is also copied from the server PC 100 to the client PC 110.

  On the other hand, in the server PC 100, the OS 201 calls GenerateCopyFilePaths () of the point-and-print library 252 (step S1604). This point-and-print library 252 is preset in “Module” of the registry 210. That is, in this embodiment, the OS 201 calls the specified API by referring to the registry 210. In addition, when calling the API, a file source directory path, a file destination directory path, and a flag indicating that the server is calling are passed as arguments. The directory name of the file transmission source and the directory name of the file transmission destination are the directory paths set by the Directory key of the registry 210.

  When GenerateCopyFilePaths () is called from the server PC 100 side, the specifying unit 261 in the server PC 100 specifies the path of the directory in which the file to be transmitted is stored (step S1605). In other words, when GenerateCopyFilePaths () is called on the server PC 100 side, the specifying unit 261 returns the path in which the plug-in list information and the plug-in archive are stored as the process of GenerateCopyFilePaths (). If necessary, the source and destination directories are changed by rewriting and returning the paths of these directories.

  On the other hand, also in the client PC 110, the OS 1001 calls GenerateCopyFilePaths () of the point-and-print library 252 (step S1607). When the API is called, a file source directory path, a file destination directory path, and a flag indicating that the client is called are passed as arguments.

  When GenerateCopyFilePaths () is called from the client PC 110 side, the specifying unit 261 in the client PC 110 specifies the path of the plug-in directory 1013 that is a plug-in storage destination (step S1608). The procedure for specifying will be described later. Thereafter, the point-and-print library 252 returns the path of the identified plug-in directory 1013 to the OS 1001 (step S1609).

  Then, the OS 1001 of the client PC 110 makes a plug-in transmission request to the server PC 100 (step S1610). In response to the transmission request, the specifying unit 261 of the server PC 100 transmits a file group (plug-in archive) from the directory indicated by the path specified in step S1605 and the file name set in the Files key of the registry 210. And the plug-in list information), and the transmission unit 203 transmits the identified file group to the reception unit 1003 of the client PC 110 (step S1611).

  Thereafter, the storage unit 1005 stores the received file group in the path of the plug-in directory 1013 specified in step S1609 (step S1612).

  The printer driver 250 and a plug-in for the printer driver 250 are installed in the client PC 110 by the above-described processing procedure.

  In other words, in this embodiment, the plug-in list information indicated by the path and file name set in the registry 210 and the plug-in archive are transmitted to the client PC 110 to install the driver plug-in. .

  By the way, in this embodiment, even if the plug-in installed in the driver changes such as addition or deletion, the file name of the plug-in archive does not change. Since the file name of the plug-in archive is registered in the registry 210 in advance, the server PC 100 can use the client PC 110 only by transmitting the plug-in archive specified with reference to the registry 210 to the client PC 110. All the plug-ins are sent. On the client PC 110 side, all plug-ins collected in the plug-in archive can be recognized by referring to the plug-in list information transmitted together with the plug-in archive.

  That is, in the print control system according to the present embodiment, the plug-in archive and plug-in specified by referring to the registry 210 without recognizing what plug-in is installed in the driver on the server PC 100 side. All plug-ins can be installed on the client PC 110 simply by sending the list information. In this way, the server PC 100 can perform the plug-in installation process without recognizing each plug-in, so the processing load of the plug-in installation can be reduced.

  Next, processing based on GenerateCopyFilePaths () of the specifying unit 261 shown in Step S1605 and Step S1608 of FIG. 16 will be described. FIG. 17 is a flowchart illustrating a procedure of the above-described processing in the specifying unit 261 according to the present embodiment.

  When the specifying unit 261 is called by GenerateCopyFilePaths (), it refers to the argument and determines whether or not it is executed on the server PC side (step S1701). If it is determined that it is executed on the server PC side (step S1701: Yes), no processing is performed, and the path of the source directory specified by the argument is returned to the caller (for example, OS 1001) and the process is terminated. .

  On the other hand, if the identifying unit 261 determines that the server PC is not being executed (step S1701: No), the path of the ComonApplicationData is acquired using the SHGetSpecialFolderPath of the API of the OS 201 (step S1702). The specifying unit 261 then concatenates “driver name \ Plugin” to the acquired path of ComonApplicationData to generate a destination directory path (step S1703).

  After that, the identifying unit 261 rewrites the destination directory path received as an argument with the generated destination directory path, and then returns the rewritten destination directory path to the OS 201 (step S1704).

  As a result, the path of the plug-in transmission destination directory is set in the client PC 110. When the client PC 110 calls GenerateCopyFilePaths () to perform the processing of FIG. 17, if the flag indicating the client side is set as an argument, the destination directory path may be left empty.

  In the processing procedure described above, the plug-in list information and the plug-in archive are transmitted from the transmission source directory of the server PC 100 to the transmission destination directory of the client PC 110.

  At this time, since the configuration file of the printer driver is not changed at all after the driver is installed, the function extended by the plug-in can be obtained from the server PC 100 without breaking the affinity of the OS 201 (for example, Windows (registered trademark)). The client PC 110 can take over.

  Next, setting screen display processing in the client PC 110 according to the present embodiment will be described. FIG. 18 is a flowchart showing the above-described processing procedure in the client PC 110 according to this embodiment.

  First, the OS 1001 instructs the UI driver 254 of the printer driver 250 main body to perform screen display (step S1801).

  Next, the UI driver 254 requests initialization from the plug-in management unit 255 (step S1802). Then, the plug-in management unit 255 generates a list of plug-in names (step S1803).

  In the generation process, the plug-in management unit 255 generates a path of the plug-in directory 1013 with reference to the registry 1010, and reads plug-in list information stored thereunder (step S1804).

  Thereafter, the UI driver 254 requests initialization from the setting management unit 253 (step S1805). Thereafter, the setting management unit 253 requests the plug-in management unit 255 to acquire function information (step S1806).

  Accordingly, the plug-in management unit 255 merges the function information of the printer driver 250 main body with the function information of each plug-in (step S1807). In the process of merging, the plug-in management unit 255 reads function information stored in the driver setting directory 1012 (step S1808). Further, the plug-in management unit 255 requests the OS 1001 to expand the plug-in archive (step S1809). In accordance with the request, the expansion unit 1006 of the OS 1001 expands the plug-in archive (step S1810).

  Then, the plug-in management unit 255 reads the function information of each expanded plug-in. In the sequence shown in FIG. 18, the plug-in management unit 255 reads the function information of the borderline plug-in (step S1811) and also reads the function information of the stamp plug-in (step S1812). Each read function information is described in the XML format. Therefore, the plug-in management unit 255 merges the XML nodes of the read function information. Then, the XML node merged by the plug-in management unit 255 is transferred to the setting management unit 253. Then, the setting management unit 253 holds the acquired XML node on a memory (not shown).

  Thereafter, the plug-in management unit 255 reads DEVMODE 1011 (step S1813). Thereby, the current setting value and the like can be acquired.

  Then, the plug-in management unit 255 determines whether or not the read current setting value or the like is appropriate in view of the definition set in the read function information (for example, a value range or prohibition defined in the function information). (Step S1814).

  Next, the UI driver 254 requests the plug-in management unit 255 to acquire screen layout information (step S1815).

  Thereby, the plug-in management unit 255 merges the screen layout information of the printer driver 250 main body with the screen layout information of each plug-in (step S1816). In the process of merging, the plug-in management unit 255 reads function information stored in the driver setting directory 1012 (step S1817).

  Then, the plug-in management unit 255 reads screen layout information of each plug-in. In the sequence shown in FIG. 18, the plug-in management unit 255 reads the screen layout information of the borderline plug-in (step S1818) and also reads the screen layout information of the stamp plug-in (step S1819). The plug-in management unit 255 merges the JSON objects of each screen layout information read in this way. Then, the merged JSON object is sent to the UI driver 254.

  Thereafter, the UI driver 254 generates a screen layout of the setting screen based on the JSON object (step S1820). Then, the display unit 1007 of the OS 1001 displays the generated setting screen.

  Further, the UI driver 254 acquires a setting value from the setting management unit 253 (step S1821). Next, the UI driver 254 reflects the setting value on the screen layout of the setting screen (step S1822). Thereby, the display unit 1007 displays a setting screen in which the setting value is reflected.

  With the above-described processing procedure, the client PC 110 can display a setting screen in which driver information and plug-in information (function information and screen layout information) are merged.

  FIG. 19 is a diagram illustrating an example of a setting screen displayed by the display unit 1007 according to the processing procedure described above. In the setting screen shown in FIG. 19, a “Borderline” check box 1901 and an “Stamp” edit box 1902 are added as compared to the setting screen example of FIG.

  In the screen example shown in FIG. 19, the “Borderline” check box 1901 is displayed as unavailable and fixed to OFF. In addition, “Borderline” surrounded by a mesh line is also displayed with half luminance. In the screen example of FIG. 19, when “off” is selected in the “Layout” item, “<constraint fixvalue =“ off ”> <condition expression =” in the function information of “Borderline” (FIG. 12). This is because it is prohibited based on the description of “layout! = Off” /> </ constraint> ”.

  Next, print control in the client PC 110 according to the present embodiment will be described. FIG. 20 is a flowchart showing the above-described processing procedure in the client PC 110 according to the present embodiment.

  In the printing process, the API of the rendering driver corresponding to each event such as job start / end, page start / end, and drawing object is called from the OS 1001. However, in the sequence shown in FIG. showed that. It is assumed that processing is performed in exactly the same sequence in other APIs.

  First, the OS 1001 instructs the drawing driver 251 of the printer driver 250 main body to start page printing (step S2001).

  Next, the drawing driver 251 requests the plug-in management unit 255 to perform initialization (step S2002). Then, the plug-in management unit 255 generates a list of plug-in names (step S2003).

  In the process of generating the plug-in name, the plug-in management unit 255 generates a path of the plug-in directory 1013 with reference to the registry 1010, and reads plug-in list information stored under the path (step S2004). .

  Thereafter, the drawing driver 251 requests the setting management unit 253 to perform initialization (step S2005). Thereafter, the setting management unit 253 requests the plug-in management unit 255 to acquire function information (step S2006).

  As a result, the plug-in management unit 255 merges the function information of the printer driver 250 and the function information of each plug-in (step S2007). During the merge process, the plug-in management unit 255 reads function information stored in the driver setting directory 1012 (step S2008).

  Then, the plug-in management unit 255 reads function information of each plug-in. In the sequence shown in FIG. 20, the plug-in management unit 255 reads the function information of the borderline plug-in (step S2009) and also reads the function information of the stamp plug-in (step S2010). Each read function information is described in the XML format. Therefore, the plug-in management unit 255 merges the XML nodes of the read function information. Then, the XML node merged by the plug-in management unit 255 is transferred to the setting management unit 253. Then, the setting management unit 253 holds the acquired XML node on a memory (not shown).

  Thereafter, the plug-in management unit 255 reads DEVMODE 1011 (step S2011). Thereby, the current setting value and the like can be acquired.

  Then, the plug-in management unit 255 determines whether or not the read current setting value or the like is appropriate in view of the definition set in the read function information (for example, a value range or prohibition defined in the function information). (Step S2012).

  Next, the drawing driver 251 requests the plug-in management unit 255 to acquire function information (step S2013). As a result, the drawing driver 251 acquires the read current setting value and the like.

  Thereafter, the drawing driver 251 performs drawing processing for the page to be printed, and generates drawing data (step S2014).

  Next, the drawing driver 251 receives drawing data and a list of setting values as arguments, and requests the plug-in management unit 255 to perform processing relating to the page (step S2015).

  The plug-in management unit 255 refers to the list of plug-in names generated in step S2003 and recognizes the drawing extension module of each plug-in. Then, the plug-in management unit 255 calls a page start API to the drawing extension module of each plug-in developed from the plug-in archive. In the sequence shown in FIG. 20, the plug-in management unit 255 calls the page start API of the drawing extension module of the borderline plug-in (step S2016). At that time, drawing data and a list of setting values are transferred. Further, the plug-in management unit 255 calls the page start API of the drawing extension module of the stamp plug-in (step S2017). At that time, drawing data and a list of setting values are transferred. When the API for page start of these drawing extension modules is called, the drawing extension module of each plug-in refers to the list of setting values passed as an argument, and when drawing processing needs to be performed, drawing data The necessary drawing is performed. Then, after drawing is performed, drawing data is returned to the drawing driver 251.

  Thereafter, the drawing driver 251 outputs the returned drawing data to the OS 1001 (step S2018). Then, the OS 1001 transmits drawing data to the printer 150 (step S2019). Thereby, printing based on drawing data is performed.

  As described above, the client PC 110 can execute a drawing process in which the driver body and the plug-in are combined.

  Next, processing when a plug-in is added to the server PC 100 will be described. FIG. 21 is a diagram showing the configuration of the plug-in installer package. As shown in FIG. 21, the plug-in installer package 2100 is a directory including a plug-in installer 2101, plug-in information 2102, and a configuration file 2103 for the plug-in “stamp”. Note that the directory may be archived.

  The plug-in installer 2101 is a plug-in installer execution format file.

  The configuration file 2103 of the plug-in “stamp” includes a function information for realizing the stamp function, screen layout information, and a drawing extension module.

  The plug-in information 2102 is information describing settings related to the plug-in “stamp”. FIG. 22 is a diagram illustrating an example of plug-in information included in the plug-in installer package 2100. As shown in FIG. 22, it is described that the name of the plug-in is “stamp” and the version is “1.1.010”. The plug-in information 2102 is added to the plug-in list information at the time of installation.

  Processing when installing a plug-in on the server PC 100 will be described. FIG. 23 is a flowchart showing the above-described processing procedure in the server PC 100 according to the present embodiment. In the flowchart shown in FIG. 23, the plug-in installer is executed to add a new plug-in to the plug-in directory.

  First, the plug-in installer 2101 included in the plug-in installer package 2100 is activated. The activated plug-in installer 2101 acquires the name of the driver to which the plug-in is added (step S2301). For example, the plug-in installer 2101 may acquire a list of installed drivers from the OS 201 and inquire the user as to which driver the plug-in is to be added to from the list. Then, plug-ins are added to the driver selected by the user.

  Then, the plug-in installer 2101 acquires the path of the plug-in directory of the driver indicated by the acquired driver name from the registry 210 (step S2302). The plug-in directory specifying method is the same as the method described above. Then, the plug-in is installed in the acquired plug-in directory path.

  Next, the plug-in installer 2101 determines whether or not the same plug-in has already been added to the specified plug-in directory (step S2303). In this determination, for example, the determination is made based on whether or not the plug-in list information in the plug-in directory 213 includes the same name as the plug-in of the plug-in information 2102 in the plug-in installer package 2100.

  If the plug-in installer 2101 determines that the plug-in installer 2101 has not been added (step S2303: No), plug-in addition processing is continuously performed. 23, the plug-in installer 2101 calls the writing unit 204 to merge the plug-in information 2102 in the plug-in installer 2101 with the plug-in list information in the plug-in directory 213 (step S2305). In the present embodiment, the writing unit 204 called by the plug-in installer 2101 performs writing to add plug-in information to the end of the plug-in list information.

  Thereafter, the plug-in installer 2101 adds a new plug-in configuration file (eg, “stamp” configuration file 2103) to the plug-in archive (step S2306). For example, when the “borderline” plug-in is installed and the plug-in installer 2101 adds the “stamp” plug-in, the “stamp” configuration file 2103 in the plug-in installer package is changed to the plug-in installer 2101. When added to the in-archive, a plug-in archive as shown in FIG. 8 is generated. When plug-in information 2102 is added, plug-in list information as shown in FIG. 7 is generated. Then, the installation process ends.

  On the other hand, if the plug-in installer 2101 determines that the same plug-in has been added (step S2303: Yes), the plug-in installer 2101 starts with the version of the same plug-in already added in the plug-in directory. It is determined whether the version information of the plug-in in the plug-in installer package 2100 is newer than the information (step S2304). If it is determined that it is not new (step S2304: NO), the process is terminated.

  On the other hand, when the plug-in installer 2101 determines that the version information of the plug-in in the plug-in installer package 2100 is new (step S2304: Yes), the plug-in installer 2101 calls the writing unit 204, and the writing unit 204 The plug-in information already described in the plug-in list information is overwritten with new plug-in information (step S2307).

  Further, the plug-in installer 2101 overwrites the plug-in archive with a new plug-in configuration file, and ends the processing (step S2308). As an example, if the version of the “stamp” plug-in already stored in the plug-in archive is 1.0.0.0 and the version of the “stamp” plug-in to be added is 1.1.0.0, the plug-in installer 2101 The version information of “stamp” in the plug-in information is overwritten with 1.1.0.0, and all files in the “stamp” directory are overwritten with new files.

  The plug-in can be added or updated for the driver installed in the server PC 100 by the processing procedure described above. As a result, when the plug-in is added to or updated in the server PC 100, when the client PC 110 installs the driver, the added or updated plug-in is also installed at the same time. Thereby, the burden at the time of a user installing a driver can be reduced.

  As described above, in this embodiment, even if the function is an extension of the driver by plug-in, it can be handed over to the client PC 110 side by point-and-print without breaking the affinity with the OS.

  As described above, in the present embodiment, it is possible to realize a driver plug-in mechanism that can take over the extended function on the client PC side by point-and-print.

  Further, by including a dynamic link library for performing point and print in the driver configuration file, the library is installed in the client PC and the server PC. Accordingly, by calling the library from each of the client PC and the server PC at the time of the point-and-print event, each of the client PC and the server PC can perform an appropriate process for transmitting the plug-in. . That is, the plug-in file can be easily transmitted from the server PC to the client PC.

(Modification 1)
In the first embodiment, the client PC and the server PC are shown as separate configurations. However, in the first embodiment, for ease of explanation, the client PC and the server PC are shown as different configurations, and the client PC and the server PC may have the same configuration.

  Therefore, as a modification, an example in which the client PC and the server PC have the same configuration will be described. In the modified example, both the client PC and the server PC include a printer driver, a transmission unit, a writing unit, a reception unit, an installation unit, a storage unit, a development unit, and a display unit. Note that the processing performed by each component is the same as in the first embodiment, and a description thereof is omitted.

(Modification 2)
In the first embodiment, the example in which the printer driver is installed from the server PC to the client PC by the point-and-print has been described. However, the printer driver installation is not limited, and other office devices may be used. As an example of the office device, for example, a network scanner may be used. In the second modification, the client PC requests the server PC that manages the driver of the network scanner to install the driver. Thereby, the installation of the driver of the network scanner and the installation of the plug-in of the driver are performed. Note that the procedure at that time is the same as that of the first embodiment, and a description thereof will be omitted. Further, it may be other than office equipment, for example, peripheral equipment that can be connected to a PC such as a digital still camera.

  FIG. 24 is a diagram illustrating a hardware configuration of the server PC and the client PC according to the present embodiment and the modification. As shown in FIG. 24, the server PC and client PC according to the embodiment and the modification described above are displayed on a CPU 2401, a ROM (Read Only Memory) 2402 and a RAM 2403, an HDD 2406, a communication I / F 2404, a display device, and the like. A device 2405 and a bus 2407 for connecting them are provided, and a hardware configuration using a normal computer is employed.

  The OS and printer driver executed on the server PC or client PC according to the above-described embodiments and modifications are files in an installable or executable format, such as a CD-ROM, a flexible disk (FD), a CD-R, The program is recorded on a computer-readable recording medium such as a DVD (Digital Versatile Disk).

  Further, the OS and printer driver executed by the server PC or client PC according to the above-described embodiments and modifications are stored on a computer connected to a network such as the Internet and provided by being downloaded via the network. You may comprise. Further, the OS and printer driver of the present embodiment may be configured to be provided or distributed via a network such as the Internet.

  The OS and printer driver executed on the server PC or client PC according to the above-described embodiment and modification have a module configuration including the above-described units. As actual hardware, the CPU 2401 executes the OS from the storage medium. By reading and executing the printer driver, the above-described units are loaded onto the main storage device, and the above-described units are generated on the main storage device.

100 server PC
110 Client PC
150 Printer 160 Network 201, 1001 OS
202, 1002 Control unit 203 Transmission unit 204 Writing unit 210, 1010 Registry 211, 1011 DEVMODE
212, 1012 Driver setting directory 213, 1013 Plug-in directory 250 Printer driver 251 Drawing driver 252 Point-and-print library 253 Setting management unit 254 UI driver 255 Plug-in management unit 261 Identification unit 1003 Reception unit 1004 Installation unit 1005 Storage unit 1006 Deployment unit 1007 Display unit

JP 2009-199261 A

Claims (15)

A driver control system comprising a client on which a driver is installed and a server that manages the driver,
The server
A specifying unit for specifying a predetermined file in which the plug-ins of the driver are collectively archived and list information indicating the plug-ins stored in the file as transmission targets;
Transmission means for transmitting the driver and the file and list information specified by the specifying means to the client;
The client
Receiving means for receiving the driver, the file, and the list information from the server;
Installation means for installing the driver received by the receiving means;
Storage means for storing the file and the list information received by the receiving means in a storage means;
Control means for controlling the driver that calls the plug-in archived in the file according to the list information;
A driver control system characterized by The client
Client-side specifying means for specifying a storage destination path for storing the file and the list information according to the setting made in the installation of the driver by the installation means,
The storage means stores the file for the path specified by the specifying means;
The driver control system according to claim 1. In the server,
The specifying unit specifies the predetermined file according to a file name stored in a storage unit;
The driver control system according to claim 1, wherein: The server
In response to a call from a plug-in installer, writing for adding the plug-in to the file, and writing means for writing information for identifying the plug-in to be added to the file to the list information,
The driver control system according to any one of claims 1 to 3, further comprising: In the server,
The writing means writes version information of the plug-in, which is a criterion as to whether or not to add a plug-in, to the list information;
The driver control system according to claim 4, wherein: The client
The archive further comprises expansion means for expanding the plug-in used by the driver from the archive,
The driver controlled by the control unit performs control using the plug-in expanded by the expansion unit,
The driver control system according to claim 1, wherein: The plug-in configuration file expanded by the expansion means is an executable file having an API corresponding to the processing of each plug-in,
The driver controlled by the control means performs control using a plug-in by calling the API.
The driver control system according to claim 6. In the client,
The plug-in configuration file expanded by the expansion means includes layout information for each plug-in,
In accordance with the layout information, display means for displaying an item for setting for each plug-in on a setting screen,
The driver control system according to claim 6 or 7, wherein The layout information for each plug-in includes a type of user interface to be displayed, a function name, and coordinate information.
The driver control system according to claim 8. A driver control method executed by a client on which a driver is installed and a server that manages the driver,
In the server,
A specifying step for specifying, as a transmission target, a predetermined file in which the plug-ins of the driver are collectively archived and list information indicating the plug-ins stored in the file;
A transmission means including: the transmission step of transmitting the driver and the file and the list information identified by the identification step to the client;
In the client,
A receiving step for receiving the driver, the file, and the list information from the server;
An installation step of installing the driver received in the reception step;
A storage step of storing in the storage means the file and the list information received by the receiving step;
Control means for controlling the driver that calls the plug-in archived in the file according to the list information,
A driver control method characterized by the above. In the client,
The client side specifying means further includes a client side specifying step of specifying a storage destination path for storing the file and the list information according to the setting made in the installation of the driver by the installation step,
The storing step stores the file with respect to the path specified by the specifying step;
The driver control method according to claim 10. In the server,
The specifying step specifies the predetermined file according to a file name stored in a storage means;
12. The driver control method according to claim 10 or 11, wherein: In the server,
The writing means performs writing to add the plug-in to the file in response to a call from a plug-in installer, and writes information for identifying the plug-in to be added to the file to the list information. Write step
The driver control method according to claim 10, further comprising: In the server,
The writing step writes version information of the plug-in, which is a criterion for determining whether or not to add a plug-in to the list information;
The driver control method according to claim 13. In the client,
An expansion means further includes an expansion step of expanding a plug-in used by the driver from the archive,
The driver controlled in the control step performs control using the plug-in expanded in the expansion step;
The driver control method according to any one of claims 10 to 14, wherein:

Images