CTFR 18/983,302 CTFR 77285 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-fti AIA The present application is being examined under the pre-AIA first to invent provisions. Response to Arguments The previous rejections have been withdrawn, in light of Applicant’s amendments and remarks. However, as of a result of further search/consideration new rejections under 35 USC §§101 and 103 have been set forth in order to address the newly amended claim language. Applicant's arguments and amendments, filed 3/10/2025, concerning the rejection of the claims under 35 USC §101 have been fully considered but they are not persuasive. Regarding the rejections of the claims under 35 USC §101 , Applicants argue on pages 7-9 that the newly amended claims are not abstract because they recite improvements in a technical field. Applicant further asserts an example involving the collection of network monitoring data. The Office respectfully disagrees. First , it is counter-asserted that these claims reflect the conventional use of generic computing components, not their improvement. Second , it is noted that the example asserted involves more than the transfer/storage of data, which is considered to reflect insignificant extra-solution activity or well-known, routine and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), " i. Receiving or transmitting data over a network , e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); … OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network);" and the court cases in MPEP 2106.05(d)(II), “iv. Storing and retrieving information in memory , Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93”. Therefore, the rejection of the claims under 35 USC §101 is believed to be reasonable. Claim Rejections – 35 U.S.C. § 101 07-04-01 AIA 07-04 35 U.S.C. § 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-19 and 21 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter. At step 1: Claim 1 is directed to a “method” and thus directed to a statutory category, and claim 11 is directed to a “system” claim thus directed to a statutory category. At step 2a prong 1: Claims 1 and 11 recite the limitations that are directed to an abstract idea, “ determining , for the plurality of data files, a single common prefix; for each respective corresponding data file of the plurality of data files: determining a respective filename for the respective corresponding data file by combining the single common prefix with the respective name of the corresponding data file; associating the respective corresponding data file with the respective filename” as drafted recites a mentally perforable process as one can as one can determine a directory name prefix from a filename in an absolute or relative path, for instance, by looking at the pathname string and recognizing delimiter characters (such as a “/”, for instance), and further associating/correlating names. At step 2a prong 2: Claim 1 recites the following additional elements: “client system” which is a high-level recitation of a generic computer components (hardware and/or software) and represent mere instructions to apply on a computer as in MPEP 2106.05(f), and which does not provide integration into a practical application. Claim 11 recites “memory”, “processing circuitry”, and “client system” which are a high-level recitations of generic computer components (hardware and/or software) and represent mere instructions to apply on a computer as in MPEP 2106.05(f), and which does not provide integration into a practical application. Next, claims 1 and 11 recite “ receiving , from a remote client system, a single storage request requesting storage of a single data object that includes a plurality of data files, each of the plurality of data files comprising a respective name; storing the respective corresponding data file with the filename in a storage bucket associated with the single common prefix; after storing each of the plurality of data files, receiving , from the remote client system, a single retrieval request comprising the single common prefix; and responsive to receiving the single retrieval request comprising the single common prefix, sending the plurality of data files to the remote client system.” The limitations reflect insignificant extra-solution activity as retrieval/receiving of data (i.e. mere data gathering) such as 'obtaining information' as identified in MPEP 2106.05(g) and does not provide integration into a practical application. Additionally, claims 1 and 11 recite “ storing …” and retrieving information in memory, (see also: Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93) as identified in MPEP 2106.05(g) which also reflects insignificant extra-solution activity and does not provide integration into a practical application. Viewing the additional limitations together and the claims as a whole, nothing provides integration into a practical application. At step 2b: the conclusions for the additional elements representing mere implementation using a computer are carried over and do not provide significantly more. With respect to the "receiving…", “”storing …”, “after storing receiving …” and “sending” limitations are identified as insignificant extra-solution activity above, and when re-evaluated this element is well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), "i. Receiving or transmitting data over a network , e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); … OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network);" and thus remains insignificant extra-solution activity that does not provide significantly more. Additionally , with respect to the “storing …” limitation identified as insignificant extra-solution activity above, and when re-evaluated this element is well-understood, routine, and conventional as evidenced by the court cases in MPEP 2106.05(d)(II), “iv. Storing and retrieving information in memory , Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93”. Therefore, the claims as a whole do not change this conclusion, and the claims are ineligible. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-fti The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action: (a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made. 07-23-fti The factual inquiries for establishing a background for determining obviousness under pre-AIA 35 U.S.C. 103(a) are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. 07-21 AIA Claim s 1, 3-11, 13-19 and 21 are rejected under 35 U.S.C. §103(a) as being unpatentable over Carmichael (US Patent Application No. 2012/0254269, hereafter referred to as “Carmichael”) in view of Yoshihisa Abe et al. (“pWalrus: Towards Better Integration of Parallel File Systems into Cloud Storage”, CLUSTERWKSP 2010 , Heraklion, Greece, September 20-24, 2010, 7 pages, hereafter referred to as “Abe”) and Hrishikesh Dewan et al. (“A Survey of Cloud Storage Facilities”, 2011 IEEE World Congress on Services , Washington, DC, July 4-9, 2011, pp. 224-231, hereafter referred to as “Dewan”) . Regarding independent claim 1 : Carmichael teaches A method comprising: receiving, from a remote client system, a storage request requesting storage …, each of the plurality of data files comprising a respective name; (See Carmichael Fig. 1 showing an exemplary computing environment. Also see Carmichael paragraphs 0062-0063 and 0076 discussing communications between client and storage systems. Also see paragraph 0088 discussing the replacing of objects via a write() operation, wherein the object corresponds to a file. Also see paragraph 0089, for example, showing a pathname including a directory string for the name of a filename object in a bucket.) determining, for the plurality of data files, a single common prefix; (See Carmichael paragraph 0088 discussing that a bucket and object correspond to a directory and a file [i.e., prefix and file/name]. See also, paragraph 0089 showing a pathname with a common directory prefix for the object/filename.) for each respective corresponding data file of the plurality of data files: determining a respective filename for the respective corresponding data file by combining the single common prefix with the respective name of the corresponding data file; (See Carmichael paragraph 0088 discussing that a bucket and object correspond to a directory and a file [i.e., prefix and file/name], it having been implied that in order to access data stored with such a pathname that one “determines” the meaning of the path string to be able to access the file data. See also, paragraph 0089 showing a pathname with a common directory prefix for the object/filename.) … and storing the respective corresponding data file with the filename in a storage bucket associated with the single common prefix; (See Carmichael paragraph 0088 discussing that a bucket and object correspond to a directory and file. See also paragraph 0087 discussing the use of pathnames [which represent a data storage identifier]. See also, paragraph 0089 showing a pathname with a common directory prefix for the object/filename.) and after storing each of the plurality of data files, receiving, from the remote client system, a single retrieval request comprising the single common prefix; (See Carmichael paragraphs 0089-0090 discussing the use of a “Get” command” to retrieve/access an object/file. See also, paragraph 0089 showing a pathname with a common directory prefix for the object/filename.) and responsive to receiving the single retrieval request comprising the single common prefix, sending the plurality of data files to the remote client system. (See Carmichael paragraphs 0089-0090 discussing the use of a “Get” command” to retrieve/access an object/file, it having been implied that if the “Get” command finds the data then it would return the data. See also, paragraphs 0062-0063 and 0076 discussing communications between client and storage systems. See also, paragraph 0089 showing a pathname with a common directory prefix for the object/filename.) However, Carmichael does not explicitly teach the remaining limitations as claimed. Abe, though, teaches associating the respective corresponding data file with the respective filename; (See Abe 2 nd page, section “ A. Amazon Simple Storage Service ”, 1 st bulleted paragraph teaching that users create buckets, which are containers for data , and store in them objects, which are the base unit of user data .) It would have been obvious to one of ordinary skill in the art at the time the invention was made to apply the teachings of Abe for the benefit of Carmichael, because to do so provided a designer with options for implementing a system that offers an Internet-based storage service with a simple set of functionalities that provides virtually unlimited storage space, as taught by Abe in the 1 st paragraph of the page 2 section entitled “A. Amazon Simple Storage Service”. These references were all applicable to the same field of endeavor, i.e., management of stored/archived data. Although Carmichael does teach a single storage request for a directory (see paragraph 0089, for example), Carmichael in view of Abe does not explicitly discuss the remaining limitations as claimed such as the use of a plurality of files in a common directory. Dewan, though, teaches … of a single data object that includes a plurality of data files, …; (See Dewan page 225, 1 st paragraph of section “ A. Amazon Simple Storage Service ” discussing that buckets are like directories, and each of them [i.e., buckets/directories] may have one or more objects.) It would have been obvious to one of ordinary skill in the art at the time the invention was made to apply the teachings of Dewan for the benefit of Carmichael in view of Abe, because to do so provided a designer with options to implement a system to flexibly access storage, as taught by Dewan in the last paragraph page 225. These references were all applicable to the same field of endeavor, i.e., management of stored/archived data. Regarding claim 3 : Carmichael in view of Abe does not explicitly teach the remaining limitations as claimed. Dewan, though, teaches wherein the method further comprises extracting the plurality of data files from the single data object. (See Dewan page 225, 1 st – 2 nd paragraphs of section “ A. Amazon Simple Storage Service ” indicating that buckets may have one or more objects/files, it having been implied that if one stored such data objects that one intended to access them.) Regarding claim 4 : Carmichael teaches wherein receiving the single storage request comprises receiving the storage request through an application programming interface . (See Carmichael paragraph 0067 discussing the use of REST/API to communicate with system servers. See also 0014 discussing the accessing of objects via “restful APIs”.) Regarding claim 5 : Carmichael in view of Abe does not explicitly teach the remaining limitations as claimed. Dewan, though, teaches wherein sending the plurality of data files to the remote client system comprises sending a single data object representing a single archive of the plurality of data files. (See Dewan page 225, 1 st – 2 nd paragraphs of section “ A. Amazon Simple Storage Service ” discussing that buckets cannot be nested, implying that a single bucket is accessed.) Regarding claim 6 : Carmichael does not explicitly teach the remaining limitations as claimed. Abe, though, teaches wherein determining the common prefix comprises determining the common prefix based on metadata of the plurality of data files. (See Carmichael paragraphs 0089-0090 discussing the use of a “Get” command” to retrieve/access an object/file, it having been implied that if the “Get” command finds the data then it would return the data. See also, paragraphs 0062-0063 and 0076 discussing communications between client and storage systems. See also Page 2 Figure 2 and page 4 Fig 3 showing the use of object metadata such as objectName separate from the bucket). Regarding claim 7 : Carmichael does not explicitly teach the remaining limitations as claimed. Abe, though, teaches wherein each of the plurality of data files is associated with a corresponding independent access control list. (See Abe 2 nd page, section “ A. Amazon Simple Storage Service ”, 4 th bulleted paragraph discussing that access control lists are associated with each bucket and object, in the context of 2 nd page, section “ A. Amazon Simple Storage Service ”, 1 st bulleted paragraph discussing that objects are the base unit of data. See also page 3 Figure 2, showing ACL metadata associated with objects.) Regarding claim 8 : Carmichael does not explicitly teach the remaining limitations as claimed. Abe, though, teaches wherein the method further comprises responsive to a single retrieval request, determining that a user associated with the remote client system is authorized to access each of the plurality of data files based on each of the corresponding access control lists. (See Abe 2 nd page, section “ A. Amazon Simple Storage Service ”, 4 th bulleted paragraph discussing that access control lists are associated with each bucket and object and that an ACL can specify types of access rights granted to individual users, in the context of 2 nd page, section “ A. Amazon Simple Storage Service ”, 1 st bulleted paragraph discussing that objects are the base unit of data. See also page 3 Figure 2, showing ACL metadata associated with objects.) Regarding claim 9 : Carmichael does not explicitly teach the remaining limitations as claimed. Abe, though, teaches wherein storing the respective corresponding data file comprises storing a respective corresponding access control list with the data file. (See Abe page 3 Figure 2 showing objects, i.e., files, that include ACL information.) Regarding claim 10 : Carmichael teaches wherein the single common prefix includes a path that identifies a particular directory . (See Carmichael paragraphs 0089-0090 discussing the use of a “Get” command” to retrieve/access an object/file having a particular pathname that includes a directory name, it having been implied that if the “Get” command finds the data then it would return the data. See also paragraph 0089 showing a pathname including particular directory names in a directory hierarchy.) Claims 11 and 13-19 are substantially similar to claims 1 and 3-9, respectively, and therefore likewise rejected. Regarding claim 21 : Carmichael teaches further comprising: receiving, from the remote client system and by a hosted storage system via an application program interface, the single storage request requesting storage of the single data object that includes the plurality of data files, wherein the application program interface is configured to only support a single data object per request . (See Carmichael paragraphs 0089-0090 discussing the use of a “Get” command” to retrieve/access an object/file having a particular pathname that includes a common directory name, it having been implied that if the “Get” command finds the data then it would return the data. See also paragraph 0089 showing a pathname including particular directory names in a directory hierarchy. See also paragraphs 0005, 0014 and 0113-0114 teaching the exemplary use of the REST API for accessing objects and the implementation of a bucket/object model. Also, see Carmichael paragraph 0067 discussing the use of REST/API to communicate with system servers, and paragraph 0014 discussing the accessing of objects via “restful APIs”.) 07-21 AIA Claim s 2 and 12 are rejected under 35 U.S.C. §103(a) as being unpatentable over Carmichael (US Patent Application No. 2012/0254269, hereafter referred to as “Carmichael”) in view of Yoshihisa Abe et al. (“pWalrus: Towards Better Integration of Parallel File Systems into Cloud Storage”, CLUSTERWKSP 2010 , Heraklion, Greece, September 20-24, 2010, 7 pages, hereafter referred to as “Abe”), Hrishikesh Dewan et al. (“A Survey of Cloud Storage Facilities”, 2011 IEEE World Congress on Services , Washington, DC, July 4-9, 2011, pp. 224-231, hereafter referred to as “Dewan”) and Prahlad et al. (US Patent Application No. 2010/0333116, hereafter referred to as “Prahlad ”) . Regarding claim 2 : Carmichael in view of Abe and Dewan does not explicitly teach the remaining limitations as claimed. Prahlad, though, teaches wherein the single data object is compressed. (See Prahlad paras 0066 and 0138, for example, discussing the well-known use of storage operations such as compression.) It would have been obvious to one of ordinary skill in the art at the time the invention was made to apply the teachings of Prahlad for the benefit of Carmichael in view of Abe and Dewan, because to do so provided a designer with options to implement a system for facilitating searching for stored data and options for standard compression techniques for that data, as taught by Prahlad in the Abstract and paragraph 0138. These references were all applicable to the same field of endeavor, i.e., management of stored/archived data. Claim 12 ius substantially similar to claim 2, and therefore likewise rejected . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Relevance is provided in at least the Abstract of each cited document . US Patent Application Publications Prahlad 2010/0333116 In some embodiments, storage management systems may perform additional operations upon copies, including deduplication, content indexing, data classification, data mining or searching, electronic discovery (E-discovery) management, collaborative searching, encryption and compression . (para 0012). In one example, storage operations may be performed according to various storage preferences, for example, as expressed by a user preference or a storage policy. A "storage policy" is generally a data structure or other information source that includes a set of preferences and other storage criteria associated with performing a storage operation . The preferences and storage criteria may include, but are not limited to, a storage location (or a class or quality of storage location), deduplication requirements, relationships between system components, network pathways to utilize in a storage operation, retention policies, data characteristics, compression or encryption requirements, preferred system components to utilize in a storage operation, the estimated or historic usage or cost associated with operating system components, frequency or use/access/etc. various time-related factors, single-instancing and/or deduplication information, and other criteria relating to a data storage or management operation. (para 0066). Some cloud storage site APIs may provide advanced functionality to manipulate files stored on a cloud storage site that extend beyond basic file system calls such as open, read, write. For example, cloud storage site APIs may provide commands for the encryption, compression and/or other advanced file operations. (para 0122). Further details about encryption and encrypting archive copies of data may be found in commonly assigned U.S. Patent Publication No. US2008-0320319A1, filed on Mar. 31, 2008, entitled SYSTEM AND METHOD FOR ENCRYPTING SECONDARY COPIES OF DATA (Attorney Docket No. 60692-8041US3). Additionally, although not shown, the system may compress the data before or after a secondary copy or archival copy is shown. For example, the system may employ many different well-known techniques or applications for compressing data , including Lempel-Ziv (LZ) techniques, DEFLATE techniques, and LZ-Renau (LZR) techniques. (para 0138) . 07-40 AIA 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 extension fee 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 date of this final action. Contact Information Any inquiry concerning this communication or earlier communications from the examiner should be directed to examiner ROBERT STEVENS whose telephone number is (571) 272-4102. The examiner can normally be reached Mon - Fri 6:00 - 2:30. 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, Amy Ng can be reached on (571) 270-1698. 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. /ROBERT STEVENS/Primary Examiner, Art Unit 2164 May 31, 2026 Application/Control Number: 18/983,302 Page 2 Art Unit: 2164 Application/Control Number: 18/983,302 Page 3 Art Unit: 2164 Application/Control Number: 18/983,302 Page 5 Art Unit: 2164 Application/Control Number: 18/983,302 Page 6 Art Unit: 2164 Application/Control Number: 18/983,302 Page 7 Art Unit: 2164 Application/Control Number: 18/983,302 Page 8 Art Unit: 2164 Application/Control Number: 18/983,302 Page 9 Art Unit: 2164 Application/Control Number: 18/983,302 Page 10 Art Unit: 2164 Application/Control Number: 18/983,302 Page 11 Art Unit: 2164 Application/Control Number: 18/983,302 Page 12 Art Unit: 2164 Application/Control Number: 18/983,302 Page 13 Art Unit: 2164 Application/Control Number: 18/983,302 Page 14 Art Unit: 2164 Application/Control Number: 18/983,302 Page 15 Art Unit: 2164 Application/Control Number: 18/983,302 Page 16 Art Unit: 2164
Prosecution Insights