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 .
Response to Arguments
Applicant’s arguments, see page 11, filed 7/8/2026, with respect to specification objection have been fully considered and are persuasive. The objection of the specification has been withdrawn.
Applicant's arguments filed 7/8/2026 have been fully considered but they are not persuasive. The 101 rejection of the claims is maintained. The addition of the claim limitation to the independent claims does not show how the collection of the printing usage statistics is used to reduce or eliminate time and communication bandwidth of communications with external analytic platforms.
Applicant’s arguments with respect to claim(s) 1-31 have been considered but are moot because the new ground of rejection does not rely on all references applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. The arguments state that the previously applied reference does not perform the features of ”recording, by each client system of a plurality of client systems, an aggregated count of printed documents for each form type during a first predetermined interval of time; recording, by each client system of the plurality of client systems, an aggregated count of received print requests during a second predetermined interval of time.” This deficiency is cured by the combination of Harada and Zhang, which will be explained below.
Regarding the new amended claims, the limitation of “during a first predetermined interval” or “during a second predetermined interval” of time, the Examiner considers this as during an hour or during a span of seconds. This can occur within the primary reference of recording information since the overall system operates to record information during an hour or seconds. The only deficiency not captured is the aggregated count of printed documents and print requests during these spans of time. The reference of Harada cures this specific deficiency.
Regarding the reference of Harada, it discloses calculating the total of printed pages per MFP at the MFP and the total copy or print requests that occur on the MFP. The system can calculate this total on a daily or monthly basis, which is taught in ¶ [29], [32], [42]-[44] and [54]. Since this occurs per MFP and these calculations can occur during a span of a few seconds, an hour or daily, these are all considered as different intervals of time that these totals can be calculated. This performs the features of the above contended features. The Zhang reference is further applied to not only show a similar calculation within hour intervals, but this last reference shows the acquiring of the aggregated amounts performed at a time interval longer than the calculation of the initial calculation of the aggregated amounts at the first and second predetermined intervals. This is taught in Zhang ¶ [21]. Therefore, the combination of these references with the previously applied references discloses the features of the amended claims.
Thus, based on the above, the features of the amended claims are disclosed below.
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 an aggregated count of printed documents for each form and an aggregated count 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. In addition, the transmission of the collected data at a server requesting the information for collection at a longer predetermined period of time is considered as a well-known routine and conventional limitation that does not add significantly more than the judicial exception nor integrate the abstract idea into a practical application. 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 also 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. In addition, the transmission of the collected data at a server requesting information for collection at a longer predetermined period of time is considered as a well-known routine and conventional limitation that does not add significantly more than the judicial exception nor integrate the abstract idea 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. In addition, the transmission of the collected data at a server requesting the information for collection at a longer predetermined period of time is considered as a well-known routine and conventional limitation that does not add significantly more than the judicial exception nor integrate the abstract idea into a practical application. This applies to claims 13 and 22.
Claim 5 contains the step of consolidating aggregated information associated with printed documents and print requests 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 aggregated count 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 an aggregated count 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 aggregated count of printed documents and aggregated count 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.
Claims 29-30 are considered as insignificant solution activity since these limitations are further defining the data to be gathered or manipulated. These limitations do not add significantly more to the judicial exception nor considered to integrate the abstract idea into a practical application.
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) 1, 3-11, 13-20 and 22-31 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ohno (US Pub 2014/0240748) in view of Harada (JP Pub 2003-092654 (pub date: 3/28/2003)) and Zhang (US Pub 2017/0308151).
Re claim 1: Ohno discloses a method of collecting printing statistics comprising:
recording, by each client system of a plurality of client systems, a count of printed documents for each form type during a first predetermined interval of time (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, by each client system of a plurality of client systems, a count of received print requests during a second predetermined interval of time (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.).
However, Ohno fails to specifically teach the features of recording an aggregated count of printed documents for each form type; recording an aggregated count of received print requests; and transmitting, from each client system and based on receipt from a server, the aggregated count of printed documents and the aggregated count of print requests at a third predetermined interval of time, wherein the third predetermined interval of time is longer than the first predetermined interval of time and the second predetermined interval of time.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses recording an aggregated count of printed documents for each form type; recording an aggregated count of received print requests (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests. This is taught in ¶ [29], [32], [42]-[44] and [54].); and
[0029] When the network communication unit 47 receives the number of copies or prints from the multifunction peripheral 2 in step ST23, the number of copies or prints is added to the total number of copies and prints stored in the area of the corresponding multifunction peripheral number of the storage unit 441 in HDD44 in step ST24. At this time, the number of sheets is added to the total number of sheets for each of the grand total, the monthly basis, and the daily basis. Further, the total number of times of copying and printing is incremented by one. At this time, the total number of times of each of the grand total, the monthly unit, and the daily unit is incremented by 1. Here, the total number of times of copying and printing is the number of times of starting copying and printing.
[0032]Subsequently, in step ST27, various history information recorded in the region of the multifunction peripheral number corresponding to the multifunction peripheral that has notified of the paper jam or the multifunction peripheral that has notified of the number of copies or prints, that is, the total number of copies and prints, the monthly total number of copies, the daily total number of copies, the total number of times copying and printing are started, the monthly total number of times, the daily total number of times, the total number of times of continuous copying and printing of 10 or more sheets, the monthly total number of times, the daily total number of times, the total number of times of occurrence of paper jams, the monthly total number of times, the daily total number of times, the total number of times for each location of occurrence of paper jams, the occurrence frequency, and the contamination information due to toner scatter are read, and the necessity of maintenance of the corresponding multifunction peripheral and the contents of maintenance are analyzed by the analysis unit.
[0042](Second Embodiment)In this embodiment, in the system shown in FIG. 1, the server 4 is not provided with a storage unit for storing the total number of copies and prints, the total number of copies and prints per month, the total number of copies and prints per day, the total number of copies and prints started, the total number of copies and prints per month, the total number of copies and prints per day, the total number of continuous copies and prints of 10 or more sheets, the total number of paper jams, the total number of paper jams per month, the total number of paper jams per day, the total number of paper jams per location, the occurrence frequency, and the contamination information due to scattered toner, based on the number of copies and prints, the number of starts, the occurrence of paper jams, and the detection information of the degree of contamination of the white seal by the contamination sensor 32, which occur in each multifunction peripheral 2, but the storage unit is provided in the HDD24 of the multifunction peripheral 2.[0043]That is, as illustrated in FIG. 8, a storage unit 241 that registers, as history information, the total number of printed or copied sheets, the total number of times of printing or copying, the total number of times of occurrence of paper jams, the locations of occurrence of paper jams, the frequency of occurrence of each location of occurrence of paper jams, information on contamination due to toner scattering, and the like on the basis of information on the number of printed or copied sheets, the occurrence of jams, and the locations of occurrence of jams is provided on the HDD24 of the multifunction peripheral 2.[0044]When copying or printing is started, the MFP 2 performs a process based on the flowchart shown in FIG. 9. That is, when copying or printing is started, copying or printing is executed at step ST31. Then, the completion is checked, and if it is not completed, the execution of the copy or print of the step ST31 is repeated. When the end is determined, the content of the storage unit 241 of the ST32 is rewritten in step HDD24.
[0054] On the other hand, the server 4 requests the history information to each of the multifunction peripherals 2 periodically and sequentially, for example, every three hours from 7 a.m. to 8 p.m. The multifunction peripheral 2 that has received the history information reads, from the storage unit 241, various kinds of history information such as the total number of copied and printed sheets, the total number of sheets on a monthly basis, the total number of sheets on a daily basis, the total number of times copying and printing have been started, the total number of times on a monthly basis, the total number of times on a daily basis, the total number of times 10 or more sheets have been continuously copied or printed, the total number of times of paper jam occurrence, the total number of times on a monthly basis, the total number of times on a daily basis, the total number of times for each paper jam occurrence location, the occurrence frequency, and the contamination information due to toner scattering, and transmits the history information to the server 4.
transmitting, from each client system and based on receipt from a server, the aggregated count of printed documents and the aggregated count of print requests at a third predetermined interval of time (e.g. the system discloses sending the total of copied and printed sheets along with the number of copy and print requests in the history information at a predetermined time that can be daily or within every few hours between a certain period of time, which is seen in ¶ [54] above.).
Therefore, in view of Harada, 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 recording an aggregated count of printed documents for each form type; recording an aggregated count of received print requests; and transmitting, from each client system and based on receipt from a server, the aggregated count of printed documents and the aggregated count of print requests at a third predetermined interval of time, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
However, the combination above fails to specifically teach the features of wherein the third predetermined interval of time is longer than the first predetermined interval of time and the second predetermined interval of time.
However, this is well known in the art as evidenced by Zhang. Similar to the primary reference, Zhang discloses a server polling a printer for usage logs (same field of endeavor or reasonably pertinent to the problem).
Zhang discloses wherein the third predetermined interval of time is longer than the first predetermined interval of time and the second predetermined interval of time (e.g. the Harada reference discloses storing usage data at an hourly rate within 24 hour slots. These time slots can applied to store certain types of data in Harada associated with the printed sheets and the number of print or copy requests. This can track if these requests occur at any interval within the 24 slots. Next, the poll can occur at a once a day rate, which would be greater than the smaller interval slots, which is taught in ¶ [21].).
[0021] In the example embodiment of FIG. 1, MFPs 104 are coupled for data communication 106A, 106B, 108A, 108B using network 102. Data communications 106A, 106B include the transmission of usage logs from the MFPs 104 to a power scheduling server 116. Data communications 108A, 108B include the transmission of power saving packages from the power scheduling server 116 to MFPs 104. The MFPs 104 are also coupled for data communication using network 102 for the transmission of print jobs and other status messaging (not shown.) Network 102 suitably comprises a local area network (LAN), a remote local area network (RLAN), a wide area network (WAN) which may comprise the Internet, or any combination thereof. In an embodiment, the usage data can be time-based usage data. The usage data can indicate whether the MFP 104 has been used in a particular time slot. For example, usage data can be based on 24 hour time slots where the usage data indicates whether or not the MFP 104 was used in each hourly time slot. In an embodiment, the usage data can include time stamps that indicate the time the MFP 104 was used. In an embodiment, the usage data can include additional information, for example what service of the MFP was used, for example printing, faxing, scanning, email, and so forth. In an embodiment, the usage date can identify the user of the MFP. In an embodiment, the usage logs can be transmitted periodically, for example once an hour, or once a day. In an embodiment, the power scheduling server 116 polls the MFPs 104 for usage data.
Therefore, in view of Zhang, 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 wherein the third predetermined interval of time is longer than the first predetermined interval of time and the second predetermined interval of time, incorporated in the device of Ohno, as modified by Harada, in order to acquire usage data from a MFP at particular times after storage, which can aid in tailoring statistical data from the usage logs and produce further policies that improve use of the MFP (as stated in Zhang ¶ [17] and [18]).
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 interval 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 the third predetermined interval of time is longer than the first predetermined interval of time and the 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 4: Ohno discloses the method of claim 3, wherein said receiving comprises: to provide the recorded count of printed documents and the recorded count of print requests at the third predetermined interval 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
transmitting the recorded count of printed documents and the recorded count of print requests to the server at the third predetermined interval 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 receiving the request from the server to each client system of the plurality of client systems to provide the recorded aggregated count of printed documents and the recorded aggregated count of print requests at the third predetermined interval of time; and transmitting, from each client system from the plurality of client systems, the recorded aggregated count of printed documents and the recorded aggregated count of print requests to the server at the third predetermined interval of time.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses receiving the request from the server to each client system of the plurality of client systems to provide the recorded aggregated count of printed documents and the recorded aggregated count of print requests at the third predetermined interval of time; and transmitting, from each client system from the plurality of client systems, the recorded aggregated count of printed documents and the recorded aggregated count of print requests to the server at the third predetermined interval of time (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests. This is taught in ¶ [29], [32], [42]-[44] and [54] above. The system discloses sending the total of copied and printed sheets along with the number of copy and print requests in the history information at a predetermined time that can be daily or within every few hours between a certain period of time, which is seen in ¶ [54] above.); and
Therefore, in view of Harada, 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 receiving the request from the server to each client system of the plurality of client systems to provide the recorded aggregated count of printed documents and the recorded aggregated count of print requests at the third predetermined interval of time; and transmitting, from each client system from the plurality of client systems, the recorded aggregated count of printed documents and the recorded aggregated count of print requests to the server at the third predetermined interval of time, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
Re claim 5: Ohno discloses the method of claim 3, further comprising consolidating the received recorded count of printed documents and the received recorded count of print requests from the plurality of client systems at a fourth predetermined intervals of time, wherein the fourth predetermined interval of time is equal to or longer than the 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.
However, Ohno fails to specifically teach the features of further comprising consolidating the received recorded aggregated count of printed documents and the received recorded aggregated count of print requests.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses further comprising consolidating the received recorded aggregated count of printed documents and the received recorded aggregated count of print requests (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 further comprising consolidating the received recorded aggregated count of printed documents and the received recorded aggregated count of print requests, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
Re claim 6: Ohno discloses the method of claim 1, wherein said recording, the count 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.).
However, Ohno fails to specifically teach the features of the aggregated count number of printed documents.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses the aggregated count number of printed documents (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 aggregated count number of printed documents, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
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.).
However, Ohno fails to specifically teach the features of the aggregated count of printed documents.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses the aggregated count of printed documents (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 aggregated count of printed documents, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
Re claim 9: Ohno discloses the method of claim 8, further comprising: receiving the recorded count of printed documents and the recorded count 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 count of printed documents and the recorded count 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.).
However, Ohno fails to specifically teach the features of receiving the recorded aggregated count of printed documents and the recorded aggregated count of print requests from the plurality of client systems, storing the recorded aggregated count of printed documents and the recorded aggregated count of print requests on a database.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses receiving the recorded aggregated count of printed documents and the recorded aggregated count of print requests from the plurality of client systems, storing the recorded aggregated count of printed documents and the recorded aggregated count of print requests on a database (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server for storage. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 receiving the recorded aggregated count of printed documents and the recorded aggregated count of print requests from the plurality of client systems, storing the recorded aggregated count of printed documents and the recorded aggregated count of print requests on a database, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
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.
However, Ohno fails to specifically teach the features of receiving the recorded aggregated count of printed documents and recorded aggregated count of print requests from the plurality of client systems.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses receiving the recorded aggregated count of printed documents and recorded aggregated count of print requests from the plurality of client systems (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server for storage. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 receiving the recorded aggregated count of printed documents and recorded aggregated count of print requests from the plurality of client systems, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
Re claim 11: Ohno discloses a computer readable storage medium including instructions that, when executed by a server, cause the server to:
receive, at a third predetermined interval of time, a count of printed documents for each form type recorded by each client system of a plurality of client systems recorded at a first predetermined interval of time; and receive an count of received print requests recorded by each client system of the plurality of client systems recorded at a second predetermined interval 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.),
wherein the third predetermined interval of time is longer than the first predetermined interval of time and the 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.).
However, Ohno fails to specifically teach the features of receive, based on a request from the server and at a third predetermined interval of time, an aggregated count of printed documents for each form type recorded by each client system of a plurality of client systems recorded at a first predetermined interval of time; and
receive, based on the request from the server and at the third predetermined interval of time, an aggregated count of received print requests recorded by each client system of the plurality of client systems recorded at a second predetermined interval of time.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses receive, based on a request from the server and at a third predetermined interval of time, an aggregated count of printed documents for each form type recorded by each client system of a plurality of client systems recorded at a first predetermined interval of time; and receive, based on the request from the server and at the third predetermined interval of time, an aggregated count of received print requests recorded by each client system of the plurality of client systems recorded at a second predetermined interval of time (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests. This is taught in ¶ [29], [32], [42]-[44] and [54] above. The system discloses sending the total of copied and printed sheets along with the number of copy and print requests in the history information at a predetermined time that can be daily or within every few hours between a certain period of time, which is seen in ¶ [54] above).
Therefore, in view of Harada, 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 receive, based on a request from the server and at a third predetermined interval of time, an aggregated count of printed documents for each form type recorded by each client system of a plurality of client systems recorded at a first predetermined interval of time; and receive, based on the request from the server and at the third predetermined interval of time, an aggregated count of received print requests recorded by each client system of the plurality of client systems recorded at a second predetermined interval of time, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
However, the combination above fails to specifically teach the features of wherein the third predetermined interval of time is longer than the first predetermined interval of time and the second predetermined interval of time.
However, this is well known in the art as evidenced by Zhang. Similar to the primary reference, Zhang discloses a server polling a printer for usage logs (same field of endeavor or reasonably pertinent to the problem).
Zhang discloses wherein the third predetermined interval of time is longer than the first predetermined interval of time and the second predetermined interval of time (e.g. the Harada reference discloses storing usage data at an hourly rate within 24 hour slots. These time slots can applied to store certain types of data in Harada associated with the printed sheets and the number of print or copy requests. This can track if these requests occur at any interval within the 24 slots. Next, the poll can occur at a once a day rate, which would be greater than the smaller interval slots, which is taught in ¶ [21] above.).
Therefore, in view of Zhang, 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 wherein the third predetermined interval of time is longer than the first predetermined interval of time and the second predetermined interval of time, incorporated in the device of Ohno, as modified by Harada, in order to acquire usage data from a MFP at particular times after storage, which can aid in tailoring statistical data from the usage logs and produce further policies that improve use of the MFP (as stated in Zhang ¶ [17] and [18]).
Re claim 13: Ohno discloses the computer-readable storage medium of claim 11, wherein the instructions further configure to provide the recorded count of printed documents and the recorded count of print requests at the third predetermined interval 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 wherein the instructions further configure the server to send the request from the server to each client system of the plurality of client systems to provide the recorded aggregated count of printed documents and the recorded aggregated count of print requests at the third predetermined interval of time.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses wherein the instructions further configure the server to send the request from the server to each client system of the plurality of client systems to provide the recorded aggregated count of printed documents and the recorded aggregated count of print requests at the third predetermined interval of time (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests. This is taught in ¶ [29], [32], [42]-[44] and [54] above. The system discloses sending the total of copied and printed sheets along with the number of copy and print requests in the history information at a predetermined time that can be daily or within every few hours between a certain period of time, which is seen in ¶ [54] above.); and
Therefore, in view of Harada, 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 wherein the instructions further configure the server to send the request from the server to each client system of the plurality of client systems to provide the recorded aggregated count of printed documents and the recorded aggregated count of print requests at the third predetermined interval of time, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
Re claim 14: Ohno discloses the non-transitory computer-readable storage medium of claim 11, wherein the instructions further configure the server to consolidate the received recorded count of printed documents and recorded count of print requests from the plurality of client systems at fourth predetermined interval of time, and wherein the fourth predetermined interval of time is equal to or longer than the 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.).
However, Ohno fails to specifically teach the features of the received recorded aggregated count of printed documents and recorded aggregated count of print requests from the plurality of client systems.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses the received recorded aggregated count of printed documents and recorded aggregated count of print requests from the plurality of client systems (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 received recorded aggregated count of printed documents and recorded aggregated count of print requests from the plurality of client systems, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
Re claim 15: Ohno discloses the non-transitory computer-readable storage medium of claim 11, wherein the instructions further configure the server to record the count 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.).
However, Ohno fails to specifically teach the features of the aggregated count of printed documents.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses the aggregated count of printed documents (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 aggregated count of printed documents, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
Re claim 16: Ohno discloses the non-transitory 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 non-transitory 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.).
However, Ohno fails to specifically teach the features of the aggregated count of printed documents.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses the aggregated count of printed documents (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 aggregated count of printed documents, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
Re claim 18: Ohno discloses the non-transitory 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 count of printed documents and the count 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 count of printed documents and the recorded count 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.).
However, Ohno fails to specifically teach the features of receive the aggregated count of printed documents and the aggregated count of print requests from the plurality of client systems, store the recorded aggregated count of printed documents and the recorded aggregated count of print requests on the database.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses receive the aggregated count of printed documents and the aggregated count of print requests from the plurality of client systems, store the recorded aggregated count of printed documents and the recorded aggregated count of print requests on the database (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server for storage. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 receive the aggregated count of printed documents and the aggregated count of print requests from the plurality of client systems, store the recorded aggregated count of printed documents and the recorded aggregated count of print requests on the database, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
Re claim 19: Ohno discloses the non-transitory 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 count of printed documents and recorded count 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.).
However, Ohno fails to specifically teach the features of receive the recorded aggregated count of printed documents and recorded aggregated count of print requests from the plurality of client systems.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses receive the recorded aggregated count of printed documents and recorded aggregated count of print requests from the plurality of client systems (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server for storage. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 receive the recorded aggregated count of printed documents and recorded aggregated count of print requests from the plurality of client systems, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
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 a third predetermined interval of time, a count of printed documents for each form type recorded by each client system of a plurality of client systems recorded at first predetermined interval of time; and a count of received print requests recorded by each client system of the plurality of client systems recorded at a second predetermined interval 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.),
wherein the third predetermined interval of time is longer than the first predetermined interval of time and the 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.).
However, Ohno fails to specifically teach the features of receive, based on a request from the server and at a third predetermined interval of time, an aggregated count of printed documents for each form type recorded by each client system of a plurality of client systems recorded at a first predetermined interval of time; and
receive, based on the request from the server and at the third predetermined interval of time, an aggregated count of received print requests recorded by each client system of the plurality of client systems recorded at a second predetermined interval of time.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses receive, based on a request from the server and at a third predetermined interval of time, an aggregated count of printed documents for each form type recorded by each client system of a plurality of client systems recorded at a first predetermined interval of time; and receive, based on the request from the server and at the third predetermined interval of time, an aggregated count of received print requests recorded by each client system of the plurality of client systems recorded at a second predetermined interval of time (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests. This is taught in ¶ [29], [32], [42]-[44] and [54] above. The system discloses sending the total of copied and printed sheets along with the number of copy and print requests in the history information at a predetermined time that can be daily or within every few hours between a certain period of time, which is seen in ¶ [54] above).
Therefore, in view of Harada, 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 receive, based on a request from the server and at a third predetermined interval of time, an aggregated count of printed documents for each form type recorded by each client system of a plurality of client systems recorded at a first predetermined interval of time; and receive, based on the request from the server and at the third predetermined interval of time, an aggregated count of received print requests recorded by each client system of the plurality of client systems recorded at a second predetermined interval of time, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
However, the combination above fails to specifically teach the features of wherein the third predetermined interval of time is longer than the first predetermined interval of time and the second predetermined interval of time.
However, this is well known in the art as evidenced by Zhang. Similar to the primary reference, Zhang discloses a server polling a printer for usage logs (same field of endeavor or reasonably pertinent to the problem).
Zhang discloses wherein the third predetermined interval of time is longer than the first predetermined interval of time and the second predetermined interval of time (e.g. the Harada reference discloses storing usage data at an hourly rate within 24 hour slots. These time slots can applied to store certain types of data in Harada associated with the printed sheets and the number of print or copy requests. This can track if these requests occur at any interval within the 24 slots. Next, the poll can occur at a once a day rate, which would be greater than the smaller interval slots, which is taught in ¶ [21] above.).
Therefore, in view of Zhang, 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 wherein the third predetermined interval of time is longer than the first predetermined interval of time and the second predetermined interval of time, incorporated in the device of Ohno, as modified by Harada, in order to acquire usage data from a MFP at particular times after storage, which can aid in tailoring statistical data from the usage logs and produce further policies that improve use of the MFP (as stated in Zhang ¶ [17] and [18]).
Re claim 22: Ohno discloses the server of claim 20, wherein the instructions further configure to provide the recorded count of printed documents and the recorded count of print requests at the third predetermined interval 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 wherein the instructions further configure the server to send the request from the server to each client system of the plurality of client systems to provide the recorded aggregated count of printed documents and the recorded aggregated count of print requests at the third predetermined interval of time.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses wherein the instructions further configure the server to send the request from the server to each client system of the plurality of client systems to provide the recorded aggregated count of printed documents and the recorded aggregated count of print requests at the third predetermined interval of time (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests. This is taught in ¶ [29], [32], [42]-[44] and [54] above. The system discloses sending the total of copied and printed sheets along with the number of copy and print requests in the history information at a predetermined time that can be daily or within every few hours between a certain period of time, which is seen in ¶ [54] above.); and
Therefore, in view of Harada, 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 wherein the instructions further configure the server to send the request from the server to each client system of the plurality of client systems to provide the recorded aggregated count of printed documents and the recorded aggregated count of print requests at the third predetermined interval of time, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
Re claim 23: Ohno discloses the server of claim 20, wherein the instructions further configure the server to consolidate the received recorded count of printed documents and recorded count of print requests from the plurality of client systems at a fourth predetermined intervals of time, and wherein the fourth predetermined interval of time is equal to or longer than the 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.).
However, Ohno fails to specifically teach the features of the received recorded aggregated count of printed documents and recorded aggregated count of print requests from the plurality of client systems.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses the received recorded aggregated count of printed documents and recorded aggregated count of print requests from the plurality of client systems (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 received recorded aggregated count of printed documents and recorded aggregated count of print requests from the plurality of client systems, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
Re claim 24: Ohno discloses the server of claim 20, wherein the instructions further configure the server to record the count 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.).
However, Ohno fails to specifically teach the features of the aggregated count of printed documents.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses the aggregated count of printed documents (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 aggregated count of printed documents, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
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 count 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.).
However, Ohno fails to specifically teach the features of the aggregated count of printed documents.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses the aggregated count of printed documents (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 aggregated count of printed documents, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
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 count of printed documents and the count 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 count of printed documents and the recorded count 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.).
However, Ohno fails to specifically teach the features of receive the aggregated count of printed documents and the aggregated count of print requests from the plurality of client systems, store the recorded aggregated count of printed documents and the recorded aggregated count of print requests on the database.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses receive the aggregated count of printed documents and the aggregated count of print requests from the plurality of client systems, store the recorded aggregated count of printed documents and the recorded aggregated count of print requests on the database (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server for storage. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 receive the aggregated count of printed documents and the aggregated count of print requests from the plurality of client systems, store the recorded aggregated count of printed documents and the recorded aggregated count of print requests on the database, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
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 count of printed documents and recorded count 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.).
However, Ohno fails to specifically teach the features of receive the recorded aggregated count of printed documents and recorded aggregated count of print requests from the plurality of client systems.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses receive the recorded aggregated count of printed documents and recorded aggregated count of print requests from the plurality of client systems (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server for storage. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 receive the recorded aggregated count of printed documents and recorded aggregated count of print requests from the plurality of client systems, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
Re claim 29: (new) However, Ohno fails to specifically teach the features of the method of claim 1, wherein a form type comprises a category of printable document for which a client system of the plurality of client systems maintains a corresponding point-count statistic.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses totaling the types of printable output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses wherein a form type comprises a category of printable document for which a client system of the plurality of client systems maintains a corresponding point-count statistic (e.g. the system discloses aggregating a total of copies and prints, which are both considered a category of printable documents. The MFP and server can store this information, which is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 wherein a form type comprises a category of printable document for which a client system of the plurality of client systems maintains a corresponding point-count statistic, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
Re claim 30: (new) However, Ohno fails to specifically teach the features of the non-transitory computer-readable storage medium of claim 11, wherein a form type comprises a category of printable document for which a client system of the plurality of client systems maintains a corresponding point-count statistic.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses totaling the types of printable output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses wherein a form type comprises a category of printable document for which a client system of the plurality of client systems maintains a corresponding point-count statistic (e.g. the system discloses aggregating a total of copies and prints, which are both considered a category of printable documents. The MFP and server can store this information, which is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 wherein a form type comprises a category of printable document for which a client system of the plurality of client systems maintains a corresponding point-count statistic, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
Re claim 31: (new) However, Ohno fails to specifically teach the features of the server of claim 20, wherein a form type comprises a category of printable document for which a client system of the plurality of client systems maintains a corresponding point-count statistic.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses totaling the types of printable output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses wherein a form type comprises a category of printable document for which a client system of the plurality of client systems maintains a corresponding point-count statistic (e.g. the system discloses aggregating a total of copies and prints, which are both considered a category of printable documents. The MFP and server can store this information, which is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 wherein a form type comprises a category of printable document for which a client system of the plurality of client systems maintains a corresponding point-count statistic, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
Claim(s) 2, 12 and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Ohno, as modified by Harada and Zhang, as applied to claims 1, 11 and 20 above, and further in view of 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 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 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 non-transitory computer-readable storage medium of claim 11, wherein the instructions further configure the server to compute an count of print requests at the peak time based on the recorded count of received print requests at the second 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 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 an aggregated count of print requests based on the recorded aggregated count of received print requests.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses an aggregated count of print requests based on the recorded aggregated count of received print requests (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server for storage. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 an aggregated count of print requests based on the recorded aggregated count of received print requests, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
However, the combination above fails to specifically teach the features of the server to compute a peak time and an aggregated count of print requests at the peak time based on the recorded aggregated count 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 an aggregated count of print requests at the peak time based on the recorded aggregated count 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 an aggregated count of print requests at the peak time based on the recorded aggregated count of received print requests, incorporated in the device of Ohno, as modified by Harada, 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 and an count of print requests at the peak time based on the recorded count of received print requests at the second 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 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 an aggregated count of print requests based on the recorded aggregated count of received print requests.
However, this is well known in the art as evidenced by Harada. Similar to the primary reference, Harada discloses calculating totals of document output (same field of endeavor or reasonably pertinent to the problem).
Harada discloses an aggregated count of print requests based on the recorded aggregated count of received print requests (e.g. the system discloses a server requesting history information from a printer. The printer calculates a total number of printed and copied sheets and the total of number of copying and printing requests before sending this information together as history information to a server for storage. This is taught in ¶ [29], [32], [42]-[44] and [54] above.).
Therefore, in view of Harada, 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 an aggregated count of print requests based on the recorded aggregated count of received print requests, incorporated in the device of Ohno, in order to use a server to acquire print history information from a printer to aid in printer maintenance, which can improve usability (as stated in Harada ¶ [05]).
However, the combination above fails to specifically teach the features of the server to compute a peak time and an aggregated count of print requests at the peak time based on the recorded aggregated count 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 an aggregated count of print requests at the peak time based on the recorded aggregated count 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 an aggregated count of print requests at the peak time based on the recorded aggregated count 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]).
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.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
