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-17 are pending. Claims 18-22 are cancelled.
Claim Rejections - 35 USC § 103
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-4, 7-10, 13-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kinoshita (PGPUB 2008/0263213), and further in view of Meyers et al (PGPUB 2016/0149669).
Regarding Claims 1, 7:
Kinoshita teaches a method for storing digital objects in an object storage system, and an object storage system for storing digital objects ([abstract], web server and relaying device to relay HTTP message between mobile phone and web server), said object storage system comprising:
at least one storage node including memory for storing digital objects therein ([0056] relaying device stores the upload data and relays upload data to web server; [0008]-[0010] communication device including memory storage);
a client interface facilitating a connection with a client device ([0037]-[0039] network including mobile phone, relaying device(s), and web server; relaying device relays request from mobile phone to web server through Internet; mobile phone and relaying devices direct coupled to network; relaying device and web server direct coupled to network; [0054]-[0056] relaying device relays upload data to web server either after receiving the total size thereof or each time it receives such data); and
an upload service operative to receive a request from said client device to upload a digital object to said object storage system ([0054]-[0056] mobile phone transmits upload request to web server; relaying device receives upload request and determines whether to relay request to web server; relaying device relays upload request to web server and receives response indicating web server is able to receive upload data; [0073] upload request is request to use “Transfer-Encoding: chunked” in compliance with HTTP 1.1, i.e. segmented transmission; therefore, request is request for uploading object as series of chunks), the complete contents of said digital object to be uploaded being unknown to said client device at the time said request is made ([0056] mobile phone continues uploading upload data; relaying device uploads data each time it receives it; therefore, at the time of the request, the relaying device does not have the complete contents of the object being uploaded),
receive a series of chunks of said digital object from said client device responsive to said request ([0073] mobile phone upload request is request to use “Transfer-Encoding: chunked”; [0056] relaying device stores the upload data and relays such data to the web server; relaying device uploads data each time it receives it).
Kinoshita does not explicitly teach receiving a trailer from said client device following a final chunk of said series of chunks, said trailer including at least one parameter associated with said complete contents of said digital object uploaded by said client device, and
verifying that said complete contents of said digital object has been received using said at least one parameter included in said trailer.
However, Meyers teaches the concept of receiving a trailer from said client device following a final chunk of said series of chunks, said trailer including at least one parameter associated with said complete contents of said digital object uploaded by said client device ([abstract] method for transferring data; [0022] source data is split into data chunks; checksum values are calculated and included with each data chunk; source data includes “master checksum” in header and footer; [0023] data chunks transferred from source device to receiving device; [0028] master checksum for data file is provided; [0031] connection between source and receiving device for high-speed transfer; [0006] master checksum sent in the header and/or footer of the file, and thus before the first data chunk or after the final data chunk), and
verifying that said complete contents of said digital object has been received using said at least one parameter included in said trailer ([0023] once all the data chunks are received, the checksum of all the data chunks are compared to the master checksum of the original source data to ensure all of the data chunks have been received).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the checksum trailer teachings of Meyers with the chunked data upload teachings of Kinoshita, in order to provide a method of proving the integrity of a transmitted file both whole and in part, providing confidence to the source and destination devices that data had been reliably transmitted, or at least indicating which data needed to be sent again, preventing corruption and improving efficiency.
Regarding Claims 2, 8:
Kinoshita in view of Meyers teaches the method of claim 1 and the object storage system of Claim 7. In addition, Kinoshita teaches wherein said request comprises an HTTP request specifying transfer-encoding chunked ([0073] upload request format using “Transfer-Encoding: chunked” in compliance with HTTP1.1).
Regarding Claims 3, 9:
Kinoshita in view of Meyers teaches the method of claim 1 and the object storage system of Claim 7. In addition, Meyers teaches wherein said at least one parameter comprises a checksum of said series of chunks uploaded by said client device ([0006] master checksum sent in the header and/or footer of the file, and thus before the first data chunk or after the final data chunk).
The rationale to combine Kinoshita and Meyers is the same as provided for claims 1 and 7 due to the overlapping subject matter between claims 1 and 3, 7 and 9.
Regarding Claims 4, 10:
Kinoshita in view of Meyers teaches method of claim 3 and the object storage system of Claim 9. In addition, Meyers teaches wherein said upload service is further operative to:
assemble said series of chunks into an assembled digital object ([0032]-[0035] transmit data chunks from source device to receiving device and combine data chunks to form original data file);
determine a checksum of said assembled digital object ([0007], [0023], [0035] receiving device recombines individual checksums to create verification checksum); and
compare said checksum of said assembled digital object to said checksum included in said trailer to verify that said complete contents of said digital object has been received by said cloud object store ([0035] combined checksums verified against master checksum to ensure every data chunk was received without error).
The rationale to combine Kinoshita and Meyers is the same as provided for claims 3 and 9 due to the overlapping subject matter between claims 3 and 4, 9 and 10.
Regarding Claim 13:
Kinoshita teaches, in a client device, a method for uploading a streamed object to an object storage system ([abstract] relaying device to relay HTTP message between mobile phone and web server), said method comprising:
receiving a streamed object from a stream source ([0037]-[0039] network including mobile phone, relaying device(s), and web server; relaying device relays request from mobile phone to web server through Internet; mobile phone and relaying devices direct coupled to network; [0054]-[0056] relaying device receives upload request from mobile phone; mobile phone uploads upload data to relaying device; relaying device relays upload data to web server either after receiving the total size thereof or each time it receives such data (i.e. streamed data));
establishing a connection with said object storage system ([0037]-[0039] relaying device and web server direct coupled to network; [0054]-[0056] relaying device relays upload data to web server either after receiving the total size thereof or each time it receives such data); and
providing a request to upload said streamed object as a series of chunks to said object storage system ([0054]-[0056] mobile phone transmits upload request to web server; relaying device receives upload request and determines whether to relay request to web server; relaying device relays upload request to web server and receives response indicating web server is able to receive upload data; [0073] upload request is request to use “Transfer-Encoding: chunked” in compliance with HTTP 1.1, i.e. segmented transmission; therefore, request is request for uploading object as series of chunks), the complete contents of said streamed object being unknown to said client device at the time of said request ([0056] mobile phone continues uploading upload data; relaying device uploads data each time it receives it; therefore, at the time of the request, the relaying device does not have the complete contents of the object being uploaded),
preparing said series of chunks associated with said streamed object consistent with said request ([0073] mobile phone upload request is request to use “Transfer-Encoding: chunked”; [0056] relaying device stores the upload data and relays such data to the web server; relaying device uploads data each time it receives it), and
uploading each chunk in said series of chunks to said object storage system ([0056] relaying device uploads data to web server each time it receives it).
Kinoshita does not explicitly teach computing at least one parameter indicative of the complete contents of said series of chunks uploaded to said object storage system, and
providing a trailer to said object storage system via said object store interface following a final chunk of said series, said trailer including said at least one parameter.
However, Meyers teaches the concept of computing at least one parameter indicative of the complete contents of a series of chunks uploaded to an object storage system ([abstract] method for transferring data; [0022] source data is split into data chunks; checksum values are calculated and included with each data chunk; source data includes “master checksum” in header and footer; [0023] data chunks transferred from source device to receiving device; [0028] master checksum for data file is provided), and
providing a trailer to said object storage system via an object store interface following a final chunk of said series, said trailer including said at least one parameter ([0023] data chunks transferred from source device to receiving device; [0031] connection between source and receiving device for high-speed transfer; [0006] master checksum sent in the header and/or footer of the file, and thus before the first data chunk or after the final data chunk).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the checksum trailer teachings of Meyers with the chunked data upload teachings of Kinoshita, in order to provide a method of proving the integrity of a transmitted file both whole and in part, providing confidence to the source and destination devices that data had been reliably transmitted, or at least indicating which data needed to be sent again, preventing corruption and improving efficiency.
Regarding Claim 14:
Kinoshita in view of Meyers teaches the method of claim 13. In addition, Kinoshita teaches wherein said request comprises an HTTP request specifying transfer-encoding chunked ([0073] upload request format using “Transfer-Encoding: chunked” in compliance with HTTP1.1).
Regarding Claim 15:
Kinoshita in view of Meyers teaches the method of Claim 13. In addition, Meyers teaches wherein said step of computing said at least one parameter comprises computing a checksum of said series of chunks uploaded to said object storage system ([0022] source data is split into data chunks; checksum values are calculated and included with each data chunk; source data includes “master checksum” in header and footer).
The rationale to combine Kinoshita and Meyers is the same as provided for claim 13 due to the overlapping subject matter between claims 13 and 15.
Regarding Claim 16:
Kinoshita in view of Meyers teaches the method of Claim 15. In addition, Meyers teaches wherein said trailer includes said checksum of said series of chunks uploaded to said object storage system ([0006] master checksum sent in the header and/or footer of the file, and thus before the first data chunk or after the final data chunk).
The rationale to combine Kinoshita and Meyers is the same as provided for claim 15 due to the overlapping subject matter between claims 15 and 16.
Regarding Claim 17:
Kinoshita in view of Meyers teaches the method of claim 13. In addition, Meyers teaches the method further comprising processing said streamed object according to a client-specific process prior to uploading each said chunk in said series ([0025] source of data may be data residing on a storage medium or data captured in real-time during the transfer, e.g. audio or video being recorded; [0022] once source data is split into data chunks, checksum values are calculated and included with each data chunk).
The rationale to combine Kinoshita and Meyers is the same as provided for claim 13 due to the overlapping subject matter between claims 13 and 17.
Claims 5, 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kinoshita in view of Meyers, and further in view of Catalano (PGPUB 2016/0267279).
Regarding Claims 5, 11:
Kinoshita in view of Meyers teaches the method of claim 1 and the object storage system of Claim 7. In addition, Meyers teaches wherein said upload service is further operative to:
assemble said series of chunks into an assembled digital object ([0034] combine data chunks to form original data file);
store said assembled digital object ([0017], [0038] receiving device includes storage medium for storing the recording (i.e. received file); receiving device stores all data chunks after transfer is complete).
The rationale to combine Kinoshita and Meyers is the same as provided for claims 1 and 7 due to the overlapping subject matter between claims 1 and 5, 7 and 11.
Neither Kinoshita nor Meyers explicitly teaches encrypting said assembled digital object using an encryption key unique to said assembled digital object.
However, Catalano teaches the concept of encrypting an uploaded digital object using an encryption key unique to said uploaded object ([0024] when a file is uploaded to the server, algorithms instruct the processor to request that a new key is generated and used to encrypt the file; the technique utilized for file encryption upon upload is through using a uniquely generated key for each file); and
Meyers teaches wherein the uploaded digital object is an assembled digital object ([0034] combine data chunks to form original data file).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the per file encryption key teachings of Catalano with the chunked data upload teachings of Kinoshita in view of Meyers, in order to protect files using well-known encryption methods which prevent access to data without use of the respective decryption key, and to minimize damage in the event a malicious agent acquires a key by limiting key use to individual files, thereby improving the security environment.
Claims 6, 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kinoshita in view of Meyers, and further in view of Luby et al (PGPUB 2014/0307734).
Regarding Claim 6, 12:
Kinoshita in view of Meyers teaches the method of claim 1 and the object storage system of Claim 7.
Neither Kinoshita nor Meyers explicitly teaches wherein said at least one parameter comprises a size of said series of chunks uploaded by said client device.
However, Luby teaches the concept wherein at least one parameter comprises a size of a series of chunks uploaded by a client device ([0099] embodiments configured to perform chunk delivery and/or chunk reception operations, allowing a server to start sending an object before it is fully generated by source encoder; [0373] enhancements and benefits over existing broadcast solutions include delivering an object via chunk or sequential delivery and indicating the object’s size or other information relating to the object that is not known at the start of the delivery by adding the size value or other information as part of the object delivery in a trailer).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the size of data trailer teachings of Luby with the chunked data upload teachings of Kinoshita in view of Meyers, in order to convey additional information to a recipient which was not explicitly known at the beginning of a transmission, thereby providing an additional means of verifying that the entirety of a file had been transmitted by comparing the received file size to that indicated in the received trailer.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FORREST L CAREY whose telephone number is (571)270-7814. The examiner can normally be reached 9:00AM-5:30PM M-F.
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, William Korzuch can be reached at (571) 272-7589. 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.
/FORREST L CAREY/Examiner, Art Unit 2491
/WILLIAM R KORZUCH/Supervisory Patent Examiner, Art Unit 2491
Prosecution Insights