DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
The following title is suggested:
SYSTEMS AND METHODS FOR COLLECTING PRINTING USAGE STATISTICS COMPRISING STATISTICS INCLUDING A NUMBER OF PRINTED DOCUMENTS AND A NUMBER OF RECEIVED PRINT REQUESTS.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 11-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the computer-readable storage medium is considered as both non-transitory and transitory. Since a transitory embodiment is non-statutory, claims 11-19 are considered to contain non-statutory subject matter.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s) a mental process or a method of organizing human activity. In particular, the recording or writing down of a number of printed documents for each form and a number of received print requests at different intervals can occur with a pencil and paper using a human mental or physical activity. This judicial exception is not integrated into a practical application because the use of client systems is considered as disclosing the technological environment. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the use of client systems is a well-known routine and conventional activity.
For claims 11 and 20 introduce a server that receives this information at a third predetermined interval. The use of the server is considered to disclose a technological environment and does not integrate the abstract idea of the presented in claim 1 captured in claims 11 and 20 into a practical application. The receipt of a group of information at a third interval is considered as a well-known, routine and conventional activity and is not considered as an additional element that is sufficient to amount to significantly more than the judicial exception.
Claim 2 is considered as a mental process that allows a user to computer or calculate a peak time based on the stored or recorded number of requests in the system recorded at a specific period of time. This feature, taken alone or in combination, does not integrate the abstract idea into a practical application nor is it considered significantly more than the judicial exception. This applies to claims 12 and 21.
Similar to claim 11 and 20, claim 3 contains the abstract idea of a mental process or a method of organizing human activity of receiving recorded number of printed documents and the number of print requests at a specific third interval of time. The use of client systems is considered as disclosing a technological environment that does not integrate the abstract idea into a practical application. The additional element of the designation of the third predetermined interval of time is considered as a well-known, routine and conventional activity that is not considered to amount to significantly more than the judicial exception.
Claim 4 discloses the receipt of data at a server at a third interval is considered as a data gathering step that does not integrate the abstract idea into a practical application. The sending of a request from a server to a client system to provide information is an additional element that is well-known, routine and conventional activity that is not considered to amount to significantly more than the judicial exception. This applies to claims 13 and 22.
Claim 5 contains the step of consolidating information at a fourth time interval that is considered as selecting the type of data to be manipulated, which is considered as insignificant extra-solution activity. This aspect does not integrate the abstract idea into a practical application. Determining a fourth time interval to be set at a particular longer time is considered as a well-known, routine and conventional activity that does not amount to significantly more than the judicial exception. This applies to claims 14 and 23.
Claim 6 discloses the recording the number of printed documents for type of account, which is an abstract idea of a mental process or a method of organizing human activity. This could also be considered as a data gathering step. In either case, the above considered alone or in combination, does not integrate the abstract idea into a practical application. The account information in claims 6 or 7 are considered as an additional element that indicates the technological environment that is not sufficient to amount to significantly more than the judicial exception. This applies to claims 15, 16, 24 and 25.
Claim 8 discloses recording a number of printed document for several systems, which is considered as an abstract idea of a mental process or method of organizing human activity. In addition, this can be considered as a data gathering step. In either case, this limitation, taken alone or in combination, does not integrate the abstract idea into a practical application. The printing using the first or second systems is considered as well-known, routine and conventional activity that does not amount to significantly more than the judicial exception. This applies to claims 17 and 26.
Claims 9 and 10 contain the abstract idea of receiving recorded numbers of printed documents and numbers of print requests. This is considered as a mental step of recording or writing down the information. In addition, this can be considered as a data gathering step. This abstract idea, considered alone or in combination, does not integrate the abstract idea into a practical application. The storing of the information on a database managed by the computing device or on a database stored on and managed by cloud servers is considered as well-known, routine and conventional activity that does not amount to significantly more than the judicial exception. This applies to claims 18, 19, 27 and 28.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 3, 5-11, 14-20 and 23-28 is/are rejected under 35 U.S.C. 102(a1 and/or a2) as being anticipated by Ohno (US Pub 2014/0240748).
Re claim 1: Ohno discloses a method of collecting printing statistics comprising:
recording a number of printed documents for each form type at first predetermined intervals of time by each client system of a plurality of client systems (e.g. the invention discloses storing a number of printed documents associated with the form of a cloud print job and an intranet print job. The printed number of documents are stored at a different time when the job is printed or completed, which is taught in ¶ [68]-[71]. This time is later than the temporary time of storing the job request ID.); and
[0068] Subsequently, the print job receiving unit 323 determines whether the received job is for intranet printing or cloud printing (S502). In intranet printing and cloud printing, the ports used when receiving the job are different from each other, and the received job can be determined based on the port. The determination method is not limited thereto, and alternatively, the received job may be determined based on information as to whether the user ID is included in the job. Next, the printer driver 312 performs the user authentication processing by using an intranet user ID of a general user with the print job receiving unit 323 (S520).
[0069] More specifically, the printer driver 312 embeds the intranet user ID and the password into the print job before transmitting the print job. The print job receiving unit 323 that has received the print job queries the authentication unit 340 of the intranet user managing server 140 about the user authentication. Note that there are different variations of the authentication method, and thus, the authentication method is not limited thereto. After the user authentication processing, the print job receiving unit 323 extracts the job ID of the print job and the intranet user ID of the general user, and temporarily stores them in association with each other (S503).
[0070] Next, the print job receiving unit 323 passes the received print job to the print processing unit 322, and the print processing unit 322 executes the print processing and the print-related processing (S506). Then, the print processing unit 322 temporarily stores the print-related information (S507). Subsequently, the print processing unit 322 stores the intranet user ID, the job ID, and the number of printed sheets used for the print processing in the job log storing unit 321 (S509, S510 and S513). FIG. 4A illustrates a job log example stored in the job log storing unit 321. More specifically, the print processing unit 322 adds a new record to a format in a table format shown in FIG. 4A. Then, the print processing unit 322 records the received date and time of the print job, the intranet user ID of the print job, the job ID of the print job, the number of printed sheets, and a transmission "non-transmitted" in a date and time column, a user ID column, a job ID column, the number of printed sheets column, and a transmission column, respectively.
[0071] Subsequently, a description will be given of the processing for transmitting the job log from the printer 120 to the intranet print managing server 130 with reference to FIG. 8B. Note that, the processing shown in FIG. 8B is performed in the both cases of intranet printing and cloud printing. The job log transmitting unit 324 periodically searches for a row in which "non-transmitted" is entered in the transmission flag column shown in FIG. 4A from among the job logs stored in the job log storing unit 321. The job log transmitting unit 324 transmits the retrieved row to the job log receiving unit 332 of the intranet print managing server 130 (S514 and S515). When the transmission is completed, the job log transmitting unit 324 records "transmitted" in the transmission flag column in FIG. 4A (S516).
recording a number of received print requests at second predetermined intervals of time by each client system of the plurality of client systems (e.g. the invention discloses a job ID and user ID is stored in association with each other at an initial interval, which is taught in ¶ [69] above.).
Re claim 3: Ohno discloses the method of claim 1, further comprising receiving recorded numbers of printed documents and recorded numbers of print requests at third predetermined intervals of time from each client system of the plurality of client systems (e.g. a server can receive both the job IDs and documents printed from the printer or MFP. This occurs at a different time from the temporary storing of the job ID and the printed documents once printed. This is taught in [71] above and [72]-[77]. This can be a later time after the storage of the job ID temporarily and the storage of the printed sheets.),
[0072] Next, a description will be given of the count processing by the intranet print managing server 130 with reference to FIG. 9A. Upon receipt of a job log from each printer (S601), the job log receiving unit 332 the intranet print managing server 130 performs the analysis and update processing with respect to each row (S610). If only the job log row (reference numeral 411 in FIG. 4A) of which printing is performed in intranet printing is focused on, the job log receiving unit 332 confirms whether a column of the user ID is changed to a mark specific to cloud printing (S602).
[0073] When it is determined that the printing is intranet printing, the job log receiving unit 332 advances the processing to S610 and ends the analysis and update processing of this row. When all processing of other rows (S610) is ended, a printer ID of a transmission source is added to the object row as well as the other rows, the transmission flag column (reference numeral 415 in FIG. 4A) is eliminated, and the row focused on is merged in the consolidated job log (S609). The merge result in the consolidated job log is shown in FIG. 4B. Among printer IDs, a row 421 corresponds to the row 411 shown in FIG. 4A.
[0074] Next, a description will be given of the processing when a system manager or the like accesses the intranet print managing server 130 by using the Web browser with reference to FIG. 9B. Note that the processing shown in FIG. 9B is performed in both of the cases of intranet printing and cloud printing. When a system manager accesses the intranet print managing server 130 by using the Web browser, the intranet print managing server 130 displays a management screen (the screen without the table in FIG. 7) (S621). When the system manager presses an OK button after inputting conditions for filtering a user or a print job such as "department", "period", or the like, the intranet print managing server 130 receives the request (S622). Then, the intranet print managing server 130 issues a query for searching for a row conforming to a filter condition, and retrieves the relevant row group from the consolidated job log storing unit 331 (S623).
[0075] Subsequently, the intranet print managing server 130 batches the retrieved row group for each intranet user ID, and adds the number of printed sheets (S624). Then, the intranet print managing server 130 generates a screen in which information relating to the number of printed sheets is represented in a table format, and responds the Web browser with the screen (S625). In this manner, the system manager can comprehend the number of printed sheets for each user, and manage the number of printed sheets without experiencing a feeling that something is wrong by calling attention to a user whose number of printed sheets is high even on the occasion where cloud printing is performed.
[0076] Next, a description will be given of the print processing and the count processing in the case of cloud printing. FIG. 10 illustrates a process flow performed by the cloud print server 160. This flow is the processing from a print instruction by a user through the Web browser to a print job transmission to the printer. A general user operates the Web browser 310 of the client 110, operates the Web application 350 of the Web application server 150, and generates a content the user wishes to be printed. After generating the content, the general user instructs the Web application 350 to execute printing using the printer 120 via the cloud printing system.
[0077] The Web application 350 subjects the content to a format conversion as necessary, and transmits the content to the cloud print server 160. The content receiving unit 365 of the cloud print server 160 receives the content (S701). Subsequently, the content receiving unit 365 performs the authentication processing with the cloud user ID by cooperating with the authentication unit 380 of the cloud user managing server 180 (S702).
wherein each third predetermined interval of time is longer than any of each first predetermined interval of time and each second predetermined interval of time (e.g. the time of sending the job ID and printed documents is a time that can be later than after the receipt of the print job and after recording the printed documents. The time of when the information is sent to the servers is detailed in ¶ [71]-[77] above. This time frame can be at a later and longer time frame than the receipt of jobs and storage of related job ID and printed documents information.).
Re claim 5: Ohno discloses the method of claim 3, further comprising consolidating the received recorded numbers of printed documents and the received recorded numbers of print requests from the plurality of client systems at fourth predetermined intervals of time, wherein each fourth predetermined interval of time is equal to or longer than each third predetermined interval of time (e.g. the system manager can access the intranet print managing server associated with a printer to set a cloud print setting. The system manager can access this setting once a day or at a larger interval that is larger than the time when job logs are sent to the server in order to see all the printed documents. The system manager accessing the server is taught in ¶ [62]-[65]. As seen in figure 4, the print requests of a user are consolidated into a single list for the user’s print requests, which is taught in ¶ [95].).
[0062] A system manager in the company or the like registers the printer 120 with the cloud print server 160. In this manner, information for connecting to the printer 120 is stored in the printer information storing unit 361 of the cloud print server 160, which enables transmission of the print job from the print job transmitting unit 363 to the print job receiving unit 323 of the printer 120. The printer information storing unit 361 may be on the cloud print managing server 170 side. Also, an area for the printer 120 (hereinafter called "cloud spooler") is set up in the print job storing unit 364 at the same time as the registration. The print job stored in the cloud spooler is transmitted to the printer 120 by the print job transmitting unit 363, and deleted from the cloud spooler after the printing is completed.
[0063] Also, a system manager in the company or the like performs a setting for managing print-related information for the registered printer. More specifically, a system manager in the company or the like accesses the cloud print server 160 or the cloud print managing server 170 by using the Web browser. The management screen generating unit 374 of the cloud print managing server 170 extracts the printer (group) registered by the manager from the printer information storing unit 361, generates a screen shown in FIG. 5 so as to display it on the Web browser. The manager inputs a check to a printer desired for managing the number of printed sheets. The management screen generating unit 374 stores a setting flag for managing the checked printer in the printer information storing unit 361. In this manner, an operation in the cloud print server 160 is changed. The details thereof will be described below. Although print-related information will be described below, the number of printed sheets is assumed to be the print-related information in this example. A system manager in the company or the like registers a cloud user ID of a general user with the cloud spooler of the cloud print server 160. In this manner, the general user can log into the print service server 160 with his cloud user ID, and populate the print job to the cloud spooler.
[0064] Also, a system manager in the company or the like registers the intranet print managing server 130 with the printer 120. In this manner, the printer 120 transmits print-related information from the job log transmitting unit 324 to the intranet print managing server 130. A system manager in the company or the like registers the printer 120 with the intranet print managing server 130. In this manner, information required for connecting to the printer 120 is stored in the printer information storing unit 335 of the intranet print managing server 130, and print-related information transmitted from the printer 120 is stored in the consolidated job log storing unit 331.
[0065] Also, a system manager in the company or the like performs a setting relating to cloud printing to the printer 120. More specifically, since a setting screen shown in FIG. 6 is displayed when the system manager accesses the intranet print managing server 130, the system manager inputs a check to "Permit cloud printing to printers under management", and selects "count the number of printed sheets for each user and add it to the number of printed sheets in intranet printing". Then, as shown in FIG. 7, a management for the number of printed sheets of an anonymous user and each intranet user ID is enabled when a manager counts the number of printed sheets. This may be set for an individual printer by designating each printer. Also, this may be set on the printer side by displaying the setting screen on the printer. This setting content is stored in the printer information storing unit 335. The printer information storing unit 335 may be provided with the printer 120.
[0095] Next, the cloud user ID is converted to the intranet user ID. In S606 in FIG. 9A, the cloud user ID "User-X" queries the intranet user managing server 140, and the cloud user ID "User-X" is converted to the intranet user ID "023456". Then, the intranet user ID "023456" is overwritten on the cloud user ID "User-X" column. The state after overwriting is the user ID 441 in FIG. 4D. Finally, the row 441 is consolidated with the job logs of other printers, and this becomes the row 422 in FIG. 4B. This is the explanation of the specific conversion example. In this example, a configuration is applied where the cloud print managing server is separated from the cloud print server, but the cloud print managing server may be included in one physical device or logical device. Also, in this example, in cloud printing, the job ID is employed as specific information for specifying the cloud user ID, but the specific information is not limited thereto. The cloud print managing server 170 may acquire arbitrary information from the cloud print server 160 or the Web application 350. A configuration may be applied where the cloud print managing server 170 manages the arbitrary information by associating it with the print job to thereby pass the cloud user ID to the intranet print managing server 130 based on the arbitrary information.
Re claim 6: Ohno discloses the method of claim 1, wherein said recording, the number of printed documents is further performed for each account of one or more accounts at first predetermined intervals of time by each client system of the plurality of client systems (e.g. the system records the number of printed documents according to a user account, which is considered as a software account. This is taught in ¶ [68]-[71] above.).
Re claim 7: Ohno discloses the method of claim 6, wherein the one or more accounts comprises at least one of a software account, a part account, a service account, or a vehicle account (e.g. the system records the number of printed documents according to a user account, which is considered as a software account. This is taught in ¶ [68]-[71] above.).
Re claim 8: Ohno discloses the method of claim 1, further comprising: printing each document of the documents provided by either a first system or a second system; and recording the number of printed documents for each system of the first system or the second system that provided the printed documents (e.g. several users associated with separate computers can submit jobs to one or more printers in the system. The print jobs associated with the intranet printing or cloud printing is stored within the servers. The different jobs from different users and stored within the system is illustrated in ¶ [95] above and seen in figure 4B.).
Re claim 9: Ohno discloses the method of claim 8, further comprising: receiving the recorded numbers of printed documents and the recorded numbers of print requests from the plurality of client systems by a computing device of the first system (e.g. if the print job is an intranet print request, computers or users on this system can send jobs to the printer. The job log associated with the printer can be sent to a server that stores the number of printed documents and jobs associated with a user or users, which is taught in ¶ [68]-[71] above.);
storing the recorded numbers of printed documents and the recorded numbers of print requests on a database in the computing device; and managing the database by the computing device (e.g. the server associated with intranet printing can store the recorded printed documents number and the number of print requests for a user. A system manager can manage this storage that contains a server operating the database, which is seen in figure 1 and discussed in ¶ [62]-[65] above.).
Re claim 10: Ohno discloses the method of claim 8, wherein the second system comprises the server that is a virtual server implemented on a cloud including a plurality of physical servers, the method further comprising: receiving the recorded numbers of printed documents and recorded numbers of print requests from the plurality of client systems by a database stored across one or more physical servers of the plurality of physical servers on the cloud; and managing the database on the cloud (e.g. the system contains cloud servers that implement the cloud system. The cloud server can receive number of documents printed by a user as well as the number of print jobs that have been submitted to the printer for a cloud printing job. This is taught in ¶ [93]-[95]. The cloud print server information is managed by a system manager, which is taught in ¶ [62]-[65] above.).
[0093] In the following, a description will be given of a specific conversion example principally with reference to FIG. 4. In the case of cloud printing, on the intranet side, the row 414 shown in FIG. 4A is recorded in the job log in the printer 120 in S511 to S512. At this time, the fixed string "CloudPrint" indicating cloud printing is recorded in the user ID column. Also, the prefix "ABC-" indicating cloud printing is added to the job ID "00A8D034" included in the cloud print job in the job ID column and recorded. On the other hand, on the cloud server side, the job information storing unit 371 of the cloud print managing server 170 records the row 1101 shown in FIG. 12 in S1402 to S1413. At this time, the cloud user ID "User-X" that has provided instructions for the printing is recorded in the cloud user ID column, and the job ID "00A8D034" is recorded in the job ID column.
[0094] Next, on the intranet side, the job log in the printer 120 is transmitted to the intranet print managing server 130. Then the job log is analyzed and converted for each row by the intranet print managing server 130. Since the user ID column is "CloudPrint", indicating cloud printing in the row 414 shown in FIG. 4A, the job ID "ABC-00A8D034" is extracted from the job ID column. Then, the prefix "ABC-00A8D034" is eliminated and "ABC-00A8D034" is changed to "00A8D034". The job ID "00A8D034" is transmitted to the cloud print managing server 170. In S1311 to 1314, the job ID having the eliminated prefix is converted to the cloud user ID "User-X". Then, the cloud user ID "User-X" is overwritten on the column "CloudPrint". The state after overwriting is the user ID 431 shown in FIG. 4C.
[0095] Next, the cloud user ID is converted to the intranet user ID. In S606 in FIG. 9A, the cloud user ID "User-X" queries the intranet user managing server 140, and the cloud user ID "User-X" is converted to the intranet user ID "023456". Then, the intranet user ID "023456" is overwritten on the cloud user ID "User-X" column. The state after overwriting is the user ID 441 in FIG. 4D. Finally, the row 441 is consolidated with the job logs of other printers, and this becomes the row 422 in FIG. 4B. This is the explanation of the specific conversion example. In this example, a configuration is applied where the cloud print managing server is separated from the cloud print server, but the cloud print managing server may be included in one physical device or logical device. Also, in this example, in cloud printing, the job ID is employed as specific information for specifying the cloud user ID, but the specific information is not limited thereto. The cloud print managing server 170 may acquire arbitrary information from the cloud print server 160 or the Web application 350. A configuration may be applied where the cloud print managing server 170 manages the arbitrary information by associating it with the print job to thereby pass the cloud user ID to the intranet print managing server 130 based on the arbitrary information.
Re claim 11: Ohno discloses a computer readable storage medium including instructions that, when executed by a server, cause the server to:
receive, at third predetermined intervals of time, a number of printed documents for each form type recorded by each client system of a plurality of client systems recorded at first predetermined intervals of time and a number of received print requests recorded by each client system of the plurality of client systems recorded at second predetermined intervals of time (e.g. a server can receive both the job IDs and documents printed from the printer or MFP. This occurs at a different time from the temporary storing of the job ID and the timing of recording the printed documents once printed. This is taught in [71]-[77] above. This can be a later time after the storage of the job ID temporarily and the storage of the number of printed sheets.),
each third predetermined interval of time is longer than any of each first predetermined interval of time and each second predetermined interval of time (e.g. the time of sending the job ID and printed documents is a time that can be later than after the receipt of the print job and after recording the printed documents. The time of when the information is sent to the servers is detailed in ¶ [71]-[77] above. This time frame can be at a later and longer time frame than the receipt of jobs and storage of related job ID and printed documents information.).
Re claim 14: Ohno discloses the computer-readable storage medium of claim 11, wherein the instructions further configure the server to consolidate the received recorded numbers of printed documents and recorded numbers of print requests from the plurality of client systems at fourth predetermined intervals of time, and wherein each fourth predetermined interval of time is equal to or longer than each third predetermined interval of time (e.g. the system manager can access the intranet print managing server associated with a printer to set a cloud print setting. The system manager can access this setting once a day or at a larger interval that is larger than the time when job logs are sent to the server in order to see all the printed documents. The system manager accessing the server is taught in ¶ [62]-[65] above. As seen in figure 4, the print requests of a user are consolidated into a single list for the user’s print requests, which is taught in ¶ [95] above.).
Re claim 15: Ohno discloses the computer-readable storage medium of claim 11, wherein the instructions further configure the server to record the number of printed documents for each account of one or more accounts (e.g. the system records the number of printed documents according to a user account, which is considered as a software account. This is taught in ¶ [68]-[71] above.).
Re claim 16: Ohno discloses the computer-readable storage medium of claim 15, wherein the one or more accounts comprises at least one of a software account, a part account, a service account, or a vehicle account (e.g. the system records the number of printed documents according to a user account, which is considered as a software account. This is taught in ¶ [68]-[71] above.).
Re claim 17: Ohno discloses the computer-readable storage medium of claim 11, wherein the instructions further configure the server to: print each document of the documents provided by either a first system or a second system; and record the number of printed documents for each system of the first system or the second system that provided the printed documents (e.g. several users associated with separate computers can submit jobs to one or more printers in the system. The print jobs associated with the intranet printing or cloud printing is stored within the servers. The different jobs from different users and stored within the system is illustrated in ¶ [95] above and seen in figure 4B.).
Re claim 18: Ohno discloses the computer-readable storage medium of claim 17, wherein the first system comprises a computing device comprising a database, and wherein the instructions further configure the server to: receive the numbers of printed documents and the numbers of print requests from the plurality of client systems recorded by the computing device (e.g. if the print job is an intranet print request, computers or users on this system can send jobs to the printer. The job log associated with the printer can be sent to a server that stores the number of printed documents and jobs associated with a user or users, which is taught in ¶ [68]-[71] above.);
store the recorded numbers of printed documents and the recorded numbers of print requests on the database; and manage the database by the computing device (e.g. the server associated with intranet printing can store the recorded printed documents number and the number of print requests for a user. A system manager can manage this storage that contains a server operating the database, which is seen in figure 1 and discussed in ¶ [62]-[65] above.).
Re claim 19: Ohno discloses the computer-readable storage medium of claim 17, wherein the second system comprises the server that is a virtual server implemented on a cloud including a plurality of physical servers, the instructions further configure the server to: receive the recorded numbers of printed documents and recorded numbers of print requests from the plurality of client systems by a database stored across one or more physical servers of the plurality of physical servers on the cloud; and manage the database on the cloud (e.g. the system contains cloud servers that implement the cloud system. The cloud server can receive number of documents printed by a user as well as the number of print jobs that have been submitted to the printer for a cloud printing job. This is taught in ¶ [93]-[95] above. The cloud print server information is managed by a system manager, which is taught in ¶ [62]-[65] above.).
Re claim 20: Ohno discloses a server comprising: one or more processors; a computer-readable storage medium including instructions that, when executed by the one or more processors, cause the server to: receive, at third predetermined intervals of time, a number of printed documents for each form type recorded by each client system of a plurality of client systems recorded at first predetermined intervals of time and a number of received print requests recorded by each client system of the plurality of client systems recorded at second predetermined intervals of time (e.g. a server can receive both the job IDs and documents printed from the printer or MFP. This occurs at a different time from the temporary storing of the job ID and the timing of recording the printed documents once printed. This is taught in [71]-[77] above. This can be a later time after the storage of the job ID temporarily and the storage of the number of printed sheets.),
each third predetermined interval of time is longer than any of each first predetermined interval of time and each second predetermined interval of time (e.g. the time of sending the job ID and printed documents is a time that can be later than after the receipt of the print job and after recording the printed documents. The time of when the information is sent to the servers is detailed in ¶ [71]-[77] above. This time frame can be at a later and longer time frame than the receipt of jobs and storage of related job ID and printed documents information.).
Re claim 23: Ohno discloses the server of claim 20, wherein the instructions further configure the server to consolidate the received recorded numbers of printed documents and recorded numbers of print requests from the plurality of client systems at fourth predetermined intervals of time, and wherein each fourth predetermined interval of time is equal to or longer than each third predetermined interval of time (e.g. the system manager can access the intranet print managing server associated with a printer to set a cloud print setting. The system manager can access this setting once a day or at a larger interval that is larger than the time when job logs are sent to the server in order to see all the printed documents. The system manager accessing the server is taught in ¶ [62]-[65] above. As seen in figure 4, the print requests of a user are consolidated into a single list for the user’s print requests, which is taught in ¶ [95] above.).
Re claim 24: Ohno discloses the server of claim 20, wherein the instructions further configure the server to record the number of printed documents for each account of one or more accounts (e.g. the system records the number of printed documents according to a user account, which is considered as a software account. This is taught in ¶ [68]-[71] above.).
Re claim 25: Ohno discloses the server of claim 24, wherein the one or more accounts comprises at least one of a software account, a part account, a service account, or a vehicle account (e.g. the system records the number of printed documents according to a user account, which is considered as a software account. This is taught in ¶ [68]-[71] above.).
Re claim 26: Ohno discloses the server of claim 20, wherein the instructions further configure the server to: print each document of the documents provided by either a first system or a second system; and record the number of printed documents for each system of the first system or the second system that provided the printed documents (e.g. several users associated with separate computers can submit jobs to one or more printers in the system. The print jobs associated with the intranet printing or cloud printing is stored within the servers. The different jobs from different users and stored within the system is illustrated in ¶ [95] above and seen in figure 4B.).
Re claim 27: Ohno discloses the server of claim 20, wherein the first system comprises a computing device comprising a database, and wherein the instructions further configure the server to: receive the numbers of printed documents and the numbers of print requests from the plurality of client systems recorded by the computing device (e.g. if the print job is an intranet print request, computers or users on this system can send jobs to the printer. The job log associated with the printer can be sent to a server that stores the number of printed documents and jobs associated with a user or users, which is taught in ¶ [68]-[71] above.);
store the recorded numbers of printed documents and the recorded numbers of print requests on the database; and manage the database by the computing device (e.g. the server associated with intranet printing can store the recorded printed documents number and the number of print requests for a user. A system manager can manage this storage that contains a server operating the database, which is seen in figure 1 and discussed in ¶ [62]-[65] above.).
Re claim 28: Ohno discloses the server of claim 20, wherein the second system comprises the server that is a virtual server implemented on a cloud including a plurality of physical servers, the instructions further configure the server to: receive the recorded numbers of printed documents and recorded numbers of print requests from the plurality of client systems by a database stored across one or more physical servers of the plurality of physical servers on the cloud; and manage the database on the cloud (e.g. the system contains cloud servers that implement the cloud system. The cloud server can receive number of documents printed by a user as well as the number of print jobs that have been submitted to the printer for a cloud printing job. This is taught in ¶ [93]-[95] above. The cloud print server information is managed by a system manager, which is taught in ¶ [62]-[65] above.).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 2, 12 and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over LI (US Pub 2022/0067044).
Re claim 2: Ohno discloses the method of claim 1, further comprising computing a number of print requests based on the recorded number of received print requests at the second predetermined intervals of time (e.g. the system manager can access the intranet print managing server associated with a printer to set a cloud print setting. The system manager can access this setting once a day or at a larger interval that is larger than the time when job logs are sent to the server in order to see all the printed documents. The system manager accessing the server is taught in ¶ [62]-[65]. As seen in figure 4, the number of print requests of a user are computed and consolidated into a single list for the user’s print requests, which is taught in ¶ [95].).
[0062] A system manager in the company or the like registers the printer 120 with the cloud print server 160. In this manner, information for connecting to the printer 120 is stored in the printer information storing unit 361 of the cloud print server 160, which enables transmission of the print job from the print job transmitting unit 363 to the print job receiving unit 323 of the printer 120. The printer information storing unit 361 may be on the cloud print managing server 170 side. Also, an area for the printer 120 (hereinafter called "cloud spooler") is set up in the print job storing unit 364 at the same time as the registration. The print job stored in the cloud spooler is transmitted to the printer 120 by the print job transmitting unit 363, and deleted from the cloud spooler after the printing is completed.
[0063] Also, a system manager in the company or the like performs a setting for managing print-related information for the registered printer. More specifically, a system manager in the company or the like accesses the cloud print server 160 or the cloud print managing server 170 by using the Web browser. The management screen generating unit 374 of the cloud print managing server 170 extracts the printer (group) registered by the manager from the printer information storing unit 361, generates a screen shown in FIG. 5 so as to display it on the Web browser. The manager inputs a check to a printer desired for managing the number of printed sheets. The management screen generating unit 374 stores a setting flag for managing the checked printer in the printer information storing unit 361. In this manner, an operation in the cloud print server 160 is changed. The details thereof will be described below. Although print-related information will be described below, the number of printed sheets is assumed to be the print-related information in this example. A system manager in the company or the like registers a cloud user ID of a general user with the cloud spooler of the cloud print server 160. In this manner, the general user can log into the print service server 160 with his cloud user ID, and populate the print job to the cloud spooler.
[0064] Also, a system manager in the company or the like registers the intranet print managing server 130 with the printer 120. In this manner, the printer 120 transmits print-related information from the job log transmitting unit 324 to the intranet print managing server 130. A system manager in the company or the like registers the printer 120 with the intranet print managing server 130. In this manner, information required for connecting to the printer 120 is stored in the printer information storing unit 335 of the intranet print managing server 130, and print-related information transmitted from the printer 120 is stored in the consolidated job log storing unit 331.
[0065] Also, a system manager in the company or the like performs a setting relating to cloud printing to the printer 120. More specifically, since a setting screen shown in FIG. 6 is displayed when the system manager accesses the intranet print managing server 130, the system manager inputs a check to "Permit cloud printing to printers under management", and selects "count the number of printed sheets for each user and add it to the number of printed sheets in intranet printing". Then, as shown in FIG. 7, a management for the number of printed sheets of an anonymous user and each intranet user ID is enabled when a manager counts the number of printed sheets. This may be set for an individual printer by designating each printer. Also, this may be set on the printer side by displaying the setting screen on the printer. This setting content is stored in the printer information storing unit 335. The printer information storing unit 335 may be provided with the printer 120.
[0095] Next, the cloud user ID is converted to the intranet user ID. In S606 in FIG. 9A, the cloud user ID "User-X" queries the intranet user managing server 140, and the cloud user ID "User-X" is converted to the intranet user ID "023456". Then, the intranet user ID "023456" is overwritten on the cloud user ID "User-X" column. The state after overwriting is the user ID 441 in FIG. 4D. Finally, the row 441 is consolidated with the job logs of other printers, and this becomes the row 422 in FIG. 4B. This is the explanation of the specific conversion example. In this example, a configuration is applied where the cloud print managing server is separated from the cloud print server, but the cloud print managing server may be included in one physical device or logical device. Also, in this example, in cloud printing, the job ID is employed as specific information for specifying the cloud user ID, but the specific information is not limited thereto. The cloud print managing server 170 may acquire arbitrary information from the cloud print server 160 or the Web application 350. A configuration may be applied where the cloud print managing server 170 manages the arbitrary information by associating it with the print job to thereby pass the cloud user ID to the intranet print managing server 130 based on the arbitrary information.
However, Ohno fails to specifically teach the features of comprising computing a peak time and a number of print requests at the peak time based on the recorded number of received print requests.
However, this is well known in the art as evidenced by Li. Similar to the primary reference, Li discloses calculating peak time when taking into account network resources (same field of endeavor or reasonably pertinent to the problem).
Li discloses comprising computing a peak time and a number of print requests at the peak time based on the recorded number of received print requests (e.g. a peak time is calculated based on the received query requests that are stored and evaluated in the system. The service peak is computed and determined based on the load created by the query requests received, which is taught in ¶ [110]. This function applied to the invention of Ohno performs the features of the claims.).
[0110] A service corresponds to different load sizes in different time periods, and there is a traffic peak and trough. Therefore, a microservice component needs to be automatically assembled and adjusted based on a service load status, to meet different service load requirements. FIG. 9 shows a process of automatically adjusting a microservice component based on service load. As shown in FIG. 10, in this embodiment, some service components are divided at a finer granularity. For example, the executor service 280 is divided into a row execution (row execution) service and a vector execution (vector execution) service. The storage engine service 282 is divided into a row storage engine, a columnar storage engine, and a memory engine at a finer granularity. Service components are deployed on a plurality of computing nodes in a distributed manner, for example, computing nodes 101 to 106 in FIG. 10. One or more service components are deployed on each computing node, and one component manager client 232 is deployed to manage the service component on the node. The job manager 220 receives a plurality of query requests, and invokes a corresponding service component on each computing node based on an execution path determined by a component manager server 231 and by using the component manager client 232, to perform service processing. When a service peak arrives, if the component manager server 231 determines, based on service monitoring information, that computing is a bottleneck in the current system, the component manager server 231 determines, based on a hardware configuration of an idle computing node 104 (it is assumed herein that an idle node includes a GPU), a microservice component that needs to be enabled on the idle node, including an SQL executor service 280 and a GPU acceleration service 298. The component manager server 231 requests a component manager client 232 on the idle node 104 to enable the SQL executor service and the GPU acceleration service. The idle node 104 enables the SQL executor service 280 and the GPU acceleration service 298, to deal with the service peak. The idle computing node 104 may be a node whose load is lower than a preset value, or may be a newly added node.
Therefore, in view of Li, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of comprising computing a peak time and a number of print requests at the peak time based on the recorded number of received print requests, incorporated in the device of Ohno, in order to compute a peak time and record system resources to determine a service peak with the load of requests arrives, which can aid in efficient resource utilization (as stated in Li ¶ [07]).
Re claim 12: Ohno discloses the computer-readable storage medium of claim 11, wherein the instructions further configure the server to compute a number of print requests at the peak time based on the recorded number of received print requests at the second predetermined intervals of time (e.g. the system manager can access the intranet print managing server associated with a printer to set a cloud print setting. The system manager can access this setting once a day or at a larger interval that is larger than the time when job logs are sent to the server in order to see all the printed documents. The system manager accessing the server is taught in ¶ [62]-[65] above. As seen in figure 4, the number of print requests of a user are computed and consolidated into a single list for the user’s print requests, which is taught in ¶ [95] above.).
However, Ohno fails to specifically teach the features of the server to compute a peak time and a number of print requests at the peak time based on the recorded number of received print requests.
However, this is well known in the art as evidenced by Li. Similar to the primary reference, Li discloses calculating peak time when taking into account network resources (same field of endeavor or reasonably pertinent to the problem).
Li discloses the server to compute a peak time and a number of print requests at the peak time based on the recorded number of received print requests (e.g. a peak time is calculated based on the received query requests that are stored and evaluated in the system. The service peak is computed and determined based on the load created by the query requests received, which is taught in ¶ [110]. This function applied to the invention of Ohno performs the features of the claims.).
Therefore, in view of Li, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of the server to compute a peak time and a number of print requests at the peak time based on the recorded number of received print requests, incorporated in the device of Ohno, in order to compute a peak time and record system resources to determine a service peak with the load of requests arrives, which can aid in efficient resource utilization (as stated in Li ¶ [07]).
Re claim 21: Ohno discloses the server of claim 20, wherein the instructions further configure the server to compute a number of print requests at the peak time based on the recorded number of received print requests at the second predetermined intervals of time (e.g. the system manager can access the intranet print managing server associated with a printer to set a cloud print setting. The system manager can access this setting once a day or at a larger interval that is larger than the time when job logs are sent to the server in order to see all the printed documents. The system manager accessing the server is taught in ¶ [62]-[65] above. As seen in figure 4, the number of print requests of a user are computed and consolidated into a single list for the user’s print requests, which is taught in ¶ [95] above.).
However, Ohno fails to specifically teach the features of the server to compute a peak time and a number of print requests at the peak time based on the recorded number of received print requests.
However, this is well known in the art as evidenced by Li. Similar to the primary reference, Li discloses calculating peak time when taking into account network resources (same field of endeavor or reasonably pertinent to the problem).
Li discloses the server to compute a peak time and a number of print requests at the peak time based on the recorded number of received print requests (e.g. a peak time is calculated based on the received query requests that are stored and evaluated in the system. The service peak is computed and determined based on the load created by the query requests received, which is taught in ¶ [110]. This function applied to the invention of Ohno performs the features of the claims.).
Therefore, in view of Li, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of the server to compute a peak time and a number of print requests at the peak time based on the recorded number of received print requests, incorporated in the device of Ohno, in order to compute a peak time and record system resources to determine a service peak with the load of requests arrives, which can aid in efficient resource utilization (as stated in Li ¶ [07]).
Claim(s) 4, 13 and 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kuroyanagi (USP 6597469).
Re claim 4: Ohno discloses the method of claim 3, wherein said receiving comprises: to provide the recorded numbers of printed documents and the recorded numbers of print requests at the third predetermined intervals of time (e.g. a server can receive both the job IDs and documents printed from the printer or MFP. This occurs at a different time from the temporary storing of the job ID and the printed documents once printed. This is taught in [71] above and [72]-[77].); and
receiving the recorded numbers of printed documents and the recorded numbers of print requests by the server at the third predetermined intervals of time (e.g. the time of sending the job ID and printed documents is a time that can be longer than after the receipt of the print job and after recording the printed documents. The time of when the information is sent to the servers is detailed in ¶ [71]-[77] above and can be considered as a third time interval.).
However, Ohno fails to specifically teach the features of sending a request from a server to each client system of the plurality of client systems.
However, this is well known in the art as evidenced by Kuroyanagi. Similar to the primary reference, Kuroyanagi discloses a server sending a request to a printer (same field of endeavor or reasonably pertinent to the problem).
Kuroyanagi discloses sending a request from a server to each client system of the plurality of client systems (e.g. a server sends an inquiry to the printer for the total number of printed documents per ID. The printer sends this information to the server, which is taught in col. 9, ll. 26-39 and col. 9, ll. 63-col. 10, ll. 55.).
(9) As shown in FIGS. 2A to 2C, the image input/output device 200 has an input/output interface 210 connected to the network 10 for data transfer to and from each terminal connected to the network 10. For example, in the data transfer to and from the print server 100, the image input/output device 200 receives data of a print job requested by the print server 100 and an inquiry command for an output state of the print job, and transmits a response to the output state inquiry command. For example, in the data transfer to and from the department manage server 300, the image input/output device 200 receives an inquiry command from the department manage server 300 and transmits a response to the inquiry command.
(12) When printable image data is supplied from the print data analysis unit 220, the image control unit 230 transfers this image data to the printer control unit 250 and controls the print control unit 250 to print output the image data. When image data is supplied from the image scanning unit 240, the image control unit 230 transfers the image data to the print control unit 250 and controls the print control unit 250 to print out the image data. A series of operations from reading an image of an original at the image scanning unit 240 to printing out the image data at the printer control, is a copy operation. This copy operation can be executed independently from the network 10. An execution instruction of the copy operation is performed by an input operation entered from an operation unit 260. The operation unit 260 has various setting keys such as a copy key for entering an execution instruction of the copy operation and a key for entering the copy ID. In response to each of the various setting keys, a key signal is output to the image control unit 230. The operation unit 260 also has a liquid crystal panel (not shown) for displaying the contents set by setting keys, the operation state notified from the image control unit 230, and the like.
(13) For the copy job output number management function of the image control unit 230, a departmental copy counter table 270 is used which manages the output number of a copy job in correspondence with each copy ID. In the departmental copy counter table 270, each copy ID is registered in a copy ID field. Fields for registering a color output number and a monochrome output number are provided for each copy ID. With the copy job output number management function, when a copy ID of a user requesting a copy job is entered from the operation unit 260, it is checked whether or not the entered copy ID is already registered in the departmental copy counter table 270. If already registered, the output number counted for this copy job is added to the output number registered in the departmental copy counter table 270 corresponding to the entered copy ID to update the contents of the departmental copy counter table 270 so as to have the addition result. Namely, if the entered copy ID is already registered in the departmental copy counter table 270, the output number of the present copy job is cumulatively written in the field corresponding to the copy ID. If the print output is a color output, the output number is cumulatively written in the color output field, whereas if the print output is a monochrome output, the output number is cumulatively written in the monochrome output field. In the example shown in FIGS. 2A to 2C, for the copy ID "a" of the departmental copy counter table 270, "3123" is written in the monochrome output number field and "89" is written in the color output number field. If the entered ID is not already registered in the departmental copy counter table 270, the copy job is inhibited.
(14) In response to a request instruction issued from the department manage server 300, the output numbers and corresponding copy ID's written in the departmental copy counter table 270 are transferred via the network 10 to the department manage server 300 which calculates a total sum of the output numbers of each print job and corresponding copy job. The output numbers written in the departmental copy counter table 270 are periodically reset.
Therefore, in view of Kuroyanagi, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of sending a request from a server to each client system of the plurality of client systems, incorporated in the device of Ohno, in order to send print stats to a server based on request, which can improve the function of limiting outputs on the system (as stated in Kuroyanagi col. 31, ll. 55-64).
Re claim 13: Ohno discloses the computer-readable storage medium of claim 11, wherein the instructions further configure to provide the recorded numbers of printed documents and the recorded numbers of print requests at the third predetermined intervals of time (e.g. a server can receive both the job IDs and documents printed from the printer or MFP. This occurs at a different time from the temporary storing of the job ID and the recording of a number of printed documents once printed. This is taught in [71]-[77] above.).
However, Ohno fails to specifically teach the features of the server to send a request from a server to each client system of the plurality of client systems.
However, Ohno fails to specifically teach the features of sending a request from a server to each client system of the plurality of client systems.
However, this is well known in the art as evidenced by Kuroyanagi. Similar to the primary reference, Kuroyanagi discloses a server sending a request to a printer (same field of endeavor or reasonably pertinent to the problem).
Kuroyanagi discloses sending a request from a server to each client system of the plurality of client systems (e.g. a server sends an inquiry to the printer for the total number of printed documents per ID. The printer sends this information to the server, which is taught in col. 9, ll. 26-39 and col. 9, ll. 63-col. 10, ll. 55 above.).
Therefore, in view of Kuroyanagi, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of sending a request from a server to each client system of the plurality of client systems, incorporated in the device of Ohno, in order to send print stats to a server based on request, which can improve the function of limiting outputs on the system (as stated in Kuroyanagi col. 31, ll. 55-64).
Re claim 22: Ohno discloses the server of claim 20, wherein the instructions further configure to provide the recorded numbers of printed documents and the recorded numbers of print requests at the third predetermined intervals of time (e.g. a server can receive both the job IDs and documents printed from the printer or MFP. This occurs at a different time from the temporary storing of the job ID and the recording of a number of printed documents once printed. This is taught in [71]-[77] above.).
However, Ohno fails to specifically teach the features of the server to send a request from a server to each client system of the plurality of client systems.
However, Ohno fails to specifically teach the features of sending a request from a server to each client system of the plurality of client systems.
However, this is well known in the art as evidenced by Kuroyanagi. Similar to the primary reference, Kuroyanagi discloses a server sending a request to a printer (same field of endeavor or reasonably pertinent to the problem).
Kuroyanagi discloses the server to send a request from a server to each client system of the plurality of client systems (e.g. a server sends an inquiry to the printer for the total number of printed documents per ID. The printer sends this information to the server, which is taught in col. 9, ll. 26-39 and col. 9, ll. 63-col. 10, ll. 55 above.).
Therefore, in view of Kuroyanagi, it would have been obvious to one of ordinary skill before the effective filing date of the claimed invention was made to have the feature of the server to send a request from a server to each client system of the plurality of client systems, incorporated in the device of Ohno, in order to send print stats to a server based on request, which can improve the function of limiting outputs on the system (as stated in Kuroyanagi col. 31, ll. 55-64).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Tsutsumi discloses gathering print statistics on a user.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHAD S DICKERSON whose telephone number is (571)270-1351. The examiner can normally be reached Monday-Friday 10AM-6PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Abderrahim Merouan can be reached at 571-270-5254. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHAD DICKERSON/Primary Examiner, Art Unit 2683
Prosecution Insights