JP2007207267A - Request management device, image forming device, job processing instruction method, and job processing instruction program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To unitarily and efficiently receive and manage requests of different kinds of jobs. <P>SOLUTION: A request management part 113a manages the requests by performing object modelling as the analogy of a so-called "folder-file" model and having a request folder class 310, a request class 320, and a request specification class 330. Moreover, the request management part 113a manages the result objects of the requests by having a result object class 340 and a result object specification class 350. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention provides a request management apparatus, an image forming apparatus, and a job process for instructing execution of a job that responds to a job processing request and managing each job processing request as a request when a job processing request by a user operation is received The present invention relates to an instruction method and a job processing instruction program.

  2. Description of the Related Art Conventionally, there has been known a multi-function machine in which a plurality of functions such as a printer, a copy, and a scanner are stored in a single casing. In such a multifunction device, a plurality of applications called a printer application, a copy application, and a scanner application are mounted on a general-purpose OS such as UNIX (registered trademark), and a plurality of functions are realized while switching execution processes of these applications. It was.

  However, since the printer application, the copy application, and the scanner application perform engine control, memory control, system control, and the like separately, waste of duplication processing occurs.

  For this reason, in Patent Document 1, the applications such as engine control, memory control, and system control, which have been performed by a plurality of applications installed in the multifunction peripheral, are grouped from each application as a common processing part (platform). The development efficiency is improved.

JP 2002-084383 A

  However, according to Patent Document 1, although processing after job generation is made common, management of job processing requests (hereinafter referred to as “requests”) and the like are separately performed in each application, so that composite processing is performed. There is room for improvement in slimming down on-board applications. Note that “job” refers to an execution unit of processing until creation of a product is completed, and indicates from the start of input to the end of output of the entire MFP. In addition, a series of document bundle reading processes and a series of printing processes may be referred to as “jobs”.

  For example, when a copy application installed in a multifunction peripheral receives a copy request, it instructs the common processing part (platform) to execute a job corresponding to the request and manages the request. However, the same job execution instruction and request management are performed for the printer application.

  For this reason, it is desirable to perform centralized management of requests, but since this request is a stage before a job that can be managed centrally is generated, the common processing part of Patent Document 1 corresponds to this request. It is impossible. This is because if the same specification restriction as that of the job is added to this request, the multi-function peripheral cannot respond to the new request.

  For these reasons, it has become a major issue how to efficiently manage requests to applications installed in multifunction peripherals. Note that such a problem does not arise only for the multi-function peripheral, and similarly occurs when, for example, a multi-function server device having a plurality of server functions for executing different jobs is formed.

  The present invention has been made to solve the above-described problems caused by the prior art, and is a request management apparatus, an image forming apparatus, which can receive and manage requests for different jobs in a centralized and efficient manner, It is an object to provide a job processing instruction method and a job processing instruction program.

  In order to solve the above-described problems and achieve the object, the invention according to claim 1 is configured to instruct execution of a job in response to a job processing request when receiving a job processing request by a user operation. A request management apparatus that manages a job processing request as a request, a request unit that instructs execution of a job according to the request, a request specification holding unit that holds detailed specifications of the request unit, the request unit, The request specification holding unit includes a request storage unit for managing a folder.

  According to the first aspect of the present invention, the request class for instructing the execution of the job according to the request, the request specification class for holding the detailed specifications of the request means, and the request folder class for managing these classes as a folder are provided. Therefore, it is possible to receive and manage requests for different jobs in a centralized and efficient manner.

  The invention according to claim 2 is characterized in that, in the invention according to claim 1, the request means corresponds to the request specification holding means on a one-to-one basis, and holds link information to the request specification holding means. To do.

  According to the invention of claim 2, the request class and the request specification class correspond one-to-one, and the request class holds link information to the corresponding request specification class. Information can be associated and managed.

  The invention according to claim 3 is the invention according to claim 1 or 2, wherein the request unit is managed by the request storage unit with the request storage unit as a parent of a tree structure.

  According to the third aspect of the present invention, since the request folder class is set as the parent of the tree structure and the request class is managed by the request folder class, the requests can be managed efficiently in an integrated manner.

  According to a fourth aspect of the present invention, in the first, second, or third aspect of the invention, the request unit acquires and holds an execution state of a job corresponding to the request unit.

  According to the fourth aspect of the present invention, since the request class performs acquisition and holding of the execution state of the corresponding job, the execution state of the job can be managed efficiently.

  According to a fifth aspect of the present invention, in the first to fourth aspects of the invention, when the request storage unit receives a job processing request by a user operation, the request storage unit generates a request unit according to the type of the user operation. It is characterized by that.

  According to the invention of claim 5, when a job processing request is received by a user operation, the request folder class generates a request class object corresponding to the type of the user operation. Requests can be managed efficiently.

  According to a sixth aspect of the present invention, in the first to fifth aspects of the invention, the request storage unit has a limit number of job processing requests that can be accepted and the number of generated request units, and a difference between these numbers. The job processing request acceptability determination process is performed based on the above.

  According to the sixth aspect of the present invention, there is a limit number of job processing requests that can be accepted and the number of objects of the generated request class, and a job processing request acceptance determination process is requested based on the difference between these numbers. Since the folder class is to be performed, the request can be efficiently rejected when the processing allowable capacity of the entire apparatus is exceeded.

  According to a seventh aspect of the present invention, in the first to sixth aspects of the present invention, the request specification means defines a request specification that defines the specification of the job processing request, and the request when the request specification cannot be satisfied. And an allowable specification used as a substitute specification of the specification.

  According to the seventh aspect of the present invention, the request specification class has a request specification that defines the specification of the job processing request and an allowable specification that is used as an alternative specification of the request specification when the request specification cannot be satisfied. Therefore, even if the user's desired specification cannot be satisfied, the execution of the job based on the alternative specification can be instructed without canceling the request immediately.

  The invention according to claim 8 is the invention according to claim 7, wherein the desired specification has an input specification and an output specification.

  According to the eighth aspect of the present invention, since the requested specification has the input specification and the output specification, the specification of the input object accompanying the input of the job processing request and the output accompanying the output of the job corresponding to the job processing request Requests can be managed efficiently based on the specification of the object.

  The invention according to claim 9 is the invention according to any one of claims 1 to 8, wherein the deliverable means for managing the progress according to the output deliverable of the job instructed to be executed by the request means, and the request specification holding means Is further provided with product specification holding means for holding the specifications of the output product.

  According to the ninth aspect of the present invention, the product class that manages the progress according to the output product of the job instructed to be executed by the request class, and the specification of the output product among the specifications held by the request specification class Since the product specification class to be held is further provided, the request can be efficiently managed even when there are a plurality of output products corresponding to the job instructed to be executed by the request class.

  The invention according to claim 10 is the invention according to claim 9, wherein the product unit corresponds one-to-one with one or a plurality of output products of the job instructed to be executed by the request unit. And

  According to the tenth aspect of the present invention, since one or a plurality of output deliverables and deliverable classes of the job instructed to be executed by the request class correspond to each other one by one, each output deliverable is managed efficiently. can do.

  According to an eleventh aspect of the present invention, in the invention of the ninth or tenth aspect, the deliverable means includes a progress status of an input material input along with the job processing request and a job corresponding to the job processing request. And the progress status of the product output by the management method as a part of the progress status of the product.

  According to the eleventh aspect of the present invention, the progress status of the input material input in response to the job processing request and the progress status of the product output by the job corresponding to the job processing request are determined as a result of the product progress status. Since it is decided to manage as a department, the progress of each product can be managed efficiently.

  The invention according to claim 12 includes hardware resources such as a display unit, a printing unit, and an imaging unit, and a common processing unit that executes a job related to image formation using the hardware resources, and includes user operations. An image forming apparatus that executes a job responding to the job processing request in the common processing unit and manages each job processing request as a request when the job processing request related to image formation is received. Request means for instructing the common processing unit, request specification holding means for holding detailed specifications of the request means, and request storage means for folder management of the request means and the request specification holding means It is characterized by that.

  According to the invention of claim 12, the request class for instructing the execution of the job according to the request, the request specification class for holding the detailed specification of the request means, and the request folder class for managing these classes as a folder are provided. Therefore, it is possible to receive and manage requests for different jobs in a centralized and efficient manner.

  According to a thirteenth aspect of the present invention, in the twelfth aspect of the present invention, the request unit is managed by the request storage unit with the request storage unit as a parent of a tree structure.

  According to the thirteenth aspect of the present invention, since the request folder class is a parent of the tree structure and the request class is managed by the request folder class, requests can be managed efficiently in an integrated manner.

  According to a fourteenth aspect of the present invention, in the invention of the twelfth or thirteenth aspect, the request storage unit has a limit number of job processing requests that can be accepted and the number of generated request units, and a difference between these numbers. The job processing request acceptability determination process is performed based on the above.

  According to the fourteenth aspect of the present invention, there is a limit number of job processing requests that can be accepted and the number of objects of the generated request class, and a job processing request acceptance determination process is requested based on a difference between these numbers. Since the folder class is to be performed, the request can be efficiently rejected when the processing allowable capacity of the entire apparatus is exceeded.

  According to a fifteenth aspect of the present invention, in the invention of the twelfth, thirteenth, or fourteenth aspect, the request specification means includes a request specification that defines the specification of the job processing request and the request specification cannot be satisfied. And an allowable specification used as a substitute specification of the desired specification.

  According to the fifteenth aspect of the present invention, the request specification class has a request specification that defines the specification of the job processing request and an allowable specification that is used as an alternative specification of the request specification when the request specification cannot be satisfied. Therefore, even if the user's desired specification cannot be satisfied, the execution of the job based on the alternative specification can be instructed without canceling the request immediately.

  According to a sixteenth aspect of the present invention, in the inventions of the twelfth to fifteenth aspects, deliverable means for managing a progress status according to an output deliverable of a job instructed to be executed by the request means, and the request specification holding means. Is further provided with product specification holding means for holding the specifications of the output product.

  According to the sixteenth aspect of the present invention, the product class that manages the progress status according to the output product of the job that is instructed to be executed by the request class, and the specification of the output product among the specifications held by the request specification class. Since the product specification class to be held is further provided, the request can be efficiently managed even when there are a plurality of output products corresponding to the job instructed to be executed by the request class.

  The invention according to claim 17 is a job processing instruction method for instructing other subsystems to perform job processing in response to a job processing request received from a user. A request specification holding means for generating request specification holding means for holding user request data representing detailed specifications in its own attribute section, a request specification holding means generating step for generating each request, and link information and request reception of the request specification holding means. A request storage means generating step for generating a request storage means for managing the request specification holding means for folder management, holding the possible limit number in its own attribute section, and the request storage means accepting the request As long as you own A determination step of reading out numerical data and determining whether or not a request can be submitted based on whether or not the accepted request exceeds a limit number; and if the determination step determines that the request can be submitted, a job corresponding to the request A request means generation step for generating a request means capable of instructing execution of the request, and a request input by passing the link information of the request specification holding means to the request means generated by the request means generation step. A request specification associating step for causing the computer to execute a request input step, wherein the request means holds the passed link information in its own attribute section, thereby associating the request specification holding means with itself. , The association A request request holding means for requesting the request specification holding means associated with the request to reference the user's desired data held in the attribute section of the request specification holding means. Based on the reference request of the request means, reads out the request data of the user held in its own attribute section, and causes the computer to execute a reference step to be passed to the request means. According to the user request data acquired from the holding means, the computer is caused to execute an instruction step for instructing the other subsystem to start job processing.

  According to the invention of claim 17, the computer generates a request specification object for generating a request specification object for each request, which holds user request data representing the detailed specification of the request received from the user in its own attribute section. A request folder object generation step for generating a request folder object for managing the request specification object in a folder by holding the step (refer to step S1102), the link information of the request specification object and the limit number of requests that can be accepted in its own attribute section When the request folder object accepts the request, it reads out the limit number data possessed by its own attribute section, and whether or not the accepted request exceeds the limit number A determination step for determining whether or not a request can be submitted (see step S1107), and a request for generating a request object that can instruct the execution of a job according to the request when the determination step determines that the request can be submitted An object generation step (see step S1108) and a request input step (see step S1109) in which a request is input by passing link information of a request specification object to the request object generated in the request object generation step The request object associates the request specification object with the request specification object by holding the passed link information in its own attribute section. A step (see step S1110) and a reference requesting step (see step S1111) for requesting reference to user request data held in the attribute section of the request specification object for the request specification object associated in the association step. Based on the request request of the request object, the request specification object reads the request data of the user held in its own attribute section and causes the computer to execute a reference step to pass to the request object. Causes the computer to execute an instruction step (see step S1117) for instructing other subsystems to start job processing in accordance with user request data acquired from the request specification object. With this configuration, it is possible to centrally and efficiently receive and manage requests for different jobs.

  Further, the invention according to claim 18 is the invention according to claim 17, wherein the request unit responds to an output product according to user request data acquired from the request specification holding unit before execution of the instruction step. A deliverable means generating step for generating a deliverable means for managing progress, and a link information providing step for passing link information of the request specification holding means to the deliverable means generated by the deliverable means generating step. The product means is executed by the computer, and the deliverable means includes the deliverables among the user request data held by the request specification holding means in accordance with the user request data acquired from the request specification holding means after execution of the reference step. Product specification holding means for holding user request data according to the means in its own attribute section A product specification holding means generating step to be performed, and a product specification associating step for associating the product specification holding means with itself by holding the passed link information in its own attribute section. It is made to perform.

  According to the invention of claim 18, the request object generates a deliverable object for managing the progress according to the output deliverable in accordance with the user request data acquired from the request specification object before executing the instruction step. Let the computer execute a deliverable object generation step (see step S1113) and a link information provision step (see step S1114) that passes link information of the request specification object to the deliverable object generated by the deliverable object generation step. The deliverable object is the user's request data stored in the request specification object according to the user's request data obtained from the request specification object after executing the reference step. A product specification object generating step (see step S1115) for generating a product specification object that holds desired data in its own attribute section, and holding the passed link information in its own attribute section, the self and the product Since the product specification associating step (see step S1116) for associating with the specification object is configured to be executed by the computer, the progress of each product can be efficiently managed.

  According to a nineteenth aspect of the present invention, there is provided a job processing instruction program for instructing another subsystem to perform job processing in response to a job processing request received from a user. Request specification holding means that is generated based on a request and holds user request data representing the detailed specifications of the request in its own attribute section; link information of the request specification holding means and a limit number of requests that can be accepted The request storage means holds the request specification holding means in the own attribute section when the request storage means accepts the request. Read the limit data, and the received request is limited. A determination step for determining whether or not a request can be submitted depending on whether or not the number exceeds the request number, and a request means capable of instructing execution of a job according to the request when the determination step determines that the request can be submitted A request means generating step for generating, and a request inputting step for inputting a request by passing link information of the request specification holding means to the request means generated by the request means generating step. The request means holds the passed link information in its own attribute section, thereby associating the request specification holding means with the request specification holding means, and the request specification holding means related by the association step. Against , Causing the computer to execute a reference request step for requesting reference of user request data held in the attribute section of the request specification holding means, the request specification holding means based on the reference request of the request means, The user's request data held in its own attribute section is read, and a reference step to be passed to the request unit is executed by the computer, and the request unit is configured according to the user's request data acquired from the request specification holding unit. The computer is caused to execute an instruction step for instructing another subsystem to start job processing.

  According to the nineteenth aspect of the present invention, the computer generates a request specification object which is generated based on a request received from a user and holds user request data representing the detailed specification of the request in its own attribute section, and the request specification. If the request folder object accepts a request in the state that holds the link information of the object and the limit number that can accept the request in its own attribute section and has the request folder object that manages the request specification object in a folder A determination step (see step S1107) that reads out the limit number data possessed in its own attribute section and determines whether or not a request can be input based on whether or not the accepted request exceeds the limit number, and input by the determination step OK If the request object is generated, a request object generation step (see step S1108) for generating a request object capable of instructing execution of a job according to the request, and a request object generated by the request object generation step, By causing the computer to execute a request input step (see step S1109) in which a request is input by passing the link information of the request specification object, the request object holds the passed link information in its own attribute section, A request specification associating step (see step S1110) for associating the request specification object with itself and the request specification object associated in the associating step A request request step (see step S1111) for requesting reference of user request data held in the attribute section of the request specification object is executed by the computer, and the request specification object The user's request data stored in the attribute section is read and the computer executes a reference step to pass to the request object. The request object is sent to other subsystems according to the user's request data obtained from the request specification object. Since the instruction step (see step S1117) for instructing the start of job processing is executed by the computer, requests for different jobs can be received and managed centrally and efficiently.

  According to a twentieth aspect of the present invention, in the nineteenth aspect of the present invention, the request unit responds to an output product according to user request data acquired from the request specification holding unit before executing the instruction step. A deliverable means generating step for generating a deliverable means for managing progress, and a link information providing step for passing link information of the request specification holding means to the deliverable means generated by the deliverable means generating step. The product means is executed by the computer, and the deliverable means includes the deliverables among the user request data held by the request specification holding means in accordance with the user request data acquired from the request specification holding means after execution of the reference step. Product specification holding means for holding user request data according to the means in its own attribute section A product specification holding means generating step to be performed, and a product specification associating step for associating the product specification holding means with itself by holding the passed link information in its own attribute section. It is made to perform.

  According to the twentieth aspect of the present invention, the request object generates a deliverable object that manages the progress according to the output deliverable according to the user request data acquired from the request specification object before executing the instruction step. Let the computer execute a deliverable object generation step (see step S1113) and a link information provision step (see step S1114) that passes link information of the request specification object to the deliverable object generated by the deliverable object generation step. The deliverable object is the user's request data stored in the request specification object according to the user's request data obtained from the request specification object after executing the reference step. A product specification object generating step (see step S1115) for generating a product specification object that holds desired data in its own attribute section, and holding the passed link information in its own attribute section, the self and the product Since the product specification associating step (see step S1116) for associating with the specification object is configured to be executed by the computer, the progress of each product can be efficiently managed.

  The request management apparatus according to claim 1 includes: a request class that instructs execution of a job according to a request; a request specification class that holds detailed specifications of the request class; and a request folder class that manages these classes as a folder. Thus, there is an effect that requests for different jobs can be received and managed centrally and efficiently.

  In the request management apparatus according to claim 2, since the request class and the request specification class correspond one-to-one, and the request class holds link information to the corresponding request specification class. The detailed information can be managed in association with each other.

  Further, the request management apparatus according to claim 3 can manage requests efficiently and centrally because the request management class is a parent of a tree structure and the request class is managed by the request folder class. There is an effect.

  Further, the request management apparatus according to the fourth aspect has an effect that the execution state of the job can be efficiently managed because the request class performs acquisition and holding of the execution state of the corresponding job.

  In the request management apparatus according to claim 5, when a job processing request is received by a user operation, the request folder class generates an object of the request class corresponding to the type of the user operation. There is an effect that job requests can be managed efficiently.

  The request management apparatus according to claim 6 has a limit number of job processing requests that can be accepted and the number of objects of the generated request class, and a job processing request acceptance determination process based on a difference between these numbers. Since the request folder class performs the request, the request can be efficiently rejected when the processing allowable amount of the entire apparatus is exceeded.

  In the request management apparatus according to claim 7, the request specification class includes a request specification that defines the specification of the job processing request and an allowable specification that is used as an alternative specification of the request specification when the request specification cannot be satisfied. Therefore, even if the user's desired specification cannot be satisfied, the execution of the job based on the alternative specification can be instructed without canceling the request immediately.

  In the request management apparatus according to the eighth aspect, since the request specification has the input specification and the output specification, it is possible to output the input corresponding to the input of the job processing request and the job corresponding to the job processing request. There is an effect that the request can be efficiently managed based on the specifications of the accompanying output.

  The request management apparatus according to claim 9 includes a deliverable class that manages a progress status according to an output deliverable of a job instructed to be executed by the request class, and an output deliverable of the specifications held by the request specification class. Since it is further provided with a product specification class that holds specifications, requests can be managed efficiently even if there are multiple output products corresponding to the job that the request class instructs to execute. There is an effect.

  In the request management apparatus according to claim 10, since one or a plurality of output deliverables and deliverable classes of the job instructed to execute by the request class correspond to each other one by one, each output deliverable is efficiently The effect is that it can be managed well.

  In addition, the request management apparatus according to the eleventh aspect of the present invention is configured to determine the progress of an input material that is input along with a job processing request and the progress status of a product output by a job corresponding to the job processing request. Since management is performed as part of the situation, the progress of each deliverable can be managed efficiently.

  An image forming apparatus according to claim 12 includes a request class that instructs execution of a job according to a request, a request specification class that holds detailed specifications of the request class, and a request folder class that manages these classes in a folder Therefore, it is possible to receive and manage requests for different jobs in an integrated and efficient manner.

  Further, the image forming apparatus according to claim 13 can manage requests centrally and efficiently because the request management class is a parent of a tree structure and the request class is managed by the request folder class. There is an effect.

  The image forming apparatus according to claim 14 has a limit number of job processing requests that can be accepted and the number of objects of the generated request class, and a job processing request acceptance determination process based on a difference between these numbers. Since the request folder class performs the request, the request can be efficiently rejected when the processing allowable amount of the entire apparatus is exceeded.

  According to a fifteenth aspect of the present invention, a request specification class includes a request specification that defines a specification of a job processing request and an allowable specification that is used as an alternative specification of the request specification when the request specification cannot be satisfied. Therefore, even if the user's desired specification cannot be satisfied, the execution of the job based on the alternative specification can be instructed without canceling the request immediately.

  According to a sixteenth aspect of the present invention, there is provided an image forming apparatus comprising: a deliverable class that manages a progress state according to an output deliverable of a job that is instructed to execute by a request class; Since it is further provided with a product specification class that holds specifications, requests can be managed efficiently even if there are multiple output products corresponding to the job that the request class instructs to execute. There is an effect.

  According to another aspect of the present invention, there is provided a job processing instruction method in which a computer generates a request specification object for each request, which holds user request data representing detailed specifications of a request received from a user in its own attribute section. Specification object generation step (see step S1102), request specification object link information, and the request folder object that holds the limit number of requests that can be accepted in its own attribute section and generates a request folder object for folder management of the request specification object If the request folder object accepts the request, the request folder object reads the limit number data possessed by its own attribute section, and the accepted request is A determination step (see step S1107) for determining whether or not a request can be submitted depending on whether or not the request is exceeded, and a request capable of instructing execution of a job according to the request when the determination step determines that the request can be submitted A request object generation step (see step S1108) for generating an object, and a request input step (see step S1109) in which a request is input by passing link information of a request specification object to the request object generated in the request object generation step. ) Is executed by the computer, and the request object maintains the passed link information in its own attribute section, thereby associating itself with the request specification object. The reference specification step (see step S1110) and the request requesting step for requesting the request specification object associated in the association step to refer to the user request data held in the attribute section of the request specification object (see step S1111). The request specification object reads the user's desired data held in its own attribute section based on the request request of the request object, and causes the computer to execute a reference step to pass to the request object. The request object uses an instruction step (see step S1117) for instructing other subsystems to start job processing in accordance with user request data acquired from the request specification object. This is advantageous in that requests for different jobs can be received and managed centrally and efficiently.

  The job processing instruction method according to claim 18 is a deliverable object for managing a progress state according to an output deliverable in accordance with user request data acquired from a request specification object before the execution of an instruction step. A product object generation step (see step S1113) for generating a link information providing step (see step S1114) for passing link information of a request specification object to the product object generated by the product object generation step. The deliverable object is the deliverable object among the user request data held by the request specification object in accordance with the user request data acquired from the request specification object after executing the reference step. A product specification object generation step (see step S1115) that generates a product specification object that holds user request data according to the user's own attribute section, and holds the passed link information in its own attribute section, Since the product specification associating step (see step S1116) for associating the self with the product specification object is configured to be executed by the computer, the progress of each product can be efficiently managed. .

  According to a nineteenth aspect of the present invention, there is provided a job processing instruction program including: a request specification object that is generated based on a request received from a user, and that stores user request data representing detailed specifications of the request in its own attribute section; The request folder object accepts the request with the request specification object link information and the limit number that can accept the request in its own attribute section and the request folder object that manages the request specification object in a folder. If so, a determination step (see step S1107) of reading the limit number data possessed by its own attribute section and determining whether or not the request can be input depending on whether or not the accepted request exceeds the limit number; If it is determined that the job can be submitted in steps, a request object generation step (see step S1108) that generates a request object that can instruct execution of a job according to the request, and a request object generated in the request object generation step In response to the request, the request execution step (see step S1109) for inputting the request by passing the link information of the request specification object is executed by the computer, and the request object holds the received link information in its own attribute section. By doing so, the request specification associating step (see step S1110) for associating the self with the request specification object, and the request specification associating at the associating step. The computer is caused to execute a reference request step (see step S1111) for requesting the object to refer to the user's desired data held in the attribute section of the request specification object. Based on the user's request data stored in its own attribute section and let the computer execute a reference step to pass to the request object. Since the computer is configured to execute an instruction step (see step S1117) for instructing the subsystem to start job processing, it is possible to receive and manage requests for different jobs in a centralized and efficient manner. There is an effect that can.

  The job processing instruction program according to claim 20 is a deliverable object that manages a progress state according to an output deliverable in accordance with user request data acquired from a request specification object, before the request object is executed. A product object generation step (see step S1113) for generating a link information providing step (see step S1114) for passing link information of a request specification object to the product object generated by the product object generation step. After the reference step is executed, the deliverable object is stored in the request object in the user request data held by the request specification object according to the user request data acquired from the request specification object. A product specification object generation step (see step S1115) for generating a product specification object that holds user request data corresponding to the project in its own attribute section, and holds the passed link information in its own attribute section. Thus, the configuration is such that the product specification associating step (see step S1116) for associating the self with the product specification object is executed by the computer, so that the progress of each product can be efficiently managed. Play.

  Exemplary embodiments of a request management apparatus, an image forming apparatus, a job processing instruction method, and a job processing instruction program according to the present invention are explained in detail below with reference to the accompanying drawings. In this embodiment, the case where the present invention is applied to an image forming apparatus will be described. However, the present invention is not limited to this and can be applied to various apparatuses that perform request management.

  First, the concept of an image forming apparatus (hereinafter referred to as “multifunction machine”) 1 according to the present embodiment will be described with reference to FIGS. 1, 2, 3, 16 and 17. FIG. 1 is a network diagram for explaining a network environment surrounding the MFP 1 according to the present embodiment, and FIG. 2 is a block diagram showing a hardware configuration of the MFP 1 shown in FIG. FIG. 3 is an explanatory diagram for explaining the relationship between software and hardware of the multifunction device 1 shown in FIG. 1, and FIG. 16 is an explanation for explaining the transition of the software configuration installed in the multifunction device 1. FIG. 17 is an explanatory diagram for explaining the relationship between software and hardware of a conventional multifunction machine.

  As shown in FIG. 1, with the recent progress of networking, devices such as personal computers (PCs) provided in offices are connected to a network such as a LAN (Local Area Network) and can communicate with each other. it can. For example, as shown in the figure, a client PC, an SMTP (Simple Mail Transfer Protocol) server, an FTP (File Transfer Protocol) server, a server PC, etc. are connected to a network such as a LAN to send and receive e-mails and files. A distribution server that can transfer and that is connected to a modem can communicate with a fax machine outside the office.

  With the progress of such networking, the multifunction device 1 is also connected to the network and can communicate with devices such as a PC, and by incorporating a storage device such as a hard disk, a so-called network multifunction device can be obtained. It has evolved to meet various user needs.

  Specifically, in addition to the normal copy function, the multi function device 1 is connected to the server PC by a printer function for printing document data and the like by a print request from the client PC, and by a fax request from the client PC. It has a fax function that sends it to a fax machine in another office via a modem, and a storage function that stores received fax documents and copy documents on a hard disk with a built-in function. In order to realize such many functions, the software installed in the multifunction machine 1 has become larger and more complicated.

  FIG. 2 is a block diagram illustrating a hardware configuration of the multifunction machine 1. As shown in the figure, the multifunction machine 1 has a configuration in which a controller 10 and an engine unit (Engine) 60 are connected by a PCI (Peripheral Component Interconnect) bus. The controller 10 is a controller that controls the entire multifunction device 1 and controls drawing, communication, and input from an operation unit (not shown). The engine unit 60 is a printer engine that can be connected to a PCI bus, and is, for example, a monochrome plotter, a one-drum color plotter, a four-drum color plotter, a scanner, or a fax unit. The engine unit 60 includes an image processing part such as error diffusion and gamma conversion in addition to a so-called engine part such as a plotter.

  The controller 10 includes a CPU 11, a north bridge (NB) 13, a system memory (MEM-P) 12, a south bridge (SB) 14, a local memory (MEM-C) 17, and an ASIC (Application Specific Integrated Circuit). 16 and a hard disk drive (HDD) 18, and the north bridge (NB) 13 and the ASIC 16 are connected by an AGP (Accelerated Graphics Port) bus 15. The MEM-P 12 further includes a ROM (Read Only Memory) 12a and a RAM (Random Access Memory).

  The CPU 11 performs overall control of the multifunction machine 1 and includes a chip set including the NB 13, the MEM-P 12, and the SB 14, and is connected to other devices via the chip set.

  The NB 13 is a bridge for connecting the CPU 11 to the MEM-P 12, SB 14, and AGP 15, and includes a memory controller that controls reading and writing to the MEM-P 12, a PCI master, and an AGP target.

  The MEM-P 12 is a system memory used as a memory for storing programs and data, a memory for developing programs and data, a memory for drawing a printer, and the like, and includes a ROM 12a and a RAM 12b. The ROM 12a is a read-only memory used as a memory for storing programs and data, and the RAM 12b is a writable and readable memory used as a program / data development memory, a printer drawing memory, and the like.

  The SB 14 is a bridge for connecting the NB 13 to a PCI device and peripheral devices. The SB 14 is connected to the NB 13 via a PCI bus, and a network interface (I / F) unit and the like are also connected to the PCI bus.

  The ASIC 16 is an IC (Integrated Circuit) for image processing applications having hardware elements for image processing, and has a role of a bridge for connecting the AGP 15, PCI bus, HDD 18 and MEM-C 17. The ASIC 16 includes a PCI target and an AGP master, an arbiter (ARB) that is the core of the ASIC 16, a memory controller that controls the MEM-C 17, and a plurality of DMACs (Direct Memory) that perform rotation of image data by hardware logic. Access Controller) and a PCI unit that performs data transfer between the engine unit 60 via the PCI bus. An FCU (Fax Control Unit) 30, a USB (Universal Serial Bus) 40, and an IEEE 1394 (the Institute of Electrical and Electronics Engineers 1394) interface 50 are connected to the ASIC 16 via a PCI bus.

  The MEM-C 17 is a local memory used as an image buffer for copying and a code buffer, and an HDD (Hard Disk Drive) 18 is a storage for storing image data, programs, font data, and forms. It is.

  The AGP 15 is a bus interface for a graphics accelerator card proposed for speeding up graphics processing. The AGP 15 speeds up the graphics accelerator card by directly accessing the MEM-P 12 with high throughput. .

  FIG. 3 is a conceptual diagram showing the hardware and software configurations of the multi-function peripheral 1, and specifically, an integrated application 110 including a request management unit 113a, which is a characteristic part of the present embodiment described later, and software 100 shows a hierarchical relationship between 100 and hardware 200. As shown in the figure, the hardware 200 includes a hardware resource 201. The hardware resource 201 includes a scanner 201a, a plotter 201b, an HDD (Hard Disk Drive) 201c, a network 201d, and other resources 201e. . The other resource 201e is a hardware resource 201 other than 201a to 201d, and indicates an input / output device such as an operation panel, for example.

  The software 100 installed in the hardware 200 is hierarchized, and a service layer 102 is constructed above the operating system 103, and an application layer 103 is constructed above the service layer 102. The service layer 102 corresponds to a driver that controls each hardware resource (201a to 201e). The scanner control unit 102a, plotter control unit 102b, storage control unit 102c, distribution / mail transmission / reception control unit 102d, FAX transmission / reception It has a control unit 102e, a network communication control unit 102f, and another control unit 102g.

  Here, how the software 100 shown in FIG. 3 has taken such a hierarchical structure will be described with reference to FIGS. 16 and 17. FIG. 16 is an explanatory diagram showing the transition of the software configuration installed in the multifunction machine 1. As shown in the pre-service layer separation application 501 in FIG. 16, the software installed in the multifunctional multifunction device 1 is created as an independent application for each function such as a copy application, a FAX application, and a scanner application. It was operating on the operating system 103 shown.

  However, since these applications include a driver (service layer 102) that controls hardware resources, duplicate processing exists in each application. As a result, the scale of each application has become large.

  Therefore, as shown in an application 502 after service layer separation in FIG. 16, a portion corresponding to the service layer 102 of the application 501 before service layer separation is bundled into a service layer 102, and each application is an upper layer of the service layer 102. The application layer 101 is constructed. By adopting such a hierarchical structure, each application has been streamlined and development effort has been reduced.

  However, as the networking and multi-functionalization of the multifunction machine 1 further advance, it has become a problem that a common processing part exists in each application. Specifically, each application in the application layer 101, for example, a copy application or a scanner application, performs processing for communicating with a driver such as the scanner control unit 102a or the accumulation control unit 102c, or job management such as request reception or request execution. It had similar processing such as processing inside. As described above, when each application has the same processing, the development scale of each application is increased, and the improvement scale of each application with respect to the specification change of the service layer is increased.

  In order to solve this problem, as shown in the common routine separation application 503 in FIG. 16, it has been considered that such similar processing (common processing portion) is bundled as a common routine. However, since such a common routine is intended to share slightly different processing in each application, the processing inside the common routine becomes complicated. For example, when adding a new application such as a printer application, it is necessary to modify the common routine in order to adapt to the new application.

  However, since the internal processing of the common routine is complicated, it became difficult for repair personnel to grasp the processing, and there were concerns about the increase in the scale of repair and the impact on other applications due to repair mistakes.

  Therefore, as shown in an object-oriented application 504 in FIG. 16, such a plurality of applications are integrated into the integrated application 110 by an object-oriented design method (object modeling). Specifically, a common processing part of each application is extracted as an object model, and the integrated application 110 is configured from the collection of object models. The functions such as the conventional copy function and scanner function are realized by the cooperative relationship of the object model.

  By adopting such a configuration, for example, addition of a new function such as a printer function can be dealt with by subclassing a class belonging to the object model. For this reason, a repair part becomes clear and the influence on other functions by repair can be made small. In addition, the object modeling program is easier to grasp the process than the conventional procedural program, so it is easier for the repair staff to grasp the process, reducing the scale of the repair, and other applications due to mistakes in the repair. The influence on can be reduced.

  FIG. 17 is an explanatory diagram showing the configuration of a conventional application at the stage of the service layer separated application 502 shown in FIG. 16 and the relationship between the application and each driver of the service layer 102. As shown in the figure, the application layer 101 includes a copy application 120, a scanner application 130, a fax application 140, and a printer application 150.

  For example, the copy application 120 transmits / receives data to / from the scanner control unit 102a, the plotter control unit 102b, the accumulation control unit 102c, and the other control unit 102g in order to realize the copy function. In addition, the fax application 140 performs data transmission / reception with the plotter control unit 102b, the accumulation control unit 102c, the FAX transmission / reception control unit 102e, the network communication control unit 102f, and the other control unit 102g in order to realize the fax function. As described above, communication between each application in the application layer 101 and each driver in the service layer 102 is complicated.

  Returning to the description of FIG. 3, a plurality of applications existing in the application layer 101 are integrated into the integrated application 110 by the object modeling described above. The communication processing with each driver, which has been performed by each application overlappingly, is configured to be performed by a predetermined object model that configures the integrated application 110, so that the application of the application layer 101 and the service layer 102 of Communication between the drivers is simple compared to FIG.

  Next, the internal configuration of the integrated application 110 will be described. FIG. 4 is an explanatory diagram for explaining the positioning of the request management unit 113a in the integrated application 110, which is a characteristic part of the present embodiment, which will be described later, and the schematic configuration of the integrated application 110.

  As shown in the figure, the integrated application 110 has an operation system subsystem 111, a management system subsystem 112, and an execution system subsystem 113. The operation system subsystem 111 is a software group in charge of man-machine interface. Specifically, the operation subsystem 111 performs a service for accepting a user's request and considers the quality, cost, and delivery date of a product (for example, a copied recording sheet) corresponding to the request. Provide information service to users.

  The management subsystem 112 is a software group that manages the resources of the multifunction machine 1. Specifically, the management subsystem 112 performs a management service of the hardware resource 201 and the data state held by the hardware resource 201.

  The execution subsystem 113 is a software group in charge of executing a user request. More specifically, the execution subsystem 113 provides an execution service from a document operation request such as copying to output of a product. The operation subsystem 111, the management subsystem 112, and the execution subsystem 113 are required for the multifunction machine 1 as a whole of the integrated application 110 by requesting processing and receiving the results as necessary. Provide service.

  The execution system subsystem 113 includes a request management unit 113a and an execution control unit 113b, which are characteristic parts of the present embodiment described later. The request management unit 113a is a software group that performs so-called job management. Specifically, it accepts a user request as a request, executes the request, and manages the execution state of the request.

  The execution control unit 113b is a software group that performs other execution control, excluding the request management unit 113a from the execution subsystem 113. In FIG. 4, the request management unit 113a is arranged near the operation system subsystem 111 because the request management unit 113a that manages the user's request is the operation system subsystem 111 in charge of the man-machine interface. And have a close relationship.

  FIG. 5 is a diagram in which each subsystem shown in FIG. 4 is replaced with a UML (Unified Modeling Language) class diagram (UML class diagram). Here, UML is a system modeling language compiled by an organization called OMG (Object Management Group), and defines a notation for describing the results of system modeling. The UML is generally used in object-oriented software development.

  As shown in FIG. 5, the integrated application 110 includes a plurality of packages, and the integrated application 110 itself can also be regarded as a package. Here, the package is a grouping of each component (symbol) of the UML model, and this package is expressed by a folder-type symbol with a tab on the upper left. Such a package can also be regarded as the object model described above or a collection of object models.

  As shown in FIG. 5, the integrated application 110 is a package having three packages of an operation subsystem 111, a management subsystem 112, and an execution subsystem 113 inside. Further, the execution subsystem 113 is a package having two packages, a request management unit 113a and an execution control unit 113b. A straight line connecting the operation subsystem 111, the management subsystem 112, and the execution subsystem 113 indicates that there is a relationship such as message transmission / reception between the packages. A symbol written at the right end of the tabs of the operation subsystem 111, the management subsystem 112, and the execution subsystem 113 is a UML symbol indicating that the package is a subsystem.

  Next, the request management unit 113a which is a characteristic part of the present embodiment will be described in detail. The request management unit 113a manages the job execution request received from the user, and in response to the execution request, instructs the execution control unit 113b to execute the job, and manages the progress of the job for which the execution instruction has been issued. To take responsibility.

  FIG. 6A is an explanatory diagram for explaining the “directory-file” model, and FIG. 6B is an explanatory diagram for explaining an outline of modeling of the request management unit. As shown in FIG. 6A, a so-called “directory-file” model is a model generally used as a file management model in an operating system (OS) such as UNIX (registered trademark) or WINDOWS (registered trademark). is there.

  This “directory-file” model has a directory for managing a plurality of files and files under the management of the directory. Each directory and file has a property that is detailed information on the directory and the file. Yes. By adopting this “directory-file” model, the OS realizes file management such as file creation, copy, move, delete, and list display.

  As described above, it is expected that a stable request management model can be realized by modeling the request management unit 113a based on an analogy (analog) of the “directory-file” model that has been conventionally used.

  Therefore, as illustrated in FIG. 6B, the request management unit 113a includes a request folder for managing a plurality of requests and a request under the management of the request folder, and the request is a request that is detailed information of the request. A configuration having specifications was taken. Note that the “directory-file” model generally has a hierarchical structure in which directories are hierarchically subordinate to the directory, but the request management unit 113a is configured not to have such a hierarchical structure. However, the request management unit 113a may be configured to have such a hierarchical structure.

  FIG. 7 shows a class configuration of the request management unit 113a configured as an analogy of the “directory-file” model, expressed by a UML class diagram (UML class diagram). Here, a class is a concept that corresponds to a design drawing of the objects that make up an object-oriented system. This class has data and processing integrated (encapsulated) inside and has inheritance and aggregation relationships. It has a static relationship with other classes. In the class diagram, data and processing that each class has, and a static relationship among a plurality of classes are represented.

  Next, the class configuration of the request management unit 113a, which is a characteristic part of the present embodiment, will be described. As illustrated in FIG. 7, the request management unit 113a includes a request folder class 310, a request class 320, a request specification class 330, a product class 340, and a product specification class 350.

  A rectangle indicating each class has three sections. From the top, a rectangle indicating a class name, an attribute section indicating data (attribute) included in the class, and an operation section indicating processing (operation) included in the class are referred to. For example, a rectangular name section indicating the request folder class 310 indicates that the class name of the class is “request folder”, and the attribute section has attributes “acceptance state” and “limit number”. The operation section indicates that the operation of the class is “request input ()”.

  Thus, each class has an attribute section for possessing data (attribute) and an operation section for possessing processing (operation) for writing and reading such an attribute. Since these classes are included as a part of the program (integrated application 110), when this program stored in the ROM 12a in advance is executed, each class is materialized in a predetermined area of the RAM 12b and included in the attribute section. Each data (attribute) is expanded on the RAM 12b. Therefore, the object in which the class is materialized can write and read each data (attribute) on the RAM 12b.

  In addition, if a "-" symbol is attached to the left side of a class element such as attribute or operation, this indicates that the element is private to external classes, and if a "+" symbol is attached, this element Indicates that it is open to external classes. Also, for operations, it is customary to add a “()” symbol, such as “Request input ()”, and when describing an argument to be passed to the operation, such as “(Argument 1, Argument 2)” There is also.

  Next, each class shown in FIG. 7 will be described. The request folder class 310 is a class for receiving requests and managing requests. Specifically, the request folder class 310 has an acceptance state 310a and a limit number 310b as attributes, and a request input () 310c as an operation. When an object that materializes the request folder class 310 is generated, the acceptance state 310a and the limit number 310b are expanded on the RAM 12b, so that these data (attributes) can be written and read. Become.

  The acceptance state 310a is a state of acceptance / rejection determined from the number of requests being managed by the request folder class and the limit number 310b. For example, when the limit number 310b is 200, If it is 200, the acceptance state 310a holds the acceptance refusal state. The limit number 310b is the maximum number of requests allowed by the multi-function device 1, and varies depending on the hardware specifications on which the integrated application 110 is installed. Further, the request input () 310c performs a process of accepting a request from the operation subsystem 111 and requesting the request class 320 to execute the request by a user operation.

  The request class 320 is a class that executes requests and manages deliverables. Specifically, this request class 320 has a request state 320a as an attribute and an implementation () 320b as an operation. The request state 320a is an execution state of the document operation related to the request, for example, a state of being executed or being interrupted. Further, when the realization () 320 b receives a request start request from the request folder class 310, it refers to the request detailed information held by the request specification class 330 to determine the type of the product to be created, and the product class Processing for requesting 340 to start document creation is performed. When an object in which the request class 320 is materialized is generated, the request state 320a is expanded on the RAM 12b, so that this data (attribute) can be written and read.

  The request specification class 330 is a class that holds detailed information of a request and provides this detailed information in response to a request from another class. Specifically, the request specification class 330 has an allowable specification 330a and a user's request 330b as attributes, and a setting () 330 c and a reference () 330 d as operations. When an object that materializes the request specification class 330 is generated, the allowable range 330a and the user's request 330b are expanded on the RAM 12b, so that these data (attributes) can be written and read. It becomes.

  The allowable specification 330a is an alternative specification of the user's request 330b when the processing cannot be continued due to a trouble that occurs during execution of the request. The user's request 330b has an input specification and an output specification. Specifically, the specification about the type and input method of the input document instructed to the MFP 1 by the user is the input specification, and the specification about the type and output method of the output product based on the input document. Is the output specification. For example, if the user operates the multifunction device 1 to set a plain paper document on the ADF (automatic document feeder) of the multifunction device 1 and instruct to copy two copies onto A4 recording paper, The instruction content for setting a paper document on the ADF (automatic document feeder) of the multifunction machine 1 is an input specification, and the instruction content for “copying to A4 recording paper” is an output specification. It is assumed that the user's request 330b is once determined by the user's instruction to the multifunction device 1, but can be changed by the instruction again.

  The setting () 330 c performs processing for setting the allowable specification 330 a and the user's request 330 b as attributes of the request specification class 330. The reference () 330d performs processing for providing the allowable specification 330a and the user's request 330b set as attributes according to a request from another class. In the present embodiment, the request class 320 and the request specification class 330 are configured as separate classes. However, the request class 320 also serves as the request specification class 330 so that the request specification class 330 is not included. You can also.

  The deliverable class 340 is a class for managing the progress of the deliverable to be output and executing the deliverable. Specifically, the product class 340 includes, as attributes, a progress 340a that can be output, a progress 340b that has been output, and an execution state 340c, and a creation () 340d as an operation. When an object that materializes the deliverable class 340 is generated, the progress 340a that can be output, the progress 340b that has been output, and the execution state 340c are expanded on the RAM 12b, so that these data (attributes) Writing and reading can be performed.

  The progress 340a of what can be output represents the progress of an input item (for example, a document) input to the multifunction device 1. For example, when the user sets 50 paper originals in the multi-function peripheral 1 and makes a job processing request for instructing copying of the set paper originals, the progress 340a that can be input is from 0/50 to 50 / It takes 50, or a value from 0% to 100%. Note that the increment of the progress value may differ depending on the type of document and the data type of the document.

  The output progress 340b holds the progress status of the product output from the multifunction machine 1. For example, when the user sets 200 paper originals in the multi-function peripheral 1 and makes a job processing request to instruct the copying of the set paper originals, the progress 340b of the output ones is from 0/200 to 200. / 200, or a value from 0% to 100%.

  Note that the increment of the progress value may differ depending on the type of product and the data type of the product. The execution state 340c holds an execution state of work for creating a product. Specifically, the execution state 340c holds an execution state such as whether a work for creating a product is being executed or whether execution has been interrupted due to a failure that has occurred. The creation () 340d performs processing for accepting creation start of a deliverable.

  The product specification class 350 is a class that holds detailed information of a product, and a class that extracts and holds information necessary for creating a product from the detailed information of a request held by the request specification class 330. It is. Specifically, the product specification class 350 has an input form 350a, an output form 350b, and a user's request 350c as attributes. When an object that materializes the product specification class 350 is generated, the input form 350a, the output form 350b, and the user's request 350c are expanded on the RAM 12b, so that these data (attributes) are written. And reading out.

  The input form 350 a holds the form of the document input to the multifunction device 1. For example, as a form of the original, there are a paper original set by the user in the multifunction machine 1, a stored original held in a storage device built in the multifunction machine 1, a fax reception original, and the like.

  The output form 350b holds the form of the product output from the multi function device 1. For example, as a form of such a product, there are a product printed on paper, a product transmitted through a WAN (Wide Area Network) by e-mail, a product transmitted by fax, and the like.

  The user's request 350c is a specification about the finished product that the user has instructed to the multifunction device 1. For example, in the case of a product printed on paper, there are specifications such as A4 landscape, double-sided printing, and the number of pages per sheet. In the present embodiment, the product class 340 and the product specification class 350 are configured as separate classes. However, the product class 340 class also serves as the product specification class 350, thereby providing the product specification class 350. It can also be set as the structure which does not have.

  Next, the relationship between the classes shown in FIG. 7 will be described. As shown in the figure, the straight line connecting the rectangles indicating each class indicates that there is a relationship between the classes at both ends, and the characters near the ends of this line indicate the role of the class, and the numbers indicate the class. Each multiplicity is shown. Here, the role is the role and position of the other class as seen from one class at both ends of the line, and the multiplicity is the number of objects generated from the class at both ends of the line. It is a correspondence relationship.

  For example, the role of the request class 320 viewed from the product class 340 is “monitor”, the role of the product class 340 viewed from the request class 320 is “monitoring target”, and the multiplicity of the request class 320 is “1”. The multiplicity of the product class 340 is “1 .. *”. Here, “1 .. *” indicates that the multiplicity of the product class 340 is in a range from 1 to no upper limit. For example, when “1..3” is described, the multiplicity of the class is in the range of 1 to 3.

  First, the class relationship between the request folder class 310 and the request class 320 will be described. The request folder class 310 has a role as a storage destination when viewed from the request class 320, while the request class 320 has a role as a storage target when viewed from the request folder class 310. According to the example of the “folder-file” model described above, the request folder class 310 corresponds to the folder of the model, and the request class 320 corresponds to the file of the model.

  As shown in the figure, in the scene where the request management unit 113a is executed, there is only one object in which the request folder class 310 is expanded (substantiated) on the RAM 12b, and the request folder class 310 is stored. There are 0 or more objects in which the target request class 320 is materialized, and there is no upper limit.

  The reason that the request folder class 310 is instantiated instead of a plurality of objects is to manage all requests that are input to the multifunction machine 1 at once. In addition, the number of objects that materialize the request class 320 indicates that there is no request being executed, and although the upper limit number of such objects is not defined, of course, hardware It shall be restricted by specifications.

  Next, the relationship between the request class 320 and the request specification class 330 will be described. The request class 320 has a role as an application target when viewed from the request specification class 330, while the request specification class 330 has a role as details when viewed from the request class 320. According to the example of the “folder-file” model described above, the request class 320 corresponds to the file of the model, and the request specification class 330 corresponds to the property of the model.

  That is, the request specification class 330 is a detailed specification of the request class 320, and indicates that the target to which this detailed specification is applied is the request class 320. Then, in the scene where the request management unit 113a is executed, the object that materializes the request class 320 and the object that materializes the request specification class 330 exist in a one-to-one relationship. For example, in the case where ten requests are being executed in the multi-function device 1, there are ten objects that materialize the request class 320 and ten objects that materialize the request specification class 330, respectively.

  Next, the relationship between the request class 320 and the product class 340 will be described. The request class 320 has a role as a monitor when viewed from the product class 330, while the product class 340 has a role as a monitoring target when viewed from the request class 320. Then, in the scene where the request management unit 113a is executed, there is an object that materializes one or more product classes 340 for one object that materializes the request class 320.

  For example, when the user makes a job processing request for instructing the MFP 1 to copy 10 copies from an input original composed of five paper originals, one object of the request class 320 corresponding to the instruction is generated. Ten objects of the product class 340 are generated. Then, the object of the request class 320 monitors the objects of the ten deliverable classes 340, and determines the completion of the request with the completion of the ten deliverables, that is, the copy output of 5 × 10 copies.

  Next, the relationship between the product class 340 and the product specification class 350 will be described. The product class 340 has a role as an application target when viewed from the product specification class 350, while the product specification class 350 has a role as its details when viewed from the product class 340. ing. According to the example of the “folder-file” model described above, the product class 340 corresponds to a file of such a model, and the product specification class 350 corresponds to a property of the model.

  That is, the product specification class 350 is a detailed specification of the product class 340, and the target to which the detailed specification is applied is the product class 340. In the scene where the request management unit 113a is executed, the object that materializes the product class 340 and the object that materializes the product specification class 350 exist in a one-to-one relationship. For example, in the case where 20 deliverables are being executed in the multifunction device 1, there are 20 objects that materialize the deliverable class 340 and 20 objects that materialize the deliverable specification class 350, respectively.

  Next, the relationship between the request specification class 330 and the product specification class 350 will be described. The request specification class 330 has a role as a whole when viewed from the product specification class 350, while the product specification class 350 has a role as a part when viewed from the request specification class 330. Then, in the scene where the request management unit 113a is executed, there is an object that materializes one or more product specification classes 350 for one object that materializes the request specification class 330.

  For example, when the user makes a job processing request for instructing a copy process of 10 copies from an input original composed of five paper originals to the multifunction peripheral 1, there is one object of the request specification class 330 corresponding to the instruction. 10 objects of the product specification class 350 are generated. Further, the white diamonds written on the request specification class 330 side of the straight line connecting the request specification class 330 and the product specification class 350 are aggregated, that is, a relationship in which one class is included as a part of another class, Is shown. Specifically, the product specification class 350 is a class that extracts and holds information necessary for creating a product from the detailed information of the request held by the request specification class 330. 330, and has a relationship aggregated in the request specification class 330.

  Next, the outline of the operation of the object that materializes each class shown in FIG. 7 will be described with reference to FIGS. 8, 9 and 10-1 to 10-3. FIG. 8 is a diagram illustrating an example of the operation panel 400 of the multifunction machine 1. As shown in the figure, the operation panel 400 includes an initial setting key 401, a copy key 402, a copy server key 403, a printer key 404, a transmission key 405, a ten key 406, a clear / stop key 407, a start key 408, a preheat. A key 409, a reset key 410, and a liquid crystal touch panel 420 are provided.

  When the initial setting key 401 is touched, a menu for initial setting is displayed on the liquid crystal touch panel 420, and in this menu, a paper size to be stored can be set. In addition, the copy key 402 is used for copying, the copy server key 403 is used for storing the copy result in the multi-function device 1, and the printer key 404 is stored for faxing or storing if the operation related to the printer is to be performed. When the user wants to transmit an image or the like, touch the transmission key 405 to display a menu corresponding to the liquid crystal touch panel 420.

  FIG. 9 shows an example of a menu displayed on the liquid crystal touch panel 420 when the copy server key 403 shown in FIG. 8 is touched. As shown in FIG. 9, the liquid crystal touch panel 420 displays a document reading button 421, buttons such as a delete from list button 422, a print condition button 423, and a list of stored documents.

  Then, when it is desired to store the original, the original is set at a predetermined location and the original reading button 421 is touched. When it is desired to delete the stored document, for example, the stored document 425 with the user ID DEF is touched, the display of the stored document is inverted, and then the delete button 422 is touched from the list. If the user wants to change the print condition of the stored document, for example, touch the stored document 425 whose user ID is ABC, invert the display of the stored document, and touch the print condition button 423 to print the print condition menu. Is displayed.

  By changing the printing conditions in such a menu, the printing conditions of the selected accumulated document 425 can be changed. If the number of stored documents is large and the operation target document is not displayed in the display area, the operation target document can be displayed by touching the forward button and the backward button. .

  FIGS. 10-1 to 10-3 are UML cooperation (collaboration) diagrams representing the objects of the request folder class 310 and the request class 320 and the flow of messages between the objects. Here, the message is a call to an operation that the object has inside. For example, when the object A calls the operation B1 of the object B, the object A sends a message to the object B. it can.

  When an object sends a message to another object, the object that receives this message changes the internal attribute (data), sends a response to the message, or sends another message. Or In this way, each object proceeds in a coordinated manner.

  FIG. 10A is a UML showing the flow of messages between the objects of the request class 320 and the product class 340 and the object when the request folder object 310A, which is an object of the request folder class 310, receives a new request. It is a collaboration diagram.

  Such a new request is generated, for example, when the document reading button 421 shown in FIG. 9 is touched, and reaches the request folder object 310A via the other control unit 102g driver and the operation subsystem 111 of the service layer 102. To do. In the figure, for the sake of easy understanding, the description of the objects that materialize the request specification class 330 and the product specification class 350 is omitted.

  First, each symbol attached to the figure will be described. A rectangle with a string with an underline inside indicates an object. A string with an underline that includes a colon (:) indicates the object name before the colon and the object after the colon. Indicates the class to which the belongs. An arrow indicates a message between objects. For example, in a character string “1: request object generation” written in the vicinity of the arrow, “1” indicates a relative order of the messages in FIG. “Request object generation” indicates the content of the message. Moreover, the line which connects each object has shown that there exists a relationship with each object, For example, messages, such as an object production | generation message, are transmitted / received along this line.

  As shown in the figure, the request folder object 310A has already received two requests, a copy request object 320B and a FAX / accumulation request object 320C. This copy request object 320B is a single deliverable object being executed. It is assumed that the FAX / storage request object 320C manages two deliverable objects, that is, the waiting FAX deliverable object 340C and the waiting accumulated deliverable object 340D.

  The request folder object 310A newly accepts a copy / accumulation request and generates a copy / accumulation request object 320D (step S1001). The generated copy / accumulation request object 320D includes two product objects, that is, Then, a standby copy product object 340E and a standby storage product object 340F are generated (step S1002).

  FIG. 10B is a UML collaboration diagram illustrating the objects of the request class 320 and the product class 340 and the flow of messages between the objects when the request folder object 310A receives a request list request.

  The request list request is generated, for example, when the copy server button 403 shown in FIG. 8 is touched, and is sent to the request folder object 310A via the other control unit 102g driver and the operation system subsystem 111 of the service layer 102. To reach.

  As shown in the figure, when the request folder object 310A receives a request list request, the request folder object 310A requests three objects to be managed, that is, a copy request object 320B, a FAX / storage request object 320C, and a copy / storage request object 320D. The inquiry message is transmitted (step S1003).

  Upon receiving this message, the copy request object 320B transmits an execution status inquiry message to the managed deliverable object 340B to be managed (step S1004). Then, the product object 340B being executed that has received this message transmits an answer message indicating that the product is being executed to the copy request object 320B.

  Then, the copy request object 320B that has received this reply message transmits a request request state reply to the request folder object 310A (step S1010).

  Further, the FAX / storage request object 320C that has received the request state inquiry message (step S1003) transmitted by the request folder object 310A has two objects to be managed, that is, a waiting FAX deliverable object 340C and a waiting storage. An execution state inquiry message is transmitted to the deliverable object 340D (step S1006).

  Then, the FAX product object 340C on standby that has received this message transmits an answer message indicating that the product is on standby to the FAX / storage request object 320C (Step S1007). The stored product object 340D in the middle also transmits an execution state reply message indicating that the product is waiting to the FAX / storage request object 320C (step S1007).

  Upon receiving these two reply messages, the FAX / storage request object 320C transmits the reply of the request request state to the request folder object 310A (step S1010).

  The copy / storage request object 320D that has received the request state inquiry message (step S1003) transmitted by the request folder object 310A has two objects to be managed, that is, a standby copy product object 340E and a standby storage. An execution state inquiry message is transmitted to the deliverable object 340F (step S1008).

  Upon receiving this message, the waiting copy product object 340E transmits an execution state reply message indicating that the product is waiting to the copy / storage request object 320D (step S1009). The storage product object 340F in the middle also transmits an execution state reply message indicating that the product is waiting to the copy / storage request object 320D (step S1009).

  Upon receiving these two reply messages, the copy / storage request object 320D transmits a request request state reply to the request folder object 310A (step S1010).

  The request folder object 310A receives the request state from all of the three objects that have transmitted the request state inquiry message (step S1003), that is, the copy request object 320B, the FAX / store request object 320C, and the copy / store request object 320D. Is received (step S1010), request list information is created based on the received answer, and the response is made to the operation subsystem 111 that has made the request list request. The request list information is displayed on the liquid crystal touch panel 420 as, for example, a document list as illustrated in FIG. 9 via the other control unit 102g of the service layer 102.

  FIG. 10C illustrates the request class 320 and deliverable class 340 objects and the messages between the objects when the request folder object 310A receives a request to cancel the accumulated deliverables of the FAX / store request being managed. It is the UML collaboration diagram which showed the flow.

  Such a cancellation request is generated, for example, when the delete button 422 is touched from the list shown in FIG. 9, and is sent to the request folder object 310A via the other control unit 102g driver and the operation system subsystem 111 of the service layer 102. To reach. As shown in the figure, when receiving the cancel request, the request folder object 310A transmits a cancel message to the corresponding FAX / storage request object 320C (step S1011).

  The FAX / storage request object 320C that has received this message transmits a cancellation message to the waiting storage product object 340D (step S1012), and the standby storage product object 340D that has received this message disappears. .

  In this way, the object that materializes the class of the request management unit 113a, which is a characteristic part of the present embodiment, exchanges messages between objects that materialize the related class in accordance with the relationship between classes shown in FIG. We will proceed with the process.

  Next, the ease of function addition of the request management unit 113a, which is a characteristic part of the present embodiment, will be described. FIG. 11 is an explanatory diagram for explaining a concept when a new function such as a printer function is added to the integrated application 110.

  As shown in the figure, the integrated application 110 is configured as a collection of object models indicated by ellipses, and each object model corresponds to a role constituting the integrated application 110. When a new function such as a printer function is added to the integrated application 110, first, the added printer function is separated so as to be compatible with each object model constituting the integrated application 110. Then, the separated part is reflected in each object model.

  Adding a class by subclassification shown in the figure is one of such reflection methods. Here, subclassing is a method of designing a lower class by inheriting the attributes and operations of the upper class, and is one of the advantages of object-oriented software development.

  FIG. 12 is an explanatory diagram based on the UML class diagram illustrating subclassification of the request class 320 as an example of class addition by subclassification when a new function is added to the integrated application 110.

  As shown in the figure, the request class 320 is an upper class (super class) having, for example, a scanner request class, a copy request class, and a fax request class as lower classes (subclasses).

  As a new function shown in FIG. 11, for example, if a printer function is added, the addition of the function to the request class 320 can be expressed as an addition of a printer request class. Specifically, a new printer request can be created by adding / changing necessary processing while inheriting the request state 320a that is an attribute of the request class 320 and the realization () 320b that is the operation of the request class 320. Design a class.

  Next, a description will be given of the manner in which the object that materializes the printer request class shown in FIG. 12 is managed by the request folder class 310. FIGS. 13A to 13C are explanatory diagrams for explaining how the object of the request folder class 310 manages the subclass of the request class 320.

  As shown in FIG. 7, the request folder class 310 and the request class 320 are in a relationship between the storage destination and the storage target, but the class to be stored in the request folder class 310 is at least the attribute and operation of the request class 320. It is necessary to have. In other words, if the request class 320 is a subclass, the request folder class 310 can be a storage target.

  For example, as shown in FIG. 13A, the object of the request folder class 310 includes COPY01, which is a copy request class object obtained by subclassing the request class, and FAX01, which is a fax request class object obtained by subclassing the request class. FAX02 can be managed.

  This is because the request folder class 310 can manage subclasses of the request class 320 as described above. Then, as shown in FIG. 13B, if the printer class is designed by subclassing the request class 320 and PRNT01 is generated as an object of the class, the object of the request folder class 310 is shown in FIG. Can manage PRNT01.

  Next, the processing of each class and the flow of messages between objects generated from each class when a request is input to the request management unit 113a, which is a characteristic part of the present embodiment, will be described.

  FIG. 14 shows the processing performed by each operation at the time of request input for the request folder class 310, the request class 320, the request specification class 330, the product class 340, and the product specification class 350 shown in FIG. It is a class diagram described in the symbol.

  FIG. 15 is a UML sequence diagram showing in time series an object in which each class shown in FIG. 14 is materialized and a message flow between the objects. The rectangles arranged in the upper part of the figure indicate each object, and the broken line extending downward from each object is a line (lifeline) indicating that each object is alive, and faces downward in the figure. And time shall flow. The rectangle extending in the vertical direction on the broken line indicates a period (active section) in which each object is actually active.

  As shown in FIG. 15, when the user operates the multi-function device 1 and inputs a request, the operation subsystem 111 possesses operation setting information [a] consisting of the allowable specification [a1] and the user's request [a2]. (Step S1101). Then, the request specification object 330A is generated by calling the generation () of the request specification object 330A (step S1102). Here, this generation () is an operation that all objects have, and each object is materialized on the RAM 12 b by calling this generation ().

  Subsequently, the operation system subsystem 111 calls the setting () 330c of the request specification object 330A (step S1103), thereby obtaining the allowable specification [a1] and the user's request [a2] possessed by the operation system subsystem 111. Then, the allowable specification 330a and the user's request 330b, which are data (attributes) included in the attribute section of the request specification object 330A, are set (step S1104).

  Then, the operational subsystem 111 receives the request specification object 330A as a return value of the setting () 330c. Then, the operation subsystem 111 calls the request input () 310c of the request folder object 310A using the request specification object 330A as an argument (step S1105).

  Then, the request folder object 310A holds the link information (information indicating the storage area where the object exists on the RAM 12b) of the request specification object 330A passed as an argument of the request input () 310c (step S1106). The reason why the link information is held is that the link information is later transferred to the request object 320A, the product object 340A, and the product specification object 350A so that the request specification object 330A can be referred to from these objects.

  Then, the request folder object 310A refers to the value of the reception state 310a that is data (attribute) included in its own attribute section, and determines whether or not a request can be submitted (step S1107). If the value of the acceptance status 310a can be accepted, the process proceeds to the subsequent processing. If the value cannot be accepted, the operation subsystem 111 is notified to that effect and the processing is terminated. To do.

  Then, the request folder object 310A generates the request object 320A by calling the generation () of the request object 320A (step S1108). When the request folder object 310A can accept the value of the acceptance state 310a, which is data (attribute) included in its own attribute section, the request folder object 310A implements the request object 320A using the link information of the request specification object 330A as an argument ( ) 320b is called (step S1109).

  Subsequently, the request object 320A holds the link information of the request specification object 330A passed as an argument of the realization () 320b, thereby associating with the request specification object 330A (step S1110), and the request specification object 330A. By calling the reference () 330d (step S1111), the user's desire 330b, which is data (attribute) included in the attribute section of the request specification object 330A, is acquired as a return value of the reference () 330d (step S1112). .

  Then, the request object 320A generates a necessary number of deliverable objects 340A in accordance with the acquired user request 330b. Specifically, the request object 320A generates the necessary number of deliverable objects 340A by calling the generation () of the deliverable object 340A as many times as necessary (step S1113).

  Subsequently, the request object 320A calls the creation () 340d of the product object 340A generated previously using the link information of the request specification object 330A held in step S1108 as an argument (step S1114).

  Then, the deliverable object 340A calls the generation () of the deliverable specification object 350A using the link information of the request specification object 330A passed as the argument of the creation () 340d (step S1115). As described above, this generation () is an operation that all objects have. Then, the deliverable object 340A obtains the link information of the deliverable object 340A as a return value of the generation (), thereby associating with the deliverable specification (step S1116).

  As described above, when the request object 320A hands over the link information of the request specification object 330A generated earlier and completes the generation of the product object 340A and the product specification object 350A, the execution control unit 113b starts the document operation. An instruction is given (step S1117).

  In the above description, the request specification object 330A is generated and set prior to the generation of the request object 320A (steps S1102 and S1103), and the link information of the request specification object 330A is transferred in the subsequent inter-object communication. The configuration. However, the present invention is not limited to this, and the processing of S1102 and S1103 may be performed before S1111. For example, the processing of S1102 may be performed prior to the generation of the request object 320A, and the processing of S1103 may be performed immediately before the processing of S1111. Alternatively, the processing of S1102 and S1103 may be performed immediately before the processing of S1111. It may be configured.

  As described above, according to the present embodiment, the integrated application 110 is configured as a collection of object models by object-oriented design, and among these object models, the request management unit 113a performs request management. The management unit 113a includes a request folder class 310, a request class 320, and a request specification class 330 as an analogy of a so-called “folder-file” model, and further includes a product class 340 and a product specification class 350. As a result, user requests can be accepted in a lump, and management from the input of such requests to the output of deliverables can be performed efficiently, and the effort associated with adding new functions can be reduced. It can be.

  The request management program (job processing instruction program) executed by the image forming apparatus according to the present embodiment is a file in an installable format or an executable format, a CD-ROM (Compact Disc Read Only Memory), a flexible disk. (FD), CD-R (CD Recordable), DVD (Digital Versatile Disk), and the like may be provided by being recorded on a computer-readable recording medium. In this case, the CPU 11 reads out the request management program (job processing instruction program) from the storage medium and loads it onto the MEM-P 12, so that the above-described steps (processes), units, or units are included in the image forming apparatus. make it happen.

  Further, the request management program (job processing instruction program) may be provided by being stored on a computer connected to a network such as the Internet and downloaded via the network. Further, such a request management program (job processing instruction program) may be provided or distributed via a network such as the Internet.

  As described above, the request management apparatus, the image forming apparatus, the job processing instruction method, and the job processing instruction program according to the present invention are useful for request management, and are particularly suitable for request management of job processing requests.

1 is a network diagram showing a network environment surrounding a multifunction peripheral. FIG. 3 is an explanatory diagram for explaining hardware of a multifunction peripheral. FIG. 3 is an explanatory diagram for explaining a hierarchical structure of hardware and software in a multifunction peripheral. It is explanatory drawing for demonstrating the structure of an integrated application. It is a UML class diagram showing the configuration of an integrated application. It is explanatory drawing for demonstrating a "directory-file" model. It is explanatory drawing for demonstrating the outline | summary of modeling of a request management part. It is a UML class diagram showing the class structure of a request management part. FIG. 6 is an explanatory diagram for explaining an operation panel of the multifunction machine. It is explanatory drawing for demonstrating the example of a menu displayed on a liquid crystal touch panel. It is a UML collaboration diagram showing the behavior of an object that materializes the class of the request management unit (accepting a new request). It is a UML collaboration diagram showing the behavior (request list request reception) of the object that materializes the class of the request management unit. It is a UML collaboration diagram showing the behavior of the object that materializes the class of the request management unit (accumulation of accumulated product). It is explanatory drawing for demonstrating the concept in the case of adding a new function to an integrated application. It is a UML class diagram which showed the case where subclassification is performed as an example of new function addition. It is a UML collaboration figure explaining the behavior (before new class creation) of the object which materialized the subclassified class. It is a UML collaboration diagram explaining the behavior (creation of a new class) of an object that materializes a subclassed class. It is a UML collaboration figure explaining the behavior (after new class creation) of the object which materialized the subclassified class. It is a UML class figure explaining operation of a class of a request management part at the time of request injection. It is the UML sequence diagram shown in the behavior time series of the object at the time of request input. FIG. 6 is an explanatory diagram illustrating a transition of a software configuration installed in a multifunction peripheral. It is explanatory drawing for demonstrating the hierarchical structure of the hardware and software in the conventional multifunction machine.

Explanation of symbols

1 Image forming device (multifunction machine)
10 Controller 11 CPU
12 MEM-P
12a ROM
12b RAM
13 NB
14 SB
15 AGP
16 ASIC
17 MEM-C
18 HDD
20 Keyboard (Operation panel)
30 FCU
40 USB
50 IEEE1394
60 Engine
DESCRIPTION OF SYMBOLS 100 Software 101 Application layer 102 Service layer 102a Scanner control part 102b Plotter control part 102c Accumulation control part 102d Delivery / mail transmission / reception control part 102e FAX transmission / reception control part 102f Network communication control part 102g Other control part 103 Operating system 110 Integrated application 111 Operation System subsystem 112 management system subsystem 113 execution system subsystem 113a request management unit 113b execution control unit 120 copy application 130 scanner application 140 fax application 150 printer application 200 hardware 201 hardware resource 201a scanner 201b plotter 201c HDD
201d network 201e other resources 310 request folder class (an example of request storage means)
310A Request folder object (an example of a request storage unit)
310a Acceptance state 310b Limit number 310c Request input ()
320 Request class (example of request means)
320A request object (an example of a request means)
320B copy request object (an example of a request means)
320C FAX / Storage request object (an example of request means)
320D copy / store request object (an example of a request means)
320a request state 320b realization ()
330 Request specification class (an example of request specification holding means)
330A request specification object (an example of request specification holding means)
330a Allowable specification 330b User's request 330c Setting ()
See 330d ()
340 product class (example of product means)
340A product object (an example of product means)
340B Deliverable object being executed (example of deliverable means)
340C FAX deliverable object on standby (example of deliverable means)
340D Waiting accumulated product object (an example of product means)
340E Waiting copy product object (example of product means)
340F Waiting accumulated product object (an example of product means)
340a Progress of what can be output 340b Progress of already output 340c Execution state 340d Create ()
350 Product specification class (an example of product specification holding means)
350A product specification object (an example of product specification holding means)
350a Input format 350b Output format 350c User request 400 Operation panel 401 Initial setting key 402 Copy key 403 Copy server key 404 Printer key 405 Transmission key 406 Numeric keypad 407 Clear / stop key 408 Start key 409 Preheating key 410 Reset key 420 Touch panel 421 Document reading button 422 Delete from list button 423 Print condition button 424 Document list example 1
425 Document List Example 2
501 Application before service layer separation 502 Application after service layer separation 503 Common routine separation application 504 Object-oriented application

Claims (20)

A request management device that, when receiving a job processing request by a user operation, instructs execution of a job that responds to the job processing request and manages each job processing request as a request;
Request means for instructing execution of a job in response to the request;
Request specification holding means for holding detailed specifications of the request means;
A request management apparatus comprising: a request storage unit that performs folder management of the request unit and the request specification holding unit.   The request management apparatus according to claim 1, wherein the request unit has a one-to-one correspondence with the request specification holding unit, and holds link information to the request specification holding unit.   The request management apparatus according to claim 1, wherein the request unit is managed by the request storage unit using the request storage unit as a parent of a tree structure.   4. The request management apparatus according to claim 1, wherein the request unit acquires and holds an execution state of a job corresponding to the request unit.   5. The request according to claim 1, wherein the request storage unit generates a request unit corresponding to a type of the user operation when a job processing request is received by a user operation. Management device.   The request storage unit has a limit number of job processing requests that can be accepted and the number of generated request units, and performs a job processing request acceptance determination process based on a difference between these numbers. Item 6. The request management device according to any one of Items 1 to 5.   The request specification unit includes a request specification that defines a specification of the job processing request, and an allowable specification that is used as an alternative specification of the request specification when the request specification cannot be satisfied. The request management apparatus according to any one of 1 to 6.   The request management apparatus according to claim 7, wherein the desired specification includes an input specification and an output specification.   A deliverable means for managing a progress status according to an output deliverable of a job instructed to be executed by the request means, and a deliverable specification holding for holding a specification of the output deliverable among specifications held by the request specification holding means The request management apparatus according to claim 1, further comprising: means.   The request management apparatus according to claim 9, wherein the product unit corresponds to one or a plurality of output products of the job instructed to be executed by the request unit.   The product means includes a progress status of an input material input in accordance with the job processing request and a progress status of the product output by a job corresponding to the job processing request as a part of the product progress status. The request management apparatus according to claim 9, wherein the request management apparatus is managed as follows. It has hardware resources such as a display unit, a printing unit, and an imaging unit, and a common processing unit that executes jobs related to image formation using the hardware resources, and accepts job processing requests related to image formation by user operations An image forming apparatus that executes a job in response to the job processing request in the common processing unit and manages each job processing request as a request,
Request means for instructing the common processing unit to execute a job according to the request;
Request specification holding means for holding detailed specifications of the request means;
An image forming apparatus comprising: a request storage unit that performs folder management of the request unit and the request specification holding unit.   13. The image forming apparatus according to claim 12, wherein the request unit is managed by the request storage unit with the request storage unit as a parent of a tree structure.   The request storage unit has a limit number of job processing requests that can be accepted and the number of generated request units, and performs a job processing request acceptance determination process based on a difference between these numbers. Item 14. The image forming apparatus according to Item 12 or 13.   The request specification unit includes a request specification that defines a specification of the job processing request, and an allowable specification that is used as an alternative specification of the request specification when the request specification cannot be satisfied. The image forming apparatus according to 12, 13, or 14.   A deliverable means for managing a progress status according to an output deliverable of a job instructed to be executed by the request means, and a deliverable specification holding for holding a specification of the output deliverable among specifications held by the request specification holding means The image forming apparatus according to claim 12, further comprising a unit. A job processing instruction method for instructing other subsystems to perform job processing in response to a job processing request received from a user,
Computer
A request specification holding means for generating, for each request, a request specification holding means for holding user request data representing detailed specifications of a request received from a user in its own attribute section;
A request storage means generating step for holding link information of the request specification holding means and a limit number of requests that can be received in its own attribute section, and generating a request storage means for folder management of the request specification holding means; ,
The request storage means is:
If the request is accepted, the limit number data possessed in its own attribute section is read, and a determination step for determining whether or not the request can be entered depending on whether the received request exceeds the limit number;
A request means generating step for generating a request means capable of instructing execution of a job according to the request, when it is determined that the job can be submitted in the determination step;
The request execution step for inputting the request by passing the link information of the request specification holding means to the request means generated by the request means generation step is executed by a computer,
The request means includes
A request specification associating step of associating the self with the request specification holding means by holding the passed link information in its own attribute section;
Causing the computer to execute a reference requesting step for requesting reference of user request data held in the attribute section of the request specification holding unit to the request specification holding unit associated by the association step;
The request specification holding means is:
Based on the reference request of the request means, the user's request data held in its own attribute section is read out, and a reference step passed to the request means is executed by the computer,
The request means includes
A job processing instruction method for causing a computer to execute an instruction step for instructing the other subsystem to start job processing according to user request data acquired from the request specification holding means. The request means, before executing the instruction step,
In accordance with user request data acquired from the request specification holding means, a deliverable means generating step for generating a deliverable means for managing progress according to an output deliverable;
Causing the computer to execute a link information providing step for passing the link information of the request specification holding unit to the product unit generated by the product unit generating step
The deliverable means, after executing the reference step,
According to the user request data acquired from the request specification holding means, among the user request data held by the request specification holding means, a deliverable that holds user request data corresponding to the deliverable means in its own attribute section A product specification holding means generating step for generating a specification holding means;
18. The product specification associating step for associating the product with the product specification holding unit is caused to be executed by a computer by holding the passed link information in its own attribute section. The job processing instruction method described. A job processing instruction program for instructing job processing to other subsystems in response to a job processing request received from a user,
Computer
Request specification holding means that is generated based on a request received from a user and holds user request data representing the detailed specification of the request in its own attribute section;
In the state having the link information of the request specification holding means and the limit number of requests that can be accepted in its own attribute section, and the request storage means for folder management of the request specification holding means,
The request storage means is:
If the request is accepted, the limit number data possessed in its own attribute section is read, and a determination step for determining whether or not the request can be entered depending on whether the received request exceeds the limit number;
A request means generating step for generating a request means capable of instructing execution of a job according to the request, when it is determined that the job can be submitted in the determination step;
The request execution step for inputting the request by passing the link information of the request specification holding means to the request means generated by the request means generation step is executed by a computer,
The request means includes
A request specification associating step of associating the self with the request specification holding means by holding the passed link information in its own attribute section;
Causing the computer to execute a reference requesting step for requesting reference of user request data held in the attribute section of the request specification holding unit to the request specification holding unit associated by the association step;
The request specification holding means is:
Based on the reference request of the request means, the user's request data held in its own attribute section is read out, and a reference step passed to the request means is executed by the computer,
The request means includes
A job processing instruction program for causing a computer to execute an instruction step for instructing the other subsystem to start job processing in accordance with user request data acquired from the request specification holding means. The request means, before executing the instruction step,
In accordance with user request data acquired from the request specification holding means, a deliverable means generating step for generating a deliverable means for managing progress according to an output deliverable;
Causing the computer to execute a link information providing step for passing the link information of the request specification holding unit to the product unit generated by the product unit generating step
The deliverable means, after executing the reference step,
According to the user request data acquired from the request specification holding means, among the user request data held by the request specification holding means, a deliverable that holds user request data corresponding to the deliverable means in its own attribute section A product specification holding means generating step for generating a specification holding means;
20. The product specification associating step for associating the product with the product specification holding means is caused to be executed by a computer by holding the passed link information in its own attribute section. The job processing instruction program described.

Images