Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of claims
This non-final office action on merits is in response to the Patent Application filed on 02/17/2026. Claims 1-20 are pending and considered below.
Claim Rejections - 35 USC § 101
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1
Under step 1, the analysis is based on MPEP 2106.03, and claims 1-14, 18-20 are drawn to computer-implemented method, claim 15-17 are drawn to surgical data management system. Thus, each claim, on its face, is directed to one of the statutory categories (i.e., useful process, machine, manufacture, or composition of matter) of 35 U.S.C. §101.
Step 2A Prong One
Claim 15 recites the limitations of modifying of the retention period for the first data stream based on: an aspect of the first data, a usefulness of the first data, a score of the first data, or a situational change of the source surgical system. These limitations, as drafted, are processes that, under their broadest reasonable interpretation, cover performance of the limitations in the mind or by using a pen and paper. Even when considering the “a processor; and a memory storing instructions that, when executed by the processor, cause the processor to perform operations” language, the claim encompasses a user evaluating characteristics of the data (aspects, usefulness, score, and situational conditions) and determining an appropriate retention period based on that evaluation in their mind or by using a pen and paper. The nominal recitation of a processor; and a memory storing instructions that, when executed by the processor, cause the processor to perform operations does not take the claim limitation out of the mental processes grouping. Thus, the claim recites a mental process which is an abstract idea.
Independent claim 1 and 18 recites identical or nearly identical steps with respect to claim 15 (and therefore also recite limitations that fall within this subject matter grouping of abstract ideas), and these claims are therefore determined to recite an abstract idea under the same analysis.
Under Step 2A Prong Two
The claimed limitations, as per claim 15, include:
a processor; and a memory storing instructions that, when executed by the processor, cause the processor to perform operations comprising:
receiving, at a destination surgical system from a source surgical system, and during a performance of a surgical procedure on a patient, a first data stream including first data collected during the performance of the surgical procedure, wherein the first data stream has associated first metadata, the first metadata includes an indication of a retention period for the first data stream, and the first data includes information regarding at least two of patient data, surgical procedure data, and surgical instrument data,
storing of the received first data stream at the destination surgical system, and
after the storing of the received first data stream, modifying of the retention period for the first data stream based on:
an aspect of the first data,
a usefulness of the first data,
a score of the first data, or
a situational change of the source surgical system.
Examiner Note: underlined elements indicate additional elements of the claimed invention identified as performing the steps of the claimed invention.
The judicial exception expressed in claim 15 is not integrated into a practical application. The claim as a whole merely describes how to generally “apply” the concept of evaluating information and adjusting a data retention period based on informational characteristics in a computer environment. The claimed computer components (i.e., a processor; and a memory storing instructions that, when executed by the processor, cause the processor to perform operations) are recited at a high level of generality and are merely invoked as tools to perform an existing process of evaluating data and deciding how long to keep it. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application.
The judicial exception expressed in claim 15 is not integrated into a practical application. The abstract idea is merely carried out in a technical environment or field (i.e., a surgical data management system operating during a surgical procedure), however fails to contain meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment (see MPEP 2106.05(h)). The additional elements that are carried out in a technical environment includes at a destination surgical system from a source surgical system, and during a performance of a surgical procedure on a patient; during the performance of the surgical procedure; the first data includes information regarding at least two of patient data, surgical procedure data, and surgical instrument data; and at the destination surgical system. Accordingly, alone and in combination, these additional elements do not integrate the abstract idea into a practical application.
The judicial exception expressed in claim 15 is not integrated into a practical application. The claim recites the additional element of receiving a first data stream including first data collected, wherein the first data stream has associated first metadata, the first metadata includes an indication of a retention period for the first data stream; storing of the received first data stream; and after the storing of the received first data stream. These limitations are recited at a high level of generality (i.e., as a general means of collecting data and storing the data for later use), and amount to merely data gathering and insignificant application, which are forms of insignificant extra-solution activities. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application. The claim is directed to an abstract idea.
Therefore, under step 2A, the claims are directed to the abstract idea, and require further analysis under Step 2B.
Under step 2B
Claim 15 does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A, the claim as a whole merely describes how to generally “apply” the concept of evaluating information and adjusting a data retention period based on informational characteristics in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e., an inventive concept) to the abstract idea.
Claim 15 does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A, the abstract idea is merely carried out in a technical environment or field, however fails to contain meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e., an inventive concept) to the abstract idea.
For claim 15, under step 2B, the additional elements of receiving a first data stream including first data collected, wherein the first data stream has associated first metadata, the first metadata includes an indication of a retention period for the first data stream; storing of the received first data stream; and after the storing of the received first data stream have been evaluated. The surgical data management system comprising at processor in communication performs a general function of receiving patient data for subsequent evaluation and determination of a retention period, which represents a well-understood, routine, and conventional activity in the field of data processing and information management systems. The specification discloses that the processor is used in its ordinary capacity as a data input device and does not describe any improvement to the computer itself or to the functioning of the overall computer system (see [0229]-[0232]). Also noted in Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016), merely collecting information for analysis without a technological improvement does not add significantly more to an abstract idea. The use of the surgical data management system is no more than collecting information before analyzing the data to modify a retention period and does not integrate the abstract idea into a practical application. Additionally, as noted in In re Brown, 645 Fed. App'x 1014, 1016-1017 (Fed. Cir. 2016), merely storing the data represents an insignificant application of the underlying mental process, as the storing is performed in a generic manner and does not impose any meaningful limitation or add any technological improvement. Therefore, the claim does not recite an inventive concept and is not patent eligible.
Claims 2-5, and 8 recite no further additional elements, and only further narrow the abstract idea. The previously identified additional elements, individually and as a combination, do not integrate the narrowed abstract idea into a practical application for reasons similar to those explained above, and do not amount to significantly more than the narrowed abstract idea for reasons similar to those explained above.
Claims 6-7, 9-14, 16-17, 19-20 recite the additional elements of by the destination surgical system (claim 6), of the source surgical system (claim 7), at the source surgical system (claim 9) at the destination surgical system (claim 10), of the destination surgical system (claim 11), the destination surgical system (claims 12, 16, and 19), the source surgical system (claims 12, 16, and 19), from a second source surgical system (claim 13), of a second source surgical system (claim 13) of the source and destination surgical systems (claims 14, 17, and 20).
However, these additional elements amount to implementing an abstract idea on a generic computing device. As such, these additional elements, when considered individually or in combination with the prior devices, do not integrate the abstract idea into a practical application or amount to significantly more than the abstract idea.
Thus, as the dependent claims remain directed to a judicial exception, and as the additional elements of the claims do not amount to significantly more, the dependent claims are not patent eligible.
Therefore, the claims here fail to contain any additional element(s) or combination of additional elements that can be considered as significantly more and the claims are rejected under 35 U.S.C. 101 for lacking eligible subject matter.
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, 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 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.
Claims 1-3, 5-7, 9-20 are rejected under 35 U.S.C. 103 as being unpatentable over Shelton et al. (U.S. Patent Publication 2019/0206563 A1), referred to hereinafter as Shelton, in view of Atherton et al. (U.S. Patent Publication 2021/0117124A1), referred to hereinafter as Atherton, and Twigg (U.S. Patent Publication 2010/0257312A1), referred to hereinafter as Twigg.
Regarding claim 1, Shelton teaches a computer-implemented method, comprising (Shelton [0283] “FIG. 8 illustrates a surgical data network 201 comprising a modular communication hub 203 configured to connect modular devices located in one or more operating theaters of a healthcare facility, or any room in a healthcare facility specially equipped for surgical operations, to a cloud-based system (e.g., the cloud 204 that may include a remote server 213 coupled to a storage device 205). In one aspect, the modular communication hub 203 comprises a network hub 207 and/or a network switch 209 in communication with a network router. The modular communication hub 203 also can be coupled to a local computer system 210 to provide local computer processing and data manipulation. The surgical data network 201 may be configured as passive, intelligent, or switching. A passive surgical data network serves as a conduit for the data, enabling it to go from one device (or segment) to another and to the cloud computing resources.”):
receiving, at a destination surgical system from a source surgical system, and during a performance of a surgical procedure on a patient, a first data stream including first data collected during the performance of the surgical procedure, wherein the first data stream has associated first metadata, the first metadata includes, and the first data includes information regarding at least two of patient data, surgical procedure data, and surgical instrument data (Shelton [0242] “Referring to FIG. 1, a computer-implemented interactive surgical system 100 includes one or more surgical systems 102 and a cloud-based system (e.g., the cloud 104 that may include a remote server 113 coupled to a storage device 105). Each surgical system 102 includes at least one surgical hub 106 in communication with the cloud 104 that may include a remote server 113. In one example, as illustrated in FIG. 1, the surgical system 102 includes a visualization system 108, a robotic system 110, and a handheld intelligent surgical instrument 112, which are configured to communicate with one another and/or the hub 106. In some aspects, a surgical system 102 may include an M number of hubs 106, an N number of visualization systems 108, an O number of robotic systems 110, and a P number of handheld intelligent surgical instruments 112, where M, N, O, and P are integers greater than or equal to one.” Shelton [0243] “FIG. 2 depicts an example of a surgical system 102 being used to perform a surgical procedure on a patient who is lying down on an operating table 114 in a surgical operating room 116. A robotic system 110 is used in the surgical procedure as a part of the surgical system 102. The robotic system 110 includes a surgeon's console 118, a patient side cart 120 (surgical robot), and a surgical robotic hub 122. The patient side cart 120 can manipulate at least one removably coupled surgical tool 117 through a minimally invasive incision in the body of the patient while the surgeon views the surgical site through the surgeon's console 118. An image of the surgical site can be obtained by a medical imaging device 124, which can be manipulated by the patient side cart 120 to orient the imaging device 124. The robotic hub 122 can be used to process the images of the surgical site for subsequent display to the surgeon through the surgeon's console 118.”, Shelton [0318] “Accordingly, the data collection and aggregation module 7022 can generate aggregated metadata or other organized data based on raw data received from the surgical hubs 7006. To this end, the processors 7008 can be operationally coupled to the hub applications 7014 and aggregated medical data databases 7011 for executing the data analytics modules 7034. The data collection and aggregation module 7022 may store the aggregated organized data into the aggregated medical data databases 2212.”, Shelton [0616] “Data can be received 206522 from at least one data source, and may include patient data 206532 from a patient monitoring device, surgical staff data 206534 from a surgical staff detection device, modular device data 206536 from one or more modular devices and/or hospital data 206538 from a hospital database, as illustrated in FIG. 42. The received 206522 data is processed by the surgical hub 5104 to determine a progress status of the surgical procedure.”, Shelton [0607] “The decisions made by the surgical system 200 can be implemented, for example, by a control circuit that includes the processor 244. The control circuit is configured to receive data 250952 from a data source. The received data can include, for example, data pertaining to the vital statistics of the patient, the medical history of the patient, the type of surgical procedure being performed, the type of surgical instrument being used, any data detected by a surgical instrument and/or surgical visualization system, etc.”.);
storing the received first data stream at the destination surgical system (Shelton [0616] “Data can be received 206522 from at least one data source, and may include patient data 206532 from a patient monitoring device, surgical staff data 206534 from a surgical staff detection device, modular device data 206536 from one or more modular devices and/or hospital data 206538 from a hospital database, as illustrated in FIG. 42. The received 206522 data is processed by the surgical hub 5104 to determine a progress status of the surgical procedure.”, Shelton [0607] “The decisions made by the surgical system 200 can be implemented, for example, by a control circuit that includes the processor 244. The control circuit is configured to receive data 250952 from a data source. The received data can include, for example, data pertaining to the vital statistics of the patient, the medical history of the patient, the type of surgical procedure being performed, the type of surgical instrument being used, any data detected by a surgical instrument and/or surgical visualization system, etc.”., Shelton [0318] “Accordingly, the data collection and aggregation module 7022 can generate aggregated metadata or other organized data based on raw data received from the surgical hubs 7006. To this end, the processors 7008 can be operationally coupled to the hub applications 7014 and aggregated medical data databases 7011 for executing the data analytics modules 7034. The data collection and aggregation module 7022 may store the aggregated organized data into the aggregated medical data databases 2212.”, Shelton [0313] “The hubs 7006 are also communicatively coupled to the cloud 7004 of the computer-implemented interactive surgical system via the network 7001. The cloud 7004 is a remote centralized source of hardware and software for storing, manipulating, and communicating data generated based on the operation of various surgical systems. As shown in FIG. 12, access to the cloud 7004 is achieved via the network 7001, which may be the Internet or some other suitable computer network. Surgical hubs 7006 that are coupled to the cloud 7004 can be considered the client side of the cloud computing system (i.e., cloud-based analytics system). Surgical instruments 7012 are paired with the surgical hubs 7006 for control and implementation of various surgical procedures or operations as described herein.”); and
after the storing of the received first data stream (Shelton [0318] “Accordingly, the data collection and aggregation module 7022 can generate aggregated metadata or other organized data based on raw data received from the surgical hubs 7006. To this end, the processors 7008 can be operationally coupled to the hub applications 7014 and aggregated medical data databases 7011 for executing the data analytics modules 7034. The data collection and aggregation module 7022 may store the aggregated organized data into the aggregated medical data databases 2212.”);
Shelton fails to explicitly teach an indication of a retention period for the first data stream; modifying the retention period for the first data stream based on: an aspect of the first data, a usefulness of the first data, a score of the first data, or a situational change of the source surgical system.
Atherton teaches an indication of a retention period for the first data stream (Atherton [0030] “Storage retention periods are assigned 605 to the data, such as by using timestamps on respective computer readable data marked in respective computer readable data storage locations, for example. A time stamp may mark a timeframe for which its associated data is retained by a file system. For example, when the retention period expires, an ILG process of a computer system may automatically mark the data for deletion. Once data is marked for deletion, the ILG process typically deletes the data automatically, i.e., without human intervention, although deletion may sometimes be placed on hold for some reason, in which case the ILG process may eventually delete the data responsive to human intervention.”); and
modifying the retention period for the first data stream (Atherton [0034] “Referring now to FIG. 4, a policy table 305 for repositories A, B and C is illustrated in more detail, wherein policies specified in policy table 305 are based on geolocations of the repositories. Table 305 includes data retention policy entries and data transfer limitation policy entries for each of repositories A, B and C. One data retention entry 401 specifies a seven-year retention for data stored in repository A, another data retention entry 402 specifies a ten-year retention for data in repository B, and a third data retention entry 403 specifies a seven-year retention for data in repository C. One data transfer limitation policy entry 411 specifies that data may be transferred from repository A to repository B. Another data transfer limitation policy entry 412 specifies that data may be transferred from repository A to repository C. Another data transfer limitation policy entry 413 specifies that data may be transferred from repository B to repository A. Another data transfer limitation policy entry 414 specifies that data may be transferred from repository B to repository C. Another data transfer limitation policy entry 415 specifies that data may NOT be transferred from repository C to any other repository.”, and Atherton [0055] “More generally, a user may record a change policy entry in policy table 305 for particular data that indicates the effect that a change in location of the data has on retention of the data. According to embodiments of the present invention, the user may enter a “change,” “maintain,” or “maximum” change policy, for example. According to the “change” policy, the ILG process changes retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process changes the retention period for the data from the retention period for the first geolocation to whatever retention period applies for data stored in the second geolocation. According to the “maximum” policy, the ILG process assigns the longest retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process assigns the retention period for the data according to the longest of the retention period for the first geolocation and the retention period that ordinarily applies for data stored in the second geolocation.”).
Twigg teaches based on: an aspect of the first data, a usefulness of the first data, a score of the first data, or a situational change of the source surgical system (Twigg [0014] “The invention may be expressed in terms of a number of aspects embodying some or all of the above features. For example, viewed one aspect the invention provides a method of storing data on a plurality of physical data storage drives, each of which has a data storage component and can be switched between an operative state in which there is relatively high energy usage, and an inoperative state in which there is relatively low energy usage; wherein an active volume containing data which is currently active is stored across a plurality of drives being a first number of drives in an active set of the plurality of drives which are normally maintained in the operative state; when a volume is identified as containing only data which has become inactive, that inactive volume is transferred from the active set of drives and stored across a plurality of drives being a second number of drives within an inactive set of the plurality of drives which are normally maintained in the inoperative state; when there is a subsequent read or write request in respect of an inactive volume stored within the inactive set of drives, the inactive volume is transferred from the inactive set of drives to the drives in the active set of drives and becomes an active volume; and wherein the data storage layouts for the active set of drives and the inactive set of drives are different, and the data storage layout for the inactive drives includes a plurality of regions at predetermined different levels of increasing data storage capacity and is such that (a) when an inactive volume is transferred in its entirety to the inactive set of drives it is allocated to the smallest capacity region that will accommodate the data of the volume; and (b) when additional data only is to be added to a volume on the inactive set of drives the additional data is firstly placed in the current highest capacity region containing data for that volume until that current highest capacity region is full; and if there is remaining data to be added to the volume that remaining data is placed in the lowest capacity region that (i) will accommodate that remaining data and (ii) is of the same capacity as, or a higher capacity than, the currently highest capacity region.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to combine the teachings of Shelton with Atherton and Twigg to arrive at the claimed method. Shelton teaches a computer implemented surgical data network in which data is received from multiple sources during the performance of a surgical procedure, including patient monitoring devices, surgical instruments, and hospital systems, and communicated between surgical hubs and cloud systems. Shelton further teaches aggregating, processing, and storing such data, including generating metadata and storing organized data in databases for further analysis. Accordingly, Shelton teaches receiving, during a surgical procedure, a data stream including patient, surgical procedure, and instrument data, and storing the received data at a destination surgical system. Atherton teaches associating data with retention periods using metadata (timestamps) and managing the lifecycle of the data based on those retention periods. Atherton further teaches modifying retention periods dynamically based on changes in conditions, such as changes in storage location or policy criteria, which corresponds to modifying retention based on a “situational change.” Additionally, Twigg teaches differentiating data handling based on whether data is active or inactive, where inactive data is treated differently and stored in alternative configurations, which reflects modification of data handling based on usefulness or relevance of the data.
A person of ordinary skill in the art would have been motivated to combine Atherton’s data retention and lifecycle management techniques and Twigg’s usefulness data handling with Shelton’s surgical data system to improve data storage efficiency, optimize resource utilization, and ensure appropriate retention and deletion of large volumes of surgical data. This combination represents a predictable use of prior art elements according to their established functions, applying known data management policies to a known surgical data processing system, and would have resulted in modifying retention periods based on data characteristics, usefulness, or situational conditions as claimed.
Regarding claim 2, Shelton, Atherton, and Twigg teach the invention in claim 1, as discussed above, and further teach wherein the retention period is modified based on the aspect of the first data; and the aspect of the first data includes one of a current value of the first data, a predicted future value of the data, a taxonomy of the first data, an age of the first data, and a change in a relationship of the patient with the patient’s health care provider (Atherton [0067] “Data may be tagged with more than one location or jurisdiction, according to embodiments of the present invention. For example, if the data provides financial statements for colleges in the United States that must be generated to satisfy a requirement under the federal law of the United States and the federal law imposes a retention requirement for these statements, then the user may indicate “USA” as the geolocation and “USA federal” as the jurisdiction, even if the data is uploaded from an accountant's office located outside the United States. In addition, the ILG process also automatically associates the geolocation from which the data is uploaded in this example. Alternatively, or in addition, if a regulation of the U.S. Department of Commerce and another regulation of the U.S. Department of Education govern retention, the user may indicate “USA” as the geolocation and more specifically indicate “U.S. Department of Commerce” and “U.S. Department of Education” as governing jurisdictions. In a further alternative, the user may indicate specific provisions of the regulations of the U.S. Department of Commerce and specific provisions of the regulations of the U.S. Department of Education as governing jurisdictions. Also, assuming the data is a single file and there is a state law in one or more of the US states that also governs retention of college financial statements for colleges in that state, for example, then the user may also indicate each such state as a geolocation for association with the file and the jurisdiction(s) of each such state as associated jurisdiction(s).After initially archiving data, the ILG process writes a record in audit table 306 automatically in response to any access to the data, which may include a download, moving the data into another storage location, checking out the data, modifying the data, etc., wherein the record includes identification of the user who accessed the data, the user's Internet protocol address (i.e., IP address from which the user accessed the data), and reason for accessing. Historical governance parameter and data category tags for each particular data item are maintained in audit table 306 for the data even upon changes in governance and category, since current governance for the data may depend on past categories of the data. The tags are time stamped so that the ILG process may determine current governance parameters for the data based the data current and past states.” ).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the system of Shelton to adjust the retention period based on an aspect of the data (taxonomy). While Shelton teaches receiving, processing, and storing surgical data with associated metadata, it does not explicitly disclose modifying retention based on specific data attributes. Atherton teaches associating data with categorical and governance tags, such as jurisdictional and regulatory classifications, and maintaining such taxonomy over time to determine applicable retention parameters. Thus, Atherton teaches modifying data retention based on an aspect of the data, specifically the taxonomy or categorization of the data. A person of ordinary skill in the art would have been motivated to incorporate Atherton’s taxonomy retention framework into Shelton’s system in order to enable more context aware data management, which improve retention control and compliance, which represents a predictable use of prior art elements according to their established functions.
Regarding claim 3, Shelton, Atherton, and Twigg teach the invention in claim 1, as discussed above, and further teach wherein the retention period is modified based on the aspect of the first data; and the aspect of the first data includes a current value of the first data and a predicted future value of the data (Shelton [0594] “As described above, upon receiving an input, or data, from the data source, the processor 244 of the surgical hub 206 analyzes the received data against a stored set of data. Such analysis is performed with the goal of optimizing an outcome of a surgical procedure. In various instances, the processor 244 analyzes the received data against a stored set of data using one or more trained machine learning techniques. In supervised learning, the processor 244 predicts a parameter as accurately as possible when given new examples where the inputs and outputs are unknown.”, and Shelton [0595] “Primary techniques in trained machine learning include, for example, parametric learning and non-parametric learning. Regression, classification, and vector clustering are the two tasks involved in parametric learning. Regression predicts a continuous target variable, thereby allowing the processor 244 to estimate a value based on received input data. Continuous variables, such as, for example, a patient's height, weight, emphysema air leak rate, etc., means there are not discontinuities in the value that the predicted parameter can have. Discrete variables, on the other hand, can only take on a finite number of values—for example, the color of a staple cartridge within an end effector.” and
Atherton [0055] “More generally, a user may record a change policy entry in policy table 305 for particular data that indicates the effect that a change in location of the data has on retention of the data. According to embodiments of the present invention, the user may enter a “change,” “maintain,” or “maximum” change policy, for example. According to the “change” policy, the ILG process changes retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process changes the retention period for the data from the retention period for the first geolocation to whatever retention period applies for data stored in the second geolocation. According to the “maximum” policy, the ILG process assigns the longest retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process assigns the retention period for the data according to the longest of the retention period for the first geolocation and the retention period that ordinarily applies for data stored in the second geolocation.”, and Atherton [0030] “Storage retention periods are assigned 605 to the data, such as by using timestamps on respective computer readable data marked in respective computer readable data storage locations, for example. A time stamp may mark a timeframe for which its associated data is retained by a file system. For example, when the retention period expires, an ILG process of a computer system may automatically mark the data for deletion. Once data is marked for deletion, the ILG process typically deletes the data automatically, i.e., without human intervention, although deletion may sometimes be placed on hold for some reason, in which case the ILG process may eventually delete the data responsive to human intervention.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the retention period of data based on an aspect of the data, including a predicted future value, by combining the teachings of Shelton and Atherton. Shelton teaches analyzing received data using machine learning techniques, including regression and other predictive models, to estimate or predict parameters based on input data. This predictive analysis reflects an evaluation of the data’s significance in determining future outcomes, which correspond to a “predicted future value” of the data under a broadest reasonable interpretation. Atherton teaches assigning retention periods to data and further modifying those retention periods in response to changes in conditions affecting the data, such as changes in storage location or associated policies. A person of ordinary skill in the art would have been motivated to incorporate Shelton’s predictive data analysis into Atherton’s retention management framework in order to dynamically adjust retention periods based on analytically derived characteristics of the data, such as its relevance to predicted outcomes, which improve data lifecycle management, storage efficiency, and regulatory compliance. This combination represents a predictable use of prior art elements according to their established functions and would have yielded the claimed feature of modifying a retention period based on an aspect of the data, which includes a predicted future value.
Regarding claim 5, Shelton, Atherton, and Twigg teach the invention in claim 1, as discussed above, and further teach wherein the retention period is modified based on the aspect of the first data; and the aspect of the first data includes a taxonomy of the first data (Atherton [0067] “Data may be tagged with more than one location or jurisdiction, according to embodiments of the present invention. For example, if the data provides financial statements for colleges in the United States that must be generated to satisfy a requirement under the federal law of the United States and the federal law imposes a retention requirement for these statements, then the user may indicate “USA” as the geolocation and “USA federal” as the jurisdiction, even if the data is uploaded from an accountant's office located outside the United States. In addition, the ILG process also automatically associates the geolocation from which the data is uploaded in this example. Alternatively, or in addition, if a regulation of the U.S. Department of Commerce and another regulation of the U.S. Department of Education govern retention, the user may indicate “USA” as the geolocation and more specifically indicate “U.S. Department of Commerce” and “U.S. Department of Education” as governing jurisdictions. In a further alternative, the user may indicate specific provisions of the regulations of the U.S. Department of Commerce and specific provisions of the regulations of the U.S. Department of Education as governing jurisdictions. Also, assuming the data is a single file and there is a state law in one or more of the US states that also governs retention of college financial statements for colleges in that state, for example, then the user may also indicate each such state as a geolocation for association with the file and the jurisdiction(s) of each such state as associated jurisdiction(s).After initially archiving data, the ILG process writes a record in audit table 306 automatically in response to any access to the data, which may include a download, moving the data into another storage location, checking out the data, modifying the data, etc., wherein the record includes identification of the user who accessed the data, the user's Internet protocol address (i.e., IP address from which the user accessed the data), and reason for accessing. Historical governance parameter and data category tags for each particular data item are maintained in audit table 306 for the data even upon changes in governance and category, since current governance for the data may depend on past categories of the data. The tags are time stamped so that the ILG process may determine current governance parameters for the data based the data current and past states.” ).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the system of Shelton to adjust the retention period based on an aspect of the data, such as taxonomy. While Shelton teaches receiving, processing, and storing surgical data with associated metadata, it does not explicitly disclose modifying retention based on specific data attributes. Atherton teaches associating data with categorical and governance tags, such as jurisdictional and regulatory classifications, and maintaining such taxonomy over time to determine applicable retention parameters. Therefore, Atherton teaches modifying data retention based on an aspect of the data, specifically the taxonomy or categorization of the data. A person of ordinary skill in the art would have been motivated to incorporate Atherton’s taxonomy retention framework into Shelton’s system in order to enable more context aware data management, which improves retention control and compliance, which represents a predictable use of prior art elements according to their established functions.
Regarding claim 6, Shelton, Atherton, and Twigg teach the invention in claim 1, as discussed above, and further teach wherein the retention period is modified based on the usefulness of the first data; and the usefulness of the first data includes one of: a frequency of use of the first data by the destination surgical system, and relevance of the first data to patient outcome following the performance of the surgical procedure (Shelton [0616] “Data can be received 206522 from at least one data source, and may include patient data 206532 from a patient monitoring device, surgical staff data 206534 from a surgical staff detection device, modular device data 206536 from one or more modular devices and/or hospital data 206538 from a hospital database, as illustrated in FIG. 42. The received 206522 data is processed by the surgical hub 5104 to determine a progress status of the surgical procedure.”, and
Atherton [0034] “Referring now to FIG. 4, a policy table 305 for repositories A, B and C is illustrated in more detail, wherein policies specified in policy table 305 are based on geolocations of the repositories. Table 305 includes data retention policy entries and data transfer limitation policy entries for each of repositories A, B and C. One data retention entry 401 specifies a seven-year retention for data stored in repository A, another data retention entry 402 specifies a ten-year retention for data in repository B, and a third data retention entry 403 specifies a seven-year retention for data in repository C. One data transfer limitation policy entry 411 specifies that data may be transferred from repository A to repository B. Another data transfer limitation policy entry 412 specifies that data may be transferred from repository A to repository C. Another data transfer limitation policy entry 413 specifies that data may be transferred from repository B to repository A. Another data transfer limitation policy entry 414 specifies that data may be transferred from repository B to repository C. Another data transfer limitation policy entry 415 specifies that data may NOT be transferred from repository C to any other repository.”, and Atherton [0055] “More generally, a user may record a change policy entry in policy table 305 for particular data that indicates the effect that a change in location of the data has on retention of the data. According to embodiments of the present invention, the user may enter a “change,” “maintain,” or “maximum” change policy, for example. According to the “change” policy, the ILG process changes retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process changes the retention period for the data from the retention period for the first geolocation to whatever retention period applies for data stored in the second geolocation. According to the “maximum” policy, the ILG process assigns the longest retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process assigns the retention period for the data according to the longest of the retention period for the first geolocation and the retention period that ordinarily applies for data stored in the second geolocation.”, and
Twigg [0014] “The invention may be expressed in terms of a number of aspects embodying some or all of the above features. For example, viewed one aspect the invention provides a method of storing data on a plurality of physical data storage drives, each of which has a data storage component and can be switched between an operative state in which there is relatively high energy usage, and an inoperative state in which there is relatively low energy usage; wherein an active volume containing data which is currently active is stored across a plurality of drives being a first number of drives in an active set of the plurality of drives which are normally maintained in the operative state; when a volume is identified as containing only data which has become inactive, that inactive volume is transferred from the active set of drives and stored across a plurality of drives being a second number of drives within an inactive set of the plurality of drives which are normally maintained in the inoperative state; when there is a subsequent read or write request in respect of an inactive volume stored within the inactive set of drives, the inactive volume is transferred from the inactive set of drives to the drives in the active set of drives and becomes an active volume; and wherein the data storage layouts for the active set of drives and the inactive set of drives are different, and the data storage layout for the inactive drives includes a plurality of regions at predetermined different levels of increasing data storage capacity and is such that (a) when an inactive volume is transferred in its entirety to the inactive set of drives it is allocated to the smallest capacity region that will accommodate the data of the volume; and (b) when additional data only is to be added to a volume on the inactive set of drives the additional data is firstly placed in the current highest capacity region containing data for that volume until that current highest capacity region is full; and if there is remaining data to be added to the volume that remaining data is placed in the lowest capacity region that (i) will accommodate that remaining data and (ii) is of the same capacity as, or a higher capacity than, the currently highest capacity region.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the system of Shelton, in view of Atherton and Twigg, to adjust the retention period based on the usefulness of the data, including frequency of use. Shelton teaches receiving and processing surgical data from multiple sources during a surgical procedure, but does not disclose modifying retention based on usefulness. Atherton teaches assigning and modifying data retention periods using policy frameworks tied to data management considerations. Twigg teaches differentiating data handling based on whether data is active or inactive, where active data corresponds to frequently accessed or useful data and inactive data corresponds to less frequently used data, which teaches modification of data handling based on frequency of use, which is an indicator of usefulness. A person of ordinary skill in the art would have been motivated to incorporate Twigg’s usefulness data management techniques into Shelton’s surgical data system, in combination with Atherton’s retention framework, in order to optimize storage efficiency, prioritize retention of frequently used or relevant data, and improve overall data lifecycle management, which represents a predictable use of prior art elements according to their established functions.
Regarding claim 7, Shelton, Atherton, and Twigg teach the invention in claim 1, as discussed above, and further teach wherein the retention period is modified based on the situational change of the source surgical system; and the situational change includes one of: a recall of the source surgical system, a health hazard evaluation of the source surgical system, a failure rate of the source surgical system, and a failure severity of the source surgical system (Atherton [0030] “Storage retention periods are assigned 605 to the data, such as by using timestamps on respective computer readable data marked in respective computer readable data storage locations, for example. A time stamp may mark a timeframe for which its associated data is retained by a file system. For example, when the retention period expires, an ILG process of a computer system may automatically mark the data for deletion. Once data is marked for deletion, the ILG process typically deletes the data automatically, i.e., without human intervention, although deletion may sometimes be placed on hold for some reason, in which case the ILG process may eventually delete the data responsive to human intervention.”, Atherton [0034] “Referring now to FIG. 4, a policy table 305 for repositories A, B and C is illustrated in more detail, wherein policies specified in policy table 305 are based on geolocations of the repositories. Table 305 includes data retention policy entries and data transfer limitation policy entries for each of repositories A, B and C. One data retention entry 401 specifies a seven-year retention for data stored in repository A, another data retention entry 402 specifies a ten-year retention for data in repository B, and a third data retention entry 403 specifies a seven-year retention for data in repository C. One data transfer limitation policy entry 411 specifies that data may be transferred from repository A to repository B. Another data transfer limitation policy entry 412 specifies that data may be transferred from repository A to repository C. Another data transfer limitation policy entry 413 specifies that data may be transferred from repository B to repository A. Another data transfer limitation policy entry 414 specifies that data may be transferred from repository B to repository C. Another data transfer limitation policy entry 415 specifies that data may NOT be transferred from repository C to any other repository.”, and Atherton [0055] “More generally, a user may record a change policy entry in policy table 305 for particular data that indicates the effect that a change in location of the data has on retention of the data. According to embodiments of the present invention, the user may enter a “change,” “maintain,” or “maximum” change policy, for example. According to the “change” policy, the ILG process changes retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process changes the retention period for the data from the retention period for the first geolocation to whatever retention period applies for data stored in the second geolocation. According to the “maximum” policy, the ILG process assigns the longest retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process assigns the retention period for the data according to the longest of the retention period for the first geolocation and the retention period that ordinarily applies for data stored in the second geolocation.”, and
Shelton [0686] “In one aspect, a control program can limit control-program learning adjustments. For example, in a qualified aggregation an event or behavior could have to pass a check to determine if it is going to be allowed to affect long term behavior of a particular surgical instrument 208100, or a class of surgical instrument 208100, for example. A control program executed by a surgical instrument 208100, or a surgical hub (e.g. 102, 202), may factor out individualized or one-time failures (e.g., a damaged or mis-inserted cartridge due to a non-repeatable error) that have a minimal effect on the behavior of the control program. In other words, the data associated with the individualized error may or may not be transmitted to a surgical hub (e.g. 102, 202) and/or main database depending on the nature of the individualized error. Even, however, if it is transferred, the individualized error could be excluded from the aggregated database used to affect long term behavior of the surgical instrument 208100 as a means to prevent or detect future flaws of the surgical instrument 208100.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the data retention period based on situational changes of a system, including failure conditions, by combining the teachings of Atherton and Shelton. Atherton teaches assigning retention periods to data and modifying those retention periods based on detected changes in conditions, such as changes in storage location or policy constraints. This establishes a framework in which data retention is dynamically adjusted in response to system conditions. Shelton teaches that surgical systems evaluate operational events, including distinguishing between isolated and repeatable failures and assessing whether such failures should influence long-term system behavior, which implicitly reflects consideration of failure rate and failure severity.
It would have been obvious to incorporate Shelton’s failure evaluation of system conditions into Atherton’s retention management framework so that data associated with significant or repeated failures is retained differently than data associated with insignificant or isolated events. This combination represents a predictable use of prior art elements according to their established functions, namely using known system condition metrics (failure rate and severity) as triggers within a known policy data retention system. This would yield the predictable result of improving data governance, and post event auditing by ensuring that data relevant to system failures or hazards is retained for longer periods or handled differently than routine data.
Regarding claim 9, Shelton, Atherton, and Twigg teach the invention in claim 1, as discussed above, and further teach further comprising creating the first data stream at the source surgical system, wherein the first metadata including the indication of the retention period for the first data stream is generated when the first data stream is created (Shelton [0242] “Referring to FIG. 1, a computer-implemented interactive surgical system 100 includes one or more surgical systems 102 and a cloud-based system (e.g., the cloud 104 that may include a remote server 113 coupled to a storage device 105). Each surgical system 102 includes at least one surgical hub 106 in communication with the cloud 104 that may include a remote server 113. In one example, as illustrated in FIG. 1, the surgical system 102 includes a visualization system 108, a robotic system 110, and a handheld intelligent surgical instrument 112, which are configured to communicate with one another and/or the hub 106. In some aspects, a surgical system 102 may include an M number of hubs 106, an N number of visualization systems 108, an O number of robotic systems 110, and a P number of handheld intelligent surgical instruments 112, where M, N, O, and P are integers greater than or equal to one.” Shelton [0243] “FIG. 2 depicts an example of a surgical system 102 being used to perform a surgical procedure on a patient who is lying down on an operating table 114 in a surgical operating room 116. A robotic system 110 is used in the surgical procedure as a part of the surgical system 102. The robotic system 110 includes a surgeon's console 118, a patient side cart 120 (surgical robot), and a surgical robotic hub 122. The patient side cart 120 can manipulate at least one removably coupled surgical tool 117 through a minimally invasive incision in the body of the patient while the surgeon views the surgical site through the surgeon's console 118. An image of the surgical site can be obtained by a medical imaging device 124, which can be manipulated by the patient side cart 120 to orient the imaging device 124. The robotic hub 122 can be used to process the images of the surgical site for subsequent display to the surgeon through the surgeon's console 118.”, Shelton [0318] “Accordingly, the data collection and aggregation module 7022 can generate aggregated metadata or other organized data based on raw data received from the surgical hubs 7006. To this end, the processors 7008 can be operationally coupled to the hub applications 7014 and aggregated medical data databases 7011 for executing the data analytics modules 7034. The data collection and aggregation module 7022 may store the aggregated organized data into the aggregated medical data databases 2212.”, Shelton [0616] “Data can be received 206522 from at least one data source, and may include patient data 206532 from a patient monitoring device, surgical staff data 206534 from a surgical staff detection device, modular device data 206536 from one or more modular devices and/or hospital data 206538 from a hospital database, as illustrated in FIG. 42. The received 206522 data is processed by the surgical hub 5104 to determine a progress status of the surgical procedure.”, Shelton [0607] “The decisions made by the surgical system 200 can be implemented, for example, by a control circuit that includes the processor 244. The control circuit is configured to receive data 250952 from a data source. The received data can include, for example, data pertaining to the vital statistics of the patient, the medical history of the patient, the type of surgical procedure being performed, the type of surgical instrument being used, any data detected by a surgical instrument and/or surgical visualization system, etc.”, and
and Atherton [0030] “Storage retention periods are assigned 605 to the data, such as by using timestamps on respective computer readable data marked in respective computer readable data storage locations, for example. A time stamp may mark a timeframe for which its associated data is retained by a file system. For example, when the retention period expires, an ILG process of a computer system may automatically mark the data for deletion. Once data is marked for deletion, the ILG process typically deletes the data automatically, i.e., without human intervention, although deletion may sometimes be placed on hold for some reason, in which case the ILG process may eventually delete the data responsive to human intervention.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to configure the system of Shelton such that a data stream created at a source surgical system is associated with metadata including a retention period at the time of creation, as taught by Atherton. Shelton discloses that surgical systems and associated devices (surgical instruments, monitoring devices, and hospital systems) generate data during a surgical procedure and transmit such data streams to a surgical hub, which suggest creation of the data stream at the source surgical system. Atherton teaches assigning retention periods to data at the time the data is created or stored via timestamps or associated metadata. A person of ordinary skill in the art would have been motivated to incorporate Atherton’s retention metadata assignment into Shelton’s system to ensure proper data lifecycle management, regulatory compliance, and automated governance of surgical data from the point of creation. This combination represents a predictable use of prior art elements according to their established functions and would have yielded the claimed feature of generating retention metadata when the data stream is created.
Regarding claim 10, Shelton, Atherton, and Twigg teach the invention in claim 1, as discussed above, and further teach wherein the first data stream remains stored at the destination surgical system until after expiration of the modified retention period (Shelton [0616] “Data can be received 206522 from at least one data source, and may include patient data 206532 from a patient monitoring device, surgical staff data 206534 from a surgical staff detection device, modular device data 206536 from one or more modular devices and/or hospital data 206538 from a hospital database, as illustrated in FIG. 42. The received 206522 data is processed by the surgical hub 5104 to determine a progress status of the surgical procedure.”, Shelton [0607] “The decisions made by the surgical system 200 can be implemented, for example, by a control circuit that includes the processor 244. The control circuit is configured to receive data 250952 from a data source. The received data can include, for example, data pertaining to the vital statistics of the patient, the medical history of the patient, the type of surgical procedure being performed, the type of surgical instrument being used, any data detected by a surgical instrument and/or surgical visualization system, etc.”., Shelton [0318] “Accordingly, the data collection and aggregation module 7022 can generate aggregated metadata or other organized data based on raw data received from the surgical hubs 7006. To this end, the processors 7008 can be operationally coupled to the hub applications 7014 and aggregated medical data databases 7011 for executing the data analytics modules 7034. The data collection and aggregation module 7022 may store the aggregated organized data into the aggregated medical data databases 2212.”, Shelton [0313] “The hubs 7006 are also communicatively coupled to the cloud 7004 of the computer-implemented interactive surgical system via the network 7001. The cloud 7004 is a remote centralized source of hardware and software for storing, manipulating, and communicating data generated based on the operation of various surgical systems. As shown in FIG. 12, access to the cloud 7004 is achieved via the network 7001, which may be the Internet or some other suitable computer network. Surgical hubs 7006 that are coupled to the cloud 7004 can be considered the client side of the cloud computing system (i.e., cloud-based analytics system). Surgical instruments 7012 are paired with the surgical hubs 7006 for control and implementation of various surgical procedures or operations as described herein.” and
Atherton [0034] “Referring now to FIG. 4, a policy table 305 for repositories A, B and C is illustrated in more detail, wherein policies specified in policy table 305 are based on geolocations of the repositories. Table 305 includes data retention policy entries and data transfer limitation policy entries for each of repositories A, B and C. One data retention entry 401 specifies a seven-year retention for data stored in repository A, another data retention entry 402 specifies a ten-year retention for data in repository B, and a third data retention entry 403 specifies a seven-year retention for data in repository C. One data transfer limitation policy entry 411 specifies that data may be transferred from repository A to repository B. Another data transfer limitation policy entry 412 specifies that data may be transferred from repository A to repository C. Another data transfer limitation policy entry 413 specifies that data may be transferred from repository B to repository A. Another data transfer limitation policy entry 414 specifies that data may be transferred from repository B to repository C. Another data transfer limitation policy entry 415 specifies that data may NOT be transferred from repository C to any other repository.”, and Atherton [0055] “More generally, a user may record a change policy entry in policy table 305 for particular data that indicates the effect that a change in location of the data has on retention of the data. According to embodiments of the present invention, the user may enter a “change,” “maintain,” or “maximum” change policy, for example. According to the “change” policy, the ILG process changes retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process changes the retention period for the data from the retention period for the first geolocation to whatever retention period applies for data stored in the second geolocation. According to the “maximum” policy, the ILG process assigns the longest retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process assigns the retention period for the data according to the longest of the retention period for the first geolocation and the retention period that ordinarily applies for data stored in the second geolocation.”, and Atherton [0035] “Referring again to FIG. 3, an ILG process arising from an ILG module, such as module 320A in the illustrated instance, provides intelligent audit trails of stored data, which are different than audit trails previously provided. Previously, an audit trail for archived data has been manually constructed based on records for a repository where the data is archived. That is, records for a repository have previously been stored locally on the server that hosts the repository and the records have been limited to indicating only the events of creating, accessing and modifying files and folders of the server, the date when each such event occurred and the date when the retention period expires for each data item. Thus, to construct an audit trail for a particular set of archived data has previously required a manual process of discovery to tie the particular set of archived data to the change history indicated by the records of creating, accessing and modifying files and folders of the server on which the data was archived. Further, the records that have been stored for these events did not previously include sufficient information to enable desirable lifecycle governance features described herein, and the events themselves that were defined to trigger the writing of records were insufficient. Features are disclosed herein in addition to marking retention expiration dates for data upon initial archiving. Processes and structures defined herein provide for automatic updating of retention periods across various jurisdictions responsive to detecting certain events, which enables consistency and prevents incorrect removal of data from retention.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to configure the system of Shelton to retain stored surgical data until expiration of an assigned or modified retention period as taught by Atherton. Shelton teaches receiving and storing surgical data streams at a surgical hub or cloud system for processing and analysis, but does not describe retention duration tied to expiration conditions. Atherton teaches assigning retention periods to data and maintaining the data in storage until the expiration of those retention periods, at which point lifecycle actions such as deletion may occur. A person of ordinary skill in the art would have been motivated to incorporate Atherton’s retention lifecycle management into Shelton’s surgical data storage system in order to ensure proper data governance and efficient storage management, which are well known concerns in data systems handling sensitive. This combination would represent a predictable use of prior art elements according to their established functions, specifically, combining known surgical data collection and storage systems with known data retention and expiration policies, to yield the predictable result of maintaining stored data until expiration of an applicable retention period.
Regarding claim 11, Shelton, Atherton, and Twigg teach the invention in claim 1, as discussed above, and further teach further comprising, after the modifying of the retention period, modifying the retention period again based on: an aspect of the first data, a usefulness of the first data, a score of the first data, or a situational change of the destination surgical system (Atherton [0034] “Referring now to FIG. 4, a policy table 305 for repositories A, B and C is illustrated in more detail, wherein policies specified in policy table 305 are based on geolocations of the repositories. Table 305 includes data retention policy entries and data transfer limitation policy entries for each of repositories A, B and C. One data retention entry 401 specifies a seven-year retention for data stored in repository A, another data retention entry 402 specifies a ten-year retention for data in repository B, and a third data retention entry 403 specifies a seven-year retention for data in repository C. One data transfer limitation policy entry 411 specifies that data may be transferred from repository A to repository B. Another data transfer limitation policy entry 412 specifies that data may be transferred from repository A to repository C. Another data transfer limitation policy entry 413 specifies that data may be transferred from repository B to repository A. Another data transfer limitation policy entry 414 specifies that data may be transferred from repository B to repository C. Another data transfer limitation policy entry 415 specifies that data may NOT be transferred from repository C to any other repository.”, and Atherton [0055] “More generally, a user may record a change policy entry in policy table 305 for particular data that indicates the effect that a change in location of the data has on retention of the data. According to embodiments of the present invention, the user may enter a “change,” “maintain,” or “maximum” change policy, for example. According to the “change” policy, the ILG process changes retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process changes the retention period for the data from the retention period for the first geolocation to whatever retention period applies for data stored in the second geolocation. According to the “maximum” policy, the ILG process assigns the longest retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process assigns the retention period for the data according to the longest of the retention period for the first geolocation and the retention period that ordinarily applies for data stored in the second geolocation.”, and [0085] “It should be appreciated from the forgoing that embodiments of the present invention provide scalable technology that permits a growing enterprise to fully respond to changes in retention requirements. Embodiments of the present invention allow multisite document distribution to automatically update retention policy depending on where a document is used, allows compliance with local retention laws, propagates updated information backwards to other copies of the data and defines export and import rules for managing retention policies for different physical sites.” and
Shelton [0336] “As yet another example, data can be drawn from additional data sources 5126 to improve the conclusions that the surgical hub 5104 draws from one data source 5126. A situationally aware surgical hub 5104 could augment data that it receives from the modular devices 5102 with contextual information that it has built up regarding the surgical procedure from other data sources 5126. For example, a situationally aware surgical hub 5104 can be configured to determine whether hemostasis has occurred (i.e., whether bleeding at a surgical site has stopped) according to video or image data received from a medical imaging device. However, in some cases the video or image data can be inconclusive. Therefore, in one exemplification, the surgical hub 5104 can be further configured to compare a physiologic measurement (e.g., blood pressure sensed by a BP monitor communicably connected to the surgical hub 5104) with the visual or image data of hemostasis (e.g., from a medical imaging device 124 (FIG. 2) communicably coupled to the surgical hub 5104) to make a determination on the integrity of the staple line or tissue weld. In other words, the situational awareness system of the surgical hub 5104 can consider the physiological measurement data to provide additional context in analyzing the visualization data. The additional context can be useful when the visualization data may be inconclusive or incomplete on its own.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the retention period multiple times based on evolving data characteristics by combining the teachings of Atherton and Shelton. Atherton teaches a retention management framework in which retention periods are assigned and dynamically modified in response to changing conditions, including updates triggered by changes in storage location or policy, and further teaches that retention policies may be automatically updated over time in response to changing requirements, which show iterative re-evaluation of retention. Shelton teaches that a surgical system evaluates data using multiple data sources to provide contextual understanding, where the usefulness and relevance of data depend on its context and may be enhanced through combining additional data streams. It would have been obvious to incorporate Shelton’s contextual data evaluation into Atherton’s dynamic retention framework such that retention periods are further modified based on characteristics of the data, including its usefulness or contextual attributes, because this represents a predictable use of prior art elements according to their established functions to improve data management by adapting retention based on the relative value of data over time.
Regarding claim 12, Shelton, Atherton, and Twigg teach the invention in claim 1, as discussed above, and further teach wherein the destination surgical system includes a surgical hub; and the source surgical system is one of a hospital network, a database, a surgical instrument, or a surgical cart (Shelton [0242] “Referring to FIG. 1, a computer-implemented interactive surgical system 100 includes one or more surgical systems 102 and a cloud-based system (e.g., the cloud 104 that may include a remote server 113 coupled to a storage device 105). Each surgical system 102 includes at least one surgical hub 106 in communication with the cloud 104 that may include a remote server 113. In one example, as illustrated in FIG. 1, the surgical system 102 includes a visualization system 108, a robotic system 110, and a handheld intelligent surgical instrument 112, which are configured to communicate with one another and/or the hub 106. In some aspects, a surgical system 102 may include an M number of hubs 106, an N number of visualization systems 108, an O number of robotic systems 110, and a P number of handheld intelligent surgical instruments 112, where M, N, O, and P are integers greater than or equal to one.” Shelton [0315] “Based on connections to various surgical hubs 7006 via the network 7001, the cloud 7004 can aggregate data from specific data generated by various surgical instruments 7012 and their corresponding hubs 7006. Such aggregated data may be stored within the aggregated medical databases 7011 of the cloud 7004. In particular, the cloud 7004 may advantageously perform data analysis and operations on the aggregated data to yield insights and/or perform functions that individual hubs 7006 could not achieve on their own. To this end, as shown in FIG. 12, the cloud 7004 and the surgical hubs 7006 are communicatively coupled to transmit and receive information. The I/O interface 7007 is connected to the plurality of surgical hubs 7006 via the network 7001. In this way, the I/O interface 7007 can be configured to transfer information between the surgical hubs 7006 and the aggregated medical data databases 7011. Accordingly, the I/O interface 7007 may facilitate read/write operations of the cloud-based analytics system. Such read/write operations may be executed in response to requests from hubs 7006. These requests could be transmitted to the hubs 7006 through the hub applications. The I/O interface 7007 may include one or more high speed data ports, which may include universal serial bus (USB) ports, IEEE 1394 ports, as well as Wi-Fi and Bluetooth I/O interfaces for connecting the cloud 7004 to hubs 7006. The hub application servers 7002 of the cloud 7004 are configured to host and supply shared capabilities to software applications (e.g. hub applications) executed by surgical hubs 7006. For example, the hub application servers 7002 may manage requests made by the hub applications through the hubs 7006, control access to the aggregated medical data databases 7011, and perform load balancing. The data analytics modules 7034 are described in further detail with reference to FIG. 13.” and Shelton [0243] “FIG. 2 depicts an example of a surgical system 102 being used to perform a surgical procedure on a patient who is lying down on an operating table 114 in a surgical operating room 116. A robotic system 110 is used in the surgical procedure as a part of the surgical system 102. The robotic system 110 includes a surgeon's console 118, a patient side cart 120 (surgical robot), and a surgical robotic hub 122. The patient side cart 120 can manipulate at least one removably coupled surgical tool 117 through a minimally invasive incision in the body of the patient while the surgeon views the surgical site through the surgeon's console 118. An image of the surgical site can be obtained by a medical imaging device 124, which can be manipulated by the patient side cart 120 to orient the imaging device 124. The robotic hub 122 can be used to process the images of the surgical site for subsequent display to the surgeon through the surgeon's console 118.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to configure the system of Shelton such that the destination surgical system includes a surgical hub and the source surgical system includes one or more systems such as a surgical instrument, database, hospital network, or surgical cart. Shelton teaches a surgical system comprising a surgical hub (surgical hub or robotic hub) that communicates with multiple interconnected components, including surgical instruments, databases, and networked systems. Shelton further teaches that these components generate and transmit data to the surgical hub via a network, thereby functioning as data sources to the hub. For example, surgical instruments and robotic carts provide procedural and device data, databases provide stored medical data, and networked systems facilitate communication across hospital infrastructure. A person of ordinary skill in the art would have recognized that these interconnected components implicitly act as source systems supplying data to the hub, and it would have been an obvious design choice to characterize or implement them as such in order to facilitate modular data flow and centralized processing. This represents the predictable use of known system architectures in which multiple data generating components communicate with a central hub, and therefore the claimed configuration would have been obvious.
Regarding claim 13, Shelton, Atherton, and Twigg teach the invention in claim 12, as discussed above, and further teach further comprising receiving, at the surgical hub from a second source surgical system, and during the performance of the surgical procedure on the patient, a second data stream including second data collected during the performance of the surgical procedure, wherein the second data stream has associated second metadata, the second metadata includes an indication of a retention period for the second data stream, and the second data includes information regarding at least two of patient data, surgical procedure data, and surgical instrument data (Shelton [0242] “Referring to FIG. 1, a computer-implemented interactive surgical system 100 includes one or more surgical systems 102 and a cloud-based system (e.g., the cloud 104 that may include a remote server 113 coupled to a storage device 105). Each surgical system 102 includes at least one surgical hub 106 in communication with the cloud 104 that may include a remote server 113. In one example, as illustrated in FIG. 1, the surgical system 102 includes a visualization system 108, a robotic system 110, and a handheld intelligent surgical instrument 112, which are configured to communicate with one another and/or the hub 106. In some aspects, a surgical system 102 may include an M number of hubs 106, an N number of visualization systems 108, an O number of robotic systems 110, and a P number of handheld intelligent surgical instruments 112, where M, N, O, and P are integers greater than or equal to one.” Shelton [0243] “FIG. 2 depicts an example of a surgical system 102 being used to perform a surgical procedure on a patient who is lying down on an operating table 114 in a surgical operating room 116. A robotic system 110 is used in the surgical procedure as a part of the surgical system 102. The robotic system 110 includes a surgeon's console 118, a patient side cart 120 (surgical robot), and a surgical robotic hub 122. The patient side cart 120 can manipulate at least one removably coupled surgical tool 117 through a minimally invasive incision in the body of the patient while the surgeon views the surgical site through the surgeon's console 118. An image of the surgical site can be obtained by a medical imaging device 124, which can be manipulated by the patient side cart 120 to orient the imaging device 124. The robotic hub 122 can be used to process the images of the surgical site for subsequent display to the surgeon through the surgeon's console 118.”, Shelton [0318] “Accordingly, the data collection and aggregation module 7022 can generate aggregated metadata or other organized data based on raw data received from the surgical hubs 7006. To this end, the processors 7008 can be operationally coupled to the hub applications 7014 and aggregated medical data databases 7011 for executing the data analytics modules 7034. The data collection and aggregation module 7022 may store the aggregated organized data into the aggregated medical data databases 2212.”, Shelton [0616] “Data can be received 206522 from at least one data source, and may include patient data 206532 from a patient monitoring device, surgical staff data 206534 from a surgical staff detection device, modular device data 206536 from one or more modular devices and/or hospital data 206538 from a hospital database, as illustrated in FIG. 42. The received 206522 data is processed by the surgical hub 5104 to determine a progress status of the surgical procedure.”, Shelton [0607] “The decisions made by the surgical system 200 can be implemented, for example, by a control circuit that includes the processor 244. The control circuit is configured to receive data 250952 from a data source. The received data can include, for example, data pertaining to the vital statistics of the patient, the medical history of the patient, the type of surgical procedure being performed, the type of surgical instrument being used, any data detected by a surgical instrument and/or surgical visualization system, etc.”., and Shelton [0295] “FIG. 9 illustrates a computer-implemented interactive surgical system 200. The computer-implemented interactive surgical system 200 is similar in many respects to the computer-implemented interactive surgical system 100. For example, the computer-implemented interactive surgical system 200 includes one or more surgical systems 202, which are similar in many respects to the surgical systems 102. Each surgical system 202 includes at least one surgical hub 206 in communication with a cloud 204 that may include a remote server 213. In one aspect, the computer-implemented interactive surgical system 200 comprises a modular control tower 236 connected to multiple operating theater devices such as, for example, intelligent surgical instruments, robots, and other computerized devices located in the operating theater. As shown in FIG. 10, the modular control tower 236 comprises a modular communication hub 203 coupled to a computer system 210. As illustrated in the example of FIG. 9, the modular control tower 236 is coupled to an imaging module 238 that is coupled to an endoscope 239, a generator module 240 that is coupled to an energy device 241, a smoke evacuator module 226, a suction/irrigation module 228, a communication module 230, a processor module 232, a storage array 234, a smart device/instrument 235 optionally coupled to a display 237, and a non-contact sensor module 242. The operating theater devices are coupled to cloud computing resources and data storage via the modular control tower 236. A robot hub 222 also may be connected to the modular control tower 236 and to the cloud computing resources. The devices/instruments 235, visualization systems 208, among others, may be coupled to the modular control tower 236 via wired or wireless communication standards or protocols, as described herein. The modular control tower 236 may be coupled to a hub display 215 (e.g., monitor, screen) to display and overlay images received from the imaging module, device/instrument display, and/or other visualization systems 208. The hub display also may display data received from devices connected to the modular control tower in conjunction with images and overlaid images.”, and
and Atherton [0030] “Storage retention periods are assigned 605 to the data, such as by using timestamps on respective computer readable data marked in respective computer readable data storage locations, for example. A time stamp may mark a timeframe for which its associated data is retained by a file system. For example, when the retention period expires, an ILG process of a computer system may automatically mark the data for deletion. Once data is marked for deletion, the ILG process typically deletes the data automatically, i.e., without human intervention, although deletion may sometimes be placed on hold for some reason, in which case the ILG process may eventually delete the data responsive to human intervention.”);
storing the received second data stream at the surgical hub (Shelton [0616] “Data can be received 206522 from at least one data source, and may include patient data 206532 from a patient monitoring device, surgical staff data 206534 from a surgical staff detection device, modular device data 206536 from one or more modular devices and/or hospital data 206538 from a hospital database, as illustrated in FIG. 42. The received 206522 data is processed by the surgical hub 5104 to determine a progress status of the surgical procedure.”, Shelton [0607] “The decisions made by the surgical system 200 can be implemented, for example, by a control circuit that includes the processor 244. The control circuit is configured to receive data 250952 from a data source. The received data can include, for example, data pertaining to the vital statistics of the patient, the medical history of the patient, the type of surgical procedure being performed, the type of surgical instrument being used, any data detected by a surgical instrument and/or surgical visualization system, etc.”., Shelton [0318] “Accordingly, the data collection and aggregation module 7022 can generate aggregated metadata or other organized data based on raw data received from the surgical hubs 7006. To this end, the processors 7008 can be operationally coupled to the hub applications 7014 and aggregated medical data databases 7011 for executing the data analytics modules 7034. The data collection and aggregation module 7022 may store the aggregated organized data into the aggregated medical data databases 2212.”, Shelton [0313] “The hubs 7006 are also communicatively coupled to the cloud 7004 of the computer-implemented interactive surgical system via the network 7001. The cloud 7004 is a remote centralized source of hardware and software for storing, manipulating, and communicating data generated based on the operation of various surgical systems. As shown in FIG. 12, access to the cloud 7004 is achieved via the network 7001, which may be the Internet or some other suitable computer network. Surgical hubs 7006 that are coupled to the cloud 7004 can be considered the client side of the cloud computing system (i.e., cloud-based analytics system). Surgical instruments 7012 are paired with the surgical hubs 7006 for control and implementation of various surgical procedures or operations as described herein.”); and
after the storing of the received second data stream, modifying the retention period for the second data stream based on: an aspect of the second data, a usefulness of the second data, a score of the second data, or a situational change of the second source surgical system (Shelton [0318] “Accordingly, the data collection and aggregation module 7022 can generate aggregated metadata or other organized data based on raw data received from the surgical hubs 7006. To this end, the processors 7008 can be operationally coupled to the hub applications 7014 and aggregated medical data databases 7011 for executing the data analytics modules 7034. The data collection and aggregation module 7022 may store the aggregated organized data into the aggregated medical data databases 2212.”, and
Atherton [0034] “Referring now to FIG. 4, a policy table 305 for repositories A, B and C is illustrated in more detail, wherein policies specified in policy table 305 are based on geolocations of the repositories. Table 305 includes data retention policy entries and data transfer limitation policy entries for each of repositories A, B and C. One data retention entry 401 specifies a seven-year retention for data stored in repository A, another data retention entry 402 specifies a ten-year retention for data in repository B, and a third data retention entry 403 specifies a seven-year retention for data in repository C. One data transfer limitation policy entry 411 specifies that data may be transferred from repository A to repository B. Another data transfer limitation policy entry 412 specifies that data may be transferred from repository A to repository C. Another data transfer limitation policy entry 413 specifies that data may be transferred from repository B to repository A. Another data transfer limitation policy entry 414 specifies that data may be transferred from repository B to repository C. Another data transfer limitation policy entry 415 specifies that data may NOT be transferred from repository C to any other repository.”, and Atherton [0055] “More generally, a user may record a change policy entry in policy table 305 for particular data that indicates the effect that a change in location of the data has on retention of the data. According to embodiments of the present invention, the user may enter a “change,” “maintain,” or “maximum” change policy, for example. According to the “change” policy, the ILG process changes retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process changes the retention period for the data from the retention period for the first geolocation to whatever retention period applies for data stored in the second geolocation. According to the “maximum” policy, the ILG process assigns the longest retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process assigns the retention period for the data according to the longest of the retention period for the first geolocation and the retention period that ordinarily applies for data stored in the second geolocation.”, and
Twigg [0014] “The invention may be expressed in terms of a number of aspects embodying some or all of the above features. For example, viewed one aspect the invention provides a method of storing data on a plurality of physical data storage drives, each of which has a data storage component and can be switched between an operative state in which there is relatively high energy usage, and an inoperative state in which there is relatively low energy usage; wherein an active volume containing data which is currently active is stored across a plurality of drives being a first number of drives in an active set of the plurality of drives which are normally maintained in the operative state; when a volume is identified as containing only data which has become inactive, that inactive volume is transferred from the active set of drives and stored across a plurality of drives being a second number of drives within an inactive set of the plurality of drives which are normally maintained in the inoperative state; when there is a subsequent read or write request in respect of an inactive volume stored within the inactive set of drives, the inactive volume is transferred from the inactive set of drives to the drives in the active set of drives and becomes an active volume; and wherein the data storage layouts for the active set of drives and the inactive set of drives are different, and the data storage layout for the inactive drives includes a plurality of regions at predetermined different levels of increasing data storage capacity and is such that (a) when an inactive volume is transferred in its entirety to the inactive set of drives it is allocated to the smallest capacity region that will accommodate the data of the volume; and (b) when additional data only is to be added to a volume on the inactive set of drives the additional data is firstly placed in the current highest capacity region containing data for that volume until that current highest capacity region is full; and if there is remaining data to be added to the volume that remaining data is placed in the lowest capacity region that (i) will accommodate that remaining data and (ii) is of the same capacity as, or a higher capacity than, the currently highest capacity region.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to extend the system of Shelton to handle multiple data streams, including receiving a second data stream from a second source surgical system during a surgical procedure and storing that data at a surgical hub. Shelton teaches a surgical data architecture in which a hub communicates with multiple devices and systems (surgical instruments, robotic systems, imaging systems, and hospital databases) and receives and aggregates data generated during a procedure. This multi-source configuration reasonably suggests receiving parallel data streams from different sources during the same procedure and storing such data within the hub or associated databases. Thus, Shelton teaches or suggests the receipt and storage of a second data stream with associated metadata in a surgical environment.
It would have been further obvious to modify the retention period for the second data stream based on a situational change, as taught by Atherton. Atherton discloses assigning retention periods to data and dynamically modifying those retention periods in response to changes in conditions affecting the data, such as changes in storage location, jurisdiction, or governing policies. These changes constitute situational conditions that impact how long data should be retained. A person of ordinary skill in the art would have been motivated to incorporate Atherton’s dynamic retention management into Shelton’s system to ensure proper data lifecycle governance, regulatory compliance, and efficient management of multiple data streams. Applying Atherton’s teachings to each data stream in Shelton, including a second data stream, would have been a predictable use of prior art elements according to their established functions, thereby rendering the claimed limitation obvious.
Regarding claim 14, Shelton, Atherton, and Twigg teach the invention in claim 1, as discussed above, and further teach wherein each of the source and destination surgical systems is one of a hospital network, a database, a surgical instrument, or a surgical cart (Shelton [0243] “FIG. 2 depicts an example of a surgical system 102 being used to perform a surgical procedure on a patient who is lying down on an operating table 114 in a surgical operating room 116. A robotic system 110 is used in the surgical procedure as a part of the surgical system 102. The robotic system 110 includes a surgeon's console 118, a patient side cart 120 (surgical robot), and a surgical robotic hub 122. The patient side cart 120 can manipulate at least one removably coupled surgical tool 117 through a minimally invasive incision in the body of the patient while the surgeon views the surgical site through the surgeon's console 118. An image of the surgical site can be obtained by a medical imaging device 124, which can be manipulated by the patient side cart 120 to orient the imaging device 124. The robotic hub 122 can be used to process the images of the surgical site for subsequent display to the surgeon through the surgeon's console 118.”, Shelton [0242] “Referring to FIG. 1, a computer-implemented interactive surgical system 100 includes one or more surgical systems 102 and a cloud-based system (e.g., the cloud 104 that may include a remote server 113 coupled to a storage device 105). Each surgical system 102 includes at least one surgical hub 106 in communication with the cloud 104 that may include a remote server 113. In one example, as illustrated in FIG. 1, the surgical system 102 includes a visualization system 108, a robotic system 110, and a handheld intelligent surgical instrument 112, which are configured to communicate with one another and/or the hub 106. In some aspects, a surgical system 102 may include an M number of hubs 106, an N number of visualization systems 108, an O number of robotic systems 110, and a P number of handheld intelligent surgical instruments 112, where M, N, O, and P are integers greater than or equal to one.”, and Shelton [0315] “Based on connections to various surgical hubs 7006 via the network 7001, the cloud 7004 can aggregate data from specific data generated by various surgical instruments 7012 and their corresponding hubs 7006. Such aggregated data may be stored within the aggregated medical databases 7011 of the cloud 7004. In particular, the cloud 7004 may advantageously perform data analysis and operations on the aggregated data to yield insights and/or perform functions that individual hubs 7006 could not achieve on their own. To this end, as shown in FIG. 12, the cloud 7004 and the surgical hubs 7006 are communicatively coupled to transmit and receive information. The I/O interface 7007 is connected to the plurality of surgical hubs 7006 via the network 7001. In this way, the I/O interface 7007 can be configured to transfer information between the surgical hubs 7006 and the aggregated medical data databases 7011. Accordingly, the I/O interface 7007 may facilitate read/write operations of the cloud-based analytics system. Such read/write operations may be executed in response to requests from hubs 7006. These requests could be transmitted to the hubs 7006 through the hub applications. The I/O interface 7007 may include one or more high speed data ports, which may include universal serial bus (USB) ports, IEEE 1394 ports, as well as Wi-Fi and Bluetooth I/O interfaces for connecting the cloud 7004 to hubs 7006. The hub application servers 7002 of the cloud 7004 are configured to host and supply shared capabilities to software applications (e.g. hub applications) executed by surgical hubs 7006. For example, the hub application servers 7002 may manage requests made by the hub applications through the hubs 7006, control access to the aggregated medical data databases 7011, and perform load balancing. The data analytics modules 7034 are described in further detail with reference to FIG. 13.” ).
It would have been obvious to one of ordinary skill in the art at the time of the invention to configure the system of Shelton that each of the source and destination surgical systems is one of a hospital network, a database, a surgical instrument, or a surgical cart. Shelton teaches a distributed surgical system architecture including multiple interconnected components such as surgical instruments, robotic systems including patient side carts, surgical hubs, cloud systems, and databases, all of which communicate over a network. Shelton further teaches that these components both generate and receive data, that data may be transmitted between surgical instruments, hubs, cloud systems, and databases via the network, thereby functioning as either data sources or data destinations depending on system operation.
A person of ordinary skill in the art would have recognized that such modular, networked components are implicitly capable of operating interchangeably as source or destination systems within a distributed data environment and would have been motivated to configure them accordingly to enable flexible data exchange, improve system interoperability, and support centralized and distributed processing. This represents the predictable use of known networked computing architectures in which multiple devices and systems both send and receive data, and therefore configuring each system as either a source or destination, as claimed, would have been an obvious design choice yielding no more than predictable results.
Claims 15 and 18 are analogous to claim 1, thus claims 15 and 18 similarly analyzed and rejected in a manner consistent with the rejection of claim 1.
Claims 16 and 19 are analogous to claim 12, thus claims 16 and 19 similarly analyzed and rejected in a manner consistent with the rejection of claim 12.
Claims 17 and 20 are analogous to claim 14, thus claims 17 and 20 similarly analyzed and rejected in a manner consistent with the rejection of claim 14.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Shelton et al. (U.S. Patent Publication 2019/0206563 A1), referred to hereinafter as Shelton, in view of Atherton et al. (U.S. Patent Publication 2021/0117124A1), referred to hereinafter as Atherton, and Twigg (U.S. Patent Publication 2010/0257312A1), referred to hereinafter as Twigg, and further in view of Rahman et al. (U.S. Patent Publication 2021/0096957 A1), referred to hereinafter as Rahman.
Regarding claim 4, Shelton, Atherton, and Twigg teach the invention in claim 1, as discussed above, and further teach wherein the retention period is modified based on the aspect of the first data; and after expiration of the modified retention period, and a remainder of the first data remains stored until after expiration of the retention period (Atherton [0034] “Referring now to FIG. 4, a policy table 305 for repositories A, B and C is illustrated in more detail, wherein policies specified in policy table 305 are based on geolocations of the repositories. Table 305 includes data retention policy entries and data transfer limitation policy entries for each of repositories A, B and C. One data retention entry 401 specifies a seven-year retention for data stored in repository A, another data retention entry 402 specifies a ten-year retention for data in repository B, and a third data retention entry 403 specifies a seven-year retention for data in repository C. One data transfer limitation policy entry 411 specifies that data may be transferred from repository A to repository B. Another data transfer limitation policy entry 412 specifies that data may be transferred from repository A to repository C. Another data transfer limitation policy entry 413 specifies that data may be transferred from repository B to repository A. Another data transfer limitation policy entry 414 specifies that data may be transferred from repository B to repository C. Another data transfer limitation policy entry 415 specifies that data may NOT be transferred from repository C to any other repository.”, and Atherton [0055] “More generally, a user may record a change policy entry in policy table 305 for particular data that indicates the effect that a change in location of the data has on retention of the data. According to embodiments of the present invention, the user may enter a “change,” “maintain,” or “maximum” change policy, for example. According to the “change” policy, the ILG process changes retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process changes the retention period for the data from the retention period for the first geolocation to whatever retention period applies for data stored in the second geolocation. According to the “maximum” policy, the ILG process assigns the longest retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process assigns the retention period for the data according to the longest of the retention period for the first geolocation and the retention period that ordinarily applies for data stored in the second geolocation.”, and Atherton [0035] “Referring again to FIG. 3, an ILG process arising from an ILG module, such as module 320A in the illustrated instance, provides intelligent audit trails of stored data, which are different than audit trails previously provided. Previously, an audit trail for archived data has been manually constructed based on records for a repository where the data is archived. That is, records for a repository have previously been stored locally on the server that hosts the repository and the records have been limited to indicating only the events of creating, accessing and modifying files and folders of the server, the date when each such event occurred and the date when the retention period expires for each data item. Thus, to construct an audit trail for a particular set of archived data has previously required a manual process of discovery to tie the particular set of archived data to the change history indicated by the records of creating, accessing and modifying files and folders of the server on which the data was archived. Further, the records that have been stored for these events did not previously include sufficient information to enable desirable lifecycle governance features described herein, and the events themselves that were defined to trigger the writing of records were insufficient. Features are disclosed herein in addition to marking retention expiration dates for data upon initial archiving. Processes and structures defined herein provide for automatic updating of retention periods across various jurisdictions responsive to detecting certain events, which enables consistency and prevents incorrect removal of data from retention.”).
Shelton, Atherton, and Twigg fail to explicitly teach the aspect of the first data includes presence of patient-identifying data in the first data; and the first data is pruned of the patient-identifying data.
Rahman teaches the aspect of the first data includes presence of patient-identifying data in the first data; and the first data is pruned of the patient-identifying data (Rahman [0012] “In some embodiments of the present invention, compliant deletions are performed on one or a combination of: live data sources, which can be queried and are maintained in real-time or near real-time; backup sources used to restore or correct issues associated with the live data source; and archive sources which are often removed from the live data source, kept for retention period requirements, and not readily accessible for data queries. In some embodiments, the deletion action is a “soft delete” in which the user-identifiable information in data records is marked “delete” such that the data records are excluded from data query and viewing but are not physically removed.” and Rahman [0022] “In some embodiments in which a restoration action is performed a copy of the live data is generated and the restoration of an appropriately dated backup of the live data is applied to the copy of the live data. Deletions recorded in deletion log 115 are applied to the live data copy to include all deletions performed subsequent to the live data backup applied, and deletion information, such as data type deleted, timestamp of deletion, related records, and other information included in deletion log 115 are included in the audit data 117. In some embodiments, deletions are performed on archive records 170 of record retention system 180. In some embodiments, retention system rules 120 includes record compliance requiring retaining of original records in archive records 170. Embodiments of the present invention provide for compliance of original record retention of archive records and user deletion requests by applying deletions from deletion log 115 to a copy of records from archive records 170. User records designated in deletion log 115 are removed from audit reports of archive records, and archive records 170 retains original records. The user records are effectively deleted (from audit reports), but archive records 170 remains compliant with rules requiring retention for designated time periods.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify a data retention period based on the presence of patient identifying data and to remove such identifying data while retaining the remainder of the data, by combining the teachings of Atherton and Rahman. Atherton teaches assigning and dynamically modifying retention periods for data based on policy driven attributes and conditions associated with the data, including system defined rules governing lifecycle management and retention across different contexts. These teachings demonstrate that retention decisions are based on characteristics or attributes of the data and may be updated in response to relevant conditions. Rahman teaches managing sensitive data by selectively removing user-identifiable information from data records (via soft delete) while retaining the underlying data for compliance with retention requirements, including maintaining archived data while excluding identifying information from use or access.
A person of ordinary skill in the art would have been motivated to incorporate Rahman’s selective removal of identifying information into Atherton’s retention management framework in order to address privacy and regulatory concerns associated with sensitive data, such as patient identifying information. It would have been an obvious design choice to treat the presence of identifying information as a data attribute relevant to retention policy decisions, and to modify retention behavior accordingly, such as removing identifying information after a certain retention period while continuing to store the remaining non identifying data for longer term analytical or compliance purposes. This combination represents a predictable use of prior art elements according to their established functions and results in the claimed approach of modifying retention based on the presence of patient identifying data and pruning such identifying data while retaining the remainder of the data.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Shelton et al. (U.S. Patent Publication 2019/0206563 A1), referred to hereinafter as Shelton, in view of Atherton et al. (U.S. Patent Publication 2021/0117124A1), referred to hereinafter as Atherton, and Twigg (U.S. Patent Publication 2010/0257312A1), referred to hereinafter as Twigg, and further in view of Barmes et al. (U.S. Patent No. 10339147 B1), referred to hereinafter as Barmes.
Regarding claim 8, Shelton, Atherton, and Twigg teach the invention in claim 1, as discussed above, and further teach wherein the retention period is modified; and based on at least one of a quality of the first data, a protection level of the first data, a type of the first data, and a taxonomy of the first data (Atherton [0034] “Referring now to FIG. 4, a policy table 305 for repositories A, B and C is illustrated in more detail, wherein policies specified in policy table 305 are based on geolocations of the repositories. Table 305 includes data retention policy entries and data transfer limitation policy entries for each of repositories A, B and C. One data retention entry 401 specifies a seven-year retention for data stored in repository A, another data retention entry 402 specifies a ten-year retention for data in repository B, and a third data retention entry 403 specifies a seven-year retention for data in repository C. One data transfer limitation policy entry 411 specifies that data may be transferred from repository A to repository B. Another data transfer limitation policy entry 412 specifies that data may be transferred from repository A to repository C. Another data transfer limitation policy entry 413 specifies that data may be transferred from repository B to repository A. Another data transfer limitation policy entry 414 specifies that data may be transferred from repository B to repository C. Another data transfer limitation policy entry 415 specifies that data may NOT be transferred from repository C to any other repository.”, and Atherton [0055] “More generally, a user may record a change policy entry in policy table 305 for particular data that indicates the effect that a change in location of the data has on retention of the data. According to embodiments of the present invention, the user may enter a “change,” “maintain,” or “maximum” change policy, for example. According to the “change” policy, the ILG process changes retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process changes the retention period for the data from the retention period for the first geolocation to whatever retention period applies for data stored in the second geolocation. According to the “maximum” policy, the ILG process assigns the longest retention periods for data in storage based on storage geolocation(s), such that responsive to detecting that a storage location for the data changes from a first geolocation to a second geolocation (or that the data is added to the second geolocation), for example, the ILG process assigns the retention period for the data according to the longest of the retention period for the first geolocation and the retention period that ordinarily applies for data stored in the second geolocation.” Atherton [0067] “Data may be tagged with more than one location or jurisdiction, according to embodiments of the present invention. For example, if the data provides financial statements for colleges in the United States that must be generated to satisfy a requirement under the federal law of the United States and the federal law imposes a retention requirement for these statements, then the user may indicate “USA” as the geolocation and “USA federal” as the jurisdiction, even if the data is uploaded from an accountant's office located outside the United States. In addition, the ILG process also automatically associates the geolocation from which the data is uploaded in this example. Alternatively, or in addition, if a regulation of the U.S. Department of Commerce and another regulation of the U.S. Department of Education govern retention, the user may indicate “USA” as the geolocation and more specifically indicate “U.S. Department of Commerce” and “U.S. Department of Education” as governing jurisdictions. In a further alternative, the user may indicate specific provisions of the regulations of the U.S. Department of Commerce and specific provisions of the regulations of the U.S. Department of Education as governing jurisdictions. Also, assuming the data is a single file and there is a state law in one or more of the US states that also governs retention of college financial statements for colleges in that state, for example, then the user may also indicate each such state as a geolocation for association with the file and the jurisdiction(s) of each such state as associated jurisdiction(s).After initially archiving data, the ILG process writes a record in audit table 306 automatically in response to any access to the data, which may include a download, moving the data into another storage location, checking out the data, modifying the data, etc., wherein the record includes identification of the user who accessed the data, the user's Internet protocol address (i.e., IP address from which the user accessed the data), and reason for accessing. Historical governance parameter and data category tags for each particular data item are maintained in audit table 306 for the data even upon changes in governance and category, since current governance for the data may depend on past categories of the data. The tags are time stamped so that the ILG process may determine current governance parameters for the data based the data current and past states.”).
Shelton, Atherton, and Twigg fail to explicitly teach based on the score of the first data; and the method further comprises determining the score of the first data.
Barmes teaches based on the score of the first data; and the method further comprises determining the score of the first data (Barmes, Col. 4, lines 37-50, “The data analyzer 114 may analyze any number of characteristics of the data set or of subsets of the data set and may assign one or more scores based on the characteristics. The characteristics may represent different quality aspects of the data set. The scores of the characteristics may be weighted and/or combined to form a data set score that may represent an overall quality of the data set. The quality of the data set may be indicative of how well the data set is likely to satisfy a customer's use case. By making the data set score and/or characteristic scores available through the data marketplace 112, a customer may quickly and easily understand the quality of the data set and may compare the data set against other data sets without expending an extensive amount of time.”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify a retention period based on a score of the data, where the score is determined from characteristics such as quality, type, or taxonomy of the data, by combining the teachings of Barmes and Atherton. Barmes teaches analyzing characteristics of a data set and assigning one or more scores based on those characteristics, including quality aspects, and further combining such characteristic scores into an overall data set score indicative of the usefulness or suitability of the data. Atherton teaches assigning and dynamically modifying retention periods for data based on attributes and classifications associated with the data, including policy driven conditions and data categorizations such as jurisdiction or type. A person of ordinary skill in the art would have been motivated to incorporate Barmes’ scoring techniques into Atherton’s retention management framework in order to quantify and standardize the evaluation of data characteristics used in determining retention policies. This modification would improve the efficiency and automation of data lifecycle management by enabling retention periods to be adjusted based on a computed score reflecting the underlying characteristics of the data. This combination represents a predictable use of prior art elements according to their established functions and yields the claimed feature of modifying a retention period based on a score of the data determined from characteristics such as quality, type, or taxonomy.
Response to Arguments
Applicant’s arguments and amendments, see Remarks/Amendments submitted on 02/17/2026 with respect to the rejection of the claims have been carefully considered and is addressed below.
Claim Rejections - 35 USC § 101
Applicant’s argument that claim 1 is directed to a practical application under Step 2A, Prong Two is not persuasive. Applicant states that the recitation of receiving a data stream with associated metadata, including a retention period, and applying the evaluation to such metadata constitutes a meaningful application beyond merely linking the abstract idea to a technological environment. However, these limitations merely describe the type of data being evaluated and the context in which the abstract idea is performed. The claim does not recite any specific technological mechanism for processing the data or modifying the retention period, nor does it improve the functioning of a computer or any other technology. Rather, the claim applies the abstract idea of evaluating information and determining a retention period to a type of data within a surgical environment, which amounts to a field of use limitation and does not integrate the abstract idea into a practical application.
Applicant further states that the claim applies the alleged abstract idea in a meaningful way because the evaluation is performed on metadata associated with a data stream received at a destination surgical system. This argument is unpersuasive because evaluating metadata is an evaluation of information, which is part of the abstract idea itself. The claim does not recite any particular way that the metadata is generated that would impose a meaningful limitation on the abstract idea. Instead, the claim broadly recites evaluating characteristics of data (aspect, usefulness, score, and situational change) and modifying a retention period based on that evaluation, which can be performed mentally or with pen and paper. Therefore, the additional elements do not meaningfully limit the judicial exception.
Applicant’s statement on McRO is also unpersuasive. In McRO, the claims were found eligible because they recited specific rules that improved a technological process. In this case, the claims do not recite any specific rules or techniques for determining the retention period. Instead, the claims merely recite a desired result, modifying a retention period based on various factors, without specifying how that result is achieved. These limitations are insufficient to confer eligibility and do not demonstrate an improvement to computer functionality or another technology.
With respect to Step 2B, Applicant’s statements that the claim as a whole amounts to significantly more than the abstract idea is not persuasive. The additional elements of receiving a data stream and storing the data stream represent well-understood, routine, and conventional activities in the field of data processing and information management. The processor and memory are used in their ordinary capacities, and the specification does not describe any improvement to the functioning of the computer or to any other technology. As explained in Electric Power Group, merely collecting and analyzing information without a technological improvement does not add significantly more to an abstract idea. Similarly, storing data in a generic manner, as recited in the claim, constitutes insignificant post-solution activity (In re Brown).
Accordingly, when considered individually and as an ordered combination, the additional elements do not amount to significantly more than the abstract idea. The claims remain directed to an abstract idea without an inventive concept and are therefore not patent eligible under 35 U.S.C. § 101.
Claim Rejections - 35 USC § 103
Applicant’s arguments traversing the prior art rejection in the previous Office Action have been fully considered. However, those arguments are rendered moot because the present rejection under 35 U.S.C. §103 relies on a different set of prior art references (Shelton, Atherton, Twigg, Rahman, and Barmes), which teach or suggest the limitations of the claims. Accordingly, Applicant’s prior arguments are not responsive to the current grounds of rejection. The rejection of claims 1-20 under 35 U.S.C. §103 is therefore maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Parekh et al. (U.S. Publication No. 2017/0352038 A1) teaches a method for preserving legal hold data by detecting expiration of retention period, identifying the data as subject to legal hold, transferring it to cold storage, and enforcing restrictions to prevent its deletion or modification.
Wolf et al. (International Publication No. WO 2021/207016 A1) teaches systems and methods that analyze surgical videos by generating procedure statistics, detecting deviations from surgical videos, predicting upcoming events, enabling targeted video review, assessing clinical competency, linking patient records to spatiotemporal data, and assigning surgical teams based on procedure requirements.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KYRA R LAGOY whose telephone number is (703)756-1773. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm EST.
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, Kambiz Abdi can be reached at (571)272-6702. 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.
/K.R.L./Examiner, Art Unit 3685
/KAMBIZ ABDI/Supervisory Patent Examiner, Art Unit 3685
Prosecution Insights