JP2019128857A - Device driver - Google Patents

Abstract

To solve the problem of a driver consisting of a separate driver body and driver UI, that installing just the driver body does not allow a driver setting UI to be launched, in which case, a setting screen available is just a simple OS-standard UI.SOLUTION: An appropriate combination of a driver body and a driver UI is retrieved and associated to allow for launching a driver UI prepared by a vendor as a setting screen.SELECTED DRAWING: Figure 6

Description

  The present invention relates to an information processing apparatus, program, and system for handling a device driver.

  First, the present application is directed to a driver in which a driver main body and a driver setting user interface (hereinafter referred to as a driver UI) are separated. The configuration in which the driver main body and the driver UI are separated refers to a form in which the driver package is separated into the driver main body and the driver UI and can be separately introduced into the information processing apparatus. The driver main body here is a portion having a central function that the driver assumes. Specifically, the driver main body corresponds to a printing process for a printer, and a FAX transmission process for a facsimile (FAX).

  Next, the driver UI refers to a program that displays a detailed setting screen for the driver body. When the driver UI is not installed, the OS standard UI that the operating system (OS) has as a standard is to start. At this time, the driver main body is stored in the system portion of the OS and is managed by the OS as a general rule, whereas the driver UI is separately installed as a normal program not involving the OS. For this reason, in order to open the setting screen in the driver UI from the driver main body, it is necessary to register installation information of the driver UI in the system for the driver main body.

  However, if this registration processing is not performed, the setting screen becomes the OS standard UI as in the case where the driver UI has not been installed, and only the minimum necessary settings are provided, and detailed settings cannot be performed. Occur.

  Japanese Patent Application Laid-Open No. 2004-228620 takes measures to associate the user interface of another driver, but if the difference between the two drivers is large, there is a possibility that a problem such as the inability to save the setting may occur. Moreover, since the method of Patent Document 1 assumes replacement of the UI incorporated in the driver, there is also a problem that the signature is broken.

JP 2014-178823 A

  An object of the present invention is to provide an information processing system capable of opening a setting screen by associating a driver body and a driver UI with an appropriate combination even when a driver body having a newer configuration than the driver UI version has been introduced. It is to provide. It is another object of the present invention to provide an information processing system capable of correcting an association to a more appropriate driver UI when there is a more appropriate driver UI than a driver UI associated with the driver main body.

In order to achieve the above object, an information processing system according to the present invention is
An information processing system comprising an information processing apparatus and a printing apparatus, and a driver and a setting screen of the driver being separated,
A means for acquiring driver information (S602);
Means for acquiring information on a driver setting screen (S601);
Means for determining whether the driver and the setting screen of the driver are an appropriate combination (S604);
Means for registering association information of a driver and a driver setting screen (S606);
It is characterized by having.

  According to the information processing system of the present invention, even when a driver body having a newer configuration than the driver UI version is introduced, the driver body and the driver UI can be associated with each other in an appropriate combination, and the setting screen can be opened. it can. Further, when there is a driver UI more appropriate than the driver UI associated with the driver main body, the association can be corrected to a more appropriate driver UI.

Diagram showing system configuration The figure which shows the hardware constitutions of the client computer Diagram showing the configuration of the driver set Example of driver extension association definition data Example of model-dependent driver UI An example of OS standard driver UI Flow of basic processing of the present invention Flow to determine whether the proper combination of driver body and driver UI is appropriate Flow showing search and association processing of similar driver UI Example of model-independent driver UI Flow showing association processing of driver of model independent version Flow showing association repair process

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 is a schematic view showing an outline of a system configuration according to the present invention.

  This system includes a client computer 101, which is an example of an information processing apparatus, and a printer 102 capable of receiving print data in the page description language (PDL) format and printing. These can communicate with each other through a network 103 including a wide area network (WAN).

  The printer 102 may be a single function printer having only a print function, or a multi-function printer having a print function, a scan function, and a copy function. Further, the number of client computers 101 is not limited to one, and a plurality of client computers 101 may be connected to the network 103.

  FIG. 2 is a block diagram showing the hardware configuration of the client computer 101 of FIG.

  In the client computer 101, a central processing unit (CPU 201) controls each device connected to the system bus according to a program stored in a random access memory (RAM 202). The client computer 101 includes at least one CPU 201. In addition, the CPU 201 executes processing based on a program stored in the external memory 209, thereby realizing the software configuration of the client computer 101 and the processing of each step in the flowchart described below. The RAM 202 functions as a main memory, a work area, and the like of the CPU 201.

  Reference numeral 203 denotes a read only memory (ROM). The ROM 203 stores various programs such as a boot program and a basic input / output system (BIOS). The operation input device interface (I / F) 204 is an interface for controlling the operation input device 205 such as a keyboard or a pointing device (mouse) touch UI (User Interface). The display I / F 206 controls screen display on the display 207. An external memory I / F 208 controls access to an external memory 209 such as a hard disk (HD) or solid state disk (SSD). The external memory 209 includes an operating system program (OS) 210, an application 212 corresponding to each of the touch panel and the desktop, and a driver 3006 including a printer driver. And various files etc. are memorize | stored and it functions as a storage medium which the client computer 101 can read. A network I / F 213 is connected to the printer 102 via the network 103 and performs communication control processing.

  The configuration and arrangement destination of the driver set 3000 will be described with reference to FIG. Here, the driver set refers to a module and storage storage area required for the driver to set and execute processing on the device.

  First, the driver set 3000 is separately arranged in the OS 210, the driver 3001, and the application 212. The model-dependent file 3002 is composed of files such as a list of prohibited rules and functions for each model, factory default print settings, and default print settings for each locale. The graphics module 3003 takes charge of a function of converting a file to be printed into PDL (Page Description Language) when the driver 3001 performs printing.

  A driver UI module 21201 is a module that is called at the time of printing after the driver set 3000 is installed, and enables detailed print settings.

  The driver extension association definition 20101 is a definition of which setting screen the driver 3001 opens. For example, information is registered in a setting database area (FIG. 4) of the OS. Here, the driver UI file path 401 that defines the location of the driver UI and the driver main body ID 402 that is information for uniquely identifying the driver main body will be described here. When the driver 3001 opens the setting screen, the driver 3001 first uses the driver main body ID 402 to search for the driver extension association definition 20101 in the setting database. Then, the driver UI registered on the basis of the file path 401 of the driver UI is called for the driver whose driver body ID 402 matches.

  Hereinafter, the driver 3001 is referred to as a driver main body in order to make the distinction from the driver UI clear.

  First, an outline of the present embodiment will be described.

  When creating a package including the driver UI module 21201 in the driver main body, the OS 210 performs management including registration of association information of the driver UI module 21201. Therefore, each vendor does not perform special processing. A detailed setting screen like (A) can be called. However, when the driver UI module 21201 is introduced as the application 212, the driver UI is handled in the same way as a normal application, and thus the OS 210 cannot recognize the driver UI module 21201 as a driver-related module. In this case, the setting screen opened from the driver body is an OS standard driver UI as shown in FIG. Even if the driver UI module 21201 is already installed in the OS as an application, the OS standard driver UI is similarly opened unless the association information is registered in the driver extension association definition 20101.

  For this reason, when the driver UI module 21201 is installed in the OS 210, it is necessary to register association information with the driver main body in the driver extension association definition 20101, thereby opening a detailed setting screen as shown in FIG. Will be able to

  FIG. 6 is a flowchart showing a process of registering association information between the driver UI and the driver main body.

  In this example, since it is assumed that the installer performs the installation when installing the driver UI, the subject of the flow in this example is basically described as an installer. However, there is also conceivable a system in which installation of Point & Print is started and installation is performed without using the driver UI installer. For example, a system that performs processing at the timing when the processing of the “change” or “repair” button on the screen for managing the installation program such as “deletion of program” is executed can be cited. Alternatively, it may be executed at a predetermined timing such as “when the user logs in”, “when the PC starts up”, “every predetermined time”, or “specified time” by using an OS service or a task scheduler. Further, when the OS issues an event for notifying the driver installation, the mechanism may be used. In that case, the subject may be the OS 210 or a service started by the OS 210.

  From here, the association process of the driver UI and the driver main body in this flow will be described.

  First, the driver UI to be processed is acquired (S601). This processing refers to acquisition of what is managed by the driver UI installer. It is assumed that the target to be acquired here is information on the name and location of the driver UI, and information on the related driver UI as well.

  Next, the installed driver main body is acquired (S602). Here, one model is acquired from unprocessed installed drivers. At this time, information related to the acquired model type, for example, information including the name of the driver and ability information, is also acquired.

  Here, it is determined whether or not the driver extension association definition has been registered in the driver proper of the acquired model (S603). If it has already been registered, the processing is skipped, and the processing proceeds to S 607. If it is not registered, the processing proceeds to S 604 and the registration processing is performed.

  If it is not registered, it is determined whether the driver main body and the driver UI are an appropriate combination (S604). Details of this process will be described later.

  As a result of the processing in S604, when it is determined that the driver body and the driver UI are an appropriate combination, the association is registered in the driver extension association definition 20101. Specifically, the path of the driver UI of the appropriate combination is registered in the file path 401 information of the driver UI of the driver main body to be processed.

  Finally, it is determined whether or not an unprocessed driver body remains. If all the drivers have been processed, the process ends. If there is an unprocessed driver body, the process proceeds to S602 to process the remaining drivers. (S607).

  By the above processing, by registering the association information of the driver main body and the driver UI, it becomes possible to open the detailed setting screen.

  FIG. 7 is a flow showing the details of the process in the flow of FIG. 6 for determining whether the combination of the driver main body and the driver UI is appropriate. If any of these determinations indicates that the device is not a target device, the flow processing is terminated and a result indicating that an appropriate combination is not obtained is returned (S707).

  First, it is determined whether the driver body is the target type (S701). Here, it is first determined whether the device targeted by the driver is a printer or FAX, and whether the device is a target device based on a rough classification determined based on the ClassVer information of the target driver. I do.

  Next, the target model is determined using manufacturer information or the like (S702). This is determined from the manufacturer information registered in the driver whether or not it belongs to the company. At this time, when a specific expression is used for the product name, the classification may be performed based on this expression. For example, it is used as a determination condition whether or not "-Color--" is included in a color / monochrome machine, for example.

  Next, a determination is made based on a condition as to whether or not the driver body is a supported model (S703). In this case, based on information such as the model name and driver ID supported by the driver UI, it is determined whether or not the device is a target device.

  After the determination as to whether the model is the target, the process proceeds to determination whether the driver main body of the target device is associated with the driver UI. As one of the determinations, first, it is determined whether the version information matches (S704). In this judgment, not only the version number matches but also the judgment that it is judged that there is no problem if there is a minor version or less, and that there is no problem if it is one version before and after, etc. You may do it.

  Finally, it is determined whether the driver main body can be associated (S705). For example, even if the driver itself is installed, if a port is not actually assigned, such as when a queue is not created in the OS “device and printer”, etc., it is used even if it exists on the OS It may not be possible. The same applies to the case where an illegal port is assigned. In addition, since it is better not to associate the driver UI with the redirect printer, etc. that is generated when the remote desktop is connected, it is better not to associate the driver UI because the driver UI is not assigned. It is determined that

  If all these conditions are met, the result that the combination is appropriate for association is returned (S706).

  By performing the above determination processing, it is determined whether the driver combination is appropriate.

  In this embodiment, by performing these processes, it is possible to register an association definition of an appropriate combination of a driver body and a driver UI.

  In the first embodiment, it is possible to associate the driver main body corresponding to the driver UI. However, in the case where the package is divided for each device series, the driver UI for each series exists separately, and it is necessary to call the association process for each of them. For example, when there are PCL version and PS version driver UIs, it is necessary to separately call the PS version driver UI association process after calling the PCL version driver UI association process.

  In this embodiment, a search is made for a driver UI similar to the target driver UI, and if there is a similar driver, the association process of the driver UI is also called, thereby associating all the series of driver UIs together. Do the processing.

  The flow of FIG. 8 is a flow showing the processing of this embodiment. Basically, the processing is realized by adding search processing S801 and S802 for whether there is a driver UI similar to the processing target driver UI in the processing flow of S601 to S607 in FIG.

  First, when the processing of S607 of the first embodiment is completed, a search is performed for a driver UI similar to the driver UI that is the processing target (S801). The search method here is, for example, matching of the first character such as "start with" Office Laser Printer ~ "in" deleting a program ", to search for a similar driver UI, or to match a regular expression, or Levenstein It is also possible to use the matching degree of the character string using the distance. Alternatively, the search is based on whether the driver UI is arranged in the same hierarchy or one hierarchy as the directory in which the driver UI is arranged, or in a specific area or less determined by the company or project. In the case where it is assumed that the configuration is significantly different in this processing, a method of registering a search method and a calling method in advance in a management table or the like may be used.

  If a similar driver UI is found, that driver UI is targeted for processing, and the association processing from S602 to S607 is called (S802).

  By performing the above-described processing, it is possible to collectively perform association processing also for driver UIs similar to the driver UI being processed.

  In the first embodiment, the association process is performed only for the driver main body supported by the driver UI. However, if the driver main unit and the driver UI are distributed separately, or if the driver main unit built in the OS is used, the driver main unit and driver UI versions are different, so models and functions that are not supported by the driver UI. The driver body may have it. In such a case, there is a possibility of causing problems such as not starting or setting not being reflected even if the driver UI is forcibly associated.

  For this reason, in this embodiment, as shown in FIG. 9, when a driver UI that does not depend on the model or version is provided in advance, and the driver main body has a model or function that is not supported, the model as shown in FIG. Associate the independent driver UI. Although this model-independent driver UI is shown in FIG. 9 as an example in which setting items are narrowed down so that the difference is easy to understand, the type is not particularly limited as long as there is no problem due to a difference in device or version. Absent. For example, a configuration that does not depend on the model or version, a configuration that has a common function, or a configuration that has all functions in advance and dynamically switches the UI may be used.

  As described above, by using a model-independent driver UI, although the driver UI as shown in FIG. 5A built for each model is inferior to the driver UI, it is possible to provide the driver UI with a certain sense of use. It becomes possible.

  To explain using FIG. 10, when the driver main body and the driver UI of the appropriate combination are not found in S605 of the flow of FIG. 6 of the first embodiment, the model independent driver UI and the driver main body of FIG. Association is performed (S1001).

  In the embodiments so far, there is a case where the association of the driver is not appropriate. For example, even if the appropriate combination of the driver body and the driver UI is associated by the means of the first embodiment, only the driver body is upgraded by the OS update function or the like, and as a result, the versions may be different. is there.

  In such a case, for example, when the user downloads the latest driver UI, it can be said that it is appropriate to change the association from the existing one to the latest driver UI. Even in the case where the model-independent driver UI is associated in the third embodiment, if the user obtains the latest driver UI and there is an official driver UI corresponding to the model, the association is made there. It is more appropriate to replace it.

  Therefore, a process for determining whether the association between the driver UI and the driver main body is correct and updating the association will be described with reference to the flowchart of FIG.

  First, the driver main body already installed is acquired (S1101). This process is basically the same as the process of S602.

  Next, it is determined whether the acquired driver main body is associated with a configurable driver UI (S1102). Specifically, the driver UI and the driver main body version are compared, and it is determined that they are not appropriate if they do not match or if there is a certain amount or more of an open version. In addition to this, the driver UI is actually started by dynamically acquiring and comparing the capabilities of the driver main body and the driver UI programmatically and comparing the method to determine whether it is appropriate or by running the program startup process. It is good also as a condition of determination whether or not.

  Even if it is determined that the activation is safe under the conditions of S1102, even if a model-independent driver UI is associated, if there is a model-dependent version of the official driver UI, it is better to update the association. Therefore, it is determined that it is not appropriate, and the process proceeds to step S1104 (S1103).

  From there, the driver UI to be processed is acquired as in the processing of S601 and S802 (S1104).

  Next, it is determined whether or not the driver body to be processed is an appropriate combination with the driver UI. Since this is the same as the processing in S604, it is omitted (S1105).

  If it is determined that the driver main body and the driver UI are an appropriate combination as a result of the process of S1105, the process proceeds to S1107 (S1106).

  If it is determined that the combination of the driver body and the driver UI is more appropriate, the association contents of the driver extension association definition 20101 are updated with the target combination (S1107).

  If the combination is not appropriate, the process advances to step S1104 to acquire the next unprocessed driver UI (S1108).

  Finally, if an unprocessed driver main body remains, the process moves to step S1101 and shifts to the next driver main body update determination (S1109).

  By performing the above-described processing, it is possible to determine whether the association between the driver UI and the driver main body is correct and to perform the association update processing.

101 client computer, 201 CPU, 202 RAM

Claims (5)

An information processing system comprising an information processing apparatus and a printing apparatus, and a driver and a setting screen of the driver being separated,
A means for acquiring driver information (S602);
Means for acquiring information on a driver setting screen (S601);
Means for determining whether the driver and the setting screen of the driver are an appropriate combination (S604);
Means for registering association information of a driver and a driver setting screen (S606);
An information processing system characterized by having. Means (S604) for determining whether the driver and the driver setting screen of the information processing system are an appropriate combination;
A unit (S701) for determining whether the driver is a target type of the setting screen of the driver;
A means (S702) for judging whether the driver is the target of the setting screen of the driver from the manufacturer and department information of the driver;
A means (S703) for determining whether the driver is a model supported by the setting screen of the driver;
Means for the driver to compare the versions of the driver (S704);
A means (S705) for determining whether the driver can be used;
The information processing system according to claim 1, comprising: The information processing system according to claim 1, further comprising means (S802) for processing a setting screen of the driver similar to the setting screen of the driver. The information processing system according to claim 1, further comprising means (S1001) for registering association information between the driver and a model-independent driver setting screen. The information processing system according to claim 1,
Means for determining whether the driver can use the setting screen of the driver (S1102);
And a means (S1103) for determining whether the driver is associated with the setting screen of the model-independent driver.