DETAILED ACTION
Priority
The current application claims benefit of provisional applications 63/343069, 63/343071, 63/343072, and 63/343073, filed on May 17th, 2022. Examiner acknowledges the applicant’s claim for priority.
Status of Claims
In the response dated March 9th, 2026, Applicant amended claims 1, 3, 11, 12, and 20. Claims 1-9, 11-18, and 20-23 are pending.
Information Disclosure Statement
The information disclosure statement filed on March 9th, 2026 is being considered by the examiner.
Response to Arguments
In response to the argument put forward in the amendment, Examiner will address them in the order they were presented.
Regarding pages 10-11, Applicant’s arguments regarding the teachings of Moore and Schecter have been considered but are moot in view of the amended claim language.
Regarding pages 11-12, Applicant’s arguments have been considered but are unpersuasive. Applicant describes that Moore does not teach Moore using an encryption engine different than the upstream medical device’s encryption. While Examiner agrees that encryption may partially occur through the medical device’s system, Moore also teaches that encryption may be employed in a number of ways” [0265] including item-level encryption, tag-level encryption, and more. These systems occur separate from the medical device’s internal encryption keys and allow for both centralized encryption as well as device originating encryption. Therefore, Examiner finds the arguments that Moore is silent on the amended claim language unpersuasive.
Regarding page 12, Applicant’s arguments have been considered but are unpersuasive. Applicant argues that the references to not teach selectively decrypting subsets of data. Examiner disagrees. Moore’s teaching in paragraph [1045] describes that the that aggregated medical information from medical devices may be “parsed if desired”. Similarly, paragraph [0312] explains how filtering techniques may employ encryption process to further the filtering process based on protected metrics. This allows for Moore to selectively decrypt and encrypt incoming data rather than requiring excessive computational power to decrypt every message. Therefore, Examiner maintains that Moore teaches the amended claims, as cited in the rejection below.
Regarding pages 13-16, Applicant’s arguments have been considered but are moot in view of the amended claim language.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are: “medical/domain codes annotator component” or “a clinical validation annotator component” or “regulatory compliance annotator component” or “medical device component” or “clinically unvalidated device” in claim 1.
Examiner interprets the “medical/domain codes annotator component” language, under broadest reasonable interpretation, to include a generic computer component capable of processing data.
Examiner interprets the “a clinical validation annotator component” language, under broadest reasonable interpretation, to include a generic computer component capable of processing data.
Examiner interprets the “regulatory compliance annotator component” language, under broadest reasonable interpretation, to include a generic computer component capable of processing data.
Examiner interprets the “clinically unvalidated device” language, under broadest reasonable interpretation, to include a generic computer capable of processing medical data.
Examiner interprets the “medical device component” language, under broadest reasonable interpretation, to include a generic computer component capable of displaying data.
Paragraph [0065] of the specification states “Examples of computer programs or computer code include machine code… that are executed by a computer, an electronic component, or a microprocessor” and supports the claim language interpretations above. Similarly, Figure 2 depicts these components being used in a computer integrated system and also supports this interpretation.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitations interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitations to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
35 USC § 101- Analysis
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-9, 11-18, and 20-23 will be analyzed under 35 U.S.C. 101 to determine subject matter eligibility.
Step 1
The claims recite subject matter within a statutory category as a process, machine, and/or article of manufacture. The following steps will determine subject matter eligibility, that claims 1-20 are nonetheless unpatentable under 35 U.S.C. 101.
Step 2A Prong One
Claim 1 states:
“A coordination gateway of a digital healthcare framework comprising:
a receiver configured to receive encrypted data as a bitstream from a medical device component in the digital healthcare framework, wherein the data includes a plurality of data frames generated by a medical device that aggregates collected physiological sensor data, a unique device identifier (UDI), and a unique user identifier (UUI);
(b) a decryption engine configured to selectively decrypt a subset of the data frames, wherein the remaining data frames are passed as encrypted
(c) an annotation component configured to receive the data frames and tag the received data frames to form annotated physiological sensor data comprising:
(i) a medical/domain codes annotator component configured to:
(1) identify one or more pre-determined code types associated with data received by the receiver, wherein the identifying includes applying code-selection rules based on effective dates for the rules relative to a timestamp of the collected data, and
(2) tag data received by the receiver with the identified one or more pre-determined code types;
(ii) a clinical validation annotator component configured to:
(1) identify clinical validation information regarding whether or not the medical device component that the received data corresponds to is clinically validated, and
(2) tag data received by the receiver with the clinical validation information, the clinical validation information being obtained from a locally stored list, wherein the clinical validation information includes a subset of data indicating that the data received by the receiver originates from a clinically unvalidated device; and
(iii) a regulatory compliance annotator component configured to:
(1) identify regulatory compliance information based on verifying when the medical device component that the received data corresponds to is compliant with one or more regulatory rules, and
(2) tag data received by the receiver with the regulatory compliance information; and
(d) an encryption engine configured to selectively encrypt the annotated physiological sensor data
(c) a transmitter configured to transmit the annotated physiological data outputs of the annotation component to a data distribution gateway of the digital healthcare framework wherein the data distribution gateway allows processing of annotated physiological data that contains the subset of data indicating that the data received by the receiver originates from a clinically unvalidated device.
The broadest reasonable interpretation of these steps includes mental processes and/or human activity because each bolded component can practically be performed by the human mind or with pen and paper. Specifically, the examiner interprets the broadest reasonable interpretation for phrases such as “medical/domain codes annotator component” or “a clinical validation annotator component” or “regulatory compliance annotator component” to be a component of human organization within this healthcare framework. Other than reciting generic computer terms in claim 1 like a “receiver”, a “medical device component”, “data distribution gateway”, or a “transmitter”, nothing in the claims precludes the italicized portions from practically being performed in the mind. For example, but for the “receiver” language, “identify one or more pre-determined code types associated with data,” in the context of this claim encompasses managing human behavior of a healthcare professional categorizing the International Classification of Disease codes of a patient’s disease state. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” or “Human Activity” grouping of abstract ideas. Accordingly, the claim language:
(b) an annotation component configured to receive the data frames and tag the received data frames … comprising:
(i) a medical/domain codes annotator component configured to:
(1) identify one or more pre-determined code types associated with data received …
and
(2) tag data received … with the identified one or more pre-determined code types;
(ii) a clinical validation annotator component configured to:
(1) identify clinical validation information regarding whether or not … the received data corresponds to is clinically validated, and
(2) tag data received …with the clinical validation information, the clinical validation information being obtained from a locally stored list, wherein the clinical validation information includes a subset of data indicating that the data received …
(iii) a regulatory compliance annotator component configured to:
(1) identify regulatory compliance information based on verifying … that the received data corresponds to is compliant with one or more regulatory rules, and
(2) tag data received …with the regulatory compliance information;
as drafted, under the broadest reasonable interpretation, includes multiple abstract ideas that will be identified as a single abstract idea moving forward.
Independent claims 11 and 20 recite similar steps of receiving data frames created by a validated or unvalidated medical device, identifying code types associated with various data, tagging data frames with annotations of physiological sensor data, verifying that the medical device information is complying with various regulations, and transmitting the annotated data to a data distribution gateway to a larger healthcare framework. These claims fall under the same category of an abstract idea, and follow the same rationale, as claim 1.
Dependent claims 2-4, 6-9, 12-13, and 15-18 recite additional subject matter which further narrows or defines the abstract idea embodied in the claims (such as claim 4, reciting particular aspects of how “data corresponds to data transmitted from a healthcare provider, and the medical/domain codes annotator component configured to identify a unique national provider identifier (NPI) associated with the healthcare provider and tag the received data with the NPI” may be performed in the mind but for recitation of generic computer components).
Step 2A Prong Two
This judicial exception is integrated into a practical application. Independent claim 1 recites a combination of elements that receive encrypted physiological data created by a validated or unvalidated medical devices, identify code types associated with various data, tagging data frames with annotations of physiological sensor data, verifying that the medical device information is complying with various regulations, and unencrypting the physiological data, and transmitting the annotated data to a data distribution gateway to a larger healthcare framework. Although each of the collective steps analyzed individually may be viewed as mere pre or post-solution activity, the combination of encrypting physiological sensor data, tagging this data with various clinical information, and supporting the regulatory processing of this information allows for a
The dependent claims recite additional subject matter which further limits claim 1’s material without adding ineligible subject matter and, therefore, follows the same rationale as claim 1.
Thus, based on the aforementioned analysis, claims 1-9, 11-18, and 20-23 recite eligible subject matter under 35 USC 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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-9, 11-18, and 20-23 are rejected under 35 U.S.C. 103 as being unpatentable over Moore (US 20080040151) in view of Schecter (AU2016362517).
Regarding claim 1, Moore teaches.
A coordination gateway ([0127] “gateway” (116)) of a digital healthcare framework ([Figure 31] “healthcare information management system” where the system is a digital healthcare framework)
comprising: a receiver configured to receive encrypted data as a bitstream ([0171] “RSS provides a standard format for the delivery of content through data feeds.” And [0207] “an RSS feed may be encrypted so that it may only be read by a specific type of wireless device, a specific wireless device, or on a specific wireless device only after entry of a password that is issued to a known user of that wireless device.” And [0172] “Although not depicted, a single content source 204 may also have multiple data feeds 202” where receiving data feeds comprise data in the form of a bit stream, commonly known as binary) from a medical device component in the digital healthcare framework, wherein the data includes a plurality of data frames generated by a medical device that aggregates collected physiological sensor data, ([0952] “Other cardiovascular diagnostic and therapeutic devices that may interact with syndicated data in the above manner include but are not limited to a Arrhythmia detector and alarm (including ST-segment measurement and alarm), Blood pressure alarm,… Radiofrequency physiological signal transmitter and receiver” where receiver comprises the physiological sensor data of multiple medical devices in the framework; see also [0286] “As another example, medical information may be produced by a medical device, and the medical device information may be pushed into a data stream” comprises a plurality of data streams) a unique device identifier (UDI), ([0334] “Device-related data, for example pertaining to device-related error, may be stored in a syndicated format. From these syndicated data, for example, it may be possible to create feeds that alert institutions to possible device related problems. Moreover, for example, institutions may record their device-related data in a syndicated format that is shared with an overseeing body.” Where a unique device identifier is device-related data; see optionally [0234] “A syndication message definition may include any or all of the elements of the following standards and drafts, all of which are hereby incorporated in their entirety by reference:… unique identifier (guid)”) and a unique user identifier (UUI); ([0621] “database functions applied to syndicated business management systems may allow a practice manager to compile information about the resources expended in treating a particular condition, or about the resource utilization of a particular physician” where the resource utilization of a particular physician is aggregated by uniquely identifying a user to pieces of equipment; see also [0286] “all information related to a particular topic, person, entity, or the like may be acquired from a range of different data streams and placed into a corresponding pool” where all information regarding a person comprises a unique user identifier)
a decryption engine configured to selectively decrypt a subset of the data frames, wherein the remaining data frames are passed as encrypted ([0265] “Security may impact a number of features of a syndication system. For example, a data stream system may use identity assignment and/or encryption and/or identity authentication and/or decryption by public and private encryption keys for RSS items and similar structured data sets and data streams.” Where the data stream system [comprising a decryption engine] optionally decrypts information)
an annotation component configured to receive the data frames and tag the received data frames to form annotated physiological sensor data, comprising: ([0191] “Data services 410 may be embodied, for example, in a client-side application, a remote application or service, an application layer of an enhanced syndication services protocol stack, as application services deployed, for example, in the services-oriented architecture described below, or a combination of these. Data services 410 may include… any functions associated with data including storing, manipulating, retrieving, transforming, verifying, authenticating, formatting, reformatting, tagging, linking, hyperlinking, reporting, viewing, and so forth.” Where the data services provided via an application layer comprise an annotation component; see also [1059] “A device could record salient information at each step of the treatment process” where the device [i.e., an annotation component] records salient information during the treatment process [i.e., annotates physiological sensor data]; see also [0952] “cardiovascular diagnostic and therapeutic … data may be published, shared, used, received and/or stored locally with the device, and/or in association with a remote architecture (e.g., server, database, etc.) accessible to the device (e.g., through the internet, WAN, LAN, wireless connection, etc.).” where receiving physiological sensor data locally stored within the device may be from multiple medical devices in the framework)
a medical/domain codes annotator component ([0191] “Data services 410 may be embodied, for example, in a client-side application, a remote application or service, an application layer of an enhanced syndication services protocol stack, as application services deployed, for example, in the services-oriented architecture described below, or a combination of these. Data services 410 may include… any functions associated with data including storing, manipulating, retrieving, transforming, verifying, authenticating, formatting, reformatting, tagging, linking, hyperlinking, reporting, viewing, and so forth.” Where the data services provided via an application layer comprise an annotation component; see also [1059] “A device could record salient information at each step of the treatment process” where device comprises a medical domain codes annotator component) configured to:
(2) tag data received by the receiver with the identified one or more pre-determined code types; ([1059] “Information that may be used [to record salient information] may include, but is not limited to, admission time, time of first consultation, health status/diagnosis on intake (e.g., ICD-10 code), the patient's currently prescribed medications, timing of treatment(s), treatment dosages, duration of treatment, time of discharge, and timing of follow-up consultations.” Where the device is the annotator and which identifies then tags predetermined code types)
a clinical validation annotator component ([0323] “Layered over this sequential data infrastructure are the domains of a healthcare institution, each with a potentially unique set of circumstances impacting each step of the data infrastructure. For example, conformance to clinical standards, total quality management, outcomes measurement, accreditation and accountability, healthcare provider training and performance monitoring, cost tracking and cost-effectiveness analysis, patient education, infrastructure monitoring, and others may each share a core set of data needs, but have additional data requirements not shared by the other domains” where infrastructure containing a total quality system management comprises a clinical validation annotator component) configured to: (1) identify clinical validation information regarding whether or not the medical device component that the received data corresponds to is clinically validated; ([0327] “As part of a [Total Quality Management]/[Continuous Quality Improvement] project, data could be collected on each patient who visits the ER within a defined period of time, this data could be combined with other useful information, such as, day of the week, time of day of the visit, injury causing the ER visit, and so on” where a total quality management system is part of the Food and Drug Administration’s clinical validation requirements) and (2) tag data received by the receiver with the clinical validation information, the clinical validation information being obtained from a locally stored list, ([0327] “Syndicated data may be used to interact with information associated with a TQM/CQI project” where the data interaction indicates tagging data; see also [0949] “In embodiments, anesthesiology and critical care diagnostic and therapeutic devices may be able to interact with syndicated data, or publish one or more syndicated feeds. For example, anesthesiology diagnostic and therapeutic devices may be able to publish syndicated data, subscribe to and receive syndicated data feeds, and store syndicated data. This data may be published, shared, used, received and/or stored locally with the device, and/or in association with a remote architecture (e.g., server, database, etc.) accessible to the device (e.g., through the internet, WAN, LAN, wireless connection, etc.). For example, a device such as an ultrasonic air embolism monitor may subscribe to a syndicated data feed that is published, shared, used by the device's manufacturer to inform of device updates, recalls, and the like. This information may be stored locally with the machine, and/or stored on an associated architecture, such as a hospital's central network, where the syndicated information may be reviewed by staff.”) wherein the clinical validation information includes a subset of data indicating that the data received by the receiver originates from a clinically unvalidated device ([0327] “This syndicated data, in turn, could be aggregated at a city, state, or national level for the purposes of … accreditation, and so forth.” Where accreditation on the national level is clinically validating a device)
and a regulatory compliance annotator component ([0600] “As another example, a syndicated information management system may permit patients to interact with other patients or healthcare providers via RSS feed 202, web feed, RSS stream or RSS channel to obtain or exchange information about a particular procedure or medical condition. As described herein, HIPAA and other regulatory frameworks may require special identification properties, or restricted or conditional access properties for information to be exchanged in this way. Interactions with the syndicated medical information management system and the properties restricting this access may be logged, recorded and permanently archived for legal purposes or to demonstrate compliance with applicable regulations.” Comprises a compliance annotator component) configured to: (1) identify regulatory compliance information based on verifying when the medical device component that the received data corresponds to is compliant with one or more regulatory rules, ([0627] “all participants have access to a complex mix of data sources that may include scientific background information, experimental data, clinical data about disease states or targets, laboratory notes, regulatory requirements and the like. Researchers may collaborate to produce a publication or other report concerning a study and its results. Researchers working together on a project may also interact with third parties (collectively termed "reviewers") who review, evaluate and/or comment upon the research, its data or its conclusions.”; see also [0927] “regulatory bodies, may interact with syndicated summaries of intervention complication rates, medication side effects … and the like through the use of an RSS-enabled application”)
and (2) tag data received by the receiver (See “receiver” above) with the regulatory compliance information; ([0951] “For example, a device such as an echocardiograph may subscribe to a syndicated data feed that is published, shared, used by the device's manufacturer to inform of device updates, recalls, and the like…. The device may also publish a syndicated data feed. This data may include, but is not limited to, the performance of the device (e.g., consistency with established safety parameters)” where subscribing tags regulatory compliance information)
(d) an encryption engine configured to selectively encrypt the annotated physiological sensor data, ([0312], [0286] “As another example, medical information may be produced by a medical device, and the medical device information may be pushed into a data stream” comprises a plurality of data streams; see also [0265] “Security may impact a number of features of a syndication system. For example, a data stream system may use identity assignment and/or encryption and/or identity authentication and/or decryption by public and private encryption keys for RSS items and similar structured data sets and data streams.” Where the data stream system [comprising an encryption engine] optionally encrypts information) the encryption engine being different from an encryption mechanism associated with the medical device component that originally encrypted the received data frames; ([0270] "In another aspect, a series of encryption keys may be used by the source and various aggregators or other intermediaries" occurs outside of the medical device encryption)
a transmitter ([0952] “Radiofrequency physiological signal transmitter and receiver” where transceiver is a medical device in the framework outputs the annotation component data) configured to transmit the annotated physiological data to a data distribution gateway of the digital healthcare framework ([0952] “cardiovascular diagnostic and therapeutic … data may be published, shared, used, received and/or stored locally with the device, and/or in association with a remote architecture (e.g., server, database, etc.) accessible to the device (e.g., through the internet, WAN, LAN, wireless connection, etc.).” where receiving physiological sensor data locally stored within the device may be from multiple medical devices in the framework) wherein the data distribution gateway allows processing of annotated physiological data ([0951] In embodiments, cardiovascular diagnostic and therapeutic devices may be able to interact with syndicated data, or publish one or more syndicated feeds. For example, cardiovascular diagnostic and therapeutic devices may be able to publish syndicated data, subscribe to and receive syndicated data feeds, and store syndicated data. This data may be published, shared, used, received and/or stored locally with the device, and/or in association with a remote architecture (e.g., server, database, etc.) accessible to the device (e.g., through the internet, WAN, LAN, wireless connection, etc.). For example, a device such as an echocardiograph may subscribe to a syndicated data feed that is published, shared, used by the device's manufacturer to inform of device updates, recalls, and the like. This information may be stored locally with the machine, and/or stored on an associated architecture, such as a hospital's central network, where the syndicated information may be reviewed by staff. The device may also publish a syndicated data feed. This data may include, but is not limited to, the performance of the device (e.g., consistency with established safety parameters), the amount of device usage, personnel using the device, patients with whom the device was operated, and so forth.” where the remote architecture [i.e., an annotation component in connection with a gateway component] records and publishes a syndicated data feed during the treatment process [i.e., annotates physiological sensor data]) that contains the subset of data indicating that the data received by the receiver originates from a clinically unvalidated device ([00327]”This syndicated data, in turn, could be aggregated at a city, state, or national level for the purposes of … accreditation, and so forth.” Where aggregating information for the purpose of accreditation is clinically validating a device; see optionally [0662] “The syndicated research reporting data may include submissions for peer review, submissions for regulatory approval, disclosures to patient or community groups, reports to business sponsors, applications for grants, requests for research proposals, requests for grant applications and the like.” Where submitting information for regulatory approval denotes a clinically unvalidated device)
Regarding claim 1, Moore is silent on, as taught by Schecter:
(1) identify one or more pre-determined code types associated with data received by the receiver, wherein the identifying includes applying code-selection rules based on a type of the physiological sensor data and a value of the physiological sensor data, effective dates for the rules relative to a timestamp of the collected data ([0102] “physiological measurements serve to verify or help to determine the condition of the corresponding subject in conjunction with the data from the measurement devices” and [0018] “The respective data element is interrogated to determine a condition of the medical device or to determine a condition of the corresponding subject. Responsive to the interrogating, (i) a first medical code that indicates that the condition of the medical device or the condition of the corresponding subject has been evaluated.” Where a condition of a medical device and a subject are based on the type and value of physiological sensor data)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Moore with the teachings of Schecter, with a reasonable expectation of success, by explicitly applying code selection rules based on a type and value of physiological sensor data that corresponds to a medical device and clinical subject. This would have ensured a higher quality of care and allowed for more accurate information analytics by providing explicit annotation codes while information is continuously entered into this system. Schecter is adaptable to Moore as both inventions ensure compliance in a healthcare setting for medical devices by creating a network of computing systems to syndicate data. Moore would have found Schecter’s teaching while finding solutions to the well understood problem that “there is often no organized or efficient means for evaluating whether a health care institution is checking such medical devices on a regular basis”, as seen in paragraph [0003].
Regarding claim 2, Moore-Schecter teaches all of the limitations of claim 1. Moore also teaches:
wherein the one or more pre-determined code types are any of the following: a code associated with a medical procedure, a code associated with a disease classification ([1059] “Information that may be used [to record salient information] may include, but is not limited to, admission time, time of first consultation, health status/diagnosis on intake (e.g., ICD-10 code), the patient's currently prescribed medications, timing of treatment(s), treatment dosages, duration of treatment, time of discharge, and timing of follow-up consultations.”, where the ICD-10 code is a disease classification standard), a code associated with a drug, or a code associated with a payment category. ([0570] “diagnoses may be identified by numeric codes, for example those provided by the International Classification of Diseases ("ICD") coding systems, most recently revised as ICD-10, by Diagnostic Related Groups ("DRG") codes, and the like, and procedures may be identified by numeric codes, for example those provided by the AMA Current Procedure Terminology ("CPT") coding system and the like”)
Regarding claim 3, Moore-Schecter teaches all of the limitations of claim 1. Moore also teaches
wherein the one or more pre-determined code types is a Current Procedural Terminology (CPT) code. ([0570] “diagnoses may be identified by numeric codes, for example those provided by … the AMA Current Procedure Terminology ("CPT") coding system and the like”)
Regarding claim 4, Moore-Schecter teaches all of the limitations of claim 1. Moore also teaches:
wherein the received data corresponds to data transmitted from a healthcare provider, and the medical/domain codes annotator component configured to identify a unique national provider identifier (NPI) associated with the healthcare provider and tag the received data with the NPI. ([0340] “In embodiments, healthcare institutions may interact with syndicated evidence-based information, such as… training and credentials” where syndicated data is a is data transmitted from a healthcare provider and [0421] “Individuals … may need to offer credentials indicating that they are licensed physicians.” Where licensed physician credentials are an NPI identified and tagged by the annotator)
Regarding claim 5, Moore-Schecter teaches all of the limitations of claim 1. Moore also teaches:
wherein the clinical validation annotator component communicates with an external source over a network, the external source providing the clinical validation information ([0340] “In embodiments, healthcare institutions may interact with syndicated evidence-based information, such as medical research, clinical trial findings, case studies, peer-reviewed articles, academic presentations, and the like, through the use of an application 406” ; see also [0126] “FIG. 1 shows a network for providing a syndicated data stream such as an RSS stream.”)
Regarding claim 6, Moore-Schecter teaches all of the limitations of claim 1. Moore also teaches:
wherein the clinical validation information is locally stored within the coordination gateway ([0127] “gateway” (116)), where the gateway is comprises a connection with the clinical validation information).
Regarding claim 7, Moore-Schecter teaches all of the limitations of claim 1. Moore also teaches:
wherein the regulatory compliance information comprises recall information associated with the medical device component ([0927]“regulatory bodies, may interact with syndicated summaries of intervention complication rates, medication side effects … and the like through the use of an RSS-enabled application” and[0951] “For example, a device such as an echocardiograph may subscribe to a syndicated data feed that is published, shared, used by the device's manufacturer to inform of device updates, recalls, and the like…. The device may also publish a syndicated data feed. This data may include, but is not limited to, the performance of the device (e.g., consistency with established safety parameters)” see also Figure 31’s “MRI” and other devices connected to the data collection facility, which tags data).
Regarding claim 8, Moore-Schecter teaches all of the limitations of claim 1. Moore also teaches:
wherein each of the medical/domain codes annotator, the clinical validation annotator, and the regulatory compliance annotator operate independently ([0640] “As a further example, in certain embodiments all meaningful patient identifiers may be held in a syndicated pod independent of other clinical data” where the pool of data denotes annotator independence)
Regarding claim 9, Moore-Schecter teaches all of the limitations of claim 8. Moore also teaches:
wherein the medical/domain codes annotator component, the clinical validation annotator component, and the regulatory compliance annotator component operate sequentially, out of order, or in parallel ([0323] “Layered over this sequential data infrastructure are the domains of a healthcare institution, each with a potentially unique set of circumstances impacting each step of the data infrastructure.” Where the infrastructure is the annotators comprising the system)
Regarding claim 11, Moore teaches:
A method as implemented in a coordination gateway ( [0127] “gateway” (116)) of a digital healthcare framework, ([Figure 31] “healthcare information management system” where the system is a digital healthcare framework) the coordination gateway comprising an annotation component, configured to receive encrypted data frames and tag the received data frames to form annotated physiological sensor data, ([0191] “Data services 410 may be embodied, for example, in a client-side application, a remote application or service, an application layer of an enhanced syndication services protocol stack, as application services deployed, for example, in the services oriented architecture described below, or a combination of these. Data services 410 may include… any functions associated with data including storing, manipulating, retrieving, transforming, verifying, authenticating, formatting, reformatting, tagging, linking, hyperlinking, reporting, viewing, and so forth.” Where the data services provided via an application layer comprise an annotation component; see also [1059] “A device could record salient information at each step of the treatment process” where the device [i.e., an annotation component] records salient information during the treatment process [i.e., annotates physiological sensor data]; see also [0952] “cardiovascular diagnostic and therapeutic … data may be published, shared, used, received and/or stored locally with the device, and/or in association with a remote architecture (e.g., server, database, etc.) accessible to the device (e.g., through the internet, WAN, LAN, wireless connection, etc.).” where receiving physiological sensor data locally stored within the device may be from multiple medical devices in the framework; see also [0207] “an RSS feed may be encrypted so that it may only be read by a specific type of wireless device, a specific wireless device, or on a specific wireless device only after entry of a password that is issued to a known user of that wireless device.” Where communication pf physiological data is encrypted) the annotation component comprising a decryption engine, ([0265] “Security may impact a number of features of a syndication system. For example, a data stream system may use identity assignment and/or encryption and/or identity authentication and/or decryption by public and private encryption keys for RSS items and similar structured data sets and data streams.” Where the data stream system [comprising a decryption engine] optionally decrypts information) a medical/domain codes annotator component, ([0191] “Data services 410 may be embodied, for example, in a client-side application, a remote application or service, an application layer of an enhanced syndication services protocol stack, as application services deployed, for example, in the services-oriented architecture described below, or a combination of these. Data services 410 may include… any functions associated with data including storing, manipulating, retrieving, transforming, verifying, authenticating, formatting, reformatting, tagging, linking, hyperlinking, reporting, viewing, and so forth.” Where the data services provided via an application layer comprise a domain codes annotation component; see also [1059] “A device could record salient information at each step of the treatment process” where device comprises a medical domain codes annotator component) a clinical validation annotator component, ([0323] “Layered over this sequential data infrastructure are the domains of a healthcare institution, each with a potentially unique set of circumstances impacting each step of the data infrastructure. For example, conformance to clinical standards, total quality management, outcomes measurement, accreditation and accountability, healthcare provider training and performance monitoring, cost tracking and cost-effectiveness analysis, patient education, infrastructure monitoring, and others may each share a core set of data needs, but have additional data requirements not shared by the other domains” where infrastructure containing a total quality system management comprises a clinical validation annotator component) a regulatory compliance annotator component, (([0600] “As another example, a syndicated information management system may permit patients to interact with other patients or healthcare providers via RSS feed 202, web feed, RSS stream or RSS channel to obtain or exchange information about a particular procedure or medical condition. As described herein, HIPAA and other regulatory frameworks may require special identification properties, or restricted or conditional access properties for information to be exchanged in this way. Interactions with the syndicated medical information management system and the properties restricting this access may be logged, recorded and permanently archived for legal purposes or to demonstrate compliance with applicable regulations.” Comprises a compliance annotator component) and an encryption engine the method comprising: ([0286] “As another example, medical information may be produced by a medical device, and the medical device information may be pushed into a data stream” comprises a plurality of data streams; see also [0265] “Security may impact a number of features of a syndication system. For example, a data stream system may use identity assignment and/or encryption and/or identity authentication and/or decryption by public and private encryption keys for RSS items and similar structured data sets and data streams.” Where the data stream system [comprising an encryption engine] optionally encrypts information)
(a) receiving data, as a bitstream, ([0171] “RSS provides a standard format for the delivery of content through data feeds.” And [0207] “an RSS feed may be encrypted so that it may only be read by a specific type of wireless device, a specific wireless device, or on a specific wireless device only after entry of a password that is issued to a known user of that wireless device.” And [0172] “Although not depicted, a single content source 204 may also have multiple data feeds 202” where receiving data feeds comprise data in the form of a bit stream, commonly known as binary) from a medical device component in the digital healthcare framework, wherein the data includes one or more data frames generated by a medical device that aggregates collected physiological sensor data, ([0952] “Other cardiovascular diagnostic and therapeutic devices that may interact with syndicated data in the above manner include but are not limited to a Arrhythmia detector and alarm (including ST-segment measurement and alarm), Blood pressure alarm,… Radiofrequency physiological signal transmitter and receiver” where receiver comprises the physiological sensor data of multiple medical devices in the framework; see also [0286] “As another example, medical information may be produced by a medical device, and the medical device information may be pushed into a data stream” comprises a plurality of data streams) a unique device identifier ([0334] “Device-related data, for example pertaining to device-related error, may be stored in a syndicated format. From these syndicated data, for example, it may be possible to create feeds that alert institutions to possible device related problems. Moreover, for example, institutions may record their device-related data in a syndicated format that is shared with an overseeing body.” Where a unique device identifier is device-related data; see optionally [0234] “A syndication message definition may include any or all of the elements of the following standards and drafts, all of which are hereby incorporated in their entirety by reference:… unique identifier (guid)”) and a unique user identifier (UUI); ([0621] “database functions applied to syndicated business management systems may allow a practice manager to compile information about the resources expended in treating a particular condition, or about the resource utilization of a particular physician” where the resource utilization of a particular physician is aggregated by uniquely identifying a user to pieces of equipment; see also [0286] “all information related to a particular topic, person, entity, or the like may be acquired from a range of different data streams and placed into a corresponding pool” where all information regarding a person comprises a unique user identifier)
(b) selectively decrypting, via the encryption engine, the one or more data frames, wherein the remaining data frames are passed as encrypted; ([0265] “Security may impact a number of features of a syndication system. For example, a data stream system may use identity assignment and/or encryption and/or identity authentication and/or decryption by public and private encryption keys for RSS items and similar structured data sets and data streams.” Where the data stream system [comprising a decryption engine] optionally decrypts information)
tagging, via the medical/domain codes annotator component, data received by the receiver with the identified one or more pre-determined code types; ([1059] “Information that may be used [to record salient information] may include, but is not limited to, admission time, time of first consultation, health status/diagnosis on intake (e.g., ICD-10 code), the patient's currently prescribed medications, timing of treatment(s), treatment dosages, duration of treatment, time of discharge, and timing of follow-up consultations.” Where the device is the annotator and which identifies then tags predetermined code types)
(d) identifying, via the clinical validation annotator component, clinical validation information regarding whether or not the medical device component that the received data corresponds to is clinically validated, ([0327] “As part of a [Total Quality Management]/[Continuous Quality Improvement] project, data could be collected on each patient who visits the ER within a defined period of time, this data could be combined with other useful information, such as, day of the week, time of day of the visit, injury causing the ER visit, and so on” where a total quality management system is part of the Food and Drug Administration’s clinical validation requirements) and tagging, via the clinical validation annotator component, data received by the receiver with the clinical validation information, the clinical validation information being obtained from a locally stored list ([0327] “Syndicated data may be used to interact with information associated with a TQM/CQI project” where the data interaction indicates tagging data; see also [0949] “In embodiments, anesthesiology and critical care diagnostic and therapeutic devices may be able to interact with syndicated data, or publish one or more syndicated feeds. For example, anesthesiology diagnostic and therapeutic devices may be able to publish syndicated data, subscribe to and receive syndicated data feeds, and store syndicated data. This data may be published, shared, used, received and/or stored locally with the device, and/or in association with a remote architecture (e.g., server, database, etc.) accessible to the device (e.g., through the internet, WAN, LAN, wireless connection, etc.). For example, a device such as an ultrasonic air embolism monitor may subscribe to a syndicated data feed that is published, shared, used by the device's manufacturer to inform of device updates, recalls, and the like. This information may be stored locally with the machine, and/or stored on an associated architecture, such as a hospital's central network, where the syndicated information may be reviewed by staff.”) wherein the clinical validation information includes a subset of data indicating that the data received by the receiver originates from a clinically unvalidated device; ([00327]”This syndicated data, in turn, could be aggregated at a city, state, or national level for the purposes of … accreditation, and so forth.” Where aggregating information for the purpose of accreditation is clinically validating a device; see optionally [0662] “The syndicated research reporting data may include submissions for peer review, submissions for regulatory approval, disclosures to patient or community groups, reports to business sponsors, applications for grants, requests for research proposals, requests for grant applications and the like.” Where submitting information for regulatory approval denotes a clinically unvalidated device)
(e) identifying, via the regulatory compliance annotator component, regulatory compliance information (([0600] “As another example, a syndicated information management system may permit patients to interact with other patients or healthcare providers via RSS feed 202, web feed, RSS stream or RSS channel to obtain or exchange information about a particular procedure or medical condition. As described herein, HIPAA and other regulatory frameworks may require special identification properties, or restricted or conditional access properties for information to be exchanged in this way. Interactions with the syndicated medical information management system and the properties restricting this access may be logged, recorded and permanently archived for legal purposes or to demonstrate compliance with applicable regulations.” Where Comprises a compliance annotator component identifying compliance information via special identification properties) based on verifying when the medical device component that the received data corresponds to is compliant with one or more regulatory rules, ([0627] “all participants have access to a complex mix of data sources that may include scientific background information, experimental data, clinical data about disease states or targets, laboratory notes, regulatory requirements and the like. Researchers may collaborate to produce a publication or other report concerning a study and its results. Researchers working together on a project may also interact with third parties (collectively termed "reviewers") who review, evaluate and/or comment upon the research, its data or its conclusions.”; see also [0927]“regulatory bodies, may interact with syndicated summaries of intervention complication rates, medication side effects … and the like through the use of an RSS-enabled application”) and tagging, via the regulatory compliance annotator component, data received by the receiver (See “receiver” above) with the regulatory compliance information; ([0951] “For example, a device such as an echocardiograph may subscribe to a syndicated data feed that is published, shared, used by the device's manufacturer to inform of device updates, recalls, and the like…. The device may also publish a syndicated data feed. This data may include, but is not limited to, the performance of the device (e.g., consistency with established safety parameters)” where subscribing tags regulatory compliance information) and
(f) an encryption engine configured to selectively encrypt the annotated physiological sensor data, ([0312], [0286] “As another example, medical information may be produced by a medical device, and the medical device information may be pushed into a data stream” comprises a plurality of data streams; see also [0265] “Security may impact a number of features of a syndication system. For example, a data stream system may use identity assignment and/or encryption and/or identity authentication and/or decryption by public and private encryption keys for RSS items and similar structured data sets and data streams.” Where the data stream system [comprising an encryption engine] optionally encrypts information) the encryption engine being different from an encryption mechanism associated with the medical device component that originally encrypted the received data frames; ([0270] "In another aspect, a series of encryption keys may be used by the source and various aggregators or other intermediaries" occurs outside of the medical device encryption)
(g) transmitting ([0952] “Radiofrequency physiological signal transmitter and receiver” where transceiver is a medical device in the framework outputs the annotation component data) annotated physiological data to a data distribution gateway of the digital healthcare framework([0951] “cardiovascular diagnostic and therapeutic … data may be published, shared, used, received and/or stored locally with the device, and/or in association with a remote architecture (e.g., server, database, etc.) accessible to the device (e.g., through the internet, WAN, LAN, wireless connection, etc.).” where receiving physiological sensor data locally stored within the device may be from multiple medical devices in the framework), wherein the data distribution gateway allows processing of annotated physiological data ([0951] In embodiments, cardiovascular diagnostic and therapeutic devices may be able to interact with syndicated data, or publish one or more syndicated feeds. For example, cardiovascular diagnostic and therapeutic devices may be able to publish syndicated data, subscribe to and receive syndicated data feeds, and store syndicated data. This data may be published, shared, used, received and/or stored locally with the device, and/or in association with a remote architecture (e.g., server, database, etc.) accessible to the device (e.g., through the internet, WAN, LAN, wireless connection, etc.). For example, a device such as an echocardiograph may subscribe to a syndicated data feed that is published, shared, used by the device's manufacturer to inform of device updates, recalls, and the like. This information may be stored locally with the machine, and/or stored on an associated architecture, such as a hospital's central network, where the syndicated information may be reviewed by staff. The device may also publish a syndicated data feed. This data may include, but is not limited to, the performance of the device (e.g., consistency with established safety parameters), the amount of device usage, personnel using the device, patients with whom the device was operated, and so forth.” where the remote architecture [i.e., an annotation component in connection with a gateway component] records and publishes a syndicated data feed during the treatment process [i.e., annotates physiological sensor data]) that contains the subset of data indicating that the data received by the receiver originates from a clinically unvalidated device ([00327]”This syndicated data, in turn, could be aggregated at a city, state, or national level for the purposes of … accreditation, and so forth.” Where aggregating information for the purpose of accreditation is clinically validating a device; see optionally [0662] “The syndicated research reporting data may include submissions for peer review, submissions for regulatory approval, disclosures to patient or community groups, reports to business sponsors, applications for grants, requests for research proposals, requests for grant applications and the like.” Where submitting information for regulatory approval denotes a clinically unvalidated device)
Regarding claim 1, Moore is silent on, as taught by Schecter:
(c) identifying, via the medical/domain codes annotator component, one or more pre-determined code types associated with data received by the receiver, wherein the identifying includes applying code-selection rules based a type of the physiological sensor data and a value of the physiological sensor data, ([0102] “physiological measurements serve to verify or help to determine the condition of the corresponding subject in conjunction with the data from the measurement devices” and [0018] “The respective data element is interrogated to determine a condition of the medical device or to determine a condition of the corresponding subject. Responsive to the interrogating, (i) a first medical code that indicates that the condition of the medical device or the condition of the corresponding subject has been evaluated.” Where a condition of a medical device and a subject are based on the type and value of physiological sensor data)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Moore with the teachings of Schecter, with a reasonable expectation of success, by explicitly applying code selection rules based on a type and value of physiological sensor data that corresponds to a medical device and clinical subject. This would have ensured a higher quality of care and allowed for more accurate information analytics by providing explicit annotation codes while information is continuously entered into this system. Schecter is adaptable to Moore as both inventions ensure compliance in a healthcare setting for medical devices by creating a network of computing systems to syndicate data. Moore would have found Schecter’s teaching while finding solutions to the well understood problem that “there is often no organized or efficient means for evaluating whether a health care institution is checking such medical devices on a regular basis”, as seen in paragraph [0003].
Regarding claim 12, Moore-Schecter teaches all of the limitations of claim 11. Moore also teaches:
wherein the one or more pre-determined code types is a Current Procedural Terminology (CPT) code. ([0570] “diagnoses may be identified by numeric codes, for example those provided by … the AMA Current Procedure Terminology ("CPT") coding system and the like”)
Regarding claim 13, Moore-Schecter teaches all of the limitations of claim 11. Moore also teaches:
wherein the received data corresponds to data transmitted from a healthcare provider, and the medical/domain codes annotator component configured to identify a unique national provider identifier (NPI) associated with the healthcare provider and tag the received data with the NPI. ([0340] “In embodiments, healthcare institutions may interact with syndicated evidence-based information, such as… training and credentials” where syndicated data is a is data transmitted from a healthcare provider and [0421] “Individuals … may need to offer credentials indicating that they are licensed physicians.” Where licensed physician credentials are an NPI identified and tagged by the annotator)
Regarding claim 14, Moore-Schecter teaches all of the limitations of claim 11. Moore also teaches:
wherein the clinical validation annotator component communicates with an external source over a network, the external source providing the clinical validation information ([0340] “In embodiments, healthcare institutions may interact with syndicated evidence-based information, such as medical research, clinical trial findings, case studies, peer-reviewed articles, academic presentations, and the like, through the use of an application 406” ; see also [0126] “FIG. 1 shows a network for providing a syndicated data stream such as an RSS stream.”)
Regarding claim 15, Moore-Schecter teaches all of the limitations of claim 11. Moore also teaches:
wherein the clinical validation information is locally stored within the coordination gateway (see [0951] “servers” above, where the servers [i.e., gateway] is local).
Regarding claim 16, Moore-Schecter teaches all of the limitations of claim 11. Moore also teaches:
wherein the regulatory compliance information comprises recall information associated with the medical device component ([0927]“regulatory bodies, may interact with syndicated summaries of intervention complication rates, medication side effects … and the like through the use of an RSS-enabled application” and[0951] “For example, a device such as an echocardiograph may subscribe to a syndicated data feed that is published, shared, used by the device's manufacturer to inform of device updates, recalls, and the like…. The device may also publish a syndicated data feed. This data may include, but is not limited to, the performance of the device (e.g., consistency with established safety parameters)” see also Figure 31’s “MRI” and other devices connected to the data collection facility, which tags data).
Regarding claim 17, Moore-Schecter teaches all of the limitations of claim 11. Moore also teaches:
wherein each of the medical/domain codes annotator, the clinical validation annotator, and the regulatory compliance annotator operate independently ([0640] “As a further example, in certain embodiments all meaningful patient identifiers may be held in a syndicated pod independent of other clinical data” where the pool of data denotes annotator independence).
Regarding claim 18, Moore-Schecter teaches all of the limitations of claim 17. Moore also teaches:
wherein the medical/domain codes annotator component, the clinical validation annotator component, and the regulatory compliance annotator component operate sequentially, out of order, or in parallel ([0323] “Layered over this sequential data infrastructure are the domains of a healthcare institution, each with a potentially unique set of circumstances impacting each step of the data infrastructure.” Where the infrastructure is the annotators comprising the system).
Regarding claim 20, Moore teaches:
An article of manufacture comprising non-transitory computer storage medium storing computer readable program code which, when executed by a computer, ([0088] Each aspect of the foregoing may be embodied in one or more of a client-side application, a server-side application, one or more semiconductor devices, a computer program product embodied in a computer readable medium,”) implements a method as implemented in a coordination gateway ([0127] “gateway” (116) where gateway comprises computer storage medium) of a digital healthcare framework, ([Figure 31] “healthcare information management system” where the system is a digital healthcare framework) the coordination gateway comprising an annotation component configured to receive the encrypted data frames and tag the received data frames to form annotated physiological sensor data, ([0191] “Data services 410 may be embodied, for example, in a client-side application, a remote application or service, an application layer of an enhanced syndication services protocol stack, as application services deployed, for example, in the services oriented architecture described below, or a combination of these. Data services 410 may include… any functions associated with data including storing, manipulating, retrieving, transforming, verifying, authenticating, formatting, reformatting, tagging, linking, hyperlinking, reporting, viewing, and so forth.” Where the data services provided via an application layer comprise an annotation component; see also [1059] “A device could record salient information at each step of the treatment process” where the device [i.e., an annotation component] records salient information during the treatment process [i.e., annotates physiological sensor data]; see also [0952] “cardiovascular diagnostic and therapeutic … data may be published, shared, used, received and/or stored locally with the device, and/or in association with a remote architecture (e.g., server, database, etc.) accessible to the device (e.g., through the internet, WAN, LAN, wireless connection, etc.).” where receiving physiological sensor data locally stored within the device may be from multiple medical devices in the framework; see also [0207] “an RSS feed may be encrypted so that it may only be read by a specific type of wireless device, a specific wireless device, or on a specific wireless device only after entry of a password that is issued to a known user of that wireless device.” Where communication pf physiological data is encrypted) the annotation component comprising a decryption engine, ([0265] “Security may impact a number of features of a syndication system. For example, a data stream system may use identity assignment and/or encryption and/or identity authentication and/or decryption by public and private encryption keys for RSS items and similar structured data sets and data streams.” Where the data stream system [comprising a decryption engine] optionally decrypts information) a medical/domain codes annotator component, ([0191] “Data services 410 may be embodied, for example, in a client-side application, a remote application or service, an application layer of an enhanced syndication services protocol stack, as application services deployed, for example, in the services-oriented architecture described below, or a combination of these. Data services 410 may include… any functions associated with data including storing, manipulating, retrieving, transforming, verifying, authenticating, formatting, reformatting, tagging, linking, hyperlinking, reporting, viewing, and so forth.” Where the data services provided via an application layer comprise a domain codes annotation component; see also [1059] “A device could record salient information at each step of the treatment process” where device comprises a medical domain codes annotator component) a clinical validation annotator component, ([0323] “Layered over this sequential data infrastructure are the domains of a healthcare institution, each with a potentially unique set of circumstances impacting each step of the data infrastructure. For example, conformance to clinical standards, total quality management, outcomes measurement, accreditation and accountability, healthcare provider training and performance monitoring, cost tracking and cost-effectiveness analysis, patient education, infrastructure monitoring, and others may each share a core set of data needs, but have additional data requirements not shared by the other domains” where infrastructure containing a total quality system management comprises a clinical validation annotator component) a regulatory compliance annotator component, (([0600] “As another example, a syndicated information management system may permit patients to interact with other patients or healthcare providers via RSS feed 202, web feed, RSS stream or RSS channel to obtain or exchange information about a particular procedure or medical condition. As described herein, HIPAA and other regulatory frameworks may require special identification properties, or restricted or conditional access properties for information to be exchanged in this way. Interactions with the syndicated medical information management system and the properties restricting this access may be logged, recorded and permanently archived for legal purposes or to demonstrate compliance with applicable regulations.” Comprises a compliance annotator component) and an encryption engine the medium comprising: ([0286] “As another example, medical information may be produced by a medical device, and the medical device information may be pushed into a data stream” comprises a plurality of data streams; see also [0265] “Security may impact a number of features of a syndication system. For example, a data stream system may use identity assignment and/or encryption and/or identity authentication and/or decryption by public and private encryption keys for RSS items and similar structured data sets and data streams.” Where the data stream system [comprising an encryption engine] optionally encrypts information)
(a) computer readable program code receiving data, as a bitstream, ([0171] “RSS provides a standard format for the delivery of content through data feeds.” And [0207] “an RSS feed may be encrypted so that it may only be read by a specific type of wireless device, a specific wireless device, or on a specific wireless device only after entry of a password that is issued to a known user of that wireless device.” And [0172] “Although not depicted, a single content source 204 may also have multiple data feeds 202” where receiving data feeds comprise data in the form of a bit stream, commonly known as binary) from a medical device component in the digital healthcare framework, wherein the data includes one or more data frames generated by a medical device that aggregates collected physiological sensor data, ([0952] “Other cardiovascular diagnostic and therapeutic devices that may interact with syndicated data in the above manner include but are not limited to a Arrhythmia detector and alarm (including ST-segment measurement and alarm), Blood pressure alarm,… Radiofrequency physiological signal transmitter and receiver” where receiver comprises the physiological sensor data of multiple medical devices in the framework; see also [0286] “As another example, medical information may be produced by a medical device, and the medical device information may be pushed into a data stream” comprises a plurality of data streams) a unique device identifier ([0334] “Device-related data, for example pertaining to device-related error, may be stored in a syndicated format. From these syndicated data, for example, it may be possible to create feeds that alert institutions to possible device related problems. Moreover, for example, institutions may record their device-related data in a syndicated format that is shared with an overseeing body.” Where a unique device identifier is device-related data; see optionally [0234] “A syndication message definition may include any or all of the elements of the following standards and drafts, all of which are hereby incorporated in their entirety by reference:… unique identifier (guid)”) and a unique user identifier (UUI); ([0621] “database functions applied to syndicated business management systems may allow a practice manager to compile information about the resources expended in treating a particular condition, or about the resource utilization of a particular physician” where the resource utilization of a particular physician is aggregated by uniquely identifying a user to pieces of equipment; see also [0286] “all information related to a particular topic, person, entity, or the like may be acquired from a range of different data streams and placed into a corresponding pool” where all information regarding a person comprises a unique user identifier)
(b) computer readable program code selectively decrypting, via the decryption engine, the one or more data frames, wherein the remaining data frames are passed as encrypted; ([0265] “Security may impact a number of features of a syndication system. For example, a data stream system may use identity assignment and/or encryption and/or identity authentication and/or decryption by public and private encryption keys for RSS items and similar structured data sets and data streams.” Where the data stream system [comprising a decryption engine] optionally decrypts information)
and computer readable program code tagging, via the medical/domain codes annotator component, data received by the receiver with the identified one or more pre-determined code types; ([1059] “Information that may be used [to record salient information] may include, but is not limited to, admission time, time of first consultation, health status/diagnosis on intake (e.g., ICD-10 code), the patient's currently prescribed medications, timing of treatment(s), treatment dosages, duration of treatment, time of discharge, and timing of follow-up consultations.” Where information is identified then tagged as predetermined code types)
(d) computer readable program code identifying, via the clinical validation annotator component, clinical validation information regarding whether or not the medical device component that the received data corresponds to is clinically validated, ([0327] “As part of a [Total Quality Management]/[Continuous Quality Improvement] project, data could be collected on each patient who visits the ER within a defined period of time, this data could be combined with other useful information, such as, day of the week, time of day of the visit, injury causing the ER visit, and so on” where a total quality management system is part of the Food and Drug Administration’s clinical validation requirements and the data is processed through code) and computer readable program code tagging, via the clinical validation annotator component, data received by the receiver with the clinical validation information, the clinical validation information being obtained from a locally stored list, ([0327] “Syndicated data may be used to interact with information associated with a TQM/CQI project” where the data interaction indicates tagging data; see also [0949] “In embodiments, anesthesiology and critical care diagnostic and therapeutic devices may be able to interact with syndicated data, or publish one or more syndicated feeds. For example, anesthesiology diagnostic and therapeutic devices may be able to publish syndicated data, subscribe to and receive syndicated data feeds, and store syndicated data. This data may be published, shared, used, received and/or stored locally with the device, and/or in association with a remote architecture (e.g., server, database, etc.) accessible to the device (e.g., through the internet, WAN, LAN, wireless connection, etc.). For example, a device such as an ultrasonic air embolism monitor may subscribe to a syndicated data feed that is published, shared, used by the device's manufacturer to inform of device updates, recalls, and the like. This information may be stored locally with the machine, and/or stored on an associated architecture, such as a hospital's central network, where the syndicated information may be reviewed by staff.”) wherein the clinical validation information includes a subset of data indicating that the data received by the receiver originates from a clinically unvalidated device; ([00327]”This syndicated data, in turn, could be aggregated at a city, state, or national level for the purposes of … accreditation, and so forth.” Where aggregating information for the purpose of accreditation is clinically validating a device; see optionally [0662] “The syndicated research reporting data may include submissions for peer review, submissions for regulatory approval, disclosures to patient or community groups, reports to business sponsors, applications for grants, requests for research proposals, requests for grant applications and the like.” Where submitting information for regulatory approval denotes a clinically unvalidated device)
(e) computer readable program code identifying, via the regulatory compliance annotator component, ([0600] “As another example, a syndicated information management system may permit patients to interact with other patients or healthcare providers via RSS feed 202, web feed, RSS stream or RSS channel to obtain or exchange information about a particular procedure or medical condition. As described herein, HIPAA and other regulatory frameworks may require special identification properties, or restricted or conditional access properties for information to be exchanged in this way. Interactions with the syndicated medical information management system and the properties restricting this access may be logged, recorded and permanently archived for legal purposes or to demonstrate compliance with applicable regulations.” Comprises a compliance annotator component) regulatory compliance information ([0951] “For example, a device such as an echocardiograph may subscribe to a syndicated data feed that is published, shared, used by the device's manufacturer to inform of device updates, recalls, and the like…. The device may also publish a syndicated data feed. This data may include, but is not limited to, the performance of the device (e.g., consistency with established safety parameters)” where subscribing tags regulatory compliance information) based on verifying when the medical device component that the received data corresponds to is compliant with one or more regulatory rules, ([0627] “all participants have access to a complex mix of data sources that may include scientific background information, experimental data, clinical data about disease states or targets, laboratory notes, regulatory requirements and the like. Researchers may collaborate to produce a publication or other report concerning a study and its results. Researchers working together on a project may also interact with third parties (collectively termed "reviewers") who review, evaluate and/or comment upon the research, its data or its conclusions.”; see also [0927]“regulatory bodies, may interact with syndicated summaries of intervention complication rates, medication side effects … and the like through the use of an RSS-enabled application”) and computer readable program code tagging, via the regulatory compliance annotator component, data received by the receiver (See “receiver” above) with the regulatory compliance information; ([0951] “For example, a device such as an echocardiograph may subscribe to a syndicated data feed that is published, shared, used by the device's manufacturer to inform of device updates, recalls, and the like…. The device may also publish a syndicated data feed. This data may include, but is not limited to, the performance of the device (e.g., consistency with established safety parameters)” where subscribing tags regulatory compliance information) and
(f) computer readable program code selectively encrypting, via the encryption engine, the annotated physiological sensor data, ([0312], [0286] “As another example, medical information may be produced by a medical device, and the medical device information may be pushed into a data stream” comprises a plurality of data streams; see also [0265] “Security may impact a number of features of a syndication system. For example, a data stream system may use identity assignment and/or encryption and/or identity authentication and/or decryption by public and private encryption keys for RSS items and similar structured data sets and data streams.” Where the data stream system [comprising an encryption engine] optionally encrypts sensor data) the encryption engine being different from an encryption mechanism associated with the medical device component that originally encrypted the received data frames; ([0270] "In another aspect, a series of encryption keys may be used by the source and various aggregators or other intermediaries" occurs outside of the medical device encryption)
(g) computer readable program code transmitting the annotated physiological data to a data distribution gateway of the digital healthcare framework ([0951] “In embodiments, cardiovascular diagnostic and therapeutic devices may be able to interact with syndicated data, or publish one or more syndicated feeds. For example, cardiovascular diagnostic and therapeutic devices may be able to publish syndicated data, subscribe to and receive syndicated data feeds, and store syndicated data. This data may be published, shared, used, received and/or stored locally with the device, and/or in association with a remote architecture (e.g., server, database, etc.) accessible to the device (e.g., through the internet, WAN, LAN, wireless connection, etc.). For example, a device such as an echocardiograph may subscribe to a syndicated data feed that is published, shared, used by the device's manufacturer to inform of device updates, recalls, and the like. This information may be stored locally with the machine, and/or stored on an associated architecture, such as a hospital's central network, where the syndicated information may be reviewed by staff. The device may also publish a syndicated data feed. This data may include, but is not limited to, the performance of the device (e.g., consistency with established safety parameters), the amount of device usage, personnel using the device, patients with whom the device was operated, and so forth.”) wherein the data distribution gateway allows processing of annotated physiological data that contains the subset of data indicating that the data received by the receiver originates from a clinically unvalidated device. ([00327]” This syndicated data, in turn, could be aggregated at a city, state, or national level for the purposes of … accreditation, and so forth.” Where aggregating information for the purpose of accreditation is clinically validating a device; see optionally [0662] “The syndicated research reporting data may include submissions for peer review, submissions for regulatory approval, disclosures to patient or community groups, reports to business sponsors, applications for grants, requests for research proposals, requests for grant applications and the like.” Where submitting information for regulatory approval denotes a clinically unvalidated device)
Regarding claim 20, Moore is silent on, as taught by Schecter:
(c) computer readable program code identifying, via the medical/domain codes annotator component, one or more pre-determined code types associated with data received by the receiver, wherein the identifying includes applying code-selection rules based a type of the physiological sensor data and a value of the physiological sensor data, ([0102] “physiological measurements serve to verify or help to determine the condition of the corresponding subject in conjunction with the data from the measurement devices” and [0018] “The respective data element is interrogated to determine a condition of the medical device or to determine a condition of the corresponding subject. Responsive to the interrogating, (i) a first medical code that indicates that the condition of the medical device or the condition of the corresponding subject has been evaluated.” Where a condition of a medical device and a subject are based on the type and value of physiological sensor data)
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Moore with the teachings of Schecter, with a reasonable expectation of success, by explicitly applying code selection rules based on a type and value of physiological sensor data that corresponds to a medical device and clinical subject. This would have ensured a higher quality of care and allowed for more accurate information analytics by providing explicit annotation codes while information is continuously entered into this system. Schecter is adaptable to Moore as both inventions ensure compliance in a healthcare setting for medical devices by creating a network of computing systems to syndicate data. Moore would have found Schecter’s teaching while finding solutions to the well understood problem that “there is often no organized or efficient means for evaluating whether a health care institution is checking such medical devices on a regular basis”, as seen in paragraph [0003].
Regarding claim 22, Moore-Schecter teaches all of the limitations of claim 20. Moore also teaches:
wherein the clinical validation annotator component communicates with an external source over a network, the external source providing the clinical validation information. ([0126] “FIG. 1 shows a network for providing a syndicated data stream such as an RSS stream.”; see also [0646] In embodiments, researchers, research assistants, research analysts, report drafters, sponsors and data collectors (collectively termed "authors") may interact with syndicated authorship management systems via syndicated authorship information obtained through an RSS feed 202, web feed, RSS stream, or RSS channel, to collaboration in the collection, exchange and reporting of data or other information obtained during research. The syndicated authorship information may involve research-related information and all varieties of experimental and observational data such as basic scientific data, social scientific data, epidemiological or statistical data, preclinical data, clinical data and the like, alone or in combination with narratives including discussions, descriptions, analyses or other reports pertaining to the information and/or data. Relevant authorship systems may include systems for reporting experimental methods and materials, systems for preparing manuscripts, systems for preparing presentations, systems for preparing regulatory submissions and systems for preparing proposals.”)
Regarding claim 23, Moore-Schecter teaches all of the limitations of claim 1. Moore also teaches:
wherein the medical/domain codes annotator component, the clinical validation annotator component, and the regulatory compliance annotator component operate sequentially, out of order, or in parallel. ([0323] “Layered over this sequential data infrastructure are the domains of a healthcare institution, each with a potentially unique set of circumstances impacting each step of the data infrastructure.” Where the infrastructure is the annotators comprising the system)
Additional Considerations
The prior art made of record and not relied upon that is considered pertinent to applicant’s disclosure can be found on PTO-892 of the prior office action dated October 10th, 2025.
Allen et al. (US20210125725) discloses an automated Medical device risk assessment engine that determines, based on the compliance rules and the data dictionary, critical fields of patient data and medical device characteristics data for demonstrating medical device efficacy.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROBERT ANTHONY SKROBARCZYK whose telephone number is (571)272-3301. The examiner can normally be reached Monday thru Friday 7:30AM -5PM CST.
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, Unsu Jung can be reached at 571-272-8506. 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.
/R.A.S/Examiner, Art Unit 3792
/KAMBIZ ABDI/Supervisory Patent Examiner, Art Unit 3685