JP2005267447A - Image forming apparatus and image forming method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an image forming apparatus capable of using a plurality of image forming processing from various applications, which includes an interface adapted so that a change in the image forming processing does not affect the development of the various applications. <P>SOLUTION: The image forming apparatus comprises an application performing image forming processing and operating as a first process; a control service performing management of hardware resources used in the image forming process and operating as a second process; and a process-to-process communication means making the communication between the first process and the second process executable by a function call. The process-to-process communication means has two or more versions, and provides a corresponding function for each function changed from the old version to the first process. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention has an interface in which a plurality of image forming processes can be used from various applications so that the change of the plurality of image forming processes does not affect the development of the various applications. An image forming apparatus is provided.

  2. Description of the Related Art In recent years, an image forming apparatus in which functions of devices such as a printer, a copy, a facsimile, and a scanner are housed in a single casing is generally known. Such a composite-type image forming apparatus is provided with a display unit, a printing unit, an imaging unit, and the like in one casing, and three types of applications corresponding to a printer, a copy unit, and a facsimile device, respectively. The apparatus is operated as a printer, a copy, a scanner, or a facsimile apparatus.

  In the image forming apparatus, various information processing is executed by various programs such as applications and platforms. These programs are usually stored in these devices before the shipment of these devices, but these programs can be input to these devices using a memory card after the shipment of these devices. It is also possible to do. For example, a memory card for inputting these programs to these devices is distributed from the manufacturer to the vendor, the vendor creates these programs, and the user uses these memory cards for these devices. It is now possible to build a business model that can be input.

  However, the program provided to the image forming apparatus by the memory card as described above has a problem that the program must be corrected according to the program development of the image forming apparatus. Alternatively, even if the program realizes the same operation, various types must be prepared according to the version of the program incorporated in the image forming apparatus.

  Accordingly, an object of the present invention is to provide an image forming apparatus in which development of various programs incorporated in the image forming apparatus does not affect programs provided by a memory card or the like.

  In order to solve the above-described problems, the present invention, as described in claim 1, performs an image forming process and manages an application that operates as a first process and hardware resources used in the image forming process. And a control service that operates as a second process, and an inter-process communication unit that enables communication between the first process and the second process by a function call. And a function corresponding to each function changed from the previous version is provided to the first process.

  In such an image forming apparatus, it is possible to prevent an existing application from being influenced by, for example, a change in the specification of the control service.

  As means for solving the above problems, the present invention may be a program for causing a computer to perform processing in the image forming apparatus.

  According to the present invention, in an image forming apparatus that allows a plurality of image forming processes to be used from various applications, the change of the plurality of image forming processes is prevented from affecting development of the various applications. Can do.

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

  FIG. 1 shows a compound machine 101 corresponding to an embodiment of the present invention. The compound machine 101 shown in FIG. 1 includes various hardware 111, various software 112, and a compound machine starting unit 113. The MFP 101 shown in FIG. 1 can function as a copy, a printer, a scanner, or a facsimile.

  As the hardware 111 of the multi-function peripheral 101, there are an imaging unit 121, a printing unit 122, and other hardware 123.

  The imaging unit 121 is hardware for reading an image (image data) from a document, and is used when functioning as a copy, a scanner, or a facsimile. The imaging unit 121 may be a monochrome image or a color image. The imaging unit 121 includes a document setting unit and the like as a mechanism related to a document.

  The printing unit 122 is hardware for printing an image (image data) on a printing medium such as printing paper, and is used when functioning as a copy, a printer, or a facsimile. The printing unit 122 may be a monochrome image or a color image. Here, the printing unit 122 employs an electrophotographic system, and includes a photoreceptor, a charging machine, an exposure machine, a developing machine, a transfer machine, a fixing machine, and the like. The printing unit 122 includes a paper feeding unit, a paper discharge unit, a printing paper conveyance mechanism, and the like as mechanisms relating to printing paper and the like.

  The other hardware 123 will be described with reference to FIG.

  As the software 112 of the multi-function peripheral 101, there are various applications 131 and various platforms 132. These programs are executed in parallel on a process basis by an OS (Operating System) such as UNIX (registered trademark).

  The application 131 is software for executing information processing unique to functions such as copying, a printer, a scanner, and a facsimile. The application 131 includes a copy application 141 that is a copy application, a printer application 142 that is a printer application, a scanner application 143 that is a scanner application, a facsimile application 144 that is a facsimile application, and a network. There is a network file application 145 that is an application for a file. The network file application 145 includes a Web browser for browsing HTML documents and the like, and Web server software for distributing HTML documents and the like.

  The application 131 can be developed using a dedicated SDK (software development kit). An application 131 developed using the SDK is called an SDK application. As the dedicated SDK, “CSDK” for developing the application 131 in C language and “JSDK” for developing the application 131 in Java (registered trademark) language are provided. An application 131 developed using CSDK is called a “CSDK application”, and an application 131 developed using JSDK is called a “JSDK application”. The MFP 101 in FIG. 1 also has a CSDK application 146 and a JSDK application 147. 1 further includes a JSDK platform 148 as software 112 that mediates between the JSDK application 147 written in the Java (registered trademark) language and the other software 112 written in the C language. Hereinafter, the SDK application 149 is collectively referred to.

  The platform 132 is software for executing information processing related to a processing request from the application 131. In order to receive a processing request from the application 131, an application program interface (API) 133 that receives the processing request by a predefined function is used, and an engine interface 134 is used to implement the request content. As the platform 132, various control services 151, a system resource manager 152, and various handlers 153 exist.

  The control service 151 interprets the processing request from the application 131 and generates a hardware 111 acquisition request according to the interpretation result. The control service 151 includes a network control service (NCS) 161, a facsimile control service (FCS) 162, a delivery control service (DCS) 163, an engine control service (ECS) 164, a memory control service (MCS) 165, , An operation panel control service (OCS) 166, a certification control service (CCS) 167, a user directory control service (UCS) 168, and a system control service (SCS) 169.

  The process of the NCS 161 performs mediation for performing data communication via a network or the like. The FCS 162 process provides an API for performing image data communication, image data reading, image data printing, and the like as a facsimile. The process of DCS 163 performs control related to the distribution of document data stored in the multifunction peripheral 101. The process of the ECS 164 performs control related to engine units such as the imaging unit 121 and the printing unit 122. The process of the MCS 165 performs control related to a memory and a hard disk drive such as image data storage and image data processing. The process of the OCS 166 performs control related to the operation panel. The process of the CCS 167 performs control related to authentication processing and billing processing. The process of the UCS 168 performs control related to management of user information. The process of the SCS 169 performs control related to system management.

  The system resource manager (SRM) 152 arbitrates the acquisition request of the hardware 111 and performs control for implementing the request content according to the arbitration result. Specifically, the process of the SRM 152 determines whether or not the hardware 111 related to the acquisition request is usable (whether or not it conflicts with other acquisition requests), and if so, indicates that fact. Notify each process of the control service 151. Furthermore, a use schedule of the hardware 111 related to the acquisition request is created, and control is performed to implement the request contents according to the creation result.

  The handler 153 manages the hardware 111 according to the arbitration result. The handler 153 includes a facsimile control unit handler (FCUH) 171 and an image memory handler (IMH) 172. The FCUH 171 manages the facsimile control unit. The IMH 172 allocates memory to each process and manages the memory allocated to each process.

  A virtual application service (VAS) 135 exists as software 112 that mediates between the application 131 and the platform 132. The VAS 135 operates as a server process using the application 131 as a client, and also operates as a client process using the platform 132 as a server. The VAS 135 has a wrapping function that hides the platform 132 when viewed from the application 131, and plays a role of absorbing version differences associated with version upgrades of the platform 132.

  The MFP starter 113 is executed first when the MFP 101 is turned on. As a result, an OS such as UNIX (registered trademark) is activated, and the application 131 and the platform 132 are activated. These programs are stored in the hard disk drive or the memory card, and are reproduced from the hard disk drive or the memory card and activated in the memory.

  FIG. 2 is a hardware configuration diagram according to the MFP 101 of FIG. The hardware 111 of the multi-function peripheral 101 includes a controller 201, an operation panel 202, a facsimile control unit (FCU) 203, an imaging unit 121, and a printing unit 122. Each component excluding the imaging unit 121 and the printing unit 122 corresponds to “other hardware 123” in FIG.

  The controller 201 includes a CPU 211, an ASIC 212, an NB (North Bridge) 221, an SB (South Bridge) 222, a MEM-P (System Memory) 231, a MEM-C (Local Memory) 232, and an HDD (Hard Disk Drive). ) 233, a memory card slot 234, a NIC (Network Interface Controller) 241, a USB device 242, an IEEE 1394 device 243, and a Centronics device 244.

  The CPU 211 is an IC for executing various information processing, and executes the application 131 and the platform 132 in parallel on a process basis by an OS such as UNIX (registered trademark). The ASIC 212 is an image processing IC. The NB 221 is a bridge for connecting the CPU 211 and the ASIC 212. The SB 222 is a bridge for connecting the NB 221 and peripheral devices. The ASIC 212 and the NB 221 are connected via an AGP (Accelerated Graphics Port).

  The MEM-P 231 is a memory connected to the NB 221. The MEM-C 232 is a memory connected to the ASIC 212. The HDD 233 is a storage connected to the ASIC 212, and is used for image data accumulation, document data accumulation, program accumulation, font data accumulation, form data accumulation, and the like. The memory card slot 234 is a slot connected to the SB 222 and is used for setting (inserting) the memory card 235.

  The NIC 241 is a controller for performing data communication using a MAC address or the like via a network or the like. The USB device 242 is a device for providing a serial port compliant with the USB standard. The IEEE 1394 device 243 is a device for providing a serial port conforming to the IEEE 1394 standard. The Centronics device 244 is a device for providing a parallel port conforming to the Centronics specification. The NIC 241, the USB device 242, the IEEE 1394 device 243, and the Centronics device 244 are connected to the NB 221 and the SB 222 via a PCI (Peripheral Component Interconnect) bus.

  The memory card slot 251 is a slot used by being connected to the SB 222, and is a slot for setting (inserting) the memory card 261.

  The operation panel 202 is hardware (operation unit) for an operator to input to the multifunction machine 101 and hardware (display unit) for the operator to obtain an output from the multifunction machine 101. The operation panel 202 is connected to the ASIC 212. The FCU 203, the imaging unit 121, and the printing unit 122 are connected to the ASIC 212 via a PCI (Peripheral Component Interconnect) bus.

  An outline of processing when the SDK application 149 performs scanning in the multi-function peripheral 101 having such a functional configuration and hardware configuration will be described with reference to FIG. FIG. 3 is a diagram for explaining an outline of processing when the SKD application scans.

  In FIG. 3, the VAS 135 is initialized (step S1), and the SDK application registers the application in the VAS (step S2). The image library is initialized (step S3). A scan instruction is issued to the image library (step S4), and scanning is performed (step S5).

  Such a process can be realized by, for example, a program code as shown in FIG.

FIG. 4 is a diagram illustrating an example of a program code of the SDK application. In FIG.
For example, when VASV2 is an old version and VASV3 is a new version, a new version of VASV3 is designated by a code 30 indicating "#define USE_VAS3".

  VASV3 is initialized by a code 31 indicating “apliID = sdkVasInit (eventCallBackFunc);”. This corresponds to step S1 in FIG.

Since the new version of VASV3 is specified, the function of VASV3 is executed by the code 33. The code 33 is, for example,
VAS_HANDLE handle;
handle = sdkSysApliExtRegistGetHandle ();
sdkSysApliExtRegistSetSdkApliId (handle, apliID);
sdkSysApliExtRegist (handle);
sdkSysApliExtRegistRelHandle (handle);
As shown. When registering an application in the new version of VASV3, a new function of VAS135 is designated by a function. By providing the functions in this way, even if the SDK application 149 is mounted on the newer VAS 135, the VAS 135 and the SDK application 149 can operate without any trouble.

  The code 33 secures a handle for each application interface, and uses the handle to set a parameter and call a function. Thereafter, a process for releasing the handle is performed.

  On the other hand, if an old version of VASV2 is specified, an apliID for identifying the SDK application 149 is registered by the code 32 indicating “rmSysApliRegist (apliID);” by the process of the old version of VASV2. Conventionally, in order to correspond to the new function of the VAS 135, for example, it has been necessary to change the program code such that an argument must be added in addition to the apliID. When the arguments are different in different versions, there arises a problem that the VAS 135 does not operate normally or the SDK application 149 does not operate normally.

  When the VAS 135 gives a new function as a function, and when the SDK application 149 uses a new version, it is always operated regardless of the combination of the version of the SDK application 149 and the VAS 135 by describing like the code 33. Can be possible.

  The codes 32 and 33 correspond to step S2 in FIG.

  The code 34 indicating “image_library_init ();” is used for initialization for mail communication and the library processing unit is started as a thread. This corresponds to step S3 in FIG. Then, a scan command is issued to the thread by using a mail with a code 35 indicating “scanStart ();”, and a scanning operation is executed. This corresponds to steps S4 and S5 in FIG.

Thereafter, an event for the operation executed by scanStart () is received by the code 36, and the handle that has notified the event is released. The code 36 is, for example,
while (1) {
/ * Processing of events received by defaultHandler () * /
recieveMail (eventID, handle);
switch (eventID) {
case SDK_SYS_PARAM:
if (SDK_LANG_JP! = sdkSysParamGetLanguage (handle))
exit (1);
sdkSysParamRelHandle (handle);
break;
}
}
It is described as follows.

Further, code 37 shows a default handler that first receives events from ECS 164, MCS 165, SCS 169, and the like. The code 37 is, for example,
defaultHandler (short eventID, int handle) {
sendMail (eventID, handle);
}
It is described as follows.

  This default handler is a function notified by the initialization of VASV3. The SDK 149 performs application registration with the apliID assigned to the notified default handler.

  Next, a sequence flow when the program code as shown in FIG. 4 is executed will be described with reference to FIG. FIG. 5 is a diagram showing a sequence flow. In FIG. 5, the SDK application 149, the ECS 164, the MCS 165, the SCS 169, and the like are processes. An ipc (Internal Process Communication) is provided as an application interface that enables a function call to such a process and notifies an event.

  In FIG. 5, before describing the sequence flow, the functional configuration of the VAS 135 will be described. The VAS 135 includes an image library 135a, a VASV2 library 135b, and VASV3.

  The image library 135a is a library for supplying a highly functional API to an application with a high degree of use difficulty. For example, in response to one function call from the SDK application 149, the image library 135a performs a series of operations on the VASV2 library on behalf of the SDK application 149, and an event for the plurality of series of operations. Is processed multiple times in place of the SDK application 149. Then, at the end of the series of operations, the SDK application 149 is notified of one event. The event to be notified to the SDK application 149 is a state relating to the operation, for example, the scanning operation is normally completed, the cover is opened during the scanning, the door of the MFP is opened during the copying, or the paper jam occurs. Notice.

  The VASV2 library 135b is a library for converting a function call to the old version of the VAS 135 into a function call to the new version of the VAS 135. The VASV 3135c is a processing unit in which a new version of the VAS 135 is installed.

  The SDK application 149 as a client performs a function call to the ECS 164, MCS 165, and SCS 169 as a server, and notifies the SDK application 149 as a client from the ECS 164, MCS 165, and SCS 169 as a server by an event. Implemented. Since the SDK application 149, the ECS 164, the MCS 165, and the SCS 169 are processes, the function call and the event notification are performed via the interface ipc.

  The VASV 3135c receives (1) an event acquisition request from the SDK application 149 to the image library 135a, (2) a function call to the old version VAS 135 (VASV 2 library 135b), and (3) a new version VAS 135 (VASV 3135c). Corresponds to the function call.

  In FIG. 5, since the application registration of the SDK application 149 is the same as that of the old version, apparently a function call is made to the VASV2 via the interface ipc (a11), and the VASV2 library 135b is actually the new version of the VASV3135c. (A3).

  For example, when the SDK application 149 issues a scan instruction as an operation instruction, it issues a scan command (message) to the thread of the VASV2 library 135b (a1). The VASV2 library 135b makes a function call to the VASV2 library 135b via the interface ipc (a2). The VASV2 library 135b makes a function call to the VASV3135c via the interface ipc (a3). The VASV 3135c causes the ECS 164, the MCS 165, the SCS 168, etc. to execute an operation by a function call via the interface ipc (a4).

  When an event related to operation occurs, the ECS 164, MCS 165, SCS 168, and the like notify the event via the interface ipc. The event is notified by calling the callback function (defaulHandler) of the SDK 149 (b1). When the event is notified as sendMail by the callback function (defaulHandler), the VASV 3135c notifies the VASV2 library 135b of the event as VASV3 mail via the interface ipc (b2).

  The VASV2 library 135b receives a plurality of events for a series of operations in response to a single operation instruction from the SDK application 149 as a VASV2 mail, and an event indicating a final operation result as an VASV2 mail SDK via the interface ipc. The application 149 is notified (b4). On the other hand, the SDK application 149 separately receives a plurality of events corresponding to the series of operations as VASV2 mail via the interface ipc, which is necessary for the control for presenting information regarding the operation to the operation panel 202 (b41). ). For example, in the event from the image library 135a, the final operation state such as “the door has been opened” or “paper jam has occurred” is notified (b4). In the event from the VASV2 library 135b, “the door has been opened”. If it is “If”, the information specifying the door is notified, and if “Paper jam has occurred”, the information specifying the location where the paper jam has occurred is notified.

  Thus, the communication paths a1, a2, a11, b3, and b41 are portions corresponding to the old version. Since the specifications of the old version are absorbed by the VASV2 library 135b, the SDK application 149 corresponding to the specifications of the old version does not need to be modified according to changes in the ECS 164, the MCS 165, the SCS 168, and the like.

  Also, the SDK application 149 corresponding to the new version can use the specifications of the old version as they are. In particular, when an operation instruction is issued using the image library 135a, the communication path is as described above.

  Further, when the SDK application 149 corresponding to the new version uses a function specific to the new version, the function is directly called to the VASV 3135c via the interface ipc (a12). That is, the VAS 135 does not affect the SDK application 149 when new functions increase by providing new functions to the SDK application 149 using individual functions.

  When a function call is made directly to the VASV 3135c (a12), the event is notified from the VASV2 library 135b to the SDK application 149 as a VASV3 mail (b42).

  Next, event processing will be described with reference to FIG. FIG. 6 is a diagram for explaining event processing. The processing in FIG. 6 shows a flow of processing the event of the code 36 by starting the defaultHander of the code 37 shown in FIG.

  In FIG. 6, when the data 21 regarding the operation is notified by the callback function (defaultHandler) of the SDK application 149 from the ECS 164, the MCS 165, the SCS 169, etc. (Steps S101 and S102), the memory for storing the data 21 is allocated. The corresponding handle No. is acquired from the event table 29 (step S103). A VASV3 event is generated (step S104), and the event is issued as a VASV3 mail by sendMail (step S105). The message data 22 includes an event ID that identifies the event and a handle No.

  The SDK application 149 reads the issued event by making a function call to readMial (step S106). Using the acquired handle number as an argument, the VASV 3135c is requested to acquire data (step S107). The VASV 3135c refers to the event table 29, extracts the data 21 from the data address corresponding to the handle No., and notifies the SDK application 149 (step S109). Thereafter, the handle of the data 21 is released by a function call from the SDK application 149.

  As described above, two or more versions of the VAS 135 accompanying the change of the platform 132 can be function-called from the application 131 operating as a process (for example, the SDK application 149 developed by a vendor or the like) via the interface ipc. In addition, by giving function additions by individual functions, and by converting to function calls of the new version (VASV3135c), the effect of the platform 132 change on the application 131 corresponding to the old version In addition, the application 131 corresponding to the new version can also be supported.

  In other words, the existing SDK application 149 can be operated without changing the binary code corresponding to the compiled old version.

  According to the present invention, application program development can be prevented from being affected by, for example, a change in inter-process communication accompanying a change in image forming processing.

It is a figure showing the compound machine 101 applicable to the Example of this invention. FIG. 2 is a hardware configuration diagram according to the multifunction machine 101 of FIG. 1. It is a figure for demonstrating the process outline | summary in case an SKD application scans. It is a figure which shows the example of the program code of an SDK application. It is a figure which shows a sequence flow. It is a figure for demonstrating the process of an event.

Explanation of symbols

DESCRIPTION OF SYMBOLS 101 Compound machine 111 Hardware 112 Software 113 Compound machine starting part 121 Imaging part 122 Printing part 123 Other hardware 131 Application 132 Platform 133 Application program interface 134 Engine interface 135 Virtual application service 135a Image library 135b VASV2 library 135c VASV3
141 Copy application 142 Printer application 143 Scanner application 144 Facsimile application 145 Network file application 146 CSDK application 147 JSDK application 148 JSDK platform 149 SDK application 151 Control service 152 System resource manager 153 Handler 161 Network control service 162 Facsimile control service 164 Engine control service 165 Memory control service 166 Operation panel control service 167 Certification control service 168 User directory control service 169 System control service 171 Faximi Re-control unit handler 172 Image memory handler 201 Controller 202 Operation panel 203 Facsimile control unit 211 CPU
212 ASIC
221 NB
222 SB
231 MEM-P
232 MEM-C
233 HDD
234 Memory card slot 235 Memory card 241 NIC
242 USB device 243 IEEE 1394 device 244 Centronics device

Claims (20)

An application that performs image formation processing and operates as the first process;
Management of hardware resources used in the image forming process, a control service that operates as a second process,
Inter-process communication means for enabling communication between the first process and the second process by a function call;
The inter-process communication means has two or more versions, and provides functions corresponding to individual functions changed from the previous version to the first process.   2. The image according to claim 1, wherein the inter-process communication means includes conversion means for converting a function call by a function provided to the first process by the old version into a function call to a new version. Forming equipment.   The image forming apparatus according to claim 1, wherein the inter-process communication unit notifies an event from the second process to the first process by a callback function registered by the application. The inter-process communication means notifies the event from the second process to the first process by a mail transmission function,
The image forming apparatus according to claim 1, wherein the application acquires the event by a mail reception function.   The inter-process communication means notifies the first process of the execution result of the processing by the event when the first process instructs the processing of the valid old version by the function call of the old version. The image forming apparatus according to claim 1, wherein the image forming apparatus is an image forming apparatus.   When the first process instructs the processing of the new version by the function call of the new version, the inter-process communication means notifies the first process of the result of executing the processing by the event. The image forming apparatus according to claim 1.   The image forming apparatus according to claim 1, wherein the application is provided from outside by a memory card. A memory card used in the image forming apparatus according to claim 1,
A computer for controlling the image forming apparatus;
The procedure for registering an application by specifying a callback function to get the event,
Procedures for performing operations related to image formation by function calls;
A procedure for acquiring data relating to an event corresponding to the function call;
A memory card storing a computer-executable program for executing a procedure that operates as the callback function. In an image forming method for performing image forming processing by an application,
An inter-process communication procedure that enables communication between a first process of the application and a second process of a control service that manages hardware resources used in the image forming process by a function call;
The inter-process communication procedure performs processing according to two or more versions, and executes each function changed from the previous version by the first process by a function call.   10. The inter-process communication procedure includes a conversion procedure for converting into a function call to a new version when a function call corresponding to the old version is made from the first process. Image forming method.   11. The image forming method according to claim 9, wherein the inter-process communication procedure notifies an event from the second process to the first process by a callback function registered by the application. The inter-process communication procedure notifies an event from the second process to the first process by a mail transmission function,
12. The image forming method according to claim 9, wherein the application acquires the event by a mail reception function.   In the inter-process communication procedure, when the first process instructs the processing of the old version that is valid by the function call of the old version, the first process is notified of the result of executing the processing by the event. The image forming method according to claim 9, wherein the image forming method is an image forming method.   In the inter-process communication procedure, when the first process instructs the processing of the new version by the function call of the new version, the result of executing the processing is notified to the first process by the event. The image forming method according to any one of claims 9 to 13. In a program for causing a computer to perform processing in an image forming method for performing image forming processing by an application,
An inter-process communication procedure that enables communication between a first process of the application and a second process of a control service that manages hardware resources used in the image forming process by a function call;
The computer-executable program, wherein the inter-process communication procedure performs processing according to two or more versions, and executes each function changed from the previous version by the first process by a function call.   16. The inter-process communication procedure includes a conversion procedure for converting into a function call to a new version when a function call corresponding to the old version is made from the first process. A computer executable program.   The computer-executable program according to claim 15 or 16, wherein the inter-process communication procedure notifies an event from the second process to the first process by a callback function registered by the application. . The inter-process communication procedure notifies an event from the second process to the first process by a mail transmission function,
The computer-executable program according to any one of claims 15 to 17, wherein the application acquires the event by a mail reception function.   In the inter-process communication procedure, when the first process instructs the processing of the old version that is valid by the function call of the old version, the first process is notified of the result of executing the processing by the event. The image forming method according to claim 15, wherein the image forming method is an image forming method.   In the inter-process communication procedure, when the first process instructs the processing of the new version by the function call of the new version, the result of executing the processing is notified to the first process by the event. The image forming method according to any one of claims 15 to 19.

Images