JP2006085477A - Accounting management program and image formation apparatus - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To efficiently achieve an accounting process using a plurality of accounting devices. <P>SOLUTION: An accounting management program makes a computer execute an accounting execution process which corresponds to the accounting devices by one to one and instructs accounting execution thereto, and a counter value process which selects one or a plurality accounting execution processes to request the accounting execution to the selected execution processes. The program performs object modeling corresponding to an addition-type accounting device and a substraction-type accounting device by object oriented design and achieves the accounting process by cooperation relationships by objects in an accounting book class, a slip class, a charge table class, a counter value class, a transaction table class, an input amount class, a billing amount class and a billing destination class. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention is mounted on a service providing apparatus that provides a service in response to a user's request or a charging management apparatus that can communicate with the service providing apparatus, and calculates a service charge for a service requested by the user to the service providing apparatus. The present invention relates to a management program and an image forming apparatus.

  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 (R), and a plurality of functions are realized while switching execution processes of these applications. .

  However, since the printer application, the copy application, and the scanner application perform engine control, memory control, system control, and the like separately, wasteful duplication processing has occurred.

  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.

  In Patent Document 2, a communication line usage fee that is generated when the fax function is used is stored as table data, and the printer function provision fee that accompanies the provision of the fax function and the communication line usage fee are as follows. By adding, the user is charged for providing the fax function.

JP 2002-084383 A Japanese Patent Laid-Open No. 10-023189

  However, the invention disclosed in Patent Document 1 shares a processing part for controlling hardware, and does not share all internal processes of each application. For this reason, there is still room for improvement in the application on the multifunction peripheral in order to improve the development efficiency.

  For example, a billing process that accepts a function provision request such as a copy service via the operation panel control software or network control software and charges according to the provided function is a process that is common to each application on the copier However, since it is not a process for directly controlling the hardware, it is realized separately for each application and can be shared.

  The invention disclosed in Patent Document 2 relates to billing processing for a service combining a plurality of functions on a multifunction peripheral, and does not consider performing a plurality of billing processes in parallel. Therefore, when the multi-function peripheral accepts multiple service requests and performs billing processing for each service request, it becomes difficult to accurately manage each billing process, and billing processing is not performed correctly. There is a possibility that a billing error such as this is likely to occur. In particular, in an environment where a plurality of billing devices such as a coin rack device and a key card device can be used, the possibility of such billing mistakes further increases.

  For these reasons, it has become a big issue how to efficiently and highly reliably charge the application installed in the multifunction peripheral. Note that such a problem does not occur only for the multi-function peripheral, but also occurs when, for example, a charging management apparatus that charges a fee-based service is formed.

  SUMMARY An advantage of some aspects of the invention is that it provides a charge management program and an image forming apparatus capable of efficiently realizing charge processing.

  In order to solve the above-described problems and achieve the object, a billing management program according to the first aspect of the present invention is a billing management program that provides a service in response to a user request or a billing management that can communicate with the service providing device. A billing management program that is installed in a device, calculates a service fee for a service requested by the user to the service providing device, and instructs the billing device to perform billing of the service fee, and corresponds to the billing device on a one-to-one basis And a billing execution means for instructing the billing apparatus to execute billing, and one or a plurality of the billing execution means are selected, and the computer functions as a counter means for requesting the billing execution to the selected billing execution means. To do.

  According to a second aspect of the present invention, there is provided a billing management program according to the first aspect of the present invention, wherein the billing execution means is one-to-one with a subtractive billing unit corresponding to the subtractive billing device and one-to-one billing device. And an addition-type charging unit corresponding to the above.

  According to a third aspect of the present invention, there is provided a charge management program according to the first or second aspect, wherein the charge execution means further comprises a management means for managing all the addition-type charge means, One addition-type charging means is selected and charging execution is instructed. If the selected addition-type charging means cannot continue the charging execution, another adding-type charging means is selected to continue the charging execution. And

  According to a fourth aspect of the present invention, there is provided a billing management program according to the third aspect of the present invention, wherein the managing means holds the total amount and the limit amount, and if a billing request is received, the billing amount included in the billing request Is added to the total amount, and charging is instructed to the addition type charging means when a predetermined condition is satisfied.

  According to a fifth aspect of the present invention, there is provided a charge management program according to the third or fourth aspect, wherein the consideration means manages the subtractable charge means and the management means as children of a tree structure, and the management means The addition type charging means is managed as a child of a tree structure.

  According to a sixth aspect of the present invention, there is provided a billing management program according to the fifth aspect of the present invention, further comprising transaction table means for holding a list of available charging devices, wherein the consideration means is a search result of the transaction table means. The subtracting charging unit or the adding charging unit is selected based on the above.

  According to a seventh aspect of the present invention, there is provided a billing management program according to the fifth or sixth aspect, wherein the subtracting billing unit is configured to send the subtracting billing device to the consideration unit when the corresponding subtracting billing device becomes incapable of billing. It is characterized by requesting the change of the billing destination.

  The billing management program according to the invention of claim 8 is the billing management program according to the invention of claim 5, 6 or 7, wherein the billing means is configured to charge the billing amount when the corresponding addition-type billing apparatus becomes incapable of billing. The requesting means is requested to change the billing destination, and the billing amount means requests the billing means to change the billing destination.

  According to a ninth aspect of the present invention, there is provided a billing management program according to any one of the fifth to eighth aspects of the present invention, wherein if the subtracting billing means is selected from the consideration means, the balance of the subtracting billing device held by itself Based on the above, it is determined whether or not the billing can be executed, and the determination result is returned to the consideration means.

  A billing management program according to a tenth aspect of the present invention is the billing management program according to any of the fifth to ninth aspects of the present invention, a book means for receiving a service request notification including a service request content from the control program of the service providing apparatus, and the service request notification. A slip means generated by the book means, and the slip means generates the consideration means and requests the consideration means to perform charging processing.

  The billing management program according to the invention of claim 11 is the charge management program according to the invention of claim 10, which holds a list of charges for the service to be provided, searches for the corresponding service charge in response to the request of the slip means, and responds with the charge It is further characterized by further comprising a charge table means.

  The billing management program according to a twelfth aspect of the invention is characterized in that, in the eleventh aspect of the invention, the slip means does not generate the consideration means when the service fee is free.

  An image forming apparatus according to a thirteenth aspect of the present invention is an image forming apparatus that calculates a service fee of a service requested by a user and instructs the charging device to perform charging of the service fee, wherein the charging device And charging means for instructing the charging apparatus to execute charging, and consideration means for selecting one or a plurality of the charging execution means and requesting the selected charging execution means to execute charging It is characterized by that.

  According to the billing management program of claim 1, the billing execution unit that has a one-to-one correspondence with the billing device, instructs the billing device to execute billing, and selects one or a plurality of billing execution units. Since the computer is made to function as a compensation means for requesting charging to a software developer, software developers and software maintenance personnel can easily grasp the configuration and role of the charging unit and use a plurality of charging devices. In this case, even if service requests are processed in parallel, the charging status can be managed accurately, so that the charging process can be efficiently realized.

  According to the charge management program of claim 2, the charge execution means includes a subtraction charge means corresponding to the subtraction charge apparatus on a one-to-one basis, and an addition charge means corresponding to the addition charge apparatus on a one-to-one basis. Therefore, the present invention has an effect that it is possible to perform efficient billing processing by absorbing the difference in functions inherent in the addition-type billing device and the subtraction-type billing device.

  According to the billing management program of claim 3, the billing execution unit further includes a management unit that manages all the addition-type billing units, and the management unit selects one billing-type billing unit and executes billing. When the selected addition type charging means cannot continue the charging execution, the other charging type charging means is selected to continue the charging execution, so that the charging apparatus can be systematically managed. It is possible to perform an effective charging process.

  According to the billing management program of claim 4, the management means holds the total amount and the limit amount, and when the billing request is received, the billing amount included in the billing request is added to the total amount, Since the billing execution instruction is instructed to the addition-type billing means when the condition is satisfied, there is an effect that the frequency of the billing instruction to the billing apparatus can be reduced and efficient billing processing can be performed.

  According to the charging management program of claim 5, the consideration means manages the subtracting charging means and the management means as children of a tree structure, and the managing means manages the addition charging means as a child of the tree structure. With this configuration, the software developer and software maintenance personnel can easily grasp the configuration and role of the accounting unit and can perform an efficient accounting process.

  The billing management program according to claim 6 further comprises transaction table means for holding a list of available billing devices, and the consideration means is based on a search result of the transaction table means. Since it is configured to select the type billing means, software developers and software maintenance personnel can easily grasp the configuration and role of the billing unit, and can easily add or remove the billing device There is an effect.

  According to the billing management program of claim 7, the subtractive billing means is configured to request the charge means to change the billing destination when the corresponding subtractable billing apparatus becomes incapable of billing. Therefore, it is possible to perform an efficient charging process by switching the charging device according to the state of the charging device.

  According to the billing management program of claim 8, the billing means requests the billing amount means to change the billing destination when the corresponding addition type charging device becomes incapable of charging, and the billing amount Since the means is configured to request the charge means to change the billing destination, the billing device can be switched according to the state of the billing device systematically managed so that efficient billing processing can be performed. Play.

  Further, according to the billing management program according to claim 9, if the subtracting billing means is selected from the consideration means, it determines whether or not billing can be executed based on the balance of the subtracting billing device held by itself. Since the determination result is configured to respond to the consideration means, there is an effect that the accounting process can be surely performed.

  According to the billing management program of claim 10, book means for receiving a service request notification including service request contents from the control program of the service providing apparatus, and slip means generated by the book means for each service request notification; The slip means generates the consideration means and requests the consideration means to perform the billing process, so that it is possible to perform a plurality of billing processes in parallel.

  The billing management program according to the eleventh aspect further comprises a billing table means for holding a list of charges for the service to be provided, searching for a corresponding service charge in response to a request from the slip means, and responding to the charge. As a result, the service fee can be calculated regardless of the type of service to be provided.

  According to the billing management program of claim 12, the slip means is configured not to generate the consideration means when the service fee is free, so that the efficiency is improved even when the service fee is free. The effect that it can perform typical processing is produced.

  According to the image forming apparatus of the thirteenth aspect, the charging execution unit that has a one-to-one correspondence with the charging apparatus and instructs the charging apparatus to execute charging, and the one or more charging execution units are selected and selected. Since the billing execution means is provided with a billing means for requesting billing execution, the software developer and software maintenance personnel can easily grasp the structure and role of the billing unit and use a plurality of billing devices. Even when the service request is processed in parallel or when the service request is processed in parallel, the charging status can be managed accurately, so that the charging process can be efficiently realized.

  Exemplary embodiments of an accounting management program according to the present invention and an image forming apparatus including a computer for executing the program will be described below in detail 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 billing management.

  First, an outline 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, 19, and 20. 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. 19 is an explanation for explaining the transition of the software configuration installed in the multifunction device 1. FIG. 20 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 became normal. For example, as shown in the figure, a client PC, an SMTP (Simple Mail Transfer Protocol) server, an FTP (File Transfer Protocol) server, an accounting server 2, a server PC, and the like are connected to such a network to send and receive electronic mail. And file transfer, and a modem-connected distribution server can communicate with a fax machine outside the office.

  With the progress of such networking, the multifunction device 1 is also connected to such a network and can communicate with a device such as a PC. 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.

  For example, in addition to the normal copy function, the multi function device 1 has a printer function for printing document data or the like in response to a print request from the client PC, and a modem connected to the server PC for document data or the like in response to a fax request from the client PC. It has a fax function that sends it to fax machines in other offices via the Internet, and a storage function that stores received fax documents and copy documents on a built-in hard disk.

  Further, the multifunction device 1 performs billing processing using a billing server 2 connected via a network, in addition to performing billing processing using a device directly connected to the main body of the multifunction device 1 such as the billing device 1a. I was able to do it. Here, the charging device 1a is a device such as a coin rack device for collecting a fee, a preset key card device that records a usage amount of a copy or the like for a subsequent fee collection, and a credit card device. Is a device that manages billing data in order to collect charges later.

  In this way, in order to realize many functions required by the progress of compounding and networking, the software installed in the compound machine 1 is large and complicated. Along with this, the man-hours for developing and maintaining such software have also increased significantly.

  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) 12b.

  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 program / data storage memory, and the RAM 12b is a writable / readable memory used as a program / data development memory, a printer drawing memory, or 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 device 1, and specifically, an integrated application 110 including a charging unit 112a, which is a characteristic part of the present embodiment to be 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. 19 and 20. FIG. 19 is an explanatory diagram showing changes in the software configuration installed in the multifunction machine 1. As shown in the pre-service layer separation application 501 in FIG. 19, 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. 19, 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 of 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 charges for services provided by various functions. It had similar processing such as management 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. 19, 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. 19, 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. 20 is an explanatory diagram showing the configuration of a conventional application at the stage of the service layer separated application 502 shown in FIG. 19 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 simpler than that shown in FIG.

  Next, the internal configuration of the integrated application 110 will be described. FIG. 4 is a block diagram showing the internal configuration of the integrated application 110. As shown in the figure, the integrated application 110 includes 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 process for accepting a user request, a process for instructing execution of the request, and a process for providing the user with information about the execution status and execution result of the request. .

  The management subsystem 112 is a software group that manages the resources of the image forming apparatus 1. Specifically, the management subsystem 112 performs a service for managing 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 request from a user. Specifically, the execution subsystem 113 performs processing from reading a document to outputting a product when a copy request is made.

  The operation system subsystem 111, the management system subsystem 112, and the execution system subsystem 113 mutually request processing as necessary and send the results. In this way, the subsystems cooperate to provide services required for the multifunction device 1 as the integrated application 110 as a whole.

  The management subsystem 112 includes a charging unit 112a that is a characteristic part of the present embodiment. The billing unit 112a performs billing management processing such as acceptance of billing processing, calculation of a billing amount, and a billing processing execution instruction.

  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 for which specifications are formulated by OMG (Object Management Group), and defines a notation for describing the results of modeling. This UML is widely used in the design of object-oriented software.

  As shown in FIG. 5, the integrated application 110 has a plurality of packages, and the integrated application 110 itself is one package. Here, the package is a group of components (symbols) of the UML model, and is expressed by a symbol in the form of a folder with a tab on the upper left. A straight line connecting the packages indicates that there is a relationship such as a processing request between the packages.

  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 management subsystem 112 is a package having an accounting unit 112a inside. 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 a processing request (for example, 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, accounting unit 112a, which is a characteristic part of the present embodiment, will be described in detail. Note that the charging unit 112a does not simply convert existing processing into objects when designing based on object orientation, and configures an object model so that functions can be added or modified more easily. The configuration of the object model will be described with reference to FIGS.

  FIG. 6 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 preheating key. 409, a reset key 410, and a liquid crystal touch panel 420.

  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. Further, when the user wants to make a copy, the copy key 402 is stored. When the copy result is stored in the multifunction device 1, the copy server key 403 is displayed. When the operation related to the printer is performed, the printer key 404 is displayed. 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. 7 shows an example of a menu displayed on the liquid crystal touch panel 420. This menu is displayed by touching the copy key 402 shown in FIG. As shown in FIG. 7, on this liquid crystal touch panel 420, an automatic density button 421, an automatic paper selection button 422, an equal magnification button 423, and the like are displayed. The user designates the detailed contents of the copy function by selecting these buttons, and the multi-function device 1 that has received this instruction executes a copy process according to the instructed contents.

  Billing for such copy processing is performed based on the type of copy (for example, monochrome copy or color copy), the type of recording paper (for example, A4 or A3), the number of copies, and the like. For example, when the charge for A4 monochrome copying is 10 yen per sheet, if the user inserts a 100-yen coin into the charging apparatus 1a and designates 8 such copies, the fee charged Becomes 80 yen, 80 yen is collected, and 20 yen is returned.

  In addition, when a plurality of users using the network instructs the multifunction device 1 to print electronic data or instructs the facsimile of the electronic data, the charging server 2 performs these processes. The corresponding billing history is accumulated. Then, billing is performed based on the accumulated billing history.

  As described above, due to the development of the network, a plurality of users who use the network and users who operate the multifunction device 1 often request service provision at the same time. It is necessary to go to. In addition to the billing device 1a directly connected to the multifunction device 1, a billing management device (for example, billing server 2) connected to the network and communicable with the multifunction device 1 can be a device that performs billing. There are many devices that do this. Therefore, it is necessary to reliably select and switch a device that performs charging so that there are no charging errors such as double charging or non-charging.

  Here, the types of charging apparatuses will be described. The charging device includes an addition type charging device and a subtraction type charging device. Examples of the addition type charging device include an addition type key card device, a credit card device, and a charging server 2. Examples of the subtracting type charging device include a subtracting type key card device, a coin rack device, and a prepaid card device. As described above, there are various types of billing apparatuses, and there are many cases where a plurality of billing apparatuses are connected to perform billing by switching billing destinations.

  FIG. 8 is an explanatory diagram for explaining the outline of the billing process for service consideration. As shown in the figure, when a user makes a service request for a paid copy service or the like by operating the multi-function device 1, in this billing process, first, the price of the service to be provided is calculated, and then the billing device After selecting a billing apparatus capable of performing billing from (1a and 2) and providing the service, the selected billing apparatus collects the fee.

  If there are a large number of charging devices that can be used, it is also possible to perform charging by sequentially switching a plurality of charging devices. For example, if the count value of an addition-type billing device that is executing billing reaches the maximum value, the service provision is stopped if the billing execution destination is switched to another addition-type billing device and billing is executed. Service charges can be collected (combination of billing devices).

  As described above, when a plurality of charging apparatuses are used, a charging management mechanism that can flexibly cope with switching of charging apparatuses, addition of charging apparatuses, and removal of charging apparatuses is required. In addition, it is necessary to perform object modeling based on characteristics unique to a charging device such as an addition charging device or a subtracting charging device.

  In view of this, the charging unit 112a, which is a characteristic part of the present embodiment, has designed each class with a focus on classes corresponding to the addition type charging device and the subtraction type charging device and a class for managing switching of each charging device. FIG. 9 is a UML class diagram showing the class structure of the accounting unit 112a. As shown in the figure, the charging unit 112a includes a book class 310 that accepts user service requests, a slip class 320 that manages each service request as a “slip”, a charge table class 330 that holds a unit price list of services, a service Price class 340 for calculating the price of payment and instructing collection of the price, transaction table class 350 for holding a list of billing execution destinations, input amount class 360 corresponding to the subtraction type charging device, and billing amount class for collecting the addition type charging device 370 and a billing destination class 380 corresponding to the addition type charging device.

  Here, the unit of “slip” will be described. The unit of the slip is basically one “job” per “slip”, but the unit of the slip may be different from this. Note that “job” refers to a process execution unit until creation of a product (for example, a copied recording sheet) is completed, and indicates from the start of input to the end of output as the entire multifunction peripheral.

  For example, when the user requests 10 monochrome copies, if “10 monochrome copies” is defined as one “job”, one slip includes a request for “10 monochrome copies”. However, if “one monochrome copy” is defined as one “job”, “one monochrome copy” can be defined as one slip. In addition, when “5 color copies” and “5 monochrome copies” are requested, each of these requests is basically one voucher. However, these requests are combined into one voucher. You can also.

  Next, a class description method in the class and UML class diagram will be described. A class is a concept corresponding to a design drawing of an object constituting an object-oriented system, and defines attributes and processes in an object and a relationship with other objects.

  The class in the UML class diagram is described as a rectangle having three sections. From the top, each section is called a name section 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. For example, a rectangular name section indicating the book class 310 indicates that the class name of the class is “book”, and an attribute section indicates that the attribute of the class is “state”, and the operation section Indicates that the operations possessed by the class are “fill ()” and “cancel ()”.

  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 “Enter ()”, and to describe an argument to be passed to the operation, such as “(Argument 1, Argument 2)” There is also.

  Next, an outline of the class of charging unit 112a, which is a characteristic part of the present embodiment, will be described. As described above, the billing unit 112a includes the book class 310, the slip class 320, the fee table class 330, the consideration class 340, the transaction table class 350, the input amount class 360, the invoice amount class 370, and the invoice destination class 380. Below, the outline | summary of these classes is demonstrated first.

  The book class 310 is a class that accepts detailed contents (for example, paper size and color mode) of a chargeable function (for example, copy function and fax function), and the slip class 320 holds the received detailed contents. It is a class that keeps the billing status. The charge table class 330 is a class that holds a unit price list of functions to be charged and searches for the corresponding charge. The charge class 340 determines whether the charge is collected or not and determines a charging device as a charge destination. The transaction table class 350 is a class for holding a charging device usage restriction list for each provided function and searching for available charging devices.

  The input amount class 360 is a class for managing the state of a subtracting type charging apparatus such as a coin rack apparatus and instructing the subtracting type charging apparatus to execute charging. Further, the billing amount class 370 is a class for bundling an addition type charging device and managing the timing of addition and the total value of the fee to be added. The billing destination class 380 is an addition type charging device such as an addition type key card device. This is a class that manages the status and instructs the addition-type charging apparatus that manages the status to execute charging.

  Next, the contents of each class will be described in more detail. The book class 310 is a class that accepts detailed contents (for example, paper size and color mode) of functions (for example, a copy function and a fax function) to be charged. Specifically, this book class 310 has a state 310a as an attribute, and has an entry () 310b and a cancel () 310c as operations. When an object that materializes the book class 310 is generated, the state 310a is expanded on the RAM 12b, so that this data (attribute) can be written and read.

  The state 310a represents the current processing state of the book, and there are two states, a closed state and an open state. The closed state represents a state in which the book is closed because there is no slip to be processed, and the open state represents a state in which the book is opened and the slip is being processed.

  Fill in () 310b accepts the user's order via the operation subsystem 111, and if it is a new order, generates an object of the slip class 320 and delivers the contents of the order to this object. When an order change is received, the object of the corresponding slip class 320 is searched, and the order contents held by the object are rewritten.

  Here, the “order” represents a unit of use when the user uses the copy function or the fax function. For example, when the user designates 10 copies of “A4 monochrome copy”, “10 copies of A4 monochrome copy” is set as one “order”. In this case, “one A4 monochrome copy” may be one “order”, and there may be ten such “orders”. If the user instructs “10 A4 monochrome copies” and “10 A4 color copies” at the same time, “10 A4 monochrome copies” is set as one “order” and “10 A4 color copies”. ”Is one“ order ”, but“ 10 A4 monochrome copies ”and“ 10 A4 color copies ”can also be one“ order ”. The “order content” represents the “detailed content” such as the paper size and the color mode.

  Further, cancel () 310 c performs a cancel process for the received order. Specifically, this cancel () 310 c deletes the object of the slip class 320 that is the target of order cancellation.

  The slip class 320 is a class that holds the received detailed contents and holds the charging status. More specifically, the slip class 320 has a status 320a, a number 320b, a service content 320c, and a charge 320d as attributes, and is filled in () 320e, processed () 320f, and completed (). 320 g. When an object that materializes the slip class 320 is generated, the state 320a, the number 320b, the service content 320c, and the charge 320d are expanded on the RAM 12b, so that these data (attributes) are written and read. It becomes possible.

  The state 320a represents the processing state of the current slip class 320, and there are three states: being filled in, being processed, and processed. The filled-in state indicates a state in which the received detailed contents can be changed, the processing state indicates a state where the charging process is continuing, and the processed state indicates that the charging process has been completed. Shows the state. Here, the state transition between these states and each state will be described with reference to FIG. FIG. 10 is a UML state chart diagram showing the state transition of the slip class 320 (the state transition of the state held by the state 320a).

  As shown in the figure, if the current state is “filling in”, the state transition to the “processing” state is possible. Specifically, when () 320e to be filled in is called in the “filling” state (step S101), the state remains “filling”. When () 320f to be processed is called (step S102), the state transitions to the “processing” state.

  Also, as shown in the figure, if the current state is “processing”, state transition to the “filling” and “processed” states is possible. Specifically, when () 320 f to be processed in the “processing” state is called (step S 103), the state remains in the “processing” state. When the entry () 320e is called (step S104), the state transitions to the “filling” state, and when the completion () 320g is called (step S105), the state transitions to the “processed” state.

  As described above, the operations that can be executed are limited according to the respective states of the state 320a, and the transition destination states due to the executed operations are also limited. By using such concepts of “state” and “state transition”, the slip class 320 can accurately grasp the processing state of “slip”.

  Returning to FIG. 9, the number 320b will be described. The number 320b holds a value for identifying each object of the slip class 320. This number 320b is referred to when an object of another class specifies the object of the slip class 320 to be processed and performs processing.

  The service content 320c holds detailed content of each function such as copy and fax. This detailed content refers to the detailed content of the function requested by the user, such as “10 sheets of A4 monochrome copy” and “100 sheets of A3 color duplex copy”. The fee 320d holds a service fee corresponding to the service content 320c.

  The entry () 320e performs a process of holding the detailed contents notified from the book class 310 in the service contents 320c and whether or not the charge class 340 can collect the amount held in the charge 320d. Processing to request confirmation and determination of billing method. Further, the processing () 320 f performs processing for requesting the consideration class 340 to collect the amount held in the fee 320 d. Further, the completed () 320 g performs the termination process of the slip class 320.

  The charge table class 330 is a class that holds a unit price list of functions to be charged and searches for a corresponding charge. Specifically, the charge schedule class 330 has a unit price list 330a as an attribute and a search () 330b as an operation. Note that when an object that materializes the charge table class 330 is generated, the unit price list 330a is expanded on the RAM 12b, so that this data (attribute) can be written and read.

  The unit price list 330a holds unit prices for each function such as a copy function and a fax function. Search () 330b is called from the slip class 320, acquires the unit price of the designated function by searching the unit price list 340a, and notifies the caller of the acquired unit price.

  The consideration class 340 is a class for determining whether or not a fee is collected and determining a billing device as a billing destination. Specifically, the consideration class 340 has a state 340a as an attribute, and has an exchange () 340 b, a receipt confirmation () 340 c and a replacement request () 340 d as operations. When an object in which the consideration class 340 is materialized is generated, the state 340a is expanded on the RAM 12b, so that this data (attribute) can be written and read.

  The state 340a represents the processing state of the current consideration class 340, and there are three states: non-exchangeable, exchangeable, and replacement. The non-exchangeable state represents a state in which charges cannot be exchanged for a provided function, in other words, a state in which functions cannot be provided because charges cannot be collected. Further, the exchangeable state represents a state where functions can be provided because charges can be collected, and the in-replacement state represents a state in which a charging device for performing charge collection is being changed. Here, the state transition between these states and each state will be described with reference to FIG. FIG. 11 is a UML state chart diagram showing the state transition of the consideration class 340 (the state transition of the state held by the state 340a).

  As shown in the figure, if the current state is “non-replaceable”, the state transition to the “replaceable” and “being replaced” states is possible. Specifically, in the “non-exchangeable” state, the confirmation of receipt / non-reception () 340c is called, and if the return value is “NG” (step S201), the state remains “non-exchangeable”. If the return value is “OK” (step S202), the state transitions to the “non-exchangeable” state. Further, when the replacement request () 340d is called (step S203), the state transitions to the “currently changing” state.

  Further, as shown in the figure, if the current state is “replaceable”, the state transition to the “non-replaceable” and “being replaced” states is possible. Specifically, when () 340b to be exchanged is called in the “exchangeable” state (step S204), the state remains “exchangeable”. Even when () 340 c for confirming receipt / rejection is called and the return value is “OK” (step S 204), the state remains “exchangeable”. Further, () 340c for confirming receipt / non-receipt is called, and if the return value is “NG” (step S205), the state transitions to the “non-exchangeable” state, and when the replacement request () 340d is called ( Step S206), the state transitions to the “being replaced” state.

  Further, if the current state is “being replaced”, it is possible to change the state to the “not replaceable” and “replaceable” states. Specifically, if the receipt is confirmed () 340c is called in the “currently being exchanged” state and the return value is “NG” (step S207), the state transitions to the “non-exchangeable” state, and this is required. If the return value is “OK” (step S208), the state transitions to the “exchangeable” state.

  As described above, the operations that can be executed are limited according to the respective states of the state 340a, and the transition destination states by the executed operations are also limited. By using such concepts of “state” and “state transition”, the consideration class 340 can accurately grasp the exchangeability state of the consideration.

  Returning to FIG. 9, the exchange () 340b will be described. The exchange () 340b to be exchanged performs the accounting by the accounting method determined by executing the () 340c for confirming the receipt / non-acceptance. For example, if the determined charging method is a subtractive charging apparatus, the charging amount class 360 is charged, and if it is an adding charging apparatus, the charging amount class 370 is charged.

  The receipt confirmation () 340 c determines the billing method and performs a process of confirming whether the fee can be collected. For example, if the amount held in the charge 320d of the slip class 320 is 1000 yen, and a billing device that can collect this amount is found, this receipt confirmation () 340 c returns “OK”. On the other hand, if a charging device that can collect 1000 yen is not found, “NG” is returned. In addition, the replacement request () 340d performs processing for changing the charging method.

  The transaction table class 350 is a class that holds a usage restriction list of charging devices for each provided function and searches for available charging devices. Specifically, the transaction table class 350 has a restriction list 350a as an attribute, and has a search () 350b and an update () 350c as operations. When an object in which the transaction table class 350 is materialized is generated, the restriction list 350a is expanded on the RAM 12b, so that this data (attribute) can be written and read.

  The restriction list 350a holds a list of available charging methods for each function to be charged such as a copy function. For example, if the coin rack device cannot be selected as a billing method in the fax function, the list of billing methods that can be used in the fax function does not include the coin rack device. In the case of a function for which the usage fee is free, information indicating that there is no charging method for the function is stored. The charging method list may include the priority order of each charging device. The search () 350b retrieves the corresponding available charging method from the restriction list 350a and performs processing to notify the caller. The update () 350c performs a process of updating the restriction list 350a.

  The investment amount class 360 is a class for managing the state of a subtracting charging device such as a coin rack device and instructing the subtracting charging device to perform charging. Specifically, the input money amount class 360 has a state 360a, a name 360b, and a balance 360c as attributes, and confirms () 360d, subtracts () 360e, adds () 360f, and returns as operations. To have 360g. When an object that materializes the input amount class 360 is generated, the state 360a, name 360b, and balance 360c are expanded on the RAM 12b, so that this data (attribute) can be written and read. Become.

  The state 360a represents the processing state of the current investment amount class 360, and there are two states, insufficient balance and sufficient balance. The insufficient balance state means that the balance of the corresponding subtracting charging device is smaller than the amount held in the charge 320d of the slip class 320. The sufficient balance state means that the balance is held in the charge 320d. It shows the state that is more than the amount of money. Here, the state transition between these states and each state will be described with reference to FIG. FIG. 12 is a UML state chart diagram showing the state transition of the investment amount class 360 (the state transition of the state held by the state 360a).

  As shown in the figure, if the current state is “insufficient balance”, the state transition to the “balance sufficient” state is possible. More specifically, even when add () 360 f or return () 360 g is called in the “insufficient balance” state (step S 301), the state remains “insufficient balance”. However, if advance check () 360d is called and the return value is “OK” (step S302), the state transitions to the “Balance sufficient” state.

  Further, as shown in the figure, if the current state is “sufficient balance”, the state transition to the “insufficient balance” state is possible. Specifically, even when add () 360 f or subtract () 360 e is called in the “balance enough” state (step S 303), the state remains “balance enough”. However, if advance check () 360d is called and the return value is “NG” (step S304), the state transitions to the “insufficient balance” state.

  The state transition between the “insufficient balance” state and the “balance sufficient” state is performed only when the advance confirmation () 360d is called, and is subtracted () 360e, added () 360f, and returned () When 360d is called, this state transition is not performed. As described above, the operations that can be executed are limited according to the respective states of the state 360a, and the transition destination states due to the executed operations are also limited. By using such concepts of “state” and “state transition”, the investment amount class 360 can accurately grasp the balance state of the subtracting accounting apparatus.

  Returning to FIG. 9, the name 360b will be described. The name 360b holds the name (including abbreviations) of a subtracting charging device such as a coin rack device or a subtracting key card device, and the balance 360c holds a balance such as the balance of the inserted money and a count value.

  The prior confirmation () 360d compares the amount (charge) held in the charge 320d of the slip class 320 with the amount (balance) held in the balance 360c, and is it possible to collect such charge? A process to confirm whether or not is performed. The prior confirmation () 360d returns “OK” to the caller if collection is possible, and “NG” if collection is impossible.

  Subtracting () 360e performs processing for causing the corresponding subtracting charging apparatus to perform charging, and adding () 360f performs processing for adding the amount added to the subtracting charging apparatus to the balance 360c. Also, (360g) to be returned is the value of the balance 360c when the balance of the subtractive charging device becomes 0 or when the user presses the return button of the subtractive billing device and the balance is returned. Perform the process of setting it to zero.

  The charge amount class 370 is a class that bundles an addition type charging device such as an addition type key card device and manages the timing of addition and the total value of the charges to be added. Specifically, the billing amount class 370 has, as attributes, a state 370a, a total amount 370b, a limit amount 370c, and a settlement date 370d, and evaluates () 370e, adds () 370f, and settles as operations. () 370 g and replacement request () 370 h. When an object that materializes the billing amount class 370 is generated, the state 370a, the total amount 370b, the limit amount 370c, and the settlement date 370d are expanded on the RAM 12b, so that these data (attributes) are written and Reading can be performed.

  The state 370a represents the processing state of the current billing amount class 370, and there are four states: replaceable, addable, non-addable and being settled. The replaceable state indicates a state in which the chargeable billing device as a billing destination can be switched, and the addable state indicates a state in which charges can be collected to any of the chargeable billing devices. The state represents a state in which no charge collection is possible using any of the addition type charging devices. Further, the state of being settled indicates that fee collection (settlement) is being processed. Here, the state transition between these states and each state will be described with reference to FIG. FIG. 13 is a UML state chart diagram showing the state transition of the charge amount class 370 (the state transition of the state held by the state 370a).

  As shown in the figure, if the current state is “replaceable”, the state transition to the “addable” state is possible. Specifically, even if the replacement request () 370 h is called in the “replaceable” state (step S 401), the state remains “replaceable”. When () 370 f to be added is called (step S 402), the state transitions to the “addable” state.

  Also, as shown in the figure, if the current state is “addable”, state transition to the “settlement” and “addition impossible” states is possible. Specifically, even if () 370 f is called in the “addable” state (step S 403), the state remains “addable”. Further, when () 370 g is called up by specifying the check-out date 370 d (step S 404), the state transitions to the “settlement” state, and the addition is performed () 370 f is called and the addition process is performed. When the forehead 370c is reached (step S405), the state transitions to an “addition impossible” state.

  Further, if the current state is “cannot be added”, the state transition to the “settlement” state is possible. Specifically, when () 370 g that is settled under the condition of “immediately” in the “not addable” state is called (step S 406), the state transitions to the “under settlement” state. Furthermore, if the current state is “settlement”, the state transition to the “replaceable” state is possible. Specifically, when the settlement is completed in the “settlement” state, the state transitions to the “replaceable” state (step S407).

  As described above, the operations that can be executed are limited according to the respective states of the state 370a, and the transition destination states due to the executed operations are also limited. By using such concepts of “state” and “state transition”, the billing amount class 370 can manage the bundled charging device in a bundle, and can switch the charging device as necessary. .

  Returning to FIG. 9, the total amount 370b will be described. The total amount 370b holds the fee for the provided function. The total amount 370b is added at any time during the provision of the function, and when the settlement () 370g is called, charges are collected (addition of count value, etc.). Further, the limit amount 370c holds the upper limit value of the charge that can be added, and the payment date 370d holds the date and time of payment when the adjustment processing is performed later.

  The assessing () 370 e performs processing for confirming whether or not the amount (charge) held in the total amount 370 b can be collected for the billing destination class 380 under management, and adds () 370f performs a process of adding the service charge provided to the total amount 370b. Further, the settlement () 370 g performs a process of instructing the billing destination class 380 selected as the billing destination, and the replacement request () 370 h is a switching (attachment) of the billing destination class 380 serving as the billing destination. (Replacement) is performed.

  The billing destination class 380 is a class that manages the state of an addition-type charging device such as an addition-type key card device, and instructs the addition-type charging device that manages the charging execution. Specifically, this billing destination class 380 has a state 380a and a name 380b as attributes, and has a request () 380c, a valid () 380d, and a invalid () 380e as operations. When an object that materializes the billing destination class 380 is generated, the state 380a and the name 380b are expanded on the RAM 12b, so that these data (attributes) can be written and read.

  The state 380a represents the current processing state of the billing destination class 380, and there are two states, an invalid state and a valid state. The invalid state represents a state in which use of the corresponding addition type charging apparatus is not permitted, and the valid state represents a state in which use of the corresponding addition type charging apparatus is permitted. The name 380b holds the name (including abbreviations) of an addition type charging device such as an addition type key card device or a credit card device.

  The request () 380 c performs processing for instructing the corresponding addition-type charging device to execute charging, and the setting is enabled () 380 d performs processing for giving use permission to the corresponding addition-type charging device and disables it. Execute () 380 e performs processing for canceling the use permission for the corresponding addition type charging apparatus.

  Next, the relationship between the classes shown in FIG. 9 will be described. As shown in the figure, in the UML class diagram, when there is some relationship between classes, rectangles representing those classes are connected by a straight line. The characters near both ends of this line represent the class role, and the numbers represent the multiplicity of the class. Here, the role is the role of the class with respect to the other class connected by a straight line, and the multiplicity is the number of objects generated in association with the object of the other class connected by a straight line. That is.

  For example, the role of the slip class 320 as viewed from the book class 310 is “binding”, and the role of the book class 310 as viewed from the slip class 320 is “binding destination”. The multiplicity of the book class 310 is “1”, and the multiplicity of the slip class 320 is “0..n”. Here, “0..n” indicates that the multiplicity of the slip class 320 is in the range of 0 to n. 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 book class 310 and the slip class 320 will be described. There is only one object of the book class 310 in the charging unit 112a, and the object of the slip class 320 is generated by the object of the book class 310 for each function request of the user. That is, when a plurality of functions (such as a copy function and a printer function) are provided at the same time, slip class 320 objects corresponding to the number of functions provided at the same time are generated. Therefore, the number of objects in the book class 310 is in the range of 0 to n. Here, the number of objects of 0 indicates a case where there is no function being provided and there are no objects of the slip class 320, and although the upper limit of the number of such objects is n, naturally, the hardware specification Shall be restricted by the above.

  The book class 310 has a role of “binding destination (administrator)” when viewed from the slip class 320, while the slip class 320 is “bound (managed)” when viewed from the book class 310. It has a role as "

  Next, the relationship between the slip class 320 and the fee schedule class 330 will be described. An object of the slip class 320 is generated for each function to be provided, and a fee is generated for each such object. Therefore, the slip class 320 requests the fee table class 330 to search for the unit price of the fee, and calculates the fee based on this There is a need. Therefore, the slip class 320 and the fee table class 330 have a relationship of “searcher” and “unit price”. Further, there is only one object of the fee schedule class 330 in the charging unit 112a. As described above, there are as many objects of the slip class 320 as there are functions provided at the same time, and therefore, there exist in the range of 0 to n with respect to the objects of the fee table class 330.

  Next, the relationship between the slip class 320 and the consideration class 340 will be described. An object of the slip class 320 is generated for each function to be provided, and a charge (a price for the provided function) is generated for each such object. Therefore, the slip class 320 and the consideration class 340 have a relationship between “biller” and “consideration”. Further, since one object of the consideration class 330 exists for one object of the slip class 320, each object has a one-to-one relationship. If no fee collection is required, there is no object of the consideration class 340 corresponding to the object of the slip class 320. Therefore, the object of the consideration class 340 is 0 or more and 1 or less with respect to the object of the slip class 320. It exists in the range.

  Next, the relationship between the consideration class 340 and the transaction table class 350 will be described. The consideration class 340 needs to acquire an available (unrestricted use) billing device prior to the exchange (collection of charges) of the consideration. Therefore, the consideration class 340 and the transaction table class 350 have a relationship of “searcher” and “restriction”. The relationship between the multiplicity of both classes is the same as the relationship between the slip class 320 and the charge class 330 described above.

  Next, the relationship between the consideration class 340 and the investment amount class 360 will be described. The consideration class 340 instructs the input amount class 360, which is a class corresponding to the subtraction-type charging apparatus, to execute charging when the subtraction-type charging apparatus is selected as a price exchange destination (charge collection destination). Therefore, the consideration class 340 and the input amount class 360 have a relationship between “consideration” and “billing executor”. Note that there may be no subtractable accounting device that can be selected, and there may be a plurality of subtracting accounting devices. Therefore, there are 0 to n objects for the input amount class 360 for the object of the consideration class 340. To do.

  Next, the relationship between the consideration class 340 and the charge amount class 370 will be described. The consideration class 340 instructs the billing amount class 370, which is a class that manages the addition-type charging apparatus, to execute charging when the addition-type charging apparatus is selected as a destination for price exchange (charge collection). Therefore, the consideration class 34 and the billing amount class 370 have a relationship of “consideration” and “charger”. In addition, there is a one-to-one relationship between the charge amount class 370 object that manages bundled accounting devices in a bundle, and the consideration class 340 object. Since there is no charge amount class 370 object, the charge amount class 370 object exists in the range of 0 to 1 with respect to the object of the consideration class 340.

  Finally, the relationship between the billing amount class 370 and the billing destination class 380 will be described. The charge amount class 370 object selects one object as a charge execution destination from among the objects of the charge destination class 380 corresponding to each addition type charging device, and other objects as alternative candidates for the charge execution destination to manage. Accordingly, the billing amount class 370 and the billing destination class 380 have a relationship of “selector” and “charging agent”, and also have a relationship of “selector” and “preliminary agent”. Note that there is one object that is a “billing agent”, and there are one or more objects that are “standby agents” in the range of 1 to n.

  In this way, the book class 310, slip class 320, fee table class 330, consideration class 340, transaction table class 350, input amount class 360, invoice amount class 370, and invoice destination class 380 are mutually related. In cooperation with each other, functions necessary for the charging unit 112a are realized.

  Next, an example of the execution procedure of each class operation shown in FIG. 9 will be described. FIG. 14 is a UML sequence diagram illustrating an operation execution procedure when a function provision request is received.

  Here, the UML sequence diagram will be described. Each rectangle arranged in the upper part of FIG. 14 indicates a class object. A line extending downward from each object is a line (lifeline) indicating that each object is alive, and time is considered to flow from the top to the bottom. An elongated rectangle present on this line indicates a period during which the object is actually active (active period).

  A horizontal arrow connecting the lifelines indicates execution of an operation included in the object. Specifically, this arrow indicates that the original object of the arrow calls an operation included in the object at the end of the arrow. Further, when the arrow points to its own object, it means that the object calls the operation included in itself.

  As shown in FIG. 14, when the user operates the operation panel 400 of the multifunction device 1 and sets the function contents of the function that the user wants to provide, the setting contents (function contents) are notified to the operation subsystem 111. The Then, the operational subsystem 111 calls () 310b to be entered in the book object 310A (step S501) and notifies the book object 310A of the function content. Subsequently, the book object 310A generates a slip object 320A, calls () to fill in the generated slip object 320A (step S502), and notifies the slip object 320A of the function content. In this way, the slip object 320A reflecting the “function content” set by the user is generated.

  When the operation subsystem 111 receives a request for providing a plurality of functions, the book object 310A generates a number of slip objects 320A corresponding to the received functions, and functions to each generated slip object 320A. Notify the contents. When the operation subsystem receives a change request, the book object 310A does not generate the slip object 320A but notifies the corresponding slip object 320A of the change contents.

  Subsequently, the slip object 320A calls () 330b to search for the charge table object 330A (step S503), and requests the search for the charge of the function content. The charge table object 330A requested to search returns the corresponding “charge” to the slip object 320A as a search result (step S504). The slip object 320A that has received the search result writes the search result in the fee 320d.

  The slip object 320A confirms whether or not the consideration object 340A can be received () 340c (step S505), and requests the consideration object 340A to determine a charging apparatus that can receive the “fee”. Upon receiving the request, the consideration object 340A calls () 350b to search for the transaction table object 350A (step S506), and requests a search for a charging device capable of receiving the “fee”. The transaction table object 350A requested to search returns the corresponding charging device (charging target) to the consideration object 340A as a search result (step S507).

  For example, when the billing object notified as the search result is a subtractive billing apparatus (step S508), the consideration object 340A confirms the input amount object 360A in advance using the “charge” read from the charge 320d as an argument. () 360d is called (step S509), and a request is made to confirm whether or not the remaining balance of the subtracting accounting apparatus is sufficient. If the charge object notified as the search result is an addition-type charge device, the consideration object 340A calls () 370e to be assessed by the charge amount object 370A. In this way, when it is determined whether or not the service fee can be received, the user who made the function provision request is notified by displaying the receipt or not on the liquid crystal touch panel 420.

  Next, a processing procedure for collecting a service fee (a consideration for the provided service) when providing the service requested by the user will be described with reference to FIGS. 15 and 16. FIG. 15 is a UML sequence diagram showing an operation execution procedure when charging is performed by selecting a subtracting charging apparatus, and FIG. 16 is an operation execution procedure when charging is performed by selecting an addition charging apparatus. It is a UML sequence diagram which shows.

  First, the procedure of the charging process when the subtractive charging device is selected will be described. As shown in FIG. 15, when the function provision to the user is completed, the execution subsystem 113 notifies the corresponding slip object 320A that the function provision has been completed. This notification is performed by calling () 320f processed by the slip object 320A (step S601). The slip object 320A notified of the completion of the function provision reads the value of the charge 320d held in its own attribute section, and requests the corresponding consideration object 340A to collect this value (service charge). Specifically, the slip object 320A sets the value of the read charge 320d as an argument and then calls the exchanged object 340A () 340b for the corresponding consideration object 340A (step S602).

  Then, the consideration object 340A requested to collect the fee subtracts the charge amount execution request from the input amount object 360A from the input amount object 360A corresponding to the subtracting charging device such as a coin rack device ( ) 360e is called (step S603).

  Next, a charging process procedure when the addition type charging apparatus is selected will be described. Steps S701 and S702 shown in FIG. 16 are the same procedures as S601 and S602 shown in FIG. The consideration object 340A requested to collect the fee requests the billing amount object 370A, which manages the addition type charging device such as the addition type key card device, to execute the addition of the fee. Specifically, the consideration object 340A calls 370f to which the charge amount object 370A is added (step S703).

  The called billing amount object 370A adds the notified fee to the total amount 370b held in its own attribute section. Then, if a predetermined condition for executing the settlement is satisfied, the billing amount object 370A calls () 370g to settle itself (step S704). The billing amount object 370A that calls () 370g to be settled by itself sets the value of the total amount 370b as an argument, and then calls () 380c that is billed by the billing destination object 380A corresponding to the addition type charging device ( In step S705, a request for charging is made.

  Next, FIG. 17 shows the charging device replacement procedure when the charging device in use is in an invalid state (for example, a state in which the balance of the coin rack device is returned or a state in which the card of the key card device is removed). This will be described with reference to FIG. FIG. 17 is a UML sequence diagram showing an execution procedure of an operation when a replacement request is made from the selected subtracting charging apparatus. FIG. 18 is a flowchart of an operation when a replacement request is made from the selected addition charging apparatus. It is a UML sequence diagram which shows an execution procedure.

  First, the replacement procedure when the charging device in use is a subtractive charging device will be described. As shown in FIG. 17, the management subsystem 112 that has been notified that the subtractive charging device being used has become invalid calls the return () 360g of the corresponding input amount object 360A (step S801). . The called-in money object 360A that has been called calls up a replacement request () 340d of the consideration object 340A (step S802) and requests replacement of the accounting device. Then, the consideration object 340A that has received the replacement request reselects the charging device and performs the charging device replacement process.

  Next, a replacement procedure in the case where the charging device in use is an addition-type charging device will be described. As shown in FIG. 18, the management subsystem 112 that has been notified that the add-on billing device being used has become invalid calls the invalid billing destination object 380A () 380e (step S901). ), The corresponding billing apparatus is in an invalid state. The called billing destination object 380A calls a replacement request () 370h of the billing amount object 370A (step S902), and requests replacement of the charging device. The called billing amount object 370A further calls a replacement request () 340d of the consideration object 340A (step S903) and requests replacement of the accounting device. Then, the consideration object 340A that has received the replacement request reselects the charging device and performs the charging device replacement process.

  As described above, in the present embodiment, the mechanism of the charging unit is constructed by object-oriented design, and object modeling corresponding to the addition type charging device and the subtraction type charging device is performed, and the book class, slip class, fee By using the table class, consideration class, transaction table class, input amount class, invoice amount class, and invoice destination class, this accounting unit has been realized, so the software developer and software maintenance personnel have the configuration and role of the accounting unit. It can be easily grasped. In addition, since the charging apparatus is systematically managed and the charging apparatus is switched according to the state of the charging apparatus, the charging apparatus can be easily added or removed. Furthermore, the object modeling is performed so that the billing unit absorbs the difference in function between the billing apparatuses, so that efficient billing processing can be performed.

  In this embodiment, a billing amount class is provided as a class for bundling billing destination classes corresponding to the addition type charging device, and a class for bundling the input amount class corresponding to the subtraction type charging device is not provided. However, as in the case of an addition-type charging device, a two-stage class configuration of a class corresponding to the charging device and a class that bundles such classes can be used.

  The charge management program executed in the image forming apparatus according to the present embodiment is a file in an installable format or an executable format, and is a CD-ROM (Compact Disc Read Only Memory), a flexible disc (FD), a CD- You may comprise so that it may record and provide on computer-readable recording media, such as R (CD Recordable) and DVD (Digital Versatile Disk). In this case, the CPU 11 reads out the charge management program from the storage medium and loads it on the MEM-P 12, thereby causing the image forming apparatus to realize each step, each unit, or each unit described above.

  Further, the billing management 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 charge management program may be provided or distributed via a network such as the Internet.

  As described above, the charging management program and the image forming apparatus according to the present invention are useful for charging various apparatuses that charge for the services provided, and are particularly suitable for charging the image forming apparatus.

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. 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 explanatory drawing for demonstrating the outline | summary of the object modeling of a charging part. It is a UML class diagram which shows the class structure of an accounting part. It is a UML state chart figure which shows the state transition of a slip class. It is a UML state chart figure which shows the state transition of a consideration class. It is a UML state chart figure which shows the state transition of an investment amount class. It is a UML state chart figure which shows the state transition of a charge amount class. It is a UML sequence diagram which shows the execution procedure of operation at the time of receiving a function provision request | requirement. It is a UML sequence diagram which shows the execution procedure of operation at the time of selecting and charging a subtraction type charging apparatus. It is a UML sequence diagram which shows the execution procedure of operation at the time of selecting and charging an addition type charging apparatus. It is a UML sequence diagram which shows the execution procedure of operation at the time of making a replacement request from the selected subtractive charging apparatus. It is a UML sequence diagram which shows the execution procedure of operation at the time of making a replacement request from the selected addition type charging apparatus. FIG. 6 is an explanatory diagram illustrating a transition of a software configuration installed in a multifunction machine. 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)
1a billing device 2 billing server 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 112a charging unit 113 execution system subsystem 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 book class (an example of book means)
310A Book object (an example of book means)
310a state ()
310b fill in ()
310c Cancel ()
320 slip class (an example of slip means)
320A slip object (an example of slip means)
320a state 320b number 320c service content 320d charge 320e fill in ()
320f process ()
320g complete ()
330 Tariff class (an example of tariff means)
330A fee table object (an example of fee table means)
330a Price list 330b Search ()
340 Consideration class (an example of consideration means)
340A Consideration object (an example of compensation means)
340a state 340b exchange ()
340c Confirm receipt ()
340d Replacement request ()
350 Transaction table class (an example of transaction table means)
350A Transaction table object (an example of transaction table means)
350a Restriction list 350b Search ()
350c Update ()
360 Input amount class (an example of a subtractive charging means)
360A Input amount object (an example of a subtractive charging means)
360a Status 360b Name 360c Balance 360d Confirm in advance ()
360e subtract ()
Add 360f ()
360g to return ()
370 Charge amount class (an example of management means)
370A Charge amount object (an example of management means)
370a State 370b Total amount 370c Limit amount 370d Settlement date 370e Assess ()
370f Add ()
370g Settlement ()
370h Replacement request ()
380 Billing class (an example of an addition-type billing means)
380A Billing destination object (an example of an addition type charging means)
380a state 380b name 380c request ()
380d Enable ()
380e Disable ()
400 Operation Panel 401 Initial Setting Key 402 Copy Key 403 Copy Server Key 404 Printer Key 405 Transmission Key 406 Ten Key 407 Clear / Stop Key 408 Start Key 409 Preheating Key 410 Reset Key 420 Liquid Crystal Touch Panel 421 Automatic Density Button 422 Automatic Paper Selection Button 423 etc. Double button 501 Application before service layer separation 502 Application after service layer separation 503 Common routine separation application 504 Object-oriented application

Claims (13)

It is mounted on a service providing apparatus that provides a service in response to a user's request or a billing management apparatus that can communicate with the service providing apparatus, calculates a service fee for a service requested by the user to the service providing apparatus A billing management program for instructing a billing apparatus to execute billing of a fee,
Billing execution means that has a one-to-one correspondence with the billing device and instructs the billing device to perform billing;
A billing management program for selecting one or a plurality of billing execution means and causing the computer to function as a compensation means for requesting the billing execution means to perform billing execution.   2. The charging execution means further comprises: a subtraction type charging unit that corresponds to the subtraction type charging device on a one-to-one basis; and an addition type charging unit that corresponds to the addition type charging device on a one-to-one basis. The billing management program described.   The charging execution unit further includes a management unit that manages all the addition-type charging units. The management unit selects one addition-type charging unit and instructs the execution of charging. 3. The billing management program according to claim 1, wherein when the billing execution cannot be continued, another billing means is selected to continue the billing execution.   The management means holds the total amount and the limit amount, and if a billing request is accepted, the billing amount included in the billing request is added to the total amount, and if the predetermined condition is satisfied, the management type means 4. The charge management program according to claim 3, wherein the charge management program instructs charge execution.   4. The compensation unit manages the subtraction type charging unit and the management unit as children of a tree structure, and the management unit manages the addition type charging unit as a child of a tree structure. 4. The charge management program according to 4.   Transaction table means for holding a list of available charging devices is further provided, wherein the consideration means selects the subtraction type charging means or the addition type charging means based on a search result of the transaction table means. The charge management program according to claim 5.   7. The accounting management according to claim 5, wherein the subtracting accounting unit requests the consideration unit to change the accounting destination when the corresponding subtracting accounting apparatus becomes incapable of accounting. program.   The billing means requests the billing amount means to change the billing destination when the corresponding addition type charging apparatus becomes incapable of charging, and the billing amount means The charge management program according to claim 5, 6 or 7, wherein a change is requested.   The subtracting charging means, when selected from the consideration means, determines whether or not charging can be executed based on the balance of the subtracting charging apparatus held by itself and returns a determination result to the consideration means. The charge management program according to any one of claims 5 to 8. Bookkeeping means for receiving a service request notification including service request contents from the control program of the service providing apparatus; and slip means generated by the bookkeeping means for each service request notice;
The billing management program according to any one of claims 5 to 9, wherein the slip means generates the consideration means and requests the consideration means to perform billing processing.   The charge management according to claim 10, further comprising charge table means for holding a charge list of services to be provided, searching for a corresponding service charge in response to a request from the slip means, and responding to the charge. program.   12. The billing management program according to claim 11, wherein the slip means does not generate the consideration means when the service fee is free. An image forming apparatus that calculates a service charge of a service requested by a user and instructs the charging apparatus to perform charging of the service charge,
Billing execution means that has a one-to-one correspondence with the billing device and instructs the billing device to perform billing;
An image forming apparatus comprising: a charging unit that selects one or a plurality of the charging execution units and requests the selected charging execution unit to execute charging.

Images