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 .
Status of Claims
Claims 1-9 are pending.
Response to Arguments
Applicant's amendments as filed on 05/19/2026 has been considered and entered,
however, applicant’s arguments as filed have been fully considered but they are not persuasive.
Applicant argues that cited references fail to teach, specifically Parkinson fails to teach that “compare third authentication information with the first authentication information when determining that import data includes the third authentication information as a result of verification of the import data”. Applicant argues that first token is based on first database, second token is based on second database, thus tokens are generated based on different databases, thus, tokens are now included in import data or are based on verification of import data, see remarks, page 8.
In reply, examiner disagrees and asserts that claim is broad and doesn’t explicitly provide a strict definition of an import data, why first data including first token can’t be the import data? Also, why tokens or authentication information belonging to different databases is an issue, the claim doesn’t recite anything restricting regarding that? Parkinson sufficiently teaches that data is sent to the verification device, wherein a correspondence between the second token and the first token constitutes validation of the first token and a response is received at the first device indicating whether the verification system validated the first token and based on that comparison process between the second token to the first token is performed, see claims 1 and 6.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “authentication information in import data can be appropriately managed, and improper reuse of tokens can be avoided”, see remarks, page 7, 6th paragraph) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant then argues that Okumura fails to disclose the features such as to “maintain the token in a case that third authentication information and the first authentication information are determined to be the same authentication information and reflect the third authentication information instead of the first authentication information in the device setting and delete the token from the storage in a case that the third authentication information and the first authentication information are determined not to be the same authentication information”. Applicant’s arguments are based on assertions that tokens are being re-used with replacing old one’s with new one’s as a default and not based on comparison, there is no comparison between stored token’s as such tokens are deleted based on acceptance and not based on comparison, see remarks, pages 9-10.
In reply, examiner disagrees and asserts that applicant’s assertions are completely not true since there is a comparison taking place between old tokens as stored in table with new tokens generated to check if it is already registered/stored (basically to see if it’s same) to not have cumbersome process of using new token for each new workflow and being able to re-use the same old token in a case they are the same,
for instance, Okumura teaches acquiring a new token, different from an old token, in response to transmitting a further request for authentication to a specific cloud server in the token acquiring process, if the workflow table stores one or more workflows each including the specific cloud server as the cloud information and the old token as the token, the corresponding information registered as the token may be updated. Thus, as the same token is used to access the same cloud server in a plurality of workflows, paragraph 101, thereby, scanning application 41 may use a same token in a plurality of workflows using a same cloud server so that the user is re-authenticated to access the cloud server in an attempt to execute a workflow, the authentication information table 82 is updated. Therefore, the user may not need to be re-authenticated in each attempt to execute one of workflows using the same cloud server, paragraph 93
and after reading out a token stored in the workflow table or the authentication information table, the scanning application 41 may check whether the token is valid. For instance, the CPU 11 may inquire of a corresponding cloud server whether the token is valid. In another instance, when storing a token in the workflow table or the authentication information table, the CPU 11 may store validity information for the token such as an expiration date and a maximum number of valid uses of the token as well. In this case, the CPU 11 may read out the token from the workflow table or the authentication information table and determine whether the token is valid based on the validity information, paragraph 109, thus in this case, in an attempt to import the export file of a workflow including a token, the scanning application 41 may deletes the token from the workflow read out of the export file and store the workflow, paragraph 104, and therefore, new token is used/reflected to access the same cloud server in a plurality of workflows in response to determining that old token for authentication to a specific cloud server in the token acquiring process is not same or not valid, paragraph 101.
Applicant’s rest of the arguments are rendered moot as they are based on/repeating the assertions as above.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1 and 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over Okumura, US 2019/0286811 in view of Parkinson et al., US 2024/0015150.
Regarding claim 1, Okumura discloses a processing device (PC 1, fig. 1, paragraph 26) comprising:
an authenticator (control board including CPU 11 and authentication information table 82, fig. 1) that applies first authentication information and authenticates the processing device to a service using a token (“in an attempt to upload image data to a selected cloud server, the scanning application 41 (more specifically, the user of the scanning application 41) needs to be authenticated in accordance with regulations for the cloud server and acquire authentication information. For instance, an authentication method using OAuth 2.0 may be employed for the selected cloud server. In the authentication method using OAuth 2.0, the PC 1 receives, from the selected cloud server, an access token as the authentication information in response to transmitting account information of the user to the cloud server. When uploading the image data to the selected cloud server, the scanning application 41 transmits the image data with the access token. The access token may be an example of the authentication information”, paragraph 41);
a storage (memory 14, paragraphs 27, 31) that stores a device setting including the first authentication information and the token (when performing the authentication procedure for accessing the selected cloud server and acquiring a token from the cloud server, the scanning application 41 stores the acquired token into the non-volatile memory 14, in association with information specifying the cloud server such as scanning application 41 has an authentication information table 82 stored in the non-volatile memory 14. As exemplified in FIG. 3, the authentication information table 82 stores a token of each cloud server, paragraphs 45-46 and paragraph 59 for further details);
and one or more controllers (CPU 11, fig. 1) that verify import data imported to the processing device and reflect the import data in the device setting stored in the storage (import process by the CPU 11 to import the export file generated on another PC with the scanning application 41. For instance, the CPU 11 may perform the import process in response to accepting a user operation with scanning application 41 may once store the export file acquired from the external device into the non-volatile memory 14 and then read and import the stored export file, paragraphs 87-89),
maintain the token in a case that third authentication information and the first authentication information are determined to be the same authentication information (acquires a new token, different from an old token, in response to transmitting a further request for authentication to a specific cloud server in the token acquiring process, if the workflow table stores one or more workflows each including the specific cloud server as the cloud information and the old token as the token, the corresponding information registered as the token may be updated. Thus, as the same token is used to access the same cloud server in a plurality of workflows, paragraph 101, thereby, scanning application 41 may use a same token in a plurality of workflows using a same cloud server so that the user is re-authenticated to access the cloud server in an attempt to execute a workflow, the authentication information table 82 is updated. Therefore, the user may not need to be re-authenticated in each attempt to execute one of workflows using the same cloud server, paragraph 93),
and reflect the third authentication information instead of the first authentication information in the device setting and delete the token from the storage in a case that the third authentication information and the first authentication information are determined not to be the same authentication information (after reading out a token stored in the workflow table or the authentication information table, the scanning application 41 may check whether the token is valid. For instance, the CPU 11 may inquire of a corresponding cloud server whether the token is valid. In another instance, when storing a token in the workflow table or the authentication information table, the CPU 11 may store validity information for the token such as an expiration date and a maximum number of valid uses of the token as well. In this case, the CPU 11 may read out the token from the workflow table or the authentication information table and determine whether the token is valid based on the validity information, paragraph 109, thus in this case, in an attempt to import the export file of a workflow including a token, the scanning application 41 may deletes the token from the workflow read out of the export file and store the workflow, paragraph 104, and therefore, new token is used/reflected to access the same cloud server in a plurality of workflows in response to determining that old token for authentication to a specific cloud server in the token acquiring process is not same or not valid, paragraph 101).
Okumura fails to explicitly disclose wherein one or more controllers compare third authentication information with the first authentication information in a case that import data is determined to include the third authentication information as a result of verification of the import data.
However, Parkinson teaches wherein one or more controllers (verification computing device) compare third authentication information (first token) with the first authentication information (second token) in a case that import data (data sent to the verification device, wherein a correspondence between the second token and the first token constitutes validation of the first token) is determined to include the third authentication information as a result of verification of the import data (receiving a response at the first device indicating whether the verification system validated the first token; and responsive to the response received at the first device indicating that the verification system validated the first token, comparing the second token to the first token, claims 1 and 6).
Okumura and Parkinson are combinable because they both are in the same field of endeavor dealing with authentication tokens among image processing devices.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Okumura to incorporate the teachings of Parkinson to provide comparison techniques between the authentication information for the benefit of providing efficient and robust authentication environment eliminating occurrences of bad actors obtaining user’s information as taught by Parkinson at paragraphs 3, 5.
Regarding claim 8, Okumura discloses an image processing device (PC 1, fig. 1, paragraph 26) comprising: a processing device including: an authenticator (control board including CPU 11 and authentication information table 82, fig. 1), and an image processor (CPU 11 with scanning application 41 utilizing network communication 16, fig. 1) that performs transmission processing of an image based on an authentication result in the service (paragraphs 41, 57-60, 75). Rest of the claim recites similar features as claim 1 and thus is rejected on the same rationale as presented for claim 1.
Regarding claim 9, is a method version of claim 1 reciting similar features as claim 1 and thus is rejected on the same rationale as presented for claim 1.
Claims 2-4 are rejected under 35 U.S.C. 103 as being unpatentable over Okumura, US 2019/0286811 in view of Parkinson et al., US 2024/0015150 as applied in claim 1 above and further in view of Asahara, US 2014/0022591 further in view of Minagawa, US 2014/0226179.
Regarding claim 2, Okumura discloses import button (paragraph 81) but combination of Okumura with Parkinson fails to explicitly teach wherein import data comprises data in which a setting value of the device setting is represented in association with a tag, and one or more controllers verify the import data when the tag is detected.
However, Asahara teaches wherein import data comprises data in which a setting value of the device setting is represented in association with a tag and verification of import data (“fig. 5 illustrates an example of the import data or the export data. In this example, an identifier represented in the form of an extensible markup language (XML) file for identifying a setting value for the image forming apparatus 101 is the name of a tag. An entity of the setting value is described in a value. The type of the setting value included in the import data or the export data includes a setting value about printing such as a sheet size and setting values about a facsimile (FAX) function and communication with other apparatuses”, paragraph 24).
Okumura and Parkinson are combinable with Asahara because they all are in the same field of endeavor dealing with importing data among image processing devices.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Okumura and Parkinson to incorporate the teachings of Asahara to provide a setting value of the device setting is represented in association with a tag such that user can know that an import result log will not be output before performing the import when a setting value is imported to the image forming apparatus as taught by Asahara at paragraph 8.
Okumura and Parkinson with Asahara fail to teach one or more controllers verify import data when tag is detected.
However, Minagawa teaches one or more controllers verify import data when tag is detected (print request information described in the XML format tag includes a printer name 1341, a proxy ID 1342, capabilities 1343, and print settings 1344 is received along with user authentication token and registration request that based on that the printing service printer generation unit connects to the printing service by using the received authentication token and the printing service 330 registers the printer (verification of import data upon/when XML tag data is received/detected), paragraph 112)
Okumura, Parkinson and Asahara are combinable with Minagawa because they both are in the same field of endeavor dealing with printing data and print settings while utilizing authentication tokens.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Okumura and Parkinson with Asahara to incorporate the teachings of Minagawa such that image forming apparatus which does not have a communication module conforming to a vendor specification can cooperate with printing services as taught by Minagawa at paragraph 9.
Regarding claim 3, Combination of Okumura with Parkinson further teaches the one or more controllers determine that the import data includes the third authentication information (Okumura, acquiring a new token, different from an old token, in response to transmitting a further request for authentication to a specific cloud server, paragraph 93 and Parkinson, in the token acquiring process receiving a validated response at the first device indicating whether the verification system validated the first token to determine that request data includes second token (third authentication information) which is to be compared with the first token, claims 1 and 6).
Okumura and Parkinson are combinable because they both are in the same field of endeavor dealing with authentication tokens among image processing devices.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Okumura to incorporate the teachings of Parkinson to provide comparison techniques between the authentication information for the benefit of providing efficient and robust authentication environment eliminating occurrences of bad actors obtaining user’s information as taught by Parkinson at paragraphs 3, 5.
Combination of Okumura with Parkinson and Asahara fails to further teach wherein in a case that the detected tag represents a setting value related to an authentication method of performing the authentication of the processing device to the service using the token.
However, Minagawa teaches wherein in a case that the detected tag (print request in the form of XML formatted tag/request) represents a setting value related to an authentication method of performing the authentication of the processing device to the service using the token (print request information described in the XML format includes a printer name 1341, a proxy ID 1342, capabilities 1343, and print settings 1344 is received along with user authentication token and registration request that based on that the printing service printer generation unit connects to the printing service by using the received authentication token and the printing service 330 registers the printer, paragraph 112).
Okumura, Parkinson and Asahara are combinable with Minagawa because they both are in the same field of endeavor dealing with printing data and print settings while utilizing authentication tokens.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Okumura and Parkinson with Asahara to incorporate the teachings of Minagawa such that image forming apparatus which does not have a communication module conforming to a vendor specification can cooperate with printing services as taught by Minagawa at paragraph 9.
Regarding claim 4, Combination of Okumura with Parkinson, Asahara and Minagawa further teaches wherein the authentication method is an OAuth authentication method (Okumura, “authentication method using OAuth 2.0 may be employed”, paragraph 41).
Okumura, Parkinson and Asahara are combinable with Minagawa because they both are in the same field of endeavor dealing with printing data and print settings while utilizing authentication tokens.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Okumura and Parkinson with Asahara to incorporate the teachings of Minagawa such that image forming apparatus which does not have a communication module conforming to a vendor specification can cooperate with printing services as taught by Minagawa at paragraph 9.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Okumura, US 2019/0286811 in view of Parkinson et al., US 2024/0015150 as applied in claim 1 above and further in view of Asahara, US 2014/0022591.
Regarding claim 7, Combination of Okumura with Parkinson and Asahara further teaches wherein the import data includes first device setting information (Asahara, type of the setting value included in the import data or the export data includes a setting value about printing such as a sheet size and setting values about a facsimile (FAX) function and communication with other apparatuses, paragraph 24), and the one or more controllers replace the device setting with a first device setting based on the first device setting information (Asahara, setting in import data describe which settings/functions to use/replace depending upon communication with other apparatuses, paragraph 24), and regarding the third authentication information, maintain the token in a case when determining that the third authentication information and the first authentication information are determined to be the same authentication information (Okumura, acquires a new token, different from an old token, in response to transmitting a further request for authentication to a specific cloud server in the token acquiring process, if the workflow table stores one or more workflows each including the specific cloud server as the cloud information and the old token as the token, the corresponding information registered as the token may be updated. Thus, as the same token is used to access the same cloud server in a plurality of workflows, paragraph 101, thereby, scanning application 41 may use a same token in a plurality of workflows using a same cloud server so that the user is re-authenticated to access the cloud server in an attempt to execute a workflow, the authentication information table 82 is updated. Therefore, the user may not need to be re-authenticated in each attempt to execute one of workflows using the same cloud server, paragraph 93), and reflect the third authentication information instead of the first authentication information in the device setting and delete the token from the storage in a case determining that the third authentication information and the first authentication information are determined not to be the same authentication information (Okumura, after reading out a token stored in the workflow table or the authentication information table, the scanning application 41 may check whether the token is valid. For instance, the CPU 11 may inquire of a corresponding cloud server whether the token is valid. In another instance, when storing a token in the workflow table or the authentication information table, the CPU 11 may store validity information for the token such as an expiration date and a maximum number of valid uses of the token as well. In this case, the CPU 11 may read out the token from the workflow table or the authentication information table and determine whether the token is valid based on the validity information, paragraph 109, thus in this case, in an attempt to import the export file of a workflow including a token, the scanning application 41 may deletes the token from the workflow read out of the export file and store the workflow, paragraph 104, and therefore, new token is used/reflected to access the same cloud server in a plurality of workflows in response to determining that old token for authentication to a specific cloud server in the token acquiring process is not same or not valid, paragraph 101).
Okumura and Parkinson are combinable with Asahara because they all are in the same field of endeavor dealing with importing data among image processing devices.
Therefore, it would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Okumura and Parkinson to incorporate the teachings of Asahara to provide a setting value of the device setting is represented in association with a tag such that user can know that an import result log will not be output before performing the import when a setting value is imported to the image forming apparatus as taught by Asahara at paragraph 8.
Allowable Subject Matter
Claims 5-6 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: cited prior arts fail to explicitly teach all the limitations of claim 5 such as “The processing device according to claim 3, wherein in a case that the detected tag represents a setting value related to a different authentication method, the one or more controllers determine that the import data includes fourth authentication information and reflect the fourth authentication information in the device setting”.
Claim 6 is further dependent upon claim 5.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Wen, US 2020/0218819
Sato, US 2016/0231971
Ittogi, US 2024/0205029
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 PAWANDEEP DHINGRA whose telephone number is (571) 270-1231. The examiner can normally be reached 9:00-5:00.
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.
/PAWAN DHINGRA/Examiner, Art Unit 2683
/BENNY Q TIEU/Supervisory Patent Examiner, Art Unit 2682
Prosecution Insights