JP2008130016A - Network card - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To make it possible to know whether or not an API (Application Program Interface) is usable for an application program in each type of a printer controller before executing the API, and to allow mounting according to a use situation of the API. <P>SOLUTION: This network card provides a means for previously knowing whether or not the API provided to the application program is usable by the type of a printer controller to be mounted. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a network card attached to a printer apparatus.

  In recent years, with the widespread use of the Internet, a form in which a printing apparatus is used in a network has become common. Usually, high-priced machines such as high-speed machines and color machines tend to have a built-in network interface. However, in the case of a low-priced monochrome machine, the network interface is not included in the main unit. In general, the network card module is supplied separately.

  In this case, the printing apparatus main body and the network card module are intelligent forms each having a CPU. Further, the normal network card module side is provided with a print server function for performing overall control of various print services via the network. In addition, the printing apparatus and the network card module communicate with each other via a connection interface to implement a desired service.

  This, on the contrary, makes it possible to drive heavy network services to the network card module, relatively lowering the CPU and peripheral performance of the printing apparatus main body, and reducing the cost of the printing apparatus main body.

  The conventional network interface only needs to be able to transmit print data as typified by LPR (RFC1179), for example. Recently, there is a growing need for information management for printing apparatuses, and various means are provided as additional techniques.

  The simplest example is a form in which information management data (job control language = Job Language) is added to a port for transmitting print data. Since the job control language shares a port for sending print data, it is not necessary to increase the service port and is relatively easy to implement. However, if a large amount of data is transmitted during reception of print data, the port is occupied, and there is a problem that the exchange of information management data is stopped. In addition, in the case of a one-way connection such as the LPR protocol in a network, there is a disadvantage that information cannot be acquired in the first place.

  As the next method, there is a method using SNMP / MIB (RFC1157). In this method, a dedicated port for data transmission / reception is used, and the standard SNMP (Simple Network Management Protocol) is used. However, this method requires proprietary development of a dedicated client program that receives SNMP and provides a UI. In addition, since this method is a protocol for exchanging simple information in the first place, only simple databases such as numbers and character strings can be provided. As a result, there is a problem that information that constitutes the UI, such as a bitmap image indicating the configuration of the device, must be owned by the client program, and the client program must correspond to the model accordingly.

  More recently, methods using the HTTP protocol (RFC1945, RFC2616) are becoming mainstream. According to this method, an HTTP service is provided in the network card module, and WEB contents such as HTML data related to device information and bitmap images are provided. Further, if the client displays the WEB content on the GUI using a general WEB browser and enables the operation, the same effect can be obtained without providing a client program. In the conventional method, the client program needs to manage information (message character strings, bitmap images) unique to a wide variety of devices. It is the most suitable way to provide.

  However, any of the above-mentioned means is a means for providing a static function incorporated in the network card module in advance, and the function itself is added later, or the control method by the incorporated function is changed. A dynamic service could not be added.

  Therefore, recently, a platform technology has been proposed that enables an application program module created using the Java (registered trademark) language to operate on a Java (registered trademark) virtual machine mounted on an embedded device (Java (Registered trademark): Trademark of Sun Microsystems, Inc., USA). By using this technology, it has become possible to add new functions to a device afterwards in an embedded device such as a conventional printing apparatus.

  The Java (registered trademark) virtual machine described above has an application program interface (API) for providing various functions necessary for controlling an embedded device, including a network communication function. Therefore, application program modules created in the Java (registered trademark) language call these APIs to control embedded devices and process requests from host computers connected via a network.

Also, some conventional technologies provide a Java (registered trademark) development environment that runs on a PC in order to provide an environment that enables more efficient development of Java (registered trademark) applications. . (For example, refer to Patent Document 1.)
JP 2005-038010 A

  The API provided on the Java (registered trademark) virtual machine includes functions necessary for network communication, and is usually implemented on a network card module in order to share a basic module for processing a network communication protocol. It is a function.

  However, for these APIs, the information that can be acquired differs depending on the function of the printing apparatus main body in which the network card module is installed, or there are some that cannot be acquired depending on the function of the printing apparatus main body. . For this reason, when trying to create an application program in the Java (registered trademark) language, it is necessary to create it in consideration of the functions of the installed printing device, and it is necessary to develop a common application program that runs on multiple printing devices. It was hindering.

The present invention has been made in view of the above problems,
In an intelligent network card module having a CPU separate from the printing device, which can be attached to the printing device body,
A means for enabling an application program module operable on a Java (registered trademark) virtual machine included in the network card module to be added to the network card module from a client such as a host computer;
A Java (registered trademark) virtual machine capable of operating an application program for controlling a printing apparatus and controlling communication with a client such as a host computer is provided.
When executing an application program interface (API) that can be used from an application program, a model difference absorption unit that determines a model according to a printing apparatus in which a network card module is mounted and performs processing according to the model,
Information changing means for changing the information acquired by the model difference absorbing means to information corresponding to the application program interface (API),
Furthermore, an availability determination unit that determines whether each API is available for each model, and an availability notification unit that notifies the application program of the result of the determination as to whether the API can be used. Consists of

  Further, the network card module includes an availability determination API means that designates an ID corresponding to the API so that the application program knows whether or not the application program interface (API) can be used.

  Further, in the network card module, in order for the application program to know whether or not the application program interface (API) can be used, the network card module is configured by an availability determination API unit corresponding to each API.

Furthermore, in the network card module,
And means for specifying the model of the printing apparatus main body when the power is turned on.

Furthermore, in the network card module,
When the model of the printing apparatus main body is unknown, it is composed of model difference absorbing means for performing processing when it is identified as an unknown model.

  According to the present invention, the API provided to the application program provides a means for knowing in advance whether the API can be used depending on the model of the printer controller to be mounted. As a result, the application program can know whether it can be used for each model of the printer controller before executing the API, and can be implemented according to the usage status of the API.

(Example 1)
FIG. 1 is a block diagram illustrating a hardware configuration of a printing system according to an embodiment of the present invention. Reference numeral 1000 denotes a printer, which is mainly composed of devices that control different control systems, including a network printer server 1500 and a printer controller 1600. In the network print server 1500, reference numeral 1 denotes a network print server CPU. The network print server CPU operates based on a control program stored in the rewritable Flash ROM 3. Further, it communicates with a plurality of external devices (not shown) such as a host computer connected to a local area network (LAN2000) via a network controller (LANC5) connected to the system bus 4. For communication, a predetermined network communication protocol is used to comprehensively control various data transmission / reception requests such as print data and printer control commands sent from the external device. Then, appropriate data transfer control is performed for the printer controller 1501 connected via the expansion interface controller (EXPC7).

  The RAM 2 is used as a temporary storage area such as the main memory and work area of the CPU 1.

  The LED 6 is used as a display unit indicating the operation state of the network print server. For example, the electrical connection state (LINK) between the network controller (LANC5) and the local area network (LAN2000) is displayed. Alternatively, various operation states such as the network communication mode (10Base, 100Base, full duplex, half duplex) can be indicated by the blinking pattern and color of the LED.

  Further, the expansion interface 17 that connects the network print server 1500 and the printer controller 1501 is configured by a connector (not shown). Therefore, only the network print server 1500 can be attached and detached, and the network print server 1500 can be attached to another printer 1000 having the same configuration.

  In the printer controller 1600, reference numeral 8 denotes a printer controller CPU. The printer controller CPU operates based on a control program or the like stored in the ROM 9 or a control program or resource data (resource information) stored in the external memory 10 connected via the disk controller (DKC 15). Further, it comprehensively controls access to various devices connected to the system bus 11. Further, output image information is generated by the raster controller 12 based on print data received from the network print server 1500 connected via the expansion interface controller (EXPC 13), and an image signal is output to the print engine 16.

  Reference numeral 14 denotes a RAM that functions as a main memory, a work area, and the like of the CPU 8, and is configured so that the memory capacity can be expanded by an optional RAM connected to an expansion port (not shown).

  Reference numeral 18 denotes an operation panel (operation unit) which is provided with buttons for performing operations such as setting the operation mode of the printer 1000 and canceling print data, and a display unit such as a liquid crystal panel and an LED indicating the operation state of the printer 1000. Yes.

  The printer engine 16 shown in the figure uses a known printing technology, and examples of suitable implementation systems include an electrophotographic system (laser beam system), an ink jet system, and a sublimation method (thermal transfer) system. .

  FIG. 2 is a block diagram illustrating a software configuration in a control program stored in each storage device of the network print server 1500 / printer controller 1600, which is a control device in the printer 1000 in the printing system suitable for the embodiment of the present invention. It is.

  Each control program is analyzed and processed by the CPU of each control device.

  An operating system 1501 controls basic data input / output control of the network print server 1500. Further, the operating system 1501 includes a file system 1505, an extended interface driver 1506, and a network interface driver 1507.

  The file system 1505 performs input / output control with the program / data storage unit 9. The extension interface driver 1506 performs communication control via the printer controller 1600 and the extension interface 17. The network interface driver 1507 communicates with an external device such as a host computer (not shown) via a local area network (LAN2000) communication medium.

  Reference numeral 1502 denotes an application program interface (API). The API provides a user application 1503 that runs on the network print server 1500. Furthermore, various functions of the operating system are provided to application programs such as a management application for registering and managing the printer 1000 and user applications.

  The functions provided by the application program interface 1502 include the following APIs.

  A data transfer API that provides a print data transmission / reception function, and a resource control API that controls input / output of resource data such as bitmap images and display messages.

  A printer control API that controls the restart of the printer 1000, initialization of setting values, and settings. A job control API that controls cancellation of print jobs and reprint instructions. Print server control API for restarting the network print server 1500, initializing and setting values, and starting, registering, and deleting application programs. A hard disk control API for controlling writing / reading to / from the hard disk drive, a panel API for controlling switching of the operation panel display of the printing apparatus, and the like. These APIs include those having different availability and information that can be acquired depending on the function of the printer controller 1600 connected to the network print server 1500.

  Reference numeral 1512 denotes a model difference API absorption layer positioned above the above-mentioned various APIs, which is a middleware layer for absorbing functional differences between various APIs caused by functional differences between the printer controller 1600 connected to the network print server 1500. is there.

  Reference numeral 1601 denotes an operating system that controls various processing controls of the printer controller 1600. There, the printer engine control unit 1603 for controlling communication with the print engine and model-dependent resources such as bitmap images and error messages referenced from the network print server 1500 are included. Furthermore, a file system 1604 for controlling input / output with a model-dependent resource / program storage unit that stores a model-dependent application program or the like operating on the network print server is included.

  Reference numeral 1602 denotes an expansion interface control unit, which controls communication with the network print server 1500 via the expansion interface 17. The extended interface control unit further includes a data transfer logical interface that controls input / output of print data for each control type. Further, a resource control logic interface for controlling input / output of various data stored in the model-dependent resource / program storage unit 9 and a printer control logic interface for controlling restart of the printer 1000, initialization of setting values, setting, and the like are provided. . In addition, a job control logical interface for controlling cancellation of a print job, reprint instruction, and the like is provided. Further, the command requested from the network print server 1500 is transferred to the operating system 1601 via each logical interface, and the processing result is returned to the network print server 1500.

  FIG. 3 is a description example of an application program operating on the network print server 1500, and shows a description example in Java (registered trademark) language as a preferred example of the present invention. A line indicated by 301 in FIG. 3 is an example of calling the data transfer API described in FIG. In the figure, “printer.outdata (“ Test ”)” is a data transfer API, and here is a command to print text data “Test” as print data from the print engine via the printer controller. The processing result is stored in "result" as a numeric type.

  A line indicated by 302 in FIG. 3 indicates a standard output destination for outputting the processing result indicated by the line 301. For example, it is a description example of a command for converting a text message into an LCD display part of the operation panel 17 of the printer 1000 or an application and displaying it on a browser display part of a host computer that is a caller.

  FIG. 4 is an example of a storage table that statically stores the API availability status for each printing apparatus according to the present invention. 4-a indicates whether the API of Device A can be used, and API a and d can be used, but b and c cannot. Similarly, 4-b indicates that APIa and b can be used in DeviceB.

  FIG. 5 is a flowchart when the user application uses an API for determining whether or not an API can be used according to the present invention, and specifies the ID of the API that the user wants to determine whether to use the API.

  In S501, the API for executing the API is specified by specifying the ID of the API for which it is desired to determine whether the application can be used. When the API is executed, the model difference API absorption layer identifies the model of the printer controller 1501 in S502, and the process proceeds to S503. In S503, it is determined whether or not the API can be used from the static table that determines whether or not the API is used for each printer, and the process proceeds to S504. If it is determined in step S504 that the application is available, the process advances to step S505 to notify the application that the application can be used, and the process ends. If it is determined in step S504 that the application cannot be used, the process advances to step S506 to notify the application that the application cannot be used, and the process ends.

(Example 2)
FIG. 6 is a flowchart when the user application according to the present invention uses an API for determining whether or not an API can be used, and executes the API by specifying the ID of the API that the user wants to determine whether or not the API can be used.

  In the second embodiment, unlike the first embodiment, instead of holding a static table for determining availability, when the API for determining API availability is executed from the user application, the API is displayed. An inquiry is made to the printer controller as to whether it can be used.

  Then, from this result, the application is notified of the availability result. This is configured as in the second embodiment when it is determined whether a function (fax, hard disk, etc.) provided by installing the optional device is installed.

  In step S601, the API for executing the API is specified by specifying the ID of the API for which it is desired to determine whether the application can be used. When the API is executed, the model difference API absorption layer identifies the model of the printer controller 1501 in S602, and the process proceeds to S603. In step S603, an inquiry is made to the printer controller 1501 to determine whether or not the API can be used for each printer. If it is determined in S604 that the service can be used, the process proceeds to S605 to notify the application that the service can be used, and the process ends. If it is determined in step S604 that the application cannot be used, the process advances to step S606 to notify the application that the application cannot be used, and the process ends.

(Example 3)
In the embodiment of the first embodiment, a static table is held in order to determine availability, and in the embodiment 2, an inquiry is executed to the printer controller to dynamically determine availability. In the third embodiment, an example is shown in which a query is dynamically made regarding an API that should be determined dynamically while using a static table.

  FIG. 7 is an example of a storage table that stores the API availability status for each printing apparatus according to the present invention. 7-a indicates whether or not the API of Device A can be used, and API a and d can be used, but b cannot be used, and c is dynamically inquired. Similarly, 7-b indicates that APIa and b can be used in DeviceB.

  FIG. 8 is a flowchart when the user application uses an API for determining whether or not an API can be used according to the present invention, and executes the API by specifying the ID of the API that the user wants to determine.

  In the third embodiment, unlike the first and second embodiments, when the API for determining whether to use an API is executed from a user application that holds a static table for determining whether or not the API can be used, the API is used. The printer controller is inquired about whether it is available. Then, both methods for notifying the application of the availability result from the result are provided.

  This configuration is the same as that of the third embodiment when there is a mixture of statically fixed availability and functions (fax, hard disk, etc.) provided by installing optional devices. .

  In step S801, the API of the API for which the application is to be used is specified as the API for determining whether the application is to be used, and the API is executed. When the API is executed, the model difference API absorption layer identifies the model of the printer controller 1501 in S802, and the process proceeds to S803. In S803, referring to the availability status of the ID specified from the sexual table for each printer, the process proceeds to S804. In S804, it is determined whether static determination is possible from the static table. If static determination is possible, the process proceeds to S806. If it is determined in S805 that the static table can be used, the process advances to S806 to notify the application that it can be used, and the process ends. If it is determined in step S805 that use is not possible, the process advances to step S807 to notify the application that use is not possible, and the process ends. If it is determined in S804 that the determination cannot be made statically, the process proceeds to S808. In step S808, an inquiry is made to the printer controller 1501 to determine whether or not the API can be used for each printer. If it is determined in step S809 that the application can be used, the process advances to step S810 to notify the application that the application can be used, and the process ends. If it is determined in S809 that it cannot be used, in S811, the application is notified that it cannot be used, and the process ends.

Example 4
In the first to third embodiments, an example is shown in which an API for determining whether or not an API can be used is executed in order for an application to know whether or not an API can be used. However, the embodiment is not limited thereto. In the fourth embodiment, in order for an application to know whether or not an API can be used, a use availability confirmation API corresponding to the API is prepared one-on-one.

  FIG. 9 shows an example of the availability confirmation API. When confirming the availability of getDeviceName (), it is possible to determine the availability by executing isAvailable_getDeviceName () prepared in pairs. isAvailable_getDeviceName () returns true if it can be used, and false if it cannot be used, so that the application can know whether it can be used.

1 is a block diagram of a hardware configuration of a printing system according to an embodiment of the present invention. FIG. 2 is a block diagram of a printing system software configuration according to the embodiment of the present invention. The example of a source code description of the application program in this invention. The storage table which memorize | stores statically the availability state of API for every printing apparatus which concerns on this invention. FIG. 6 is a flowchart when the user application uses an API for determining whether or not an API can be used according to the present invention, and executes an API by specifying an ID of an API that is to be used for determining whether or not to use the API. FIG. 6 is a flowchart when the user application uses an API for determining whether or not an API can be used according to the present invention, and executes an API by specifying an ID of an API that is to be used for determining whether or not to use the API. The storage table which memorize | stores the availability state of API for every printing apparatus which concerns on this invention. FIG. 6 is a flowchart when the user application uses an API for determining whether or not an API can be used according to the present invention, and executes an API by specifying an ID of an API that is to be used for determining whether or not to use the API. API example of availability confirmation.

Explanation of symbols

1000 Printer 1500 Network Print Server 1600 Printer Controller 2000 Local Area Network 1 CPU
2 RAM
3 Flash ROM
4 System bus 5 LAN controller 6 LED
7 Expansion interface controller 8 CPU
9 ROM
10 External memory 11 System bus 12 Raster controller 13 Extended interface controller 14 RAM
15 Disk Controller 16 Print Engine 17 Expansion Interface Bus 18 Operation Panel

Claims (3)

In a network card having a CPU separate from the printing device, which can be attached to the printing device main body,
Means for allowing an application program operable on a virtual machine included in the network card to be added from the client to the network card;
A virtual machine capable of operating an application program for controlling a printing apparatus and communication with a client;
When executing an application program interface (API) that can be used from an application program, a model difference absorbing unit that determines a model according to a printing device to which a network card is mounted and performs processing according to the model,
Information changing means for changing the information acquired by the model difference absorbing means to information corresponding to the application program interface (API);
In addition, the availability determination means for determining whether each API is available for each model,
A network card comprising: an availability determining unit that notifies an application program of a result of determination as to whether or not the availability is possible by the availability determining unit. 2. The network card according to claim 1, further comprising an API for determining whether or not an application program interface (API) can be used so that an application program can determine whether or not an application program interface (API) can be used. . The network card according to claim 1, further comprising an availability determination API corresponding to each API so that the application program knows whether or not the application program interface (API) can be used.

Images