DETAILED ACTION
The instant application having Application No. 18/679,363 filed on 05/30/2024 is presented for examination by the Examiner.
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 .
Claim Objections
Claim 8 is objected to because of the following informalities:
Claim 8 recites the limitation “..with the token replacing the token” In line 17, which should be changed to “..with the value replacing the token” Appropriate correction is required.
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 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-7, 11-12 and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over McCorkindale et al. (US 2013/0272523 A1-hereinafter McCork) and in view of Kelselman et al. (US 2019/0147170 A1-hereinafter Kelselman).
Regarding claim 1, McCork discloses a method of controlling access to values in electronic documents, comprising:
receiving, by a first service, an electronic document comprising a plurality of values associated with a corresponding plurality of fields to be provided to at least one of a plurality of client devices (at least figure 1, elements 114, 122 & 124; [0024] [0027][0042][0055], document ID/document which comprises a plurality of fields is received at the multifunction device (MFD));
identifying, by the first service, from the electronic document, a field of the plurality of fields associated with a corresponding value of the plurality of values is to be encrypted (at least figure 2, [0043][0045]-[0047], i.e.: sensitive information is identified by the MFD and is to be encrypted);
maintaining, by the first service, on a database, a plurality of first encryption keys (at least figure 1, component 108, figure 2, step 220, [0045], it’s implied that the MFD maintains a plurality of keys used to encrypt sensitive data);
selecting, by the first service, from the plurality of first encryption keys, a first encryption key (at least figure 2, step 220, [0045][0048], it’s implied that a key is selected to encrypt the sensitive information);
generating, by the first service, a token using the value and the first encryption key for the field (at least [0027][0032], i.e.: encrypted sensitive information/ redacted document is generated), the first encryption key associated with a second encryption key on a second service to control access to the value (at least [0040][0048][0056], i.e.: a key used to encrypt at MFD, associates with a key used to decrypt at server); and
sending, by the first service to a client device of the plurality of client devices, the electronic document comprising the token replacing the value associated with the corresponding field (at least figure 3, step 308, [0024][0055], the document ID/document which comprises the redacted document is transmitted to the mobile device), wherein the client device is configured to transmit a request comprising a user identifier and the token to the second service to determine whether to recover the value (at least [0040][0057], the mobile device transmits a request comprising device identification associated with the mobile device and the document ID/document to the server to determine whether to decrypt encrypted sensitive information).
McCork does not explicitly disclose the plurality of first encryption keys associated with a plurality of field types, and selecting a first encryption key based on a field type of the field.
However, Kelselman discloses a plurality of first encryption keys associated with a plurality of field types (at least [0006]-[000733][0038], cryptographic keys associated with different types of data), and selecting a first encryption key based on a field type of the field (at least [0038], a cryptographic key is derived/selected based on information about a type of data to be encrypted).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature discloses by Kelselman into the method of McCork to enhance the security level of the method.
Regarding claim 2, McCork and Kelselman disclose the method of claim 1. McCork and Kelselman also obviously disclose receiving, by the first service, from the second service, the plurality of first encryption keys associated with the plurality of field types to encrypt values in electronic documents (McCork-at least [0045], key to encrypt sensitive data is at MFD, and key to decrypt encrypted sensitive data is at server. As such, when encryption algorithm used is public/private key, it is implied that the server communicated the public key to the MFD to use to encrypt the sensitive data; Kelselman-at least [0006]-[000733][0038], cryptographic keys associated with different types of data).
Regarding claim 3, McCork and Kelselman disclose the method of claim 1. McCork also discloses identifying, by the first service, from the electronic document, a second field of the plurality of fields associated with a corresponding second value of the plurality of values is not to be encrypted (at least figure 5A & 5B, [0043]-[0044], field that is determined not sensitive is identified, thus does not need to be encrypted); and
maintaining, by the first service, the corresponding second value associated with the second field in the electronic document (at least figure 5C, field that is determined as not sensitive is maintained/is not redacted or encrypted).
Regarding claim 4, McCork and Kelselman disclose the method of claim 1. McCork also discloses removing, by the first service, storage of the token from the first service, responsive to sending the electronic document to the client device (at least [0051], the document ID/document which includes redacted areas is sent/removed from the MFD and sent to client device).
Regarding claim 5, McCork and Kelselman disclose the method of claim 1. McCork also discloses identifying the field further comprises identifying the field as associated with sensitive information to be encrypted from the electronic document (at least [0043]-[0046], sensitive information is identified and is to be encrypted).
Regarding claim 6, McCork and Kelselman disclose the method of claim 1. McCork and Kelselman also disclose generating the token further comprises generating the token to include: (i) a first portion identifying the first key used to generate the token (McCork-at least [0048], the redacted area includes a first portion that identifies key used to encrypt redacted copy) and (ii) a second portion identifying the field type of the field associated with the value (McCork-at [0045][0047], sensitive field least).
Regarding claim 7, McCork and Kelselman disclose the method of claim 1. McCork also discloses sending the electronic document further comprises sending the electronic document to cause an application on the client device to display the electronic document including an indication of the value associated with the corresponding field as encrypted (at least [0065]-[0067], unredacted image/ document is displayed via display of the mobile device).
Regarding claim 11, McCork discloses the method of claim 8. McCork also discloses accessing, by the first service, a database to retrieve a second encryption key associated with a field type to decrypt tokens in electronic document (at least figure 1, component 108, figure 2, step 220, [0045], the server access its database to retrieve decryption information associated with a plurality of field type to decrypt redacted/encrypted area of documents); and
selecting, by the first service, from the plurality of second encryption keys (at least [0037][0057], a decryption information is selected to decrypt the encrypted sensitive information), the second encryption key to generate the value based on the field type identified by the token (at least [0037][0066], decryption information is used to decrypt encrypted sensitive information).
McCork does not explicitly disclose the plurality of first encryption keys associated with a plurality of field types, and selecting a first encryption key based on a field type of the field.
However, Kelselman discloses a plurality of first encryption keys associated with a plurality of field types (at least [0006]-[000733][0038], cryptographic keys associated with different types of data), and selecting a first encryption key based on a field type of the field (at least [0038], a cryptographic key is derived/selected based on information about a type of data to be encrypted).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature discloses by Kelselman into the method of McCork to enhance the security level of the method.
Regarding claim 12, McCork discloses the method of claim 8. McCork also discloses keys are generated from either the MFD or the server, and the keys generated are provided to the other of the MFD or the server to encrypt sensitive information in electronic documents (at least [0046][0048], i.e.: MFD uses key generated to encrypt sensitive data).
McCork does not explicitly disclose generating a first plurality of encryption keys and the first plurality of keys for encrypting values of the corresponding plurality of field types in electronic documents.
However, Kelselman discloses a plurality of first encryption keys are generated and used for encrypting values of corresponding plurality of field types (at least [0006]-[000733][0038], cryptographic keys associated with different types of data).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the feature discloses by Kelselman into the method of McCork to enhance the security level of the method.
Claim 15 is rejected for the same rationale as claim 1 above.
Claim 16 is rejected for the same rationale as claim 2 above.
Claim 17 is rejected for the same rationale as claim 3 above.
Claim 18 is rejected for the same rationale as claim 4 above.
Claim 19 is rejected for the same rationale as claim 6 above.
Claim 20 is rejected for the same rationale as claim 7 above.
Claims 8-10 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over McCorkindale et al. (US 2013/0272523 A1-hereinafter McCork).
Regarding claim 8, McCork discloses a method of providing access to values in electronic documents, comprising:
receiving, by a first service from a client device of a plurality of client devices, a request identifying ([0037][0056][0063], a request from mobile device is received at server identifies) (i) a user identifier associated with the client device ([0037][0051][0065], a user associates with device ID) and (ii) a token associated with a field of a plurality of fields of an electronic document (at least a redacted/ encrypted area), the token included by a second service into the electronic document using a first encryption key associated with a field type of a plurality of field types for the field (at least figures 1, 5C & 5D, [0046], sensitive information is redacted/encrypted into the document by multi-function device (MFD));
identifying, by the first service, from the plurality of field types, the field type of the field based on at least a portion of the token (at least [0065], type or content of sensitive data is identified by the server);
determining, by the first service, that the client device is permitted to access a value associated with the token based on the user identifier and the field type in accordance with a policy, the policy identifying a respective permission for each of the plurality of client devices to access the plurality of field types (at least [0065], type and amount of sensitive data made available to client device depends on or more permission levels);
generating, by an application at the mobile device, the value using a second encryption key for the field type, the second encryption key associated with the first encryption key on the second service (at least [0037]-[0039], key used to decrypt encrypted/redacted area corresponds to the key used to encrypt the sensitive information at the MFD); and
sending, by the app to the client device, the value to replace the token in the electronic document, wherein the client device is configured to present the electronic document with the token replacing the token (at least [0039][0067], decrypted sensitive information replaces the redacted/encrypted area).
McCork does not explicitly disclose the generating and sending are being done by the first service.
However, McCork discloses the first service has the decryption information to decrypt encrypted/redacted areas (at least [0037], decryption information is stored at server). As such, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to decrypt the encrypted sensitive information at the server, then send the sensitive information which has been decrypted to the mobile device to allow the decryption to be performed at either side, while still ensuring that the sensitive information is only provided to authorized entity.
Regarding claim 9, McCork discloses the method of claim 8. McCork also discloses determining, by the first service, that the client device is restricted from access to the value generated from the token based on the user identifier (at least figure 4, [0064]-[0065], access restriction is determined based on identification of mobile device requesting access); and
sending, by the first service, to the client device, an indication that the value associated with the token is restricted from provision (at least figure1, step 162, figure 4, step 408 & 410, [0064], access denied is sent to mobile device).
Regarding claim 10, McCork discloses the method of claim 8. McCork also discloses determining, by the first service, that the client device is permitted partial access to the value associated with the token based on the user identifier (at least [0065], amount of sensitive data made available is determined); and sending, by the first service, a portion of the value to partially replace the token in the electronic document (at least [0039][0067] & see obvious reason in claim 1 above, amount of decrypted sensitive information replaces the redacted/encrypted area)).
Regarding claim 13, McCork discloses the method of claim 8. McCork also discloses receiving the request further comprises receiving the request to recover the value, responsive to an application on the client device detecting an interaction with the token on the electronic document (at least [0057][0058], encrypted sensitive information scanned by app on the mobile device is decrypted).
Regarding claim 14, McCork discloses the method of claim 8. McCork also discloses sending the value further comprises sending the value to cause an application on the client device to (i) remove an indication of the value associated with the corresponding field as encrypted (at least [0058][0066], encrypted sensitive information is decrypted) and (ii) display the value instead of the token on the electronic document (at least [0058][0066], decrypted sensitive information is displayed).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHY ANH TRAN VU whose telephone number is (571)270-7317. The examiner can normally be reached Monday-Friday 7 am-1 pm.
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, Taghi T Arani can be reached at (571) 272-3787. 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.
/PHY ANH T VU/Primary Examiner, Art Unit 2438