JP2015225479A - Information processing system, information processing apparatus, information processing method and computer program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a method of correctly determining an access token even in a case where an authentication request is re-transmitted from upper service to intermediate service, and an information processing system.SOLUTION: Intermediate service comprises storage means, means for acquiring first time at which an authentication request is received, a function for acquiring a first access token from authentication service, and a function for storing the first access token in the storage means in association with the first time. At the time of storage, when a second access token for the same authentication request is already stored in the storage means, the intermediate service compares the first time and time stored in association with the second access token, and updates the access token and time information of the storage means only in a case where the first time is newer.

Description

  The present invention relates to an information processing system, an information processing apparatus, an authentication method, and a computer program.

  In recent years, peripheral device control systems in which peripheral devices are connected to information processing devices using various interfaces such as USB, Ethernet (registered trademark), and wireless LAN have been effectively used in various situations such as homes and offices. ing. Examples of the peripheral device include a printer, a copier, a facsimile machine, a scanner, a digital camera, and a complex machine of these.

  As an example of a peripheral device control system corresponding to a printer or a multifunction peripheral among peripheral devices, a cloud printing service called Google Cloud Print (registered trademark, hereinafter abbreviated as GCP) is provided by Google. By using the cloud printing service, a user activates (uses) a document creation application from a personal computer (hereinafter abbreviated as a PC) or a mobile device, and prints the document with a printer or multifunction device via the Internet. It is possible. The printing procedure using GCP is as follows.

  (1) A user performs an operation of opening a document using a document creation application provided in the PC.

  (2) In order to print the document with a printer, the user opens a print dialog, selects the printer, and performs an operation to execute printing.

  (3) A document creation application generates a print image as a PDF file.

  (4) GCP generates a print job from the print setting value selected in the print dialog and the PDF file, stores the print job in a print queue assigned to the printer in GCP, and notifies the printer of the print job Send.

  (5) Upon receiving the print job notification, the printer acquires the print job and prints the print image of the PDF file according to the print setting value.

  For example, in the case of a printer or multifunction device capable of rendering a PDF file, the printer or multifunction device can print using GCP according to the above procedure. However, in the case of a low-priced printer or multifunction peripheral that cannot render a PDF file, the low-priced printer or multifunction peripheral cannot print the print image of the PDF file in (5).

  There is an application for a Web service (image conversion service) in order to perform printing using GCP with such an inexpensive printer or multifunction machine. The image conversion service application converts the PDF file into an image format that can be printed by a low-priced printer or multifunction device such as a JPEG file. In addition, an information processing system has been proposed in which a PDF file is converted into a JPEG file using an image conversion service application and printed by a low-priced printer or multifunction device.

  In the information processing system as described above, when frequent communication occurs when the web service API provided by each web service application is used between the web service applications, traffic on the network increases. Therefore, there is a problem that the time spent for communication between services greatly affects the processing time of the entire system.

  There exists patent document 1 as a prior art for solving the problem mentioned above. In the system described in Patent Document 1, in an intermediate service that accepts an authentication request and a process execution request from a higher-level Web service application at the time of job execution, when the authentication request is accepted, the authentication request is transmitted to the authentication service. Store the received access token in association with the job. Next, it compares with the access token stored when the processing execution request for the same job is received, and executes the processing execution request only when they match. Accordingly, it is possible to suppress the communication frequency and communication amount for the intermediate service to access the authentication service.

JP2013-117748A

  However, the information processing system described in Patent Document 1 has the following problems. In a general Web service application, when there is no response for a certain period of time after calling the Web service API, a retry process is performed to time out and call the same Web service API again. Even in the above-described process in which the intermediate service receives an authentication request from a higher-level Web service application, if the intermediate service takes time to receive an access token from the authentication service, the higher-level Web service application It is assumed that the authentication request is retried. At this time, the intermediate service acquires two access tokens from the authentication service for the same job.

  Since the upper service uses the access token received in response to the authentication request for the retry process to transmit a process execution request, the intermediate service needs to store the access token acquired in the retry process in association with the target job. However, the intermediate service completes the acquisition of the access token from the authentication service for the authentication request received from the host service for the first time after the intermediate service completes the acquisition of the access token from the authentication service in the retry process. In this case, the access token stored by the intermediate service in association with the target job is different from the access token used by the upper service in the request for the process execution request, and there is a problem that authentication is not correctly performed in the process execution request.

  Therefore, in the information processing system according to the present invention, when the above-described intermediate service acquires time information before starting acquisition of an access token from the authentication service, and stores the acquired access token in association with a job, The time information is also stored in association. Further, when an access token associated with the same job is already stored when the access token is stored, the acquired time information is compared with the time information stored in association with the access token, and the acquired time The stored access token and time information are updated only when the information is newer.

  The present invention may be a system, a storage medium, and the like.

  According to the present invention, the following effects can be obtained. That is, in the information processing system having the configuration of Patent Document 1, even when the upper service retries an authentication request to the intermediate service and acquires a plurality of access tokens from the authentication service, the upper service correctly uses the processing execution request. Access tokens can be stored by intermediate services.

It is a figure which shows an example of a structure of an information processing system. 2 is a diagram illustrating an example of a hardware configuration of a PC and an MFP. FIG. It is a figure which shows an example of a structure of the software of PC. It is a figure which shows an example of a web browser. It is a figure which shows an example of a print dialog. It is an example of the flowchart which concerns on the process of information processing system. It is an example of the flowchart which concerns on the process of information processing system. It is an example of the flowchart which concerns on the process of information processing system. It is an example of the flowchart which concerns on the process of proxy APP. It is an example of the flowchart which concerns on the process of image conversion APP. It is an example of the flowchart which concerns on the process of image conversion APP. It is an example of the flowchart which concerns on the process of image conversion APP. It is an example of a calling sequence. It is an example of the flowchart which concerns on the process of image conversion APP. It is an example of the flowchart which concerns on the process of image conversion APP.

  An information processing system that manages a plurality of printers and provides a print service desired by a user using GCP is conceivable. This information processing system needs to include a proxy application that performs relay processing related to a service provided by GCP. In this information processing system, the proxy service application and the image conversion service application cooperate to process a print job. An image conversion service application converts a PDF file included in a print job issued from GCP into a JPEG file. As a result, it is possible to print with a low-priced printer or multifunction peripheral.

  In such an information processing system, for example, when a proxy service application uses an image conversion service application, it is conceivable to secure security using an authentication system using an authentication service application. For example, the proxy service application assigns a user ID and a password for authenticating the user ID to each printer managed by the proxy service application. Then, the authentication service application performs user authentication based on the user ID and password, and issues an access token for using the image conversion service application to the user ID (printer).

  The proxy service application uses the access token to access the image conversion service application. Further, the image conversion service application converts a PDF file included in a print job of a printer to which the user ID is assigned into a JPEG file, and the printer can print the JPEG file.

  Generally, the image conversion service application exports a plurality of Web service APIs to the proxy service application. Then, the proxy service application sequentially calls each Web service API exported by the image conversion service application. The image conversion service application executes processing in each Web service API that the proxy service application calls in order. The image conversion service application converts the PDF file included in the print job into a JPEG file in the processing, and deletes the unnecessary JPEG file (printed image) after the printing on the printer is completed.

  Each time the proxy service application calls each Web service API exported by the image conversion service application sequentially, it inquires about the validity and expiration date of the access token. That is, the proxy service application calls the access token validity confirmation API and the access token expiration date confirmation API among the Web service APIs exported by the authentication service application.

  The interface between the services described above, and the interface between each service and a low-priced printer or multifunction peripheral is defined by the Web service API, and usually uses the HTTPS POST method and GET method encrypted by SSL communication. ing. Security is ensured by such encrypted communication.

  In this case, when each Web service API is used, much time is required for encryption at the time of transmitting information and decryption at the time of receiving information. In addition, since the load of communication processing increases, there is a problem in that when the cloud is used, system construction and application implementation are hindered.

  Each Web service application, low-priced printer, or multifunction device accesses the authentication service application for each process and inquires about the validity and expiration date of the access token. However, if the access token validity confirmation API or the access token validity period confirmation API is called to inquire about the validity or validity period of the access token, the load of the authentication service application increases. As a result, performance degradation and authentication service application tolerances are exceeded. In order to avoid these problems, it is necessary to increase the scale of the authentication service application system. In this case, there are various problems such as a complicated system configuration of the authentication service application and an increase in operation cost.

  Further, an information processing system in which each Web service application inquires and verifies the validity and expiration date of the access token from the authentication service application is conceivable. However, in this information processing system, there is a possibility that the access token is determined to be valid under a situation where the upper Web service application is malfunctioning. If it is determined that the access token is valid, there is a problem that an unsuitable process or job (for example, another person's print job) is erroneously processed. In such a case, the target Web service application may be attacked, for example, by an access from a spoofing program pretending to be a higher-level service. Therefore, there is a problem that the Web service application malfunctions or information is leaked.

  According to the information processing system of this embodiment described below, the above-described problems can be solved. That is, according to the information processing system of the present embodiment, it is possible to suppress the communication frequency and the data communication amount between each Web service application device and reduce the load of a specific Web service application. Further, according to the information processing system of the present embodiment, it is possible to prevent malfunctions and information leaks when there is an attack such as spoofing access.

  Hereinafter, the present embodiment will be described with reference to the drawings. In addition, this embodiment does not limit this invention, and all the structures demonstrated by embodiment are not necessarily essential to the means for solving the subject of this invention.

  In the following, there is a case where an HTTPS POST method (an example of a communication method) encrypted by SSL communication is used for the Web service API. However, since this POST method is publicly available information, here Then, the detailed description is abbreviate | omitted. In the following, an HTTP GET method (an example of a communication method) may be used for the Web service API. Since this GET method is publicly available information, a detailed description thereof will be given here. Is omitted. In the following, an HTTPS GET method (an example of a communication method) encrypted by SSL communication may be used for the Web service API. However, since this GET method is publicly available information. Detailed description thereof is omitted here.

HTTP is an abbreviation for Hyper Text Transfer Protocol and is a well-known unencrypted communication protocol, and therefore, detailed description thereof is omitted here. HTTPS is an abbreviation for Hyper Text Transfer Protocol over Secure Socket Layer, and is a well-known encrypted communication protocol, and therefore detailed description thereof is omitted here. SSL is an abbreviation for Secure Socket Layer, and is a known method for encrypting and transmitting / receiving data on the Internet, and therefore detailed description thereof is omitted here. In addition, since the description regarding Google Cloud Print (GCP) is disclosed on the following site, the detailed description thereof is omitted here. Internet URL: http: // code. Google. com / apis / cloudprint / docs / overview. html
FIG. 1 shows a configuration example of an information processing system according to the present embodiment. The information processing system shown in FIG. 1 includes PC1, PC2, PC5, PC147, PC7, MFP3, MFP103, and a router (Router) 13. Each of PC1, PC2, PC5, PC147, and PC7 is an example of an information processing apparatus (computer), and is, for example, a general personal computer. Each of PC1, PC2, PC5, PC147, and PC7 includes the hardware shown in FIG.

  An OS equivalent to Chrome (registered trademark) manufactured by Google Inc. is installed in the PC 1 as an operating system (hereinafter abbreviated as OS). Each of the PC2, PC147, and PC5 is installed with a Windows (registered trademark) Server OS manufactured by Microsoft Corporation, and the PC 7 is installed with an OS equivalent to Linux (registered trademark). PC 1, PC 2, PC 5, PC 147, and PC 7 are connected to networks 4, 8, 10, and 6 that are configured by interfaces (I / F) such as Ethernet (registered trademark), and are also connected to the Internet 12. .

  Multifunction printers (hereinafter abbreviated as MFPs) 3 and 103 are configured to include a color inkjet printer, a color facsimile, a color scanner, an external storage for flash memory, and the like, and are examples of peripheral devices (computers). MFPs 3 and 103 are MFPs having a model name of Kmmn manufactured by ABC. The peripheral device may be a printer, a copier, a facsimile machine, a scanner, a digital camera, a device having a composite function thereof, or the like.

  Each of the MFP 3 and the MFP 103 is configured to include hardware shown in FIG. The MFP 3 is connected to a network 11 configured by Ethernet (registered trademark) and is also connected to the Internet 12. The MFP 103 is connected to a network 104 composed of Ethernet (registered trademark), and is also connected to the Internet 12.

  The router (Router) 13 is a broadband router (Wi-Fi BB Router) equipped with a Wi-Fi (registered trademark) wireless LAN, and is connected to the Internet 12. The mobile device (Mobile Device) 14 is a mobile phone, a mobile information terminal, or the like. The mobile device 14 is connected to the router 13 and is also connected to the Internet 12 via the router 13. The PC 1, PC 2, PC 5, PC 147, PC 7, mobile device 14, MFP 3, and MFP 103 are capable of bidirectional communication with each other via the Internet 12 (connected to be communicable). A Web browser (Web Browser) 9 is installed on the PC 1, and the Web browser 15 is installed on the mobile device 14.

  The application (Application) 145 is an application for creating a document using a Web service, and is hereinafter referred to as a document creation APP 145. The application (Application) 146 is an application that provides a cloud print service using a Web service, and is hereinafter referred to as a cloud print APP 146. The cloud printing APP 146 has a function equivalent to, for example, GCP provided by Google. By using this cloud printing service, the document creation APP 145 can be executed from the Web browser 9 in the PC 1 or the Web browser 15 in the mobile device, a certain document can be opened, and the document can be printed by the MFP 3 or the MFP 103. It becomes like this.

  For example, when the user prints an open document, when the print menu 401 shown in FIG. 4 is selected, the cloud printing APP 146 displays a print dialog 142 shown in FIG. When the user selects a printer in the print dialog 142 and presses the print button 534 to instruct execution of printing, the document creation APP 145 generates a print image as a PDF file. The cloud print APP 146 generates a print job from the print image (PDF file) and the print setting value selected in the print dialog 142, and prints the print job in the print queue for the selected printer in the cloud print service. Store the job. Further, the cloud print APP 146 transmits a print job notification to the printer (in the example of the present embodiment described later, proxy APP 143).

  When the printer or MFP has a function of rendering a PDF file, the printer or MFP can print a print job stored in the print queue. However, many inexpensive inkjet printers and MFPs do not have a function for rendering PDF files by the printer or MFP. Therefore, when printing a print job stored in the print queue with such a printer, the print image of the PDF file is converted into an image format of a type that can be rendered with a low-priced printer such as a JPEG file ( An example of pre-processing) is required.

  The application (Application) 143 is an application that provides a cloud print proxy service for causing the MFP 3 and the MFP 103 to correspond to the cloud print service provided by the cloud print APP 146. The application 143 is a relay service device that performs relay processing between the MFP 3 and the MFP 103 and the cloud print APP 146, and is hereinafter referred to as a proxy APP 143. The proxy APP 143 installed on the PC 2 can manage 5000 printers and MFPs at a time, and can make each printer and MFP correspond to a cloud printing service provided by the cloud printing APP 146.

  The application 144 is an application that provides an image conversion service for converting a PDF file into a JPEG file. An application 144 communicates with the proxy APP 143 and functions as an intermediate service device that performs related processing related to the cloud print service. Hereinafter, the application 144 is referred to as an image conversion APP 144.

The application 148 is an application that provides an authentication service that issues an access token, and is hereinafter referred to as an authentication APP 148. The authentication APP 148 issues an access token for performing authentication when the proxy APP 143 uses the image conversion APP 144. If the cloud printing service 146 is a GCP, for example, the vendor is different. Therefore, the authentication processing service provided by the authentication APP 148 is different from the authentication system and the authentication service used by the cloud printing APP 146. As will be described later, the cloud printing APP 146 issues an access token for performing authentication when the image conversion APP 144 uses the cloud printing APP 146. The access token issued by the cloud printing APP 146 may be issued by a cloud printing service provided by the cloud printing APP 146. The authentication APP 148 exports the following Web service API.
-Login function-Logout function-User registration function-User authentication function-Access token generation function-Access token validity check function-Access token expiration date check function For these functions, the HTTPS POST method encrypted by SSL communication Is being used. A program related to these processes is incorporated in the PC 147, stored in the HDD 202 shown in FIG.

  Here, in order to use the cloud printing service provided by the cloud printing APP 146, login using a user account and a password is required. Then, when registering a printer or MFP that can be used for printing in the cloud printing service, the cloud printing APP 146 first acquires an access token for using the cloud printing service by using the user account and password. . Then, the cloud printing APP 146 uses the acquired access token to register the printer or MFP in association with the user account.

  In addition, when registering a printer or MFP, the cloud printing APP 146 issues and assigns a printer ID represented by a unique value to each printer or MFP, and notifies the printer or the like to be registered of the printer ID. A detailed description of the processing related to the registration of the printer or the like is omitted.

  FIG. 2 is a diagram illustrating an example of a hardware configuration of the PC and the MFP. Each of PC1, PC2, PC5, PC147, and PC7 is configured to include the hardware shown in FIG. In FIG. 2A, description will be given by taking PC2 as an example. The PC 2 includes a random access memory unit (RAM 201), a hard disk drive unit (HDD 202), a keyboard unit (KBD 203), a CPU 204, a display for display (LCD 205), and a network board (NB 207). The PC 2 includes a bus 206 that connects the above-described components to each other.

  The HDD 202 is an example of a storage unit. The storage unit may be a portable CD-ROM or a ROM installed therein. The KBD 203 is an example of an input unit. The CPU 204 is an example of a control unit. The LCD 205 is an example of a display unit. The NB 207 is an example of a communication control unit.

  Programs such as the proxy APP 143 and each module (software) shown in FIG. 3 are stored in the HDD 202, and are read into the RAM 201 and executed by the CPU 204 as necessary. Thereby, the function of the proxy APP 143, the function of each module (software) shown in FIG. 3, and the like are realized. Various databases (DB) are provided in the HDD 202, and database information is read by the CPU 204 to the RAM 201 as necessary.

  Each of the MFP 3 and the MFP 103 is configured to include hardware shown in FIG. In FIG. 2B, the MFP 3 will be described as an example. The CPU 25 is composed of a microprocessor or the like. As a central processing unit of the MFP 3, the CPU 25 is a RAM 17, a communication unit 18, a recording unit 19, an operation unit 20, a display unit 21, a reading unit 22, a facsimile control unit 23, and an external storage control according to a program stored in the ROM 16. The unit 24 is controlled.

  The ROM 16 stores a program for executing a recording (printing) process performed by the MFP 3 in accordance with control by a printer driver (not shown), a process for notifying the PC of the status of the printing operation, and the like. The ROM 16 stores a program for executing processing for the MFP 3 to perform facsimile transmission processing or reception processing and processing for notifying the PC of the status of facsimile operation (transmission or reception) according to control by a FAX driver (not shown). . Further, the ROM 16 stores a program for executing an image reading process performed by the MFP 3 according to control by a WIA driver (not shown) or a TWAIN driver (not shown) and a process for notifying the PC of the state of the reading operation.

  The RAM 17 temporarily stores print data. The print data is mainly sent from the PC and printed by the recording unit 19 based on the print data. The RAM 17 also temporarily stores image data read by the reading unit 22, facsimile transmission data sent from the PC, facsimile reception data received by the facsimile control unit 23, and the like.

  The communication unit 18 includes a connection port for the network 4, an analog telephone line connection port, and the like, and controls Ethernet (registered trademark) and facsimile analog communication. The recording unit 19 includes an inkjet recording head, a recording unit including each color ink, a carriage, a recording paper conveyance mechanism, and the like, an ASIC for generating a printing pulse in the recording head based on the printing data, and the like. And an electric circuit composed of

  For example, the display contents (image data) of a file opened in the application by a printing operation on a printable application or a facsimile transmission operation are temporarily stored in the HDD 202 of the PC 2 as an EMF format spool file. The The spool file is converted into print data including an MFP3 control command or facsimile transmission data via a printer driver or FAX driver, and then sent to the MFP 3 via the Internet.

  The print data received by the MFP 3 is converted into print pulses by the recording unit 19 and printed on the recording paper. The facsimile transmission data received by the MFP 3 is converted into a facsimile communication protocol by the facsimile control unit 23 and transmitted to the facsimile machine of the other party via an analog telephone line.

  The operation unit 20 includes various buttons such as a power button and a reset button, and accepts operations on the MFP 3. The display unit 21 is configured by a liquid crystal display of a touch panel, and can display the status of the MFP 3, display various setting information and telephone numbers, input, and the like. The reading unit 22 includes an electric circuit including a color image sensor, an ASIC for image processing, and the like, and controls the scanner function.

  The facsimile control unit 23 includes a facsimile modem, an analog communication circuit, and the like, and controls facsimile transmission and reception according to a facsimile communication protocol. The external storage control unit 24 includes a slot for installing a flash memory, an interface circuit for storage, and the like, and controls the installed flash memory.

  FIG. 3 is a diagram illustrating an example of a software configuration of the PC. In FIG. 3, the description will be given by taking the PC 2 as an example. The I / F 92 is an I / F control stack that controls an I / F such as Ethernet (registered trademark). The IP network 91 is an IP network control stack that controls the IP network.

  The Internet Information Services (IIS) 90 is an IIS control unit that controls IIS, and the application 150 provides a Web service by using the Web server function of the IIS control unit. JAVA (registered trademark) Virtual Machine (Java (registered trademark) VM) 89 is software that converts Java (registered trademark) bytecode into platform native code and executes it, and proxy APP143 is JAVA (registered trademark) VM89. Run on. Applications 82 are an application group, and are composed of a proxy APP 143, an application 150, and the like.

  FIG. 4 is a diagram illustrating an example of the Web browser 9 provided by the document creation APP 145 of the PC 1. FIG. 4 shows a state in which a certain document is opened. A print menu 401 accepts various operations related to printing. For example, when the user operates the input unit such as KBD 203 (user operation) and presses the print menu 401 when printing an open document, a print dialog 142 shown in FIG. 5 is displayed.

  FIG. 5 is a diagram illustrating an example of the print dialog 142. The print dialog 142 is controlled by the cloud print APP 146 as a print setting screen for the MFPs 3 and 103 for the user. The print dialog 142 is displayed on the Web browser using the Web browsers 9 and 15.

  Each of the printer options 535, 536, and 537 is a selectable printer option. The printer options 535, 536, and 537 are options corresponding to a printer having a model name of AkbNmb manufactured by GHI, an MFP (MFP3) having a model name of Kmmn manufactured by ABC, and a printer having a model name of Xyz manufactured by DEF, respectively. Represents. FIG. 5 shows a state where the printer option 536 representing the MFP 3 is selected.

The paper size selection unit 530 selects a paper size to be printed by the MFP 3 from the following options according to a user operation. FIG. 5 shows a state in which Letter is selected.
Paper size options: A5, A4, B5, Letter
A paper type selection unit 531 selects a paper type to be printed by the MFP 3 from the following options according to a user operation. FIG. 5 shows a state in which Plain Paper is selected.
Paper type choices: Plain Paper, Photo Paper, Postcard
The print quality selection unit 532 selects a print quality to be printed by the MFP 3 from the following options according to a user operation. FIG. 5 shows a state where Standard is selected.
Print quality options: High, Standard, Fast
A color / density selection unit 533 selects a color or density to be printed by the MFP 3 from the following options according to a user operation. FIG. 5 shows a state where Auto is selected.
Print quality options: Auto, Manual
The print button 534 receives an instruction to start printing. When the print button 534 is pressed by a user operation, the cloud print APP 146 generates a print job for the MFP 3 associated with the printer option 536. A close button 538 receives an instruction to close the print dialog 142. When the close button 538 is pressed by a user operation, the cloud print APP 146 closes the print dialog 142.

  6, 7, and 8 are diagrams illustrating examples of flowcharts related to processing of the entire peripheral device control system. The programs according to these flowcharts are incorporated in the PC or MFP. A program of an application operating on the PC is stored in the HDD 202, and is read out and executed by the CPU 204 in the RAM 201. A program of an application operating on the MFP is stored in the ROM 16, read out to the RAM 17, and executed by the CPU 25.

  In these flowcharts, the vertical column represents the execution source of the process. In this embodiment, a user (Web browser 9), a document creation APP 145, a cloud print APP 146, a proxy APP 143, an image conversion APP 144, an authentication APP 148, and an MFP 3 are described from the left side of the drawing. Hereinafter, the communication control method will be described by taking as an example a case where a user prints a document with the MFP 3 using the PC 1 (a series of processes related to document printing).

  First, a configuration in which the MFP 3 polls a print job will be described using S617 to S621. In FIG. 6, step S617 is a step representing the start of document printing as viewed from the MFP 3 for convenience. Note that this step does not affect the execution of processing in the MFP 3 at all, but merely represents the start of this flowchart.

In step S <b> 618, the MFP 3 calls the CheckPrintJob function of the Web service API exported by the proxy APP 143. Information (an example of confirmation information) to be passed to the proxy APP 143 as the query parameter of the HTTP GET request when the MFP 3 calls this function in S618 is the following information.
・ Printer ID issued by Cloud Print APP146
-Random code In addition, the timing of calling the CheckPrintJob function is arbitrary, and is a form of polling that calls regularly, but is not limited to this form. For example, it may be configured to call when specified by the user. Further, the confirmation information included in the query parameter is not limited to the printer ID and the random code.

  The random code is an arbitrary 32-bit value generated by the MFP 3. When the CheckPrintJob function is called, the proxy APP 143 executes processing of the CheckPrintJob function described later with reference to FIG. 9A and returns a response (an example of response information) to the MFP 3 (S619).

  Subsequently, when receiving the response of the CheckPrintJob function from the proxy APP 143, the MFP 3 confirms the information (“response with print job” or “response without print job”) included in the response message (S620). . In S620, if the MFP 3 determines that the “print job present response” has been received, the process proceeds to S708 in FIG. 7. On the other hand, if the MFP 3 determines that the “print job absent response” is received, the process proceeds to S621. .

  In S621, the MFP 3 waits for a certain time (1 minute in the present embodiment), and then moves the process to S618. In this way, the MFP 3 polls the CheckPrintJob function exported by the proxy APP 143 at regular time intervals (periodically).

  Next, document printing processing will be described. Here, step S601 is a step representing the start of document printing when viewed from the user side for convenience. This step does not affect the user operation or the execution of the application at all, but merely represents the start of this flowchart.

  First, the user activates the Web browser 9, accesses the URL of the document creation APP 145, and logs in. When the user designates a certain document and gives an instruction to open the document, the Web browser 9 calls the OpenDocument function of the Web service API exported by the document creation APP 145 using the document as an input parameter ( S602).

  When the OpenDocument function is called, the document creation APP 145 opens the document specified by the input parameter and transmits the information to the Web browser 9 (S603). For example, as shown in FIG. 4, the document is opened on the Web browser 9 via the document creation APP 145.

  When the user presses the print menu 401 to print the document, the information is notified to the document creation APP 145 via the Web browser 9 (S604). Upon receiving this notification, the document creation APP 145 calls the Print Dialog function of the Web service API exported by the cloud print APP 146 (S605).

  When the Print Dialog function is called, the cloud print APP 146 opens the print dialog 142 and transmits the information to the Web browser 9 (S606). For example, as shown in FIG. 5, a print dialog 142 is displayed on the Web browser 9.

  The user operates the input unit to select a printer for printing from among a plurality of printer options (the printer option 536 associated with the MFP 3 in the example of FIG. 5), and the desired setting from each print setting value. A value is selected and the print button 534 is pressed. When the print button 534 is pressed, the document creation APP 145 is notified of information indicating a print start request from the user and information regarding the print setting value via the Web browser 9 (S607).

  The information regarding the print setting value is, for example, a URL in which a print setting file (XML file) in which the print setting value selected by the user is written is stored. Upon receiving this notification, the document creation APP 145 generates a print image as a PDF file. Then, the document creation APP 145 calls the SubmitPrintJob function of the Web service API exported by the cloud print APP 146 using the generated PDF file, information on the print setting value, and the like as input parameters (S608).

  When the SubmitPrintJob function is called, the cloud print APP 146 generates a print job based on the PDF file specified by the input parameter, information on the print setting value, and the like. Then, the cloud print APP 146 transmits a print job notification to the printer associated with the selected printer option (in this example, the proxy APP 143 because the MFP 3 requires image format conversion) (S609).

The print job includes at least the following information (hereinafter referred to as print job information).
-Print job ID issued by cloud print APP146
・ Printer ID issued by Cloud Print APP146
-Access token for using the cloud print service provided by the cloud print APP 146-URL where the print setting file (XML file) in which the print setting value is written is stored
-URL for storing the print image (PDF file)
Time stamp When the proxy APP 143 receives the print job notification, the proxy APP 143 calls the FetchPrintJob function of the Web service API exported by the cloud print APP 146 (S610). When the FetchPrintJob function is called, the cloud print APP 146 transmits information (print job information) included in the print job generated in S609 to the proxy APP 143 (S611).

  When the proxy APP 143 receives the print job information, the proxy APP 143 acquires necessary information from the print job information, and stores the acquired information and information necessary for other control in the print job management database (S622). Then, the proxy APP 143 calls the RegisterAndAuth function of the Web service API exported by the image conversion APP 144 (S622).

At this time, the CPU 204 of the proxy APP 143 functions as a transmission unit, and transmits an authentication request and a process execution request to the image conversion APP 144. Specifically, when the proxy APP 143 calls this function, information (an example of pre-processing information) to be passed to the image conversion APP 144 as an input parameter of the HTTPS POST request is information as shown below.
・ Administrator ID using authentication APP148
・ Administrator password using authentication APP148 ・ User ID using image conversion APP144
User password for using image conversion APP 144 Service ID
・ Printer ID issued by Cloud Print APP146
-Print job ID issued by cloud print APP146
Here, the service ID represents an ID for identifying each cloud printing service. For example, the following ID can be designated. The parentheses () are the outline of each cloud printing service.
GCP Consumer (GCP for consumers)
GCP Enterprise (Enterprise GCP)
Email Print Consumer (Email printing for consumers)
Email Print Enterprise (Email printing for enterprises)
ABC Cloud Print (Cloud printing provided by ABC)
“Administrator ID using authentication APP 148” is identification information of the proxy APP 143 and is registered in advance in the proxy APP 143. The “administrator password using the authentication APP 148” is a password for authenticating the proxy APP 143 ID, and is registered in the proxy APP 143 in advance. The “user ID using the image conversion APP 144” is identification information uniquely assigned to each MFP managed by the proxy APP 143. “User password using image conversion APP 144” is a password for authenticating the user ID. The proxy APP 143 automatically generates the “user ID using the image conversion APP 144” and the “user password using the image conversion APP 144”.

  The image conversion APP 144 functions as a reception unit that receives an authentication request and a process execution request. When the RegisterAndAuth function is called, the RegisterAndAuth function described later with reference to FIG. 14 is executed. Then, the image conversion APP 144 returns the response to the proxy APP 143 (S623). This response includes an access token issued by the authentication APP 148 for using the image conversion APP 144.

  The proxy APP 143 receives the response of the RegisterAndAuth function from the image conversion APP 144. The proxy APP 143 that has received the response calls the CreatePrintJobSet function of the Web service API exported by the image conversion APP 144 (S612).

In S612, when the proxy APP 143 calls this function, information (an example of pre-processing information) to be passed to the image conversion APP 144 as an input parameter of the HTTPS POST request is the following information.
・ Service ID
・ Printer ID issued by Cloud Print APP146
-Print job ID issued by cloud print APP146
-Access token for using the image conversion APP 144-Access token for using the cloud printing service-URL for storing the print image (PDF file)
In S622, the following information is stored in the print job management database of the proxy APP 143.
[Print Job Management Database]
Search key: Print job ID issued by cloud print APP 146
・ Service ID
・ Printer ID issued by Cloud Print APP146
-Access token for using the image conversion APP 144-Access token for using the cloud printing service-URL of the storage location of the print setting file (XML file)
-URL for storing the print image (PDF file)
Access token for image conversion APP 144 Print job access URL (URL of JPEG file storage destination)
-The total number of pages of the print image (JPEG file)-Print job preparation complete (PrintJobReady) (0: incomplete, 1: complete)
At this time, the proxy APP 143 sets “0” as an initial value indicating that the print job preparation is not completed in the print job preparation completion (PrintJobReady). Further, the proxy APP 143 sets an initial value “0” to the total number of pages of the print image (JPEG file).

  When the CreatePrintJobSet function is called, the image conversion APP 144 executes the process of the CreatePrintJobSet function, which will be described later with reference to FIG. 10A, and returns the response to the proxy APP 143 (S613). This response includes the session ID issued by the image conversion APP 144.

When the proxy APP 143 receives the response of the CreatePrintJobSet function from the image conversion APP 144, the proxy APP 143 calls the Confirm Progress function of the Web service API exported by the image conversion APP 144 (S614). In S614, when the proxy APP 143 calls this function, information (an example of confirmation information) to be passed to the image conversion APP 144 as a query parameter of the HTTP GET request is the following information.
・ Session ID
Sequence The session ID is information included in the response of the CreatePrintJobSet function, and the sequence is an arbitrary number generated by the proxy APP 143.

  When the ConfirmProgress function is called, the image conversion APP 144 executes the process of the ConfirmProgress function, which will be described later with reference to FIG. 11A, and returns a response (an example of response information) to the proxy APP 143 (S615). When the proxy APP 143 receives the response of the ConfirmProgress function from the image conversion APP 144, the proxy APP 143 confirms the content (“processing response”, “processing completion response”, or “error response”) included in the response message in the response. (S616). If it is determined in S616 that the proxy APP 143 has received the “processing completion response”, the process proceeds to S701 in FIG. 7. If it is determined that the “response in process” has been received, the process proceeds to S614.

  If an error has occurred in the download / image conversion thread processing of the image conversion APP 144, which will be described later with reference to FIG. 10B, the proxy APP 143 receives an “error response” and stops the printing processing in S616. However, since the case to be canceled is out of the essence of the present embodiment, the detailed description thereof is omitted. Therefore, in and after S616, the case where the proxy APP 143 receives the “processing completion response” or the “processing response” will be mainly described.

As shown in FIG. 7, in S701, the proxy APP 143 calls the CreatePrintJobResult function of the Web service API exported by the image conversion APP 144. In S701, when the proxy APP 143 calls this function, information (an example of location acquisition information) passed to the image conversion APP 144 as an input parameter of the HTTPS POST request is the following information.
・ Printer ID issued by Cloud Print APP146
-Print job ID issued by cloud print APP146
When the CreatePrintJobResult function is called, the image conversion APP 144 executes the process of the CreatePrintJobResult function described later with reference to FIG. 12, and returns the response to the proxy APP 143 (S702).

  When the proxy APP 143 receives the CreatePrintJobResult function response from the image conversion APP 144, the proxy APP 143 sets “1” to PrintJobReady (S <b> 703). Then, the proxy APP 143 sets “1” representing the print job preparation completion to the print job preparation completion (PrintJobReady) of the print job management database (S703). As a result, the MFP 3 enters a print waiting state (S704).

  As described above with reference to S618 to S621 in FIG. 6, the MFP 3 polls the CheckPrintJob function exported by the proxy APP 143 at regular intervals, and S705 represents processing equivalent to S618. A case will be described in which when the MFP 3 is in a print waiting state in S704, the MFP 3 calls the CheckPrintJob function exported by the proxy APP 143 in S705. When the CheckPrintJob function is called, the proxy APP 143 executes processing of the CheckPrintJob function described later with reference to FIG. 9A, and returns a response to the MFP 3 (S706).

  When the MFP 3 receives the response of the CheckPrintJob function from the proxy APP 143, the MFP 3 confirms the content (“response with print job” or “response without print job”) included in the response message (S707). If it is determined in S707 that the MFP 3 has received a “print job present response”, the process proceeds to S708. On the other hand, if it is determined that a “print job absent response” has been received, the process proceeds to S621.

In S708, the MFP 3 calls the GetPrintJob function of the Web service API exported by the proxy APP 143. In S708, when the MFP 3 calls this function, information (an example of acquired information) to be passed to the proxy APP 143 as a query parameter of the HTTPS GET request is the following information.
・ Printer ID issued by Cloud Print APP146
When the GetPrintJob function is called, the proxy APP 143 executes processing of the GetPrintJob function described later with reference to FIG. 9B, and returns a response to the MFP 3 (S709). Upon receiving the GetPrintJob function response from the proxy APP 143, the MFP 3 transmits a print image acquisition request to the image conversion APP 144 based on the content included in the response message in the response (S710).

  Here, the contents included in the response message in the response include the print job access URL (the URL where the print image (JPEG file) is stored), the total number of pages of the print image (JPEG file), and the image conversion APP 144. Access token. The print image acquisition request is a request for acquiring a print image (JPEG file) of each page from the image conversion APP 144.

  In this embodiment, the print job access URL is the storage destination URL of the PC 5 having the image conversion App 144, but may be the storage destination URL of other PCs. For example, the print job access URL may be transmitted directly from the PC 5. Further, for example, the PC 2 having the App 143 may acquire the print image of the designated page from the PC 5, and the PC 2 may transmit the acquired print image to the MFP 3. Further, for example, the PC 2 may send the URL of the storage location of the acquired print image to the MFP 3.

  When the image conversion APP 144 receives the print image acquisition request from the MFP 3, the image conversion APP 144 permits access from the MFP 3 to the print image (JPEG file) of the specified page, and transmits the print image to the MFP 3 (S711). Upon receiving the print image transmitted from the image conversion APP 144, the MFP 3 prints the print image (S712). Subsequently, the MFP 3 confirms the presence / absence of the next page based on the total number of pages of the print image (JPEG file) (S713). At this time, if the MFP 3 determines that there is a next page, the process proceeds to S710, and a print image acquisition request for acquiring the print image of the next page is transmitted to the image conversion APP 144. On the other hand, if the MFP 3 determines that there is no next page, the process proceeds to S801 in FIG.

  For the print image (JPEG file) acquisition process in S710 to S712, an HTTPS GET method encrypted by SSL communication is used.

As shown in FIG. 8, in S801, the MFP 3 calls an EndPrintJob function of the Web service API exported by the proxy APP 143. For the call of the EndPrintJob function, an HTTPS GET method encrypted by SSL communication is used. In S801, when the MFP 3 calls this function, information (an example of end information) to be passed to the proxy APP 143 as a query parameter of the HTTPS GET request is the following information.
・ Printer ID issued by Cloud Print APP146
-Print job ID issued by cloud print APP146
When the EndPrintJob function is called (S802), the proxy APP 143 calls the JobCompleted function of the Web service API exported by the image conversion APP 144 (S803). In S803, when the proxy APP 143 calls this function, information (an example of job processing end information) to be passed to the image conversion APP 144 as an input parameter of the HTTPS POST request is the following information.
・ Printer ID issued by Cloud Print APP146
-Print job ID issued by cloud print APP146
When the JobCompleted function is called, the image conversion APP 144 executes processing of the JobCompleted function described later with reference to FIG. 11B, and returns a response to the proxy APP 143 (S804). When the proxy APP 143 receives the response of the JobCompleted function from the image conversion APP 144, the proxy APP 143 deletes information related to the print job from the print job management database, and updates the print job management database (S805). Then, the proxy APP 143 ends the document printing process (S806).

  Next, Web service API processing exported by the proxy APP 143 will be described with reference to FIG. FIG. 9A is a diagram illustrating an example of a flowchart relating to processing of the CheckPrintJob function. FIG. 9B is a diagram illustrating an example of a flowchart relating to the processing of the GetPrintJob function. For the CheckPrintJob function, the HTTP GET method is used. As for the GetPrintJob function, an HTTPS GET method encrypted by SSL communication is used. The programs according to these flowcharts are incorporated in the PC 2, stored in the HDD 202, read out to the RAM 201 by the CPU 204 and executed.

  In S618 of FIG. 6 and S705 of FIG. 7, when the MFP 3 calls the CheckPrintJob function, the proxy APP 143 executes processing of the CheckPrintJob function shown in FIG.

  As shown in FIG. 9A, when the proxy APP 143 starts the processing of the CheckPrintJob function (S901), the proxy APP143 confirms the completion of print job preparation (PrintJobReady) in the print job management database (S902). In step S <b> 901, the printer ID and random code issued by the cloud print APP 146 are passed from the MFP 3 as query parameters of the HTTP GET request.

  When the proxy APP 143 determines that “1” indicating that the print job preparation is completed is set in the print job preparation completion (PrintJobReady), that is, the MFP 3 has a print job (YES in step S903). , The process is moved to S904. On the other hand, if the proxy APP 143 determines that “0” indicating that the print job preparation has not been completed is set, that is, the MFP 3 print job does not exist (NO in S903), the process proceeds to S905. Move.

  In S904, the proxy APP 143 sets “response with print job” to the response message included in the BODY of the response to the HTTP GET request, and moves the process to S906. In step S905, the proxy APP 143 sets “no print job response” in the response message included in the BODY of the response to the HTTP GET request, and the process proceeds to step S906. In step S906, the proxy APP 143 transmits a response message to the GET request issuer (MFP3 in this example), and ends the CheckPrintJob function processing (S907).

Details of the “print job presence response” and the “print job absence response” will be described here. The information indicating the presence of a print job and the information indicating the absence of a print job are “10101010” and “01010101”, respectively. “Print job presence response” and “Print job absence response” are the results calculated using random codes and information indicating these states, respectively. For example, the following information is converted into a character string. Consists of column information.
“Response with print job” = Random code XOR 10101010
“No print job response” = Random code XOR 01010101
As described above, the proxy APP 143 does not use the visible information defined using XML as a response to the HTTP GET request. The proxy APP 143 uses character string information whose meaning is generally unknown. As a result, it is possible to prevent malfunction or inappropriate control due to inappropriate access to the Web service API. Note that the configuration for preventing such inappropriate access is not limited to this example, and more complicated operations such as hashing may be combined.

  When the MFP 3 calls the GetPrintJob function in S708 of FIG. 7, the proxy APP 143 executes the process of the GetPrintJob function shown in FIG. 9B. As shown in FIG. 9B, the proxy APP 143 starts processing of the GetPrintJob function (S911). Then, the proxy APP 143 sets the URL of the storage destination of the print image (JPEG file) in the response message included in the BODY of the response to the HTTPS GET request (S912), and moves the process to S913.

  In S913, the proxy APP 143 sets the total number of pages of the print image (JPEG file) in the response message included in the BODY of the response to the HTTPS GET request, and moves the process to S914. In S914, the proxy APP 143 sets the access token to the image conversion APP 144 in the response message included in the BODY of the response to the HTTPS GET request, and moves the process to S915.

  In S915, the proxy APP 143 transmits a response message to the GET request issuer (MFP3 in this example), and ends the processing of the GetPrintJob function (S916).

  Next, the Web service API exported by the image conversion APP 144 and the thread function processing will be described with reference to FIG. FIG. 10A is a diagram illustrating an example of a flowchart relating to processing of the CreatePrintJobSet function. FIG. 10B is a diagram illustrating an example of a flowchart relating to processing of the download / image conversion thread function. As for the CreatePrintJobSet function, an HTTPS POST method encrypted by SSL communication is used.

  The programs according to these flowcharts are incorporated in the PC 5 and stored in the HDD 202, and are read into the RAM 201 by the CPU 204 and executed.

  When the proxy APP 143 calls the CreatePrintJobSet function in S612 of FIG. 6, the image conversion APP 144 executes the process of the CreatePrintJobSet function shown in FIG.

As shown in FIG. 10A, the image conversion APP 144 starts processing of the CreatePrintJobSet function (S1001), and executes access token confirmation processing described later in FIG. 15 (S1018). At this time, the following information is passed as an argument of this process (subroutine function).
・ Service ID
・ Printer ID issued by Cloud Print APP146
-Print job ID issued by cloud print APP146
Access token for using the image conversion APP 144 Then, the image conversion APP 144 generates a session ID, stores it in the session management database (S1002), and shifts the processing to S1003. The session management database stores the following information.
[Session Management Database]
Search key: Session ID issued by the image conversion APP 144
・ Service ID
・ Printer ID issued by Cloud Print APP146
-Print job ID issued by cloud print APP146
-Access token for using the cloud printing service-URL for storing the print image (PDF file)
Access token for using the image conversion APP 144 Print job access URL (JPEG file storage destination URL)
・ Progress status indicating progress of processing (Progress)
Here, the image conversion APP 144 acquires the printer ID and print job ID issued by the cloud print APP 146 from the input parameters of the CreatePrintJobSet function. Then, the image conversion APP 144 stores the printer ID and print job ID issued by the cloud print APP 146 in the session management database.

  Also, the image conversion APP 144 acquires an access token for using the cloud print service from the input parameters of the CreatePrintJobSet function. Then, the image conversion APP 144 stores an access token for using the cloud printing service in the session management database.

  Furthermore, the image conversion APP 144 acquires the URL of the storage location of the print image (PDF file) from the input parameters of the CreatePrintJobSet function, and stores the URL of the storage location of the print image (PDF file) in the session management database.

  Subsequently, the image conversion APP 144 sets “1” indicating that the process is in progress to the progress status (Progress) indicating the progress of the process in the session management database (S1003), and moves the process to S1004. In S1004, the image conversion APP 144 generates a download / image conversion thread, and the process proceeds to S1005. The processing of the download / image conversion thread will be described later with reference to FIG.

  Subsequently, the image conversion APP 144 sets, in the response message included in the BODY of the response to the HTTPS POST request, SUCCESS indicating that this function has been successfully completed and the session ID generated in S1002 (S1005). Then, the image conversion APP 144 transmits a response message to the POST request issuer (in this example, the proxy APP 143) (S1005). Then, the image conversion APP 144 ends the process of the CreatePrintJobSet function (S1006).

  When the image conversion APP 144 generates a download / image conversion thread in S1004, a thread different from the CreatePrintJobSet function is activated. In this thread, the download / image conversion thread process shown in FIG. 10B is executed.

  As shown in FIG. 10B, the image conversion APP 144 starts the processing of the download / image conversion thread (S1011). Then, the image conversion APP 144 uses the access token for using the cloud print service, and accesses the URL of the storage location of the print image (PDF file) using the HTTPS GET method encrypted by SSL communication. That is, the image conversion APP 144 downloads a print image (PDF file) from the cloud print service and temporarily stores it in the RAM 201 (S1012).

  Further, after completing the download, the image conversion APP 144 converts the print image (PDF file) into a JPEG file that can be printed by the MFP 3. Note that setting information indicating a printable format is stored in advance in the HDD 202 of the PC 5 for each printer or MFP. Then, the image conversion APP 144 stores the JPEG file in a folder composed of the printer ID issued by the cloud printing APP 146 and the print job ID (S1013).

In S1013, the image conversion APP 144 sets the access token to the image conversion APP 144 in the access token to the image conversion APP 144 in the session management database. The access token for the image conversion APP 144 is an access token for the printer or MFP (MFP 3 in this example) associated with the printer ID issued by the cloud print APP 146 to access the print image (JPEG file). In step S <b> 1013, the image conversion APP 144 sets the URL (first page) where the print image (JPEG file) is stored in the print job access URL in the session management database.
[Example]
Printer ID: abcde
Print job ID: 1234
Total number of pages of print image (JPEG file): 3 pages Data storage in PC2:
C: ¥ abcde1234 ¥
p1. jpg
p2. jpg
p3. jpg
URL: http: // www. abc. xxx / printdata /? pi = abcde & ji = 1234 & p = 1
Since this URL represents the JPEG file (p1.jpg) of the first page, the MFP 3 obtains the page number to be acquired in the query parameter “p” that represents the page number when acquiring the print image of each page. specify. In step S <b> 1013, the image conversion APP 144 converts the print image (PDF file) and deletes the print image (PDF file) downloaded in step S <b> 1012 from the RAM 201 after the conversion of the print image (JPEG file) of all pages is completed. .

  Subsequently, the image conversion APP 144 determines whether an error has been detected in any of the processes of S1011 to S1013 (S1014). At this time, if it is determined that an error has been detected, the image conversion APP 144 proceeds to S1016. If it is determined that no error has been detected, the image conversion APP 144 determines that the error has ended normally and proceeds to S1015.

  In step S1015, the image conversion APP 144 determines whether the progress in the session management database is correct. ? “0” representing normal termination is set in the status (Progress), and the processing of the download / image conversion thread is terminated (S1017). In step S1016, the image conversion APP 144 determines whether the progress in the session management database is correct. ? “2” indicating an error end is set in the status (Progress), and the processing of the download / image conversion thread is ended (S1017). In step S1017, the image conversion APP 144 deletes information related to the print job from the session management database, and updates the session management database.

  Next, Web service API processing exported by the image conversion APP 144 will be described with reference to FIG. FIG. 11A is a diagram illustrating an example of a flowchart relating to the process of the ConfirmProgress function. FIG. 11B is a diagram illustrating an example of a flowchart relating to processing of the JobCompleted function.

  Here, for the ConfirmProgress function, the HTTP GET method is used. For the JobCompleted function, the HTTPS POST method encrypted by SSL communication is used. The programs according to these flowcharts are incorporated in the PC 5 and stored in the HDD 202, and are read into the RAM 201 by the CPU 204 and executed.

In S614 of FIG. 6, when the proxy APP 143 calls the Confirm Progress function, the image conversion APP 144 executes the process of the Confirm Progress function shown in FIG. As shown in FIG. 11A, the image conversion APP 144 starts the process of the Confirm Progress function (S1101), and executes the access token confirmation process described later in FIG. 15 (S1125). At this time, the following information is passed as an argument of this process (subroutine function).
・ Service ID
・ Printer ID issued by Cloud Print APP146
-Print job ID issued by cloud print APP146
Access token for using the image conversion APP 144 At this time, the HTTP GET request for the Confirm Progress function includes a session ID and a sequence as query parameters. The sequence is an arbitrary number generated by a GET request issuer (proxy APP 143 in this example).

  Subsequently, the image conversion APP 144 uses the session ID included in the query parameter as a search key to determine the progress in the session management database. ? The status (Progress) is confirmed (S1102). Subsequently, the image conversion APP 144 is a progress? ? If it is determined that “0” indicating normal termination is set in the status (Progress) (YES in S1103), the process proceeds to S1104. On the other hand, if the image conversion APP 144 determines that anything other than “0” (“1” or “2”) is set (NO in S1103), the process proceeds to S1105.

  In step S1104, the image conversion APP 144 sets “processing completion response” in the response message included in the BODY of the response to the HTTP GET request, and the process proceeds to step S1108. In step S1105, the image conversion APP 144 determines whether it is a progress? ? Check the status (Progress). At this time, the image conversion APP 144 is a progress? ? If it is determined that “1” indicating that processing is in progress (Progress) is set, the process proceeds to S1106. On the other hand, if it is determined that other than “1” (“2”) is set, the process proceeds to S1107. Move processing.

  In step S1106, the image conversion APP 144 sets “response in process” in the response message included in the BODY of the response to the HTTP GET request, and the process proceeds to step S1108. In S1107, the image conversion APP 144 sets “error response” in the response message included in the BODY of the response to the HTTP GET request, and moves the process to S1108.

  In step S1108, the image conversion APP 144 transmits a response message to the GET request issuer (proxy APP 143 in this example), and ends the process of the ConfirmProgress function (S1109).

Here, details of the “processing completion response”, “processing response”, and “error response” will be described. Each of these responses is a result calculated using the sequence included in the query parameter of the GET request in S1101, and is composed of, for example, character string information obtained by converting the following information into a character string.
"Processing completion response" = Sequence "Processing response" = Sequence + 1
"Error response" = Sequence + 2
As described above, the image conversion APP 144 uses character string information that does not generally have a meaning, rather than visible information defined using XML as a response to the HTTP GET request. It is possible to prevent malfunction or inappropriate control due to inappropriate access to the Web service API. Note that the configuration for preventing such inappropriate access is not limited to this example, and more complicated operations such as hashing may be combined. In S803 of FIG. 8, when the proxy APP 143 calls the JobCompleted function, the image conversion APP 144 executes the processing of the JobCompleted function shown in FIG.

As shown in FIG. 11B, when the image conversion APP 144 starts processing of the JobCompleted function (S1121), the image conversion APP 144 executes access token confirmation processing described later in FIG. 15 (S1126). At this time, the following information is passed as an argument of this process (subroutine function).
・ Service ID
・ Printer ID issued by Cloud Print APP146
-Print job ID issued by cloud print APP146
The access token for using the image conversion APP 144 and the print image (JPEG file) are deleted (S1122), and the process proceeds to S1123.

  In step S <b> 1123, the image conversion APP 144 sets SUCCESS indicating the normal end in the response message included in the BODY of the response to the HTTPS POST request. In step S1123, the image conversion APP 144 transmits a response message to the POST request issuing source (the proxy APP 143 in this example). Then, the image conversion APP 144 ends the processing of the JobCompleted function (S1124).

  Next, processing of the Web service API exported by the image conversion APP 144 will be described with reference to FIG. FIG. 12 is a diagram illustrating an example of a flowchart according to the process of the CreatePrintJobResult function.

  As for the CreatePrintJobResult function, an HTTPS POST method encrypted by SSL communication is used. The program according to this flowchart is incorporated in the PC 5, stored in the HDD 202, read out to the RAM 201 by the CPU 204 and executed.

In S701 of FIG. 7, when the proxy APP 143 calls the CreatePrintJobResult function, the image conversion APP 144 executes processing of the CreatePrintJobResult function shown in FIG. As shown in FIG. 12, the image conversion APP 144 starts processing of the CreatePrintJobResult function (S1201), and executes access token confirmation processing described later in FIG. 15 (S1207). At this time, the following information is passed as an argument of this process (subroutine function).
・ Service ID
・ Printer ID issued by Cloud Print APP146
-Print job ID issued by cloud print APP146
Access token for using the image conversion APP 144 Subsequently, the image conversion APP 144 sets an access token for using the image conversion APP 144 in the response message included in the BODY of the response to the POST request of HTTPS (S1202). , Processing proceeds to S1203.

  In step S1203, the image conversion APP 144 sets the print job access URL (URL of the storage location of the JPEG file) in the response message included in the BODY of the response to the POST request, and the process proceeds to step S1204. In step S1204, the image conversion APP 144 sets the total number of pages of the print image (JPEG file) in the response message included in the BODY of the response to the POST request, and the process proceeds to step S1205. In step S1205, the image conversion APP 144 transmits a response message to the POST request issuer (proxy APP 143 in this example), and ends the process of the CreatePrintJobResult function (S1206).

  FIG. 13 is a diagram illustrating an example of a calling sequence of the Web service API. FIG. 13A is a diagram illustrating an example of a calling sequence between the proxy APP 143 and the MFP 3. FIG. 13B is a diagram illustrating an example of a calling sequence between the proxy APP 143 and the image conversion APP 144.

  As shown in FIG. 13A, between the proxy APP 143 and the MFP 3, the MFP 3 calls the Web service API exported by the proxy APP 143. That is, the Web service API exported by the proxy APP 143 is called in the order of CheckPrintJob function, GetPrintJob function, and EndPrintJob function.

  Here, for the CheckPrintJob function (only the polling process), the unencrypted HPPT GET method is used, and for all other functions, the HTTPS GET method encrypted by SSL communication is used. . In this way, by using an unencrypted HTTP method for polling only for confirming the presence or absence of a print job, the peripheral device control system that reduces the time required for polling and is excellent in user operability Can be realized. Further, since the load on polling can be reduced, for example, a configuration for dealing with the load is not required, so that the system construction and the firmware of the printer and MFP can be easily implemented, and the development cost can be reduced.

  As shown in FIG. 13B, between the proxy APP 143 and the image conversion APP 144, the proxy APP 143 calls a Web service API exported by the image conversion APP 144. That is, the Web service API exported by the image conversion APP 144 is called in the order of CreatePrintJobSet function, ConfirmProgress function, CreatePrintJobResult function, and JobCompleted function.

  Here, for the ConfirmProgress function (only the polling process), the unencrypted HPPT GET method is used, and for all other functions, the HTTPS POST method encrypted by SSL communication is used. .

  In this way, by using an unencrypted HTTP method for polling only for confirming the progress of processing, a peripheral device control system that reduces time required for polling and has excellent user operability. Can be realized. Further, since the load applied to polling can be reduced, for example, a configuration for dealing with the load is not required, so that the system construction and the application implementation are facilitated, and the development and operation costs can be reduced.

  Next, processing of the Web service API exported by the image conversion APP 144 will be described with reference to FIG. FIG. 14 is a diagram illustrating an example of a flowchart relating to processing of the RegisterAndAuth function. For the RegisterAndAuth function, the HTTPS POST method encrypted by SSL communication is used. The program according to this flowchart is incorporated in the PC 5, stored in the HDD 202, read out to the RAM 201 by the CPU 204 and executed.

  In FIG. 14, processing related to error cases is omitted, and only normal cases are shown. In S622 of FIG. 6, when the proxy APP 143 calls the RegisterAndAuth function, the CPU 204 of the image conversion APP 144 executes the processing of the RegisterAndAuth function shown in FIG. In step S1401, the image conversion APP 144 starts processing of the RegisterAndAuth function.

  In step S <b> 1407, the image conversion APP 144 acquires the time when the processing of the RegisterAndAuth function starts. In step S <b> 1402, the image conversion APP 144 receives preprocessing information including input parameters from the proxy APP 143. The image conversion APP 144 performs user authentication using “user ID using the image conversion APP 144” and “user password using the image conversion APP 144” as input parameters. Here, the image conversion APP 144 uses the input parameters to call a user authentication function that is one of the Web service APIs exported by the authentication APP 148 to perform user authentication. The HDD 202 of the authentication APP 148 functions as a holding unit that holds user authentication information, and the CPU 204 of the authentication APP 148 performs user authentication when a user exists.

  For example, when user authentication is the first time, there is no user in the authentication APP 148. Further, due to the storage capacity of the HDD 202 functioning as a storage unit, there may be a case where the user does not exist when the above input parameters are old. Under the above-described situation, the image conversion APP 144 fails in user authentication in S1402. When the user authentication fails, the image conversion APP 144 uses “an administrator ID using the authentication APP 148” and “an administrator password using the authentication APP 148” as input parameters from the proxy APP 143. Here, login is performed by calling a login function which is one of the Web service APIs exported by the authentication APP 148.

After login, the image conversion APP 144 performs new user registration using the “user ID that uses the image conversion APP 144” and the “user password that uses the image conversion APP 144”. Here, the image conversion APP 144 calls a user registration function that is one of the Web service APIs exported by the authentication APP 148. The image conversion APP 144 performs user authentication after new user registration or simultaneously with the registration process. When the user authentication is successful, the CPU 204 of the image conversion APP 144 calls an access token generation function that is one of Web service APIs exported by the authentication APP 148. Thereby, the CPU 204 of the image conversion APP 144 acquires an access token for using the image conversion APP 144 (S1403). The image conversion APP 144 stores an access token for using the image conversion APP 144 as a first access token in the session management database of the HDD 202 (S1404). In other words, the CPU 204 of the image conversion APP 144 functions as an acquisition unit that transmits an authentication request to the authentication APP 148 and acquires the first access token from the authentication APP 148. In addition, the session management database functions as a storage unit and stores the following information.
[Session Management Database]
Search key: Value generated by combining service ID, printer ID issued by cloud print APP 146, and print job ID issued by cloud print APP 146 Access token for using image conversion APP 144 Acquired in S1407 However, if information with the same search key is already saved when saved in the session management database, it is not saved.

  In S1404, if the information with the same search key is already stored in the session management database, the response of the RegisterAndAuth function called by the proxy APP143 has not been received even after a predetermined time has passed, so the proxy APP143 retries the RegisterAndAuth function. It can be determined that the call has been made again. When the proxy APP 143 calls the RegisterAndAuth function by retry, the input parameters are all set to the same parameters as in the first call. Therefore, the search key for storing information in the session management database has the same value for the first call and for the retry call. Further, when the proxy APP 143 retries the Web service API, the proxy APP 143 does not accept the response of the RegisterAndAuth function that is called for the first time. Then, the access token obtained from the response of the RegisterAndAuth function called in the retry process is called as an input parameter of the CreatePrintJobSet function as an access token for accessing the image conversion APP 144. Therefore, the access token acquired by the retry process must be stored in the session management database.

  In step S1408, the image conversion APP 144 determines whether the same search key information has been stored in the session management database in step S1404. If the same search key information is not stored, the access token is stored in the session management database in S1404. If the same search key information is already stored in the session management database, the stored time information is compared with the time information acquired in S1407 (S1409).

  If the time information acquired in S1407 is newer than the RegisterAndAuth function that has acquired the access token stored in the session management database, the RegisterAndAuth function that is currently being processed is a retry process that is called later. It can be judged that there is. Therefore, the access token and time information stored in the session management database are updated with the access token acquired in S1403 and the time information acquired in S1407, respectively (S1410).

  If the time information acquired in S1407 is older or the same as the comparison result, the RegisterAndAuth function that acquired the access token stored in the session management database is later than the RegisterAndAuth function that is currently being processed. It can be determined that the called retry processing has been performed. Therefore, the session management database is not updated. As a result, it is guaranteed that the access token acquired by the process of the RegisterAndAuth function called by the retry process is always stored in the session management database. Also, even when retry processing occurs a plurality of times, it is guaranteed that the access token acquired by the RegisterAndAuth function of the last called retry is saved.

  In step S <b> 1405, the image conversion APP 144 creates a response message to be included in the BODY of the response to the HTTPS POST request. Specifically, the image conversion APP 144 sets SUCCESS indicating that the RegisterAndAuth function has been normally completed and an access token for using the image conversion APP 144 acquired in S1403. Then, the image conversion APP 144 transmits a response message to the POST request issuer (proxy APP 143 in this example) (S1405). In step S1406, the image conversion APP 144 ends the processing of the RegisterAndAuth function.

  FIG. 15 is a diagram illustrating an example of a flowchart relating to the access token confirmation processing of the image conversion APP 144. The program according to this flowchart is incorporated in the PC 5, stored in the HDD 202, read out to the RAM 201 by the CPU 204 and executed.

The access token confirmation process is a subroutine function in the image conversion APP 144, and the following information is passed as an argument of the subroutine function.
・ Service ID
・ Printer ID issued by Cloud Print APP146
-Print job ID issued by cloud print APP146
The access token image conversion APP 144 for using the image conversion APP 144 executes access token confirmation processing in S1018 of FIG. 10, S1125 of FIG. 11A, S1126 of FIG. 11B, and S1207 of FIG. . As shown in FIG. 15, the image conversion APP 144 starts an access token confirmation process in S1501. The image conversion APP 144 generates a search key by combining the service ID, the printer ID issued by the cloud print APP 146, and the print job ID issued by the cloud print APP 146 (S1502). In S1503, the image conversion APP 144 searches the session management database using this search key.

  In step S1504, if the image conversion APP 144 finds information associated with the search key in the session management database, the image conversion APP 144 proceeds to step S1505. If not found, the image conversion APP 144 proceeds to step S1509. The CPU 204 of the image conversion APP 144 compares whether or not the access token (second access token) for using the image conversion APP 144 matches the access token stored in the session management database. That is, the CPU 204 of the image conversion APP 144 functions as a comparison unit that compares the first access token and the second access token. In step S1506, the image conversion APP 144 proceeds to step S1507 if it is determined that they match, and proceeds to step S1509 if it determines that they do not match.

  In step S1507, the image conversion APP 144 sets Success indicating success to a return value. Then, the image conversion APP 144 returns to the caller of this subroutine function (S1508). In step S1509, the image conversion APP 144 sets Failure indicating failure to a return value. Then, the image conversion APP 144 creates a response message in response to an HTTP POST request of the Web service API exported by the image conversion APP 144 that is the caller of this subroutine function. The CPU 204 of the image conversion APP 144 sets FAILURE indicating that the API has succeeded and ended in failure to the response message included in the response BODY, and stops the processing (S1509). Then, the image conversion APP 144 transmits a response message to the POST request issuer (in this example, the proxy APP 143) (S1510). Then, the image conversion APP 144 ends the subroutine function and the API processing (S1511). That is, here, the CPU 204 of the image conversion APP 144 functions as a process execution unit that executes a process when it is determined that the first access token and the second access token match, and stops the process when it is determined that they do not match. To do.

  In step S1505, the image conversion APP 144 performs comparison processing. Specifically, the access token for using the image conversion APP 144 passed as an argument of the subroutine function is compared with the access token for using the image conversion APP 144 stored in the session management database. By comparing whether or not the access tokens match, the image conversion APP determines the validity of the access token without using the access token validation function exported by the authentication APP 148. Therefore, every time the proxy APP 143 calls the image conversion APP 144, the image conversion APP 144 does not need to call the access token validation function of the Web service API exported by the authentication APP 148. As a result, performance can be improved.

  Further, the scale of the system of the authentication APP 148 can be reduced, and the configuration can be simplified. Thereby, the operation cost can be lowered. Furthermore, it is also effective against an attack by a spoofing program impersonating the proxy APP 143, which is a higher-level service. It is also possible to prevent malfunctions and information leaks due to attacks such as access from spoofing programs.

  Furthermore, when the proxy APP 143, which is a higher-level service, malfunctions, for example, an access token given to a certain print job may be associated with another print job due to the malfunction. Even in such a case, the image conversion APP 144 can stop printing without processing the print job, so that erroneous printing can be prevented.

  Further, when there is no user in the authentication APP 143, the image conversion APP 144 performs new user registration. This eliminates the need for the user to perform user registration, and improves usability.

  The information processing system of the present embodiment described above can achieve the following effects. The information processing system according to the present embodiment determines the validity of the access token based on the comparison processing result of the access token for using the image conversion APP. Therefore, according to the information processing system of the present embodiment, it is possible to suppress a large number of calls of the Web service API provided by the Web service application and improve performance. In addition, the scale of the Web service application system can be reduced, and the configuration can be simplified. Further, the operation cost can be reduced by simplifying the configuration.

  Further, according to the information processing system of the present embodiment, it is possible to prevent malfunction and information leakage at the time of an attack by a spoofing program impersonating a Web service application. In addition, when a Web service application malfunctions, it is possible to prevent erroneous processing of a non-applicable process or job (for example, another person's print job).

  Further, according to the information processing system of the present embodiment, time is not required for the confirmation process of the progress status of the image conversion process by polling and the confirmation process of the presence / absence of a print job by polling, thereby improving user operability. be able to. Furthermore, since it does not hinder the implementation of firmware of a low-cost printer or multifunction machine having a low performance like the MFP 3 and each process does not take time, the operability for the user can be improved.

  In addition, according to the information processing system of the present embodiment, a delay occurs in the process of acquiring an access token for using the image conversion APP from the authentication service, and even when the retry process of the authentication request is executed from the upper service, It is possible to correctly determine the validity of the access token used by the upper service when transmitting the process execution request.

  In the embodiment described above, a personal computer is assumed as the information processing apparatus. However, the present invention is not limited to this example, and can be applied to any information processing apparatus (terminal) that can be used in a similar manner, such as a DVD player, a game, a set-top box, and an Internet home appliance.

  In the above-described embodiment, the MFP is exemplified as the peripheral device. However, the peripheral device may be any one of a copying machine, a facsimile, a scanner, a digital camera, and a device having a composite function thereof.

  In the above-described embodiment, an OS equivalent to Windows (registered trademark) is used as an example of the OS. However, the present invention is not limited to this OS, and an arbitrary OS can be used. In the above-described embodiment, Ethernet (registered trademark) is used as a configuration example of the network 4. However, the configuration is not limited to this example, and any other network configuration may be used.

  In the embodiment described above, Ethernet (registered trademark) is used as an interface between the PC 1, PC 2, PC 5, PC 7 and the MFP 3, MFP 103. However, the present invention is not limited to this interface, and any interface such as a wireless LAN, IEEE 1394, Bluetooth (registered trademark), USB, or the like may be used. Moreover, you may comprise the function in various applications (firmware), a part of the process which concerns on the flowchart mentioned above, or all using dedicated hardware.

(Other examples)
The present invention can also be realized by executing the following processing. That is, when the proxy APP 143 calls the RegisterAndAuth function by retry, the image conversion APP 144 first calls the service ID, printer ID, and print job ID used to generate the search key when storing information in the session management database. A value different from the setting value of the RegisterAndAuth function is set. This prevents information from being stored in the session management database with the same search key even if the RegisterAndAuth function is recalled due to a retry.

  The present invention can also be realized by executing the following processing. That is, software (computer program) that realizes the functions of the above-described embodiments is supplied to a system or apparatus via a network or various storage media. Then, the computer (or CPU, MPU, etc.) of the system or apparatus reads out and executes the program. In this case, the program and the storage medium storing the program constitute the present invention.

143 Proxy APP, 144 Image Conversion APP, 148 Authentication APP

Claims (7)

A relay service device (143) that performs relay processing related to a service provided to a user by a providing device (3, 103) via a network, and an intermediate service device that communicates with the relay service device and performs related processing regarding the service (148) (144) and an authentication service device that receives an authentication request from the intermediate service device and performs an authentication process,
The relay service device
Transmission means (S622, S612) for transmitting an authentication request and a process execution request to the intermediate service device;
The intermediate service device is:
Acquisition means (S1407) for acquiring a first time at which the authentication request from the relay service device is received;
Obtaining means (S1402, S1403) for transmitting the authentication request from the relay service device to the authentication service device and obtaining a first access token from the authentication service device that has been successfully authenticated;
Storage means for storing the first access token in association with the first time (S1404);
A comparison unit (S1505) for comparing a first access token stored in the storage unit with a second access token included in the processing execution request when the processing execution request is received;
If the comparing means determines that the first access token and the second access token match, the processing received from the intermediate service device is executed (S1507), and the first access token and the second access token are executed. If it is determined that the access tokens do not match, the processing is not executed (S1509),
The storage means is further stored in association with the first time and the third access token when the third access token has already been saved by the storage means (S1408). Comparing means (S1409) for comparing with a second time, and updating the third access token to the first access token only when the first time is newer than the second time. An information processing system characterized by storing (S1410). The transmitting means transmits an authentication request including authentication information of a user and authentication information of the relay service device to the intermediate service device,
If the authentication service has not succeeded in the authentication using the user authentication information, the acquisition unit registers the user authentication information in the authentication service device using the authentication information of the relay service device. The information processing system according to claim 1, wherein registration processing is executed. The authentication service includes holding means for holding authentication information of the user,
The acquisition means acquires the first access token issued by the authentication service device when the authentication service holds authentication information corresponding to the authentication information of the user. The information processing system according to claim 1 or 2.   The information processing system according to any one of claims 1 to 3, wherein the intermediate service is an image conversion service that converts a PDF file received from the relay service apparatus into a JPEG file. An intermediate service device that communicates with a relay service device that performs relay processing related to a service provided to a user by a providing device via a network, and makes an authentication request to the authentication service device,
Receiving means for receiving an authentication request and a process execution request from the relay service device;
Obtaining means for obtaining a first time at which the authentication request from the relay service device is received;
Obtaining means for sending the authentication request to the authentication service device and obtaining a first access token from the authentication service device that has been successfully authenticated;
Storage means for storing the first access token in association with the first time;
A comparison unit that compares a first access token stored in the storage unit with a second access token included in the processing execution request when the processing execution request is received;
When the comparing means determines that the first access token and the second access token match, the processing received from the intermediate service device is executed, and the first access token and the second access token are When it is determined that they do not match, a process execution unit that does not execute the process is provided,
The storage means further includes a first time and a second time stored in association with the third access token when the third access token is already stored by the storage means. And the third access token is updated to the first access token and stored only when the first time is newer than the second time. Intermediate service device. A relay service device that performs relay processing related to a service provided by a providing device to a user via a network; an intermediate service device that communicates with the relay service device and performs related processing related to the service; and an authentication request from the intermediate service device. An authentication method in an information processing system including an authentication service device that receives and performs authentication processing,
A request step in which the relay service device makes an authentication request to the intermediate service device;
An acquisition step in which the intermediate service device acquires a first time at which the authentication request is received from the relay service device;
Receiving the authentication request from the relay service device and obtaining a first access token from the authentication service device that has been successfully authenticated;
A storage step in which the intermediate service device stores the first access token in association with the first time;
A comparison step of comparing the first access token stored in the storage unit with the second access token included in the process execution request when the intermediate service device receives the process execution request;
When the intermediate service device determines that the first access token and the second access token match, the intermediate service device executes a process received from the intermediate service device, and executes the first access token and the second access token. If it is determined that the tokens do not match, a process execution step that does not execute the process,
In the storage step, when the third access token is already stored by the storage step, the first time and the second time stored in association with the third access token are stored. And the third access token is updated and stored in the first access token only when the first time is newer than the second time. Authentication method. A computer program for causing a computer to execute the authentication method according to claim 6.