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
Applicant has amended claims 1-2, 4, 6-8, 10, 12-14, 16, and 18 and added claims 19-20 in the filed amendment on 3/9/2026. Claims 1-20 are pending in this office action.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot in new ground of rejection.
Applicant argued that the prior arts of the record do not amended claims 1, 7, 13.
In response to Applicant’s argument, claims are rejected under the new ground.
In addition, Mehta teaches limitation
“receiving, from a build service, a query for information related to a dataset, the dataset being in……, for one or more builds that……” as receiving, from a client computing device e.g., client computing device 102, a request for a backup copy as information related to a file e.g., primary data 112 as dataset (figs. 1A, 1C, 10, paragraphs 4, 83-85, 339-341), the file e.g., primary data 112 as dataset is in native format (fig. 1C, paragraphs 78, 258) for new versions that are created and saved (fig. 6, paragraphs 307-312), each version as each build representing a file (paragraph 311). The client computing device that saves a file as a new version (paragraphs 311-312) is represented as a build service;
“providing, to the build service, first information related to a change in the dataset since ……of the dataset performed by the build service in a second format managed by the build service” as transmitting as providing, to the client computing device, a copy of the first file as first information (fig. 1A, paragraph 4), the copy of first file as the first information is related to a backup copy of the file e.g., the primary data 112 (figs. 1A, 5, paragraph 4), the backup copy is related the primary data 112 that includes change of an instance of an object or change of metadata over time as it is modified by application 110 (paragraphs 86, 92) since an instance of a data object in primary data 112 modified as performed by application 110 of client computing device (fig. 1A, paragraph 86), the instance of a data object in backup format as a second format is managed by the client computing device (paragraphs 4, 86);
In particularly:
Secondary storage computing devices 106 may index secondary copies 116 (e.g., using a media agent 144), enabling users to browse and restore at a later time and further enabling the lifecycle management of the indexed data. After creation of a secondary copy 116 that represents certain primary data 112, a pointer or other location indicia (e.g., a stub) may be placed in primary data 112, or be otherwise associated with primary data 112, to indicate the current location of a particular secondary copy 116. Since an instance of a data object or metadata in primary data 112 may change over time as it is modified by application 110 (or hosted service or the operating system), system 100 may create and manage multiple secondary copies 116 of a particular data object or metadata, each copy representing the state of the data object in primary data 112 at a particular point in time (paragraph 86).
To create a secondary copy 116 involving the copying of data from primary storage subsystem 117 to secondary storage subsystem 118, client computing device 102 may communicate the primary data 112 to be copied (or a processed version thereof generated by a data agent 142) to the designated secondary storage computing device 106, via a communication pathway 114 (paragraph 92).
The network-accessible backup agent 302 may also monitor files stored in a network-accessible folder that have been accessed by an application running on the client computing device 102 and implement procedures for storing saved versions of the accessed files (paragraph 288);
“the first information indicating” as a copy of the file e.g.., a secondary copy as the first information (figs. 1A-1C, paragraphs 4, 258- 259) representing as indicating a pointer or other location indicia (e.g., a stub) may be placed in primary data 112, or be otherwise associated with primary data 112, to indicate the current location of a particular secondary copy 116 (paragraph 86)
“transmitting, to the build service, a request for information regarding a new build ……” as sending, to the client computing device as the build service (paragraphs 311-312), instruction(s) as a request for data-agent-processed data as information regarding a new backup copy as a new build created based on a backup job (fig. 1E, paragraphs 242-243);
“receiving, from the build service, second information regarding the dataset related to the new build in the second format” as receiving, from the client computing device as the build service (paragraphs 311-312), data-agent-processed data as second information regarding to the primary data 112A or 112 B as the dataset related to new backup copy as the new build in backup format as in the second format (paragraphs 244-245, fig. 1E).
In particularly:
[0153] A backup operation creates a copy of a version of primary data 112 at a particular point in time (e.g., one or more files or other data units). Each subsequent backup copy 116 (which is a form of secondary copy 116) may be maintained independently of the first. A backup generally involves maintaining a version of the copied primary data 112 as well as backup copies 116. Further, a backup copy in some embodiments is generally stored in a form that is different from the native format, e.g., a backup format. This contrasts to the version in primary data 112 which may instead be stored in a format native to the source application(s) 110. In various cases, backup copies can be stored in a format in which the data is compressed, encrypted, deduplicated, and/or otherwise modified from the original native application format. For example, a backup copy may be stored in a compressed backup format that facilitates efficient long-term storage. Backup copies 116 can have relatively long retention periods as compared to primary data 112, which is generally highly changeable. Backup copies 116 may be stored on media with slower retrieval times than primary storage device 104. Some backup copies may have shorter retention periods than some other types of secondary copies 116, such as archive copies (described below). Backups may be stored at an offsite location.
“……in association with the new build” as including as storing, in index 153, information indicating where the backup copy as the new build resides on disk library 108A (paragraph 245, fig. 1E);
“wherein the method is performed by one or more processors” as the method is performed by a processor (paragraph 6).
Do teaches limitation
“a first format not managed by the build service” as an independent or common proprietary format as a first format cannot run by a hypervisor in target client device; thus a backup data in independent or common proprietary format as a first format is converted into a format that allow the hypervisor run on VM on target client device (fig. 3, paragraphs 324, 339), the target client device that create an incremental backup of the VM 302A data (paragraph 293) is represented as the build service.
For example, the media agent can convert the data backup of the VM into an independent or common proprietary format. Similarly, the media agent can convert the memory backup of the VM into an independent or common proprietary format. In some cases, the data backup of the VM can be converted into an independent format, whereas the memory backup of the VM can be converted into a different format (e.g., the common proprietary format), or vice-versa (paragraph 339);
“performed based on the first information” as an auxiliary copy as a new build generated as performed based on initial secondary copy as the first information (paragraph 179).
In particularly: [0179] An auxiliary copy is generally a copy of an existing secondary copy 116. For instance, an initial secondary copy 116 may be derived from primary data 112 or from data residing in secondary storage subsystem 118, whereas an auxiliary copy is generated from the initial secondary copy 116. Auxiliary copies provide additional standby copies of data and may reside on different secondary storage devices 108 than the initial secondary copies 116;
“storing the second information” as storing the second data in a secondary storage device (paragraph 340);
“perform one or more operations to transform the data of one or more input datasets into the data of one or more output datasets” as converting second data as input dataset into third data as output dataset for transmitting the third data to the target computing device (fig. 8, paragraph 342-343); or
transforming one or more primary data objects 133C, 122 and 129C in storage device 104 as one or more input datasets into one or more data objects 133C’, 122’ and 129C’ in device 108 (fig. 1B, paragraphs 90-91);
“in the first format” as a backup data in independent or common proprietary format as a first format is converted into a format that allow hypervisor run on VM on target client device (fig. 3, paragraphs 324, 339);
“a previous build” as a previous snapshot as previous build (paragraph 293).
In particularly:
At data flow step 3, the client 305A takes an incremental backup of the VM 302A data (e.g., a backup corresponding to the VM 302A data files that have changed since the first backup of the VM 302A data). In some embodiments, the client 305A takes one or more additional incremental backups of the VM 302A data. For example, the client 305A takes one or more snapshots of VM 302A data that has changed since the previous snapshot (paragraph 293).
At data flow step 6, the media agent 344 (e.g., the virtual machine replication engine 310) may convert the backup data (e.g., the VM 302A data backup and/or the VM 302A memory backup) from a format that corresponds with the hypervisor 327A into an independent format or common proprietary format (paragraph 302).
Do further teaches limitation
“since a previous build of the dataset performed by the build service in a second format managed by the build service” as since a previous build of data in a format as a second format (paragraph 302) performed by the client 305A as the build service (paragraph 239);
“a new build performed based on the first information” as an auxiliary copy as a new build generated as performed based on initial secondary copy as the first information (paragraph 179).
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, 3-7, 9-13, 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Mehta et al (or hereinafter “Mehta”) (US 20180285207) in view of DORNEMANN et al (or hereinafter “Do”) (US 20180143880) and Lerios et al (or hereinafter “Le”) (US 20140050419)
As to claim 1, Mehta teaches a method of handling a dataset for a build pipeline, comprising:
“receiving, from a build service, a query for information related to a dataset, the dataset being in……, for one or more builds that……” as receiving, from a client computing device e.g., client computing device 102, a request for a backup copy as information related to a file e.g., primary data 112 as dataset (figs. 1A, 1C, 10, paragraphs 4, 83-85, 339-341), the file e.g., primary data 112 as dataset is in native format (fig. 1C, paragraphs 78, 258) for new versions that are created and saved (fig. 6, paragraphs 307-312), each version as each build representing a file (paragraph 311). The client computing device that saves a file as a new version (paragraphs 311-312) is represented as a build service;
“providing, to the build service, first information related to a change in the dataset since ……of the dataset performed by the build service in a second format managed by the build service” as transmitting as providing, to the client computing device, a copy of the first file as first information (fig. 1A, paragraph 4), the copy of first file as the first information is related to a backup copy of the file e.g., the primary data 112 (figs. 1A, 5, paragraph 4), the backup copy is related the primary data 112 that includes change of an instance of an object or change of metadata over time as it is modified by application 110 (paragraphs 86, 92) since an instance of a data object in primary data 112 modified as performed by application 110 of client computing device (fig. 1A, paragraph 86), the instance of a data object in backup format as a second format is managed by the client computing device (paragraphs 4, 86);
In particularly:
Secondary storage computing devices 106 may index secondary copies 116 (e.g., using a media agent 144), enabling users to browse and restore at a later time and further enabling the lifecycle management of the indexed data. After creation of a secondary copy 116 that represents certain primary data 112, a pointer or other location indicia (e.g., a stub) may be placed in primary data 112, or be otherwise associated with primary data 112, to indicate the current location of a particular secondary copy 116. Since an instance of a data object or metadata in primary data 112 may change over time as it is modified by application 110 (or hosted service or the operating system), system 100 may create and manage multiple secondary copies 116 of a particular data object or metadata, each copy representing the state of the data object in primary data 112 at a particular point in time (paragraph 86).
To create a secondary copy 116 involving the copying of data from primary storage subsystem 117 to secondary storage subsystem 118, client computing device 102 may communicate the primary data 112 to be copied (or a processed version thereof generated by a data agent 142) to the designated secondary storage computing device 106, via a communication pathway 114 (paragraph 92).
The network-accessible backup agent 302 may also monitor files stored in a network-accessible folder that have been accessed by an application running on the client computing device 102 and implement procedures for storing saved versions of the accessed files (paragraph 288);
“the first information indicating” as a copy of the file e.g.., a secondary copy as the first information (figs. 1A-1C, paragraphs 4, 258- 259) representing as indicating a pointer or other location indicia (e.g., a stub) may be placed in primary data 112, or be otherwise associated with primary data 112, to indicate the current location of a particular secondary copy 116 (paragraph 86)
“transmitting, to the build service, a request for information regarding a new build ……” as sending, to the client computing device as the build service (paragraphs 311-312), instruction(s) as a request for data-agent-processed data as information regarding a new backup copy as a new build created based on a backup job (fig. 1E, paragraphs 242-243);
“receiving, from the build service, second information regarding the dataset related to the new build in the second format” as receiving, from the client computing device as the build service (paragraphs 311-312), data-agent-processed data as second information regarding to the primary data 112A or 112 B as the dataset related to new backup copy as the new build in backup format as in the second format (paragraphs 244-245, fig. 1E).
In particularly:
[0153] A backup operation creates a copy of a version of primary data 112 at a particular point in time (e.g., one or more files or other data units). Each subsequent backup copy 116 (which is a form of secondary copy 116) may be maintained independently of the first. A backup generally involves maintaining a version of the copied primary data 112 as well as backup copies 116. Further, a backup copy in some embodiments is generally stored in a form that is different from the native format, e.g., a backup format. This contrasts to the version in primary data 112 which may instead be stored in a format native to the source application(s) 110. In various cases, backup copies can be stored in a format in which the data is compressed, encrypted, deduplicated, and/or otherwise modified from the original native application format. For example, a backup copy may be stored in a compressed backup format that facilitates efficient long-term storage. Backup copies 116 can have relatively long retention periods as compared to primary data 112, which is generally highly changeable. Backup copies 116 may be stored on media with slower retrieval times than primary storage device 104. Some backup copies may have shorter retention periods than some other types of secondary copies 116, such as archive copies (described below). Backups may be stored at an offsite location.
“……in association with the new build” as including as storing, in index 153, information indicating where the backup copy as the new build resides on disk library 108A (paragraph 245, fig. 1E);
“wherein the method is performed by one or more processors” as the method is performed by a processor (paragraph 6).
Mehta does not explicitly teach limitations
a first format not managed by the build service;
perform one or more operations to transform the data of one or more input datasets into the data of one or more output datasets;
a previous build;
storing the second information;
performed based on the first information;
a version of transformation code used to run the previous build;
Do teaches limitation
“a first format not managed by the build service” as an independent or common proprietary format as a first format cannot run by a hypervisor in target client device; thus a backup data in independent or common proprietary format as a first format is converted into a format that allow the hypervisor run on VM on target client device (fig. 3, paragraphs 324, 339), the target client device that create an incremental backup of the VM 302A data (paragraph 293) is represented as the build service.
For example, the media agent can convert the data backup of the VM into an independent or common proprietary format. Similarly, the media agent can convert the memory backup of the VM into an independent or common proprietary format. In some cases, the data backup of the VM can be converted into an independent format, whereas the memory backup of the VM can be converted into a different format (e.g., the common proprietary format), or vice-versa (paragraph 339);
“perform one or more operations to transform the data of one or more input datasets into the data of one or more output datasets” as converting second data as input dataset into third data as output dataset of output datasets e.g., objects for transmitting the third data to the target computing device (fig. 8, paragraph 342-343); or
transforming one or more primary data objects 133C, 122 and 129C in storage device 104 as one or more input datasets into one or more data objects 133C’, 122’ and 129C’ in device 108 (fig. 1B, paragraphs 90-91);
“a previous build” as a previous snapshot as previous build (paragraph 293).
In particularly:
At data flow step 3, the client 305A takes an incremental backup of the VM 302A data (e.g., a backup corresponding to the VM 302A data files that have changed since the first backup of the VM 302A data). In some embodiments, the client 305A takes one or more additional incremental backups of the VM 302A data. For example, the client 305A takes one or more snapshots of VM 302A data that has changed since the previous snapshot (paragraph 293).
At data flow step 6, the media agent 344 (e.g., the virtual machine replication engine 310) may convert the backup data (e.g., the VM 302A data backup and/or the VM 302A memory backup) from a format that corresponds with the hypervisor 327A into an independent format or common proprietary format (paragraph 302);
“performed based on the first information” as an auxiliary copy as a new build generated as performed based on initial secondary copy as the first information (paragraph 179).
In particularly: [0179] An auxiliary copy is generally a copy of an existing secondary copy 116. For instance, an initial secondary copy 116 may be derived from primary data 112 or from data residing in secondary storage subsystem 118, whereas an auxiliary copy is generated from the initial secondary copy 116. Auxiliary copies provide additional standby copies of data and may reside on different secondary storage devices 108 than the initial secondary copies 116;
“storing the second information” as storing the second data in a secondary storage device (paragraph 340).
Do further teaches limitation
“since a previous build of the dataset performed by the build service in a second format managed by the build service” as since a previous build of data in a format as a second format (paragraph 302) performed by the client 305A as the build service (paragraph 239);
“a new build performed based on the first information” as an auxiliary copy as a new build generated as performed based on initial secondary copy as the first information (paragraph 179);
“receiving, from the build service, second information regarding the dataset related to the new build in the second format” as receiving, from the client device as the build service, data as second information based on the file related to new copy in a second format (paragraphs 91, 179, 232).
Do and Mehta teach a method retrieving data in a storage device based on a request to generate a dataset. These references are same field with application’s field. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Do’s teaching to Mehta’s system in order to reduce utilized storage capacity in the production system and/or in secondary storage, to facilitate organization and search of data, to improve user access to data files across multiple computing devices and/or hosted services for restoring data when data is corrupted.
Le teaches limitations
“a version of transformation code used to run the previous build” as a version of transformation identifier as transformation code used to execute a first image copy that is used to create an altered image copy is represented as the previous build (abstract, paragraphs 5-6, 73);
“perform one or more operations to transform the data of one or more input datasets into the data of one or more output datasets” as perform an operation to transform an image of images into an altered image of altered images (paragraphs 53-54).
Le and Mehta teach a method retrieving data in a storage device based on a request to generate a dataset. These references are same field with application’s field. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Le’s teaching to Mehta’s system in order to correctly facilitate applying, to dataset, transformations selected on a user device, to protect data from transmitting and/or accessing without permission, and further to limit an amount of data transmitted between the publishing client and the social networking system
As to claims 3, 9, 15, Mehta, Do and Le teach limitation
“the query including a dataset title” as the request includes (Mehta: paragraph 4) file name (Le: paragraph 55).
As to claims 4, 10,16, Mehta, Do and Le teach limitation
“wherein the transformation code is implemented using operations including at least one of map, filter, flatMap, or groupByKey” as the transformation identifier as the transformation code as the transformation code is executed using (Le: abstract, paragraph 9) operations including (Mehta: fig. 6, lines 307-310) mapping (Do: paragraph 165).
As to claims 5, 11,17, Mehta, Do and Le teach limitation
“the one or more processors further configured to perform” as a processor is associated with the memory and configured to perform (Mehta: paragraph 9) or
“the one or more sequences of instructions which, when executed, cause the one or more processors to further perform” as one or more program includes instructions to perform (Mehta: paragraph 9)
“converting one or more changes in the dataset from the first format to the second format” as converting, from a native format into a secondary copy format, (Mehta: paragraph 289) one or more changes files (Do: paragraph 155).
As to claims 6, 12, 18, Mehta, Do and Le teach limitation
“the second information indicating a version of transformation code used to run the new build” as the data-agent-processed data as second information regarding (Mehta: paragraphs 244-245, fig. 1E) a version of transformation identifier as transformation code used to apply to (Le: abstract, paragraph 9) new file as the new build (Do: paragraph 262).
Claim 7 recites same limitation subject matter as discussed in claim 1; thus claim 7 is rejected under the same reason as discussed in claim 1. In addition, Mehta teaches a system for handling a dataset for a build pipeline, comprising: a memory; one or more processors coupled to the memory and configured to perform: (as a memory and a processor is associated with the memory and configured to perform: paragraphs 7, 9).
Claim 13 recites same limitation subject matter as discussed in claim 1; thus claim 13 is rejected under the same reason as discussed in claim 1. In addition, Mehta teaches one or more non-transitory, computer-readable storage media storing one or more sequences of instructions which, when executed cause one or more processors to perform: (paragraphs 7, 9).
Claims 2, 8, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Mehta in view of Do and Le and further in view of Hille-Doering et al (or hereinafter “Hi”) (US 20120059842).
As to claims 2, 8, 14, Mehta, Do and Le each limitation
“wherein the transformation code includes……” as the transformation identifier as the transformation code includes version (Le: abstract, paragraphs 6, 9).
Mehta, Do and Le do not explicitly teach limitation
code for at least one of text search, logistic regression, alternating least squares, or interactive analytics
Hi teaches limitation
“code for at least one of text search, logistic regression, alternating least squares, or interactive analytics” as context-based module 128 as code can perform a full-text search of the back-end repository 184 (paragraph 34).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Hi’s teaching to Mehta’s system in order to
perform automatic searching in the background to provide suggestions to the user so that the user can continue entering data in the user interface without interruption.
Claims 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mehta in view of Do and Le and further in view of Block et al (US 20110282914).
As to claim 19, Mehta, Do and Le teach limitation
“wherein the one or more operations to transform the data includes……” as the one or more operations to (Meta: paragraphs 214-219) convert the data includes an replication operation (Do: paragraph 7; Le: abstract, paragraph 9).
Mehta, Do and Le do not teach limitation
a join operation.
Block teaches limitation
“a join operation” as operations to transform data includes join operation (paragraphs 16, 45, 56).
Block further teaches limitation “the one or more operations to transform the data includes a join operation” as operations to transform data includes join operation (paragraphs 16, 45, 56).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Block’s teaching to Mehta’s system in order to increase the speed and throughput of the data transfer and further to perform database operations on inputs from both the database and the application quickly.
As to claim 20, Mehta, Do, Le and Block teach limitation “wherein the join is performed using an SQL database system” as join is performed by a SQL database system (Block: paragraphs 16, 46, 56).
Claims 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mehta in view of Do and Le and further in view of Chen et al (US 20160063030).
As to claim 19, Mehta, Do and Le teach limitation
“wherein the one or more operations to transform the data includes……” as the one or more operations to (Meta: paragraphs 214-219) convert the data includes an replication operation (Do: paragraph 7; Le: abstract, paragraph 9).
Mehta, Do and Le do not teach limitation
a join operation.
Chen teaches limitation
“a join operation” as operations to transform data includes join operation (paragraphs 53-54).
Chen further teaches limitation “the one or more operations to transform the data includes a join operation” as operations to transform data includes join operation (paragraphs 53-54).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply Chen’s teaching to Mehta’s system in order to allow data to be transferred in parallel, increasing processing speed.
As to claim 20, Mehta, Do, Le and Chen teach limitation “wherein the join is performed using an SQL database system” as join is performed by a SQL database system (Chen: paragraphs 53-54).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure
Alatorre; Gabriel et al (US-20160364301)
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CAM-Y T TRUONG whose telephone number is (571)272-4042. The examiner can normally be reached (571) 272 4042.
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, SHERIEF BADAWI can be reached at (571) 272-9782. 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.
/CAM Y T TRUONG/ Primary Examiner, Art Unit 2169