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 .
DETAILED ACTION
Response to Arguments
Applicant's arguments filed 2/12/2026 have been fully considered, and are persuasive. The amended claim language further specifying and differentiating the functionality provided by the “storage layer abstraction server” versus, e.g., the “data host” persuasively claims beyond the previously cited prior art combination. However, after further search and consideration, a new grounds of rejection has been made in view of North (US-20170177609-A1).
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, 2, 5, 6, 11, 12, 15 – 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Thomas (US-10594774-B2) in view of Lisiecki (US-20020143798-A1) and North (US-20170177609-A1).
Regarding claim 1, Thomas shows a computer-implemented method comprising:
receiving, at an interface of a storage layer abstraction server (col. 1 lines 23-40, col. 8 lines 35-40, col. 11 lines 20-30), a first request for a first user to upload a first file to a first data host (col. 3 lines 59-62, col. 4 line 64 – col. 5 line 15, col. 5 lines 35-45), wherein the first request includes first storage settings for storing the first file at the first data host (col. 5 lines 40-45, col. 7 lines 1-2 and 26-46, col. 8 lines 41-48, col. 16 lines 1-9, discussing a user uploading multiple files, each file associated with its own particular “configuration settings” which include file distribution controls selected by the uploader such as requirements for characteristics of the downloading user, availability windows, and password requirements) generating a first unique identifier associated with the first file, the first user, and the first data host (col. 5 lines 40-48); identifying the first credentials for the first data host (col. 5 lines 35-45); establishing a first connection to the first data host using the first credentials (col. 5 lines 35-45, col. 6 lines 15-20); sending, over the first connection, the first file to the first data host for storage at the first data host for the first user (col. 5 lines 35-40) according to the first storage settings (the uploaded file is stored and then managed in accordance with the “configuration settings” specified by the file uploader, as discussed in col. 7 lines 1-2 and 26-46) providing the first unique identifier in response to the first request (col. 5 lines 55-60), and receiving, at the interface of the storage layer abstraction server, a second request for the first user to upload a second file to a data host, wherein the second request includes second storage settings for storing the second file at the data host that are different than the first storage settings (col. 16 lines 1 – 10 discussing that the “first client may upload another shared content” and provide particular configuration settings for that content, including a password; as col. 7 lines 1-2 and 25 – 46 note, different combinations of “configuration settings” - which include particular passwords, file storage, and distribution controls - may be provided for each particular shared content). Thomas does not show receiving, at the interface of the storage layer abstraction server, a second request for the first user to upload a second file to a second data host, wherein the second data host is different than the first data host. Lisiecki shows receiving, at the interface of the storage layer abstraction server ([33-35]), a second request for the first user to upload a second file to a second data host, wherein the second data host is different than the first data host (Fig. 5, [14,17,36-37]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the data distribution techniques of Thomas with the distributed, multi-server storage of Lisiecki in order to enable improvements to system responsiveness and efficiency via Lisiecki’s distributed architecture.
The above combination does not show where the generating, identifying, establishing, sending, and providing are performed by the storage layer abstraction server, and where the receiving, from the first user, at the interface of the storage layer abstraction server at which the first request was received for the first user to upload the first file to the first data host, a second upload request. North shows: where the generating ([12-13]), identifying (Fig. 1 item 28, Fig. 2 items 210 and 211, [8,41-42]), establishing (Fig. 2 item 221, [40, 45]) sending ([40,46-47,49], Fig. 2 item 280), and providing ([12-15]) are performed by the storage layer abstraction server, and where the receiving, from the first user, at the interface of the storage layer abstraction server at which the first request was received for the first user to upload the first file to the first data host (Fig. 1, see “virtualized server 11” which is suggested to perform the functionality of the claimed “storage layer abstraction server” with Fig. 1’s multiple “storage server’s 16” acting as the claimed “data hosts”; the “virtualized server 11” acts as an interface to the storage as discussed in Abstract, [5,11,18,54-56], and cited above), a second upload request ([46,56] discussing support for multiple file uploads).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the virtualized server functionality of North and thus further separate the back-end storage functionality from the interface layer in order to ensure the users involved with the storage operations have all the desired options for where their files are actually stored (e.g., their own private storage, or one of a multiple of other well-known options such as cloud storage), ensuring the resultant disclosure can meet individual user preferences regarding cost, security, supported vendors, data retention, and other options well-known to be associated with data storage implementation decisions.
Regarding claim 2, the above combination further shows identifying, in the storage layer abstraction server, second credentials for the second (Lisiecki, [14,17]) data host (Thomas, col. 7 lines 25-42, col. 8 lines 45-48); generating a second unique identifier associated with the second (Lisiecki, [14,17]) file, the first user, and the second data host (Thomas, col. 5 lines 40-48); establishing a second connection to the second data host using the second credentials (Thomas, col. 5 lines 35-40, col. 6 lines 15-20);
sending, over the second connection, the second file to the second data host for storage at the second data host for the first user (Thomas, col. 5 lines 35-40, col. 7 lines 25-45); and providing the second unique identifier in response to the second request (Thomas, col. 5 lines 55-60).
Regarding claim 5, the above combination further shows wherein the first storage settings and the second storage settings comprise security settings (Thomas, col. 7 lines 25-31, col. 7 lines 35-41, discussing password requirements, along with controls on file distribution destinations and file retention/distribution windows).
Regarding claim 6, the above combination further shows wherein the second storage settings specify stricter security settings than the first storage settings (Thomas, col. 7 lines 24-45, discussing different combinations of storage settings, including use additional authentication/authorization requirements). Regarding claims 11 and 16, the limitations of said claims are addressed in the analysis of claim 1.
Regarding claims 12 and 17, the limitations of said claims are addressed in the analysis of claim 2.
Regarding claims 15 and 20, the limitations of said claims are addressed in the analysis of claim 5.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Thomas in view of Lisiecki and North, as applied to claim 1 above, further in view of Cha (US-8881257-B2).
Regarding claim 7, the above combination shows where the first connection is established using a first protocol (Lisiecki, suggesting FTP or HTTP [12,19,34]). The above combination does not show where a second connection is established using a second protocol, wherein the second protocol is a different protocol than the first protocol Cha shows where a second connection is established using a second protocol, wherein the second protocol is a different protocol than the first protocol (col. 12 lines 8-23).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the multi-protocol support of Cha in order to better support client’s varying capabilities, and thus support more types of clients.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Thomas in view of Lisiecki and North, as applied to claim 1 above, further in view of Sumarigo-MSFT (Sumarigo-MSFT. "Azure Storage Explorer reauthenticate error when accessing my tenant". https://learn.microsoft.com/en-us/answers/questions/1200663/azure-storage-explorer-reauthenticate-error-when-a. April. (Year: 2023)).
Regarding claim 8, the above combination shows receiving a third request for retrieval of the first file, wherein the third request includes the first unique identifier but does not include the first credentials (Thomas, col. 10 lines 32-56); establishing a third connection with the first data host (Thomas, col. 8 lines 41-47); receiving contents of the first file from the first data host (Thomas, col. 8 lines 22-41, col. 10 lines 52-56); and providing the contents of the first file in response to the third request (Thomas, col. 8 lines 22-41, col. 10 lines 52-56). The above combination does not show: identifying, in the storage layer abstraction server, the first credentials for the first data host. Sumarigo-MSFT shows identifying, in the storage layer abstraction server, the first credentials for the first data host (pg. 2).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the authentication persistence of Sumarigo-MSFT in order to simplify user interaction with the resultant system by avoiding repetitive steps after a user has been verified.
Claims 9 and 10 is rejected under 35 U.S.C. 103 as being unpatentable over Thomas in view of Lisiecki, North, and Sumarigo-MSFT, as applied to claim 8 above, further in view of Rusinov (US-20160323400-A1).
Regarding claim 9, the above combination shows claim 1. The above combination does not show wherein the third request is received from a data-owning user that provided the first request. Rusinov shows wherein the third request is received from a data-owning user that provided the first request ([60]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the above combination with the upload and retrieval techniques of Rusinov in order to better ensure user access to data, facilating additional storage services such as data backup.
Regarding claim 10, the above combination shows wherein the third request is received from a receiving user to which the data-owning user has shared the first file (Thomas, col. 8 lines 21-26, col. 8 lines 36-40, col. 10 lines 39-56).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN M MACILWINEN whose telephone number is (571)272-9686. The examiner can normally be reached Monday - Friday, 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, Glenton B Burgess can be reached at (571) 272 - 3949. 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.
JOHN MACILWINEN
Primary Examiner
Art Unit 2442
/JOHN M MACILWINEN/Primary Examiner, Art Unit 2454