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 .
This Office Action is in response to the application 18/994706 filed on 01/15/2025.
Claims 1-13, 16, 18, 19, and 21-24 have been examined and are pending in this application.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. PCT/US2023/027702, filed on 07/14/2023, which further claims the benefit of provisional application US 63/3 94,780, filed on 08/03/2022.
Information Disclosure Statement
The information disclosure statement (IDS), submitted on 01/15/2025, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claims 1, 10 and 19 are objected to because of the following informalities:
Regarding claims 1, 10, and 19 recite the limitation “the storage resources,” in line 9, line 10, and line 2, respectively. It’s suggested that said limitation be further amended to “the plurality of storage resources.” (emphasis added).
Regarding claim 19; claim 19 recites the limitations "the authentication service device authenticating ...," "the merge service device receiving ...," and "the merge service device further processing ... and providing ..." to properly recite embodiment and associate function performed by the claimed embodiment, it's suggested that the aforementioned limitations be further amended to "the authentication service device configured to authenticate ..." "the merge service device configured to receive ...," and "the merge service device further configured to process ... and provide ...," respectively. see Ex parte Kazuo Ezawa (Appeal 2010-006832) for details.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 1-13, 16, 18-19, and 21-24 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 2 recites the limitations "the values" in line 1, "the memory location" in line 3, and "the storage resource" in lines 2-3. There is insufficient antecedent basis for this limitation in the claim.
Claim 3 recites the limitations "the values in the pointer file," in line 2, and “the token values,” in line 3. There is insufficient antecedent basis for this limitation in the claim.
Claim 4 recites the limitations "a plurality of storage resources,” in line 3. There is insufficient antecedent basis for this limitation in the claim.
Claim 11 recites the limitations "the values" in line 1, "the memory location" in line 3, and "the storage resource" in lines 2-3. There is insufficient antecedent basis for this limitation in the claim.
Claim 12 recites the limitations "the values in the pointer file," in line 2, “the token values,” in line 3, and “the identified locations,” in line 4. There is insufficient antecedent basis for this limitation in the claim.
Claim 13 recites the limitations "a plurality of storage resources,” in line 3. There is insufficient antecedent basis for this limitation in the claim.
Claim 19 recites the limitations "the pointer file," in line 5, “the authentication service device,” in line 6, and “a pointer file,” in line 9. There is insufficient antecedent basis for this limitation in the claim.
Claim 21 recites the limitations "the authentication information," in line 1, and “the storage resources,” in line 2. There is insufficient antecedent basis for this limitation in the claim.
Claim 24 recites the limitations "a host map," in line 4-5. There is insufficient antecedent basis for this limitation in the claim.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as "configured to" or "so that"; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “customer service device that receives ...,” and “authentication service device authenticating ...,” recited in claim 19.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lewis (WO 2020/160136) in view of Steinberg et al. (“Steinberg,” US 2020/0143074).
Regarding claim 1: Lewis discloses a method comprising:
receiving a request from an owner of a source file to break the source file into a set of microshard data fragments and store the set of microshard data fragments (Lewis: page 5 lines 19-20 local or native data is received from a client; col. 7 lines 3-7 the source data splits each file into multiple segments [] each of the encrypted fragments are then [] is stored to any one of a plurality of cloud storage providers);
processing the source file to generate the set of microshard data fragments representing the source file and store the generated set of microshard data fragments in a plurality of storage resources (Lewis: col. 7 lines 20-22 a source data file is created, the source data file is split into fragments [] the fragments are distributed in multiple cloud storage providers);
generating authentication information linking the owner of the source file to the stored set of microshard data fragments (Lewis: col. 7 lines 21-26 an encryption key is created by the user; each fragment is encrypted using the encryption key [] the user is able to open the pointer file, enter the encryption key, and authenticate to the cloud storage providers);
generating a pointer file identifying the locations on the storage resources where each microshard data fragment from the set of microshard data fragments is stored (Lewis: col. 4 lines 1-2 creating a pointer file on a local computer, wherein the pointer file is configured to store a location of the one or more fragments).
Lewis is not explicitly disclose providing the pointer file to the owner of the source file without retaining a copy of the pointer file along with at least a portion of the authentication information allowing the owner to request future access to the generated set of microshard data fragments.
However, Steinberg discloses providing the pointer file to the owner of the source file without retaining a copy of the pointer file along with at least a portion of the authentication information allowing the owner to request future access to the generated set of microshard data fragments (Steinberg: par. 0010 manage a set of pointers as reassembly keys; par. 0030 running a software program or driver 302 or hardware that creates and manages a set of pointers to each of the microshard data fragments which enables splitting the original user "source data" (or content) into microshard data fragments and being able to reassemble microshard data fragments back to the original content. These pointers serve a function analogous to encryption/decryption keys, associate a set of pointers with a file name or other identifier).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Steinberg with the system/method of Lewis to include providing the pointer file to the owner with at least a portion of the authentication information allowing the owner to request future access to the generated set of microshard data fragments. One would have been motivated to providing ability for the user or data owner to set the microshard data fragment size allows for a balance between the desired level of security and system performance (Steinberg: par. 0026).
Regarding claim 2: Lewis in view of Steinberg discloses the method of claim 1.
Steinberg further discloses wherein the values in the pointer file include at least one of an electronic address for the storage resource, an electronic address for the memory location on the storage resource, and a provider of the storage resource (Steinberg: par. 0040 is needed for a pointer to identify the physical location of the file in which a microshard data fragment was written. With label substitution, the address of each remote host or storage resource).
The motivation is the same that of claim 1 above.
Regarding claim 3: Lewis in view of Steinberg discloses the method of claim 1.
Steinberg further discloses tokenizing at least a portion of the values in the pointer file (Steinberg: par. 0036 the remote host 402 of microshard data fragment number 401 may be defined by a token rather than an actual storage resource);
generating a mapping file identifying a relationship between the token values and the identified locations on the storage resources (Steinberg: par. 0036 mapping file or repository 500 that maps the tokens to actual storage resources. The tokens may represent [] the name or address of the physical system); and
storing the mapping file along with the authentication information in a host map file as part of an authentication service (Steinberg: par. 0036 if such a tokenization is used, then the mapping repository 500 [] is stored remotely from where the pointer repository 400 are persisted, and is used to combine with the pointers to identify the true location of the microshard data fragments).
The motivation is the same that of claim 1 above.
Regarding claim 4: Lewis in view of Steinberg discloses the method of claim 3.
Steinberg further discloses processing the host map file to generate a set of microshard data fragments representing the host map file and storing the generated set of microshard data fragments in a plurality of storage resources (Steinberg: par. 0036 FIG. 5 illustrates an example mapping file or repository 500 that maps the tokens to actual storage resources [] the mapping repository 500 [] is stored remotely from where the pointer repository 400 are persisted).
The motivation is the same that of claim 1 above.
Regarding claim 5: Lewis in view of Steinberg discloses the method of claim 1.
Lewis further discloses wherein the pointer file is stored at a site under the control of the owner (Lewis: col. 3 line 19 the pointer file is stored locally on a user's computer).
Regarding claim 6: Lewis in view of Steinberg discloses the method of claim 1.
Lewis further discloses wherein the portion of the authentication information includes at least one of an access key and a secret (Lewis: col. 7 lines 11-13 any computer or device that has possession of the pointer file, knows the encryption key, and has access to the cloud provider storage can retrieve each portion of the file from multiple cloud providers).
Regarding claim 7: Lewis in view of Steinberg discloses the method of claim 1.
Steinberg further discloses wherein each one of the set of microshard data fragments representing the source file has a maximum size that is less than the size of a data field in the source file (Steinberg: par. 0025 at least 5 characters (which may be captured in 5 bytes) of information [] would need to be intercepted in order to possibly reconstruct a valuable piece of information. Therefore [] a size of 4 characters (bytes) could be set as the maximum size of a microshard data fragment).
The motivation is the same that of claim 1 above.
Regarding claim 8: Lewis in view of Steinberg discloses the method of claim 1.
Lewis further discloses wherein the owner is at least one of a user, a customer, and a provider (Lewis: fig. 1, clients and cloud provider).
Regarding claim 9: Lewis in view of Steinberg discloses the method of claim 1.
Lewis further discloses wherein the owner can request retrieval and reassembly of the source file by providing proper access information and the pointer file (Lewis: col. 6 lines 16-20 the source computer or device maintains a lookup table and is able to reassemble the data [] the source computer or device can retrieve each portion of the file from multiple cloud providers, whereby the portions are re-assembled into the complete data file by using the lookup table).
Regarding claim 10: Lewis discloses an apparatus comprising:
a communication interface that receives a request from an owner of a source file to break the source file into a set of microshard data fragments and store the set of microshard fragments (Lewis: fig. 1; page 5 lines 19-20 local or native data is received from a client; col. 7 lines 3-7 the source data splits each file into multiple segments [] each of the encrypted fragments are then [] is stored to any one of a plurality of cloud storage providers); and
a processor coupled to the communication interface, the processor configured to process the source file to generate the set of microshard data fragments representing the source file and store the generated set of microshard data fragments in a plurality of storage resources (Lewis: fig. 1; col. 7 lines 20-22 a source data file is created, the source data file is split into fragments [] the fragments are distributed in multiple cloud storage providers), the processor further configured to access information linking the owner of the source file to the stored set of microshard data fragments (Lewis: col. 7 lines 21-26 an encryption key is created by the user; each fragment is encrypted using the encryption key [] the user is able to open the pointer file, enter the encryption key, and authenticate to the cloud storage providers) and generate a pointer file identifying the locations on the storage resources where each microshard data fragment from the set of microshard data fragments is stored (Lewis: col. 4 lines 1-2 creating a pointer file on a local computer, wherein the pointer file is configured to store a location of the one or more fragments);
wherein the pointer file is provided to the owner of the source file without retaining a copy of the pointer file along with authentication information allowing the owner to request future access to the generated set of microshard data fragments (Steinberg: par. 0010 manage a set of pointers as reassembly keys; par. 0030 running a software program or driver 302 or hardware that creates and manages a set of pointers to each of the microshard data fragments which enables splitting the original user "source data" (or content) into microshard data fragments and being able to reassemble microshard data fragments back to the original content. These pointers serve a function analogous to encryption/decryption keys, associate a set of pointers with a file name or other identifier).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Steinberg with the system/method of Lewis to include providing the pointer file to the owner with at least a portion of the authentication information allowing the owner to request future access to the generated set of microshard data fragments. One would have been motivated to providing ability for the user or data owner to set the microshard data fragment size allows for a balance between the desired level of security and system performance (Steinberg: par. 0026).
Regarding claims 11-13: Claims 11-13 are similar in scope to claims 2-4, respectively, and are therefore rejected under similar rationale.
Regarding claim 16: Claim 16 is similar in scope to claim 7, and is therefore rejected under similar rationale.
Regarding claim 18: Claim 18 is similar in scope to claim 9, and is therefore rejected under similar rationale.
Regarding claim 19: Lewis discloses a system comprising:
a plurality of storage resources, each of the storage resources storing a portion of a set of microshard shard data fragments representing a source file (Lewis: fig. 1; col. 7 lines 4-7 the source data splits each file into multiple segments [] each of the encrypted fragments are then distributed to multiple cloud properties whereby only a portion of the fragments of the source data file is stored to any one of a plurality of cloud storage providers);
a customer service device that receives access information from an owner of the source file (Lewis: fig. 1; page 8 lines 14-15 the source user shares the pointer file, encryption key, and access to the cloud properties), the pointer file linking storage locations to the set of microshard data fragments representing the source file (Lewis: col. 4 lines 1-2 creating a pointer file on a local computer, wherein the pointer file is configured to store a location of the one or more fragments), the authentication service device authenticating the access to the microshard data fragments by the owner (Lewis: col. 7 lines 21-26 an encryption key is created by the user; each fragment is encrypted using the encryption key [] the user is able to open the pointer file, enter the encryption key, and authenticate to the cloud storage providers); and
a merge service device that is coupled to the customer service device, the merge service device receiving a pointer file from the owner and retrieving the set of microshard data fragments from the plurality of storage resources based on information in the pointer file (Lewis: col. 8 lines 8-12 any computer or device that has possession of the pointer file, knows the encryption key, and has access to the cloud properties can retrieve each portion of the file from multiple cloud providers, whereby the portions are downloaded, decrypted using the user generated encryption key stored in the pointer file, and locally reassembled into the complete data file).
the merge service device further processing the set of microshard data fragments to reconstruct the source file and providing the reconstructed source file to the owner without retaining a copy of the pointer file (Steinberg: par. 0010 manage a set of pointers as reassembly keys; par. 0030 running a software program or driver 302 or hardware that creates and manages a set of pointers to each of the microshard data fragments which enables splitting the original user "source data" (or content) into microshard data fragments and being able to reassemble microshard data fragments back to the original content. These pointers serve a function analogous to encryption/decryption keys, associate a set of pointers with a file name or other identifier).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Steinberg with the system/method of Lewis to include providing the pointer file to the owner with at least a portion of the authentication information allowing the owner to request future access to the generated set of microshard data fragments. One would have been motivated to providing ability for the user or data owner to set the microshard data fragment size allows for a balance between the desired level of security and system performance (Steinberg: par. 0026).
Regarding claims 21-22: Claims 21-22 are similar in scope to claims 6-7, respectively, and are therefore rejected under similar rationale.
Regarding claim 23: The system of claim 19, wherein the merge service further receives a mapping file from the authentication service (Steinberg: par. 0033 pointer entries, defining where the microshard data fragments are stored, are created for each of the files 901, 902 and stored into a pointer repository), the mapping file providing a relationship between a set of token values in the pointer and a set of identifiers for the locations (Steinberg: par. 0036 mapping file or repository 500 that maps the tokens to actual storage resources. The tokens may represent [] the name or address of the physical system).
The motivation is the same that of claim 19 above.
Regarding claim 24: Lewis in view of Steinberg discloses the system of claim 19.
Steinberg further discloses wherein the merge service further receives a different pointer file associated a set of microshard data fragments representing a hostmap file from the owner, retrieves set of microshard data fragments representing a hostmap file from the plurality of storage resources based on information in the different pointer file, set of microshard data fragments representing a hostmap file to reconstruct the hostmap file prior to receiving the pointer file from the owner (Steinberg: fig. 9; par. 0033 source data may be broken into microshard data fragments and distributed across multiple storage resources. Example files 901 and 902 are broken into a plurality of 4 character (byte) microshard data fragments as illustrated by elements 905 and 906 [] the microshard data fragments are then stored across a plurality of remote storage resources 910, 911, 912. Pointer entries, defining where the microshard data fragments are stored, are created for each of the files 901, 902 and stored into a pointer repository).
The motivation is the same that of claim 19 above.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Fahimeh Mohammadi whose telephone number is (571)270-7857. 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, Luu Pham can be reached at 5712705002. 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.
/FAHIMEH MOHAMMADI/ Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights