DETAILED ACTION
This action is in response to the initial filing filed on August 13, 2025. Claims 1-20 have been examined and are currently pending.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Inventorship
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Information Disclosure Statement
The Information Disclosure Statement filed on October 21, 2025 has been considered. An initialed copy of the Form 1449 is enclosed herewith.
Claim Objections
Claim 1 is objected to because of the following informalities: Independent claim 1 recites, “the queue elements” in line 8 lacks antecedent basis. Appropriate correction is required.
Claim 1 is objected to because of the following informalities: Independent claim 1 recites, “the activity elements” in line 10 lacks antecedent basis. Appropriate correction is required.
Claim 4 is objected to because of the following informalities: Dependent claim 4 recites, “the transactions” in line 2 lacks antecedent basis. Appropriate correction is required.
Claim 7 is objected to because of the following informalities: Dependent claim 7 recites, “the second plurality of vary medical data formats” in lines 2-3 lacks antecedent basis. Appropriate correction is required.
Claim 8 is objected to because of the following informalities: Dependent claim 8 recites, “the second plurality of vary medical data formats” in lines 2-3 lacks antecedent basis. Appropriate correction is required.
Claim 18 is objected to because of the following informalities: Dependent claim 18 recites the term “computingsystem”. Add a space between the words computing and system. Appropriate correction is required.
Claim 18 is objected to because of the following informalities: Dependent article claim 18 is dependent upon method claim 1. Appropriate correction is required.
Claim 19 is objected to because of the following informalities: Independent claim 19 recites, “the queue elements” in line 14 lacks antecedent basis. Appropriate correction is required.
Claim 19 is objected to because of the following informalities: Independent claim 19 recites, “the activity elements” in line 16 lacks antecedent basis. Appropriate correction is required.
Claim 20 is objected to because of the following informalities: Independent claim 20 recites, “the queue elements” in line 10 lacks antecedent basis. Appropriate correction is required.
Claim 20 is objected to because of the following informalities: Independent claim 20 recites, “the activity elements” in line 12 lacks antecedent basis. Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-6, 8-10, 12-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Wall US Publication 20120221354 A1 in view of Bauman et al. US Publication 20100114951 A1 further in view of Vincent et al. US Publication 20200058388 A1.
Claims 1, 19, and 20:
As per claims 1, 19, and 20, Wall teaches a method, computer system, and non-transitory computer readable medium comprising:
passing, by one or more processors and as part of a workflow, a first plurality of medical data objects between activities in random access memory (paragraphs 0090 and 0073 “The method of FIG. 4 also includes selecting (410), in dependence upon workflow selection rules and the attributes of the medical image business object, one or more clinical workflows to process the medical image. Workflow selection rules are rules that are tailored to carrying out the image processing transaction on the medical images and the medical image business object according to the request received by the health care provider. Such workflow selection rules identify the necessary requirements of the transaction and select workflows having services that carry out those requirements as well as select workflows that are tailored for the attributes of those images such as the slice size, number of slices, type of scanner used to create the images, standards used for the images and many others as will occur to those of skill in the art. Workflows may include analytics for tumor detection, tumor growth, aneurysm detection, vessel separation in a patients head, and many other medical conditions, workflows for image compression, image resolution, distribution of images, and many other workflows for medical image processing that will occur to those of skill in the art.” and “System memory (28) in the example of FIG. 7 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) (30) and/or cache memory (32). Computer system/server (12) may further include other removable/non-removable, volatile/non-volatile computer system storage media…”),
wherein the activities include an input activity, a processing activity, a flow activity and an output activity (paragraphs 0090 and 0073 “The method of FIG. 4 also includes selecting (410), in dependence upon workflow selection rules and the attributes of the medical image business object, one or more clinical workflows to process the medical image. Workflow selection rules are rules that are tailored to carrying out the image processing transaction on the medical images and the medical image business object according to the request received by the health care provider. Such workflow selection rules identify the necessary requirements of the transaction and select workflows having services that carry out those requirements as well as select workflows that are tailored for the attributes of those images such as the slice size, number of slices, type of scanner used to create the images, standards used for the images and many others as will occur to those of skill in the art. Workflows may include analytics for tumor detection, tumor growth, aneurysm detection, vessel separation in a patients head, and many other medical conditions, workflows for image compression, image resolution, distribution of images, and many other workflows for medical image processing that will occur to those of skill in the art.” and “System memory (28) in the example of FIG. 7 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) (30) and/or cache memory (32). Computer system/server (12) may further include other removable/non-removable, volatile/non-volatile computer system storage media…”),
and wherein the first plurality of medical data objects are in a first plurality of varying medical data formats and in a first plurality of disparate medical protocols (paragraphs 0027-0029 “The medical imaging cloud computing environment (100) of FIG. 1 includes medical imaging cloud gateway (110) in one or more of the health care provider networks (1540. The medical imaging cloud gateway (110) includes a medical digital image communications protocol adapter (112), a module of automated computing machinery that is capable of receiving a medical digital image from a provider of medical images such as a hospital (102), MRI center (106), doctor's office, and so on as will occur to those of skill in the art. The medical digital image communications protocol adapter (112) is capable of receiving the medical image according to any number of protocols supported by the providers of the medical images such as DICOM, HL7, and others as will occur to those of skill in the art.”);
storing, using the queue elements, the first plurality of medical data objects in a queue (paragraphs 0038-0039 “In the example of FIG. 1, the medical image communications protocol adapter (112) may store the medical images (114) in one or more medical image caches (116, 122, 196) available in the medical imaging could computing environment (100). A medical image cache is data storage that is accessible more quickly than medium typically used for longer term storage of medical images and yet robust enough to store the often large digital medical image files. For example, a medical image cache may be implemented on hard disk or magnetic disk storage rather than for example, tape storage which is slower to access.”);
obtaining, by the one or more processors, at least a portion of the first plurality of medical data objects for the activity elements (paragraphs 0040-0041 “The medical digital image transaction cluster (120) of FIG. 1 selects, in dependence upon workflow selection rules and the attributes of the medical image business object, one or more clinical workflows to process the medical image. Workflow selection rules are rules that are tailored to carrying out the image processing transaction on the medical images and the medical image business object according to the request received by the health care provider. Such workflow selection rules identify the necessary requirements of the transaction and select workflows having services that carry out those requirements as well as select workflows that are tailored for the attributes of those images such as the slice size, number of slices, type of scanner used to create the images, standards used for the images and many others as will occur to those of skill in the art. Workflows are often clinical in nature and may include analytics for tumor detection, tumor growth, aneurysm detection, vessel separation in a patients head, and many other medical conditions, workflows for image compression, image resolution, distribution of images, and many other workflows for medical image processing that will occur to those of skill in the art.”);
transforming, by the one or more processors, using the workflow and the activity elements, each received medical data object into one of a second plurality of medical data formats (paragraph 0052 and 0077 “The request is transmitted according to one of a plurality of a medical image communications protocol supported by medical digital image communications protocol adapter and used by a producer of the medical images. In the example of medical imaging gateway (110) is capable of receiving a request for an image processing transaction from a health care provider (204) according to the DICOM standard, a health care provider (206) that produces medical images according to the HL7 standard, or some other health care providers (208) using other protocols and standards for creating and transmitted medical digital images.” and “Routing (414) the resultant medical image according to the method of FIG. 4 may include creating a response to the request, the response conforming to a particular digital image communications protocol used for the destination, and transmitting the response according to the particular digital image communications protocol. Routing (414) the resultant medical image to a destination may also include storing the resultant medical image on a gateway within the medical digital image computing environment assigned to the producer of the medical image and transmitting the response according to the particular digital image communications protocol may include transmitting in the response data access information to access the resultant medical image on the gateway.”);
and transmitting, by the one or more processors, the transformed medical data objects in the second plurality of medical data formats using a second plurality of disparate medical protocols with the second medical device, in response to the request from the second medical device (paragraph 0052 and 0077 “Routing (414) the resultant medical image according to the method of FIG. 4 may include creating a response to the request, the response conforming to a particular digital image communications protocol used for the destination, and transmitting the response according to the particular digital image communications protocol. Routing (414) the resultant medical image to a destination may also include storing the resultant medical image on a gateway within the medical digital image computing environment assigned to the producer of the medical image and transmitting the response according to the particular digital image communications protocol may include transmitting in the response data access information to access the resultant medical image on the gateway.”).
Wall does not teach removing, using the queue elements, expired medical data objects of the first plurality of medical data objects from the queue. However, Bauman teaches a Medical Image Importer and Method and further teaches, “Once a job has been processed by a Reconciler or Importer and designated to be stored, reconciled or otherwise transmitted from the Medical Information importer 10, that job is transferred to the "Queue" tab 124 that can be selected from the Study Screen 120 in FIG. 4. These jobs remain visible from the Queue tab 124 until the selected process is carried out, at which time they can be removed from the Queue tab 124. According to alternate embodiments, the resolved jobs displayed under the Queue tab 124 that have been stored in the PACS server 106 or other storage destination can optionally remain there with a status that reflects storage of that Medical Information, reconciliation of the Medical Information, etc. . . . . Such entries can be expunged from the queue as new entries are added once the queue has reached the maximum number of entries or can simply expire after a predetermined period of time has elapsed since the Medical Information has been stored.” (paragraph 0078). Therefore, it would have been obvious to one of ordinary skill in the art at time of filing to modify Wall to include removing, using the queue elements, expired medical data objects of the first plurality of medical data objects from the queue as taught by Bauman in order to create or generate space for new data or content.
Wall does not teach dequeuing, using the queue elements, the first plurality of medical data objects from the queue, in response to a request from a second medical device. However, Vincent teaches an Image Viewer and further teaches, “After generating the request, processing logic queues the request for the compressed image pixel data in a request queue of the medical image management system (processing block 602). Note that there may be a number of requests that are queued in the queue. These requests may be handled in the order in which they were stored in the queue. In another embodiment, the requests are handled based on priority. In one embodiment, the priority is controlled by subscription logic of the medical image management system.” (paragraph 0068), “Subsequently, processing logic dequeues the request from the request queue (processing block 603). In one embodiment, the processing logic to dequeue the request for the compressed image pixel data is part of a loader of a medical image management system.” (paragraph 0069), “Processing logic sends the dequeued request to the remotely located server over a network using a network interface of the medical image management system (processing block 604). In one embodiment, the request is sent over the Internet to the remote server that has access to the images that is to be rendered.” (paragraph 0070), “Processing logic of the server receives the request (processing block 605), fetches the image data (e.g., the image data for a DICOM image) from storage (e.g., a remotely located storage) (processing block 606), compresses the fetched image pixel data (processing block 607), and then sends the compressed image data from the remotely located server to the medical image management system over the network (processing block 608).” (paragraph 0071). Therefore, it would have been obvious to one ordinary skill in the art at the time of filing to modify Wall and Bauman to include dequeuing, using the queue elements, the first plurality of medical data objects from the queue, in response to a request from a second medical device as taught by Vincent in order to process an item in a queue.
Claim 2:
As per claim 2, Wall, Bauman, and Vincent teach the method of claim 1 as described above and Wall further teaches wherein the passing does not use other temporary mass storage (paragraphs 0090 and 0073).
Claim 3:
As per claim 3, Wall, Bauman, and Vincent teach the method of claim 1 as described above and Wall further teaches wherein the workflow includes at least one of transactions, activity elements, configuration parameters or queue elements (paragraphs 0034 and 0039).
Claim 4:
As per claim 4, Wall, Bauman, and Vincent teach the method of claim 1 as described above and Wall further teaches wherein each of the transactions comprises execution of one or more workflow elements with or on other workflow elements (paragraphs 0034 and 0039).
Claim 5:
As per claim 5, Wall, Bauman, and Vincent teach the method of claim 1 as described above and Wall further teaches determining, by the one or more processors, a workflow based on configuration parameters specific to an activity instance and one or more of activities (paragraphs 0034 and 0039).
Claim 6:
As per claim 6, Wall, Bauman, and Vincent teach the method of claim 1 as described above and Wall further teaches grouping activity elements and queue elements as transactions (paragraphs 0034 and 0039).
Claim 8:
As per claim 8, Wall, Bauman, and Vincent teach the method of claim 1 as described above and Wall further teaches wherein the first plurality of varying medical data formats and the first plurality of disparate medical protocols are co- extensive with the second plurality of varying medical data formats and the second plurality of disparate medical protocols (paragraphs 0027-0029).
Claim 9:
As per claim 9, Wall, Bauman, and Vincent teach the method of claim 1 as described above and Wall further teaches wherein the workflow at least one of:
is based exclusively on activities and queue elements (paragraphs 0034 and 0039);
does not require persisting activity states;
is a directed acyclic graph;
or is recoverable by reprocessing pending queue elements.
Claim 10:
As per claim 10, Wall, Bauman, and Vincent teach the method of claim 1 as described above and Wall further teaches wherein the workflow is based on a closed taxonomy of activities for handling medical data, comprising at least one of:
input from network;
input from queue;
data processing (paragraph 0041);
flow control;
output to queue;
or output to network.
Claim 12:
As per claim 12, Wall, Bauman, and Vincent teach the method of claim 1 as described above and Wall further teaches further comprising executing, by the one or more processors, transactions of the workflow in parallel because the activity elements are stateless and reentrant (paragraphs 0026 and 0034).
Claim 13:
As per claim 13, Wall, Bauman, and Vincent teach the method of claim 1 as described above and Wall further teaches further comprising re-executing, by the one or more processors, transactions of the workflow by starting from a last queue containing the first plurality of medical data objects, in response to the transactions being interrupted (paragraphs 0034 and 0039).
Claim 14:
As per claim 14, Wall, Bauman, and Vincent teach the method of claim 1 as described above and Wall further teaches wherein the workflow comprises a plurality of input activities (paragraph 0034).
Claim 15:
As per claim 15, Wall, Bauman, and Vincent teach the method of claim 1 as described above and Wall further teaches wherein the workflow comprises a plurality of input activities, and wherein at least two input activities from the plurality of the input activities share a single HTTP endpoint or a single TCP/IP port for receiving medical data objects through the first plurality of disparate medical protocols (paragraphs 0028 and 0049).
Claim 16:
As per claim 16, Wall, Bauman, and Vincent teach the method of claim 1 as described above and Wall further teaches wherein the workflow comprises a plurality of input activities, and wherein each input activity from the plurality of input activities are associated with a different Uniform Resource Locator (URL) path (paragraphs 0040-0041).
Claim 18:
As per claim 18, Wall, Bauman, and Vincent teach the method of claim 1 as described above and Wall further teaches wherein the one or more processors is distributed across a computing system (paragraphs 0085-0087).
Claim(s) 7 is rejected under 35 U.S.C. 103 as being unpatentable over Wall, Bauman, and Vincent as applied to claim 1 above, and further in view of Jarman et al. US Publication 20180032573 A1.
Claim 7:
As per claim 7, Wall, Bauman, and Vincent teach the method of claim 1 as described above but do not teach wherein at least one of the first plurality of varying medical data formats and the first plurality of disparate medical protocols, or the second plurality of varying medical data formats and the second plurality of disparate medical protocols includes one or more of:
HL7 v2 - all message types. However, Jarman teaches Systems and Methods for Bi-Directional Database Application Programming Interface, Extract Transform and Load System, and User Computing Device and further teaches, “In some embodiments, the systems and methods described herein may be applied in the healthcare context. For example, the data exchange service 112 may be implemented to enable Healthcare as a Service (HaaS). In the example, the dating exchange service 112 may enable healthcare scheduling, messaging, retrieval of patient summary, clinical, and/or analytics data, processing of patient intake forms, physician searching, real or near-time eligibility, payment, demographics, provide a consistent display of healthcare data, ordering of healthcare products, and/or other healthcare services described herein. The bi-directional communication interface and/or data stores of the data exchange service 112 may implement the workflows and/or customized logic for processing patient-related data to enable the healthcare services. Example providers and/or data sources 104 include electronic medical records (EMR) systems, hospital information systems (HIS), radiology information systems (RIS), laboratory information systems (LIS), dietary information systems, picture archiving indication systems (PACS), emergency department and/or room systems, medical transcription systems, and/or some combination thereof. Example EMR systems that may be supported by the data exchange service 112 (via direct database access and/or via the communication interface 114) include Allscripts, IDX, Centricity, and MediTech. Example interfaces, communication protocols, and/or specifications that may be supported by the communication interface 114 include HL7, HL7 over SSL, HL7v2, HL7v3, Minimal Lower Layer protocol (MLLP), Fast Healthcare Interoperability Resources (FIHR), Continuity of Care Document (CCD), Clinical Document Architecture (CDA), Consolidated Clinical Document Architecture (CCDA), Digital Imaging and Communications in Medicine (DICOM), Nationwide Health Information Network (NwHIN) Direct, X12, and/or some combination thereof.” (paragraph 0031). Therefore, it would have been obvious to one of ordinary skilled in the art at the time of filing to modify Wall, Bauman, and Vincent to include HL7 v2 - all message types as taught by Jarman in order to facilitate communication and exchange of medical information.
HL7 v3 - all message types;
HL7 FHIR R4 - all resource types;
HL7 FHR R5 - all resource types;
HL7 CDA R2- all document types;
DICOM (DVIMSE) - all services;
and DICOM (DICOMweb) - all services.
Claim(s) 11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Wall, Bauman, and Vincent as applied to claim 1 above, and further in view of Hutchins et al. US Publication 20160292374 A1.
Claim 11:
As per claim 11, Wall, Bauman, and Vincent teach the method of claim 1 as described above but do not teach further comprising dynamically configuring, by the one or more processors, the workflow via an IoT configuration service as a set of discrete activity elements and a set of parameters for each activity element, the parameters being retrieved from the loT configuration service, and without reprogramming any software component. However, Hutchins teaches an Adverse Event Prioritization and Handling and further teaches, “In one embodiment, a group of servers each host an event engine with a respective set of interconnected tasks and queues that form a workflow. The group of servers may include a load balancer which routes the biometric measured by the IoT devices to one of the servers for processing. Because the data is processed using different tasks, the event engines can process multiple health events simultaneously. Stated differently, the event engines process the health events using a series of steps in the workflow where each step (or task) can process a respective health event in parallel.” (paragraph 0017). Therefore, it would have been obvious to one of ordinary skilled in the art at the time of filing to modify Wall, Bauman, and Vincent to include further comprising dynamically configuring, by the one or more processors, the workflow via an IoT configuration service as a set of discrete activity elements and a set of parameters for each activity element, the parameters being retrieved from the loT configuration service, and without reprogramming any software component as taught by Hutchins in order to facilitate performing specific functions or activities.
Claim 17:
As per claim 17, Wall, Bauman, and Vincent teach the method of claim 1 as described above but do not teach further comprising reporting a status of the workflow as an accumulation of a status of processing queues via an IoT reporting service. However, Hutchins teaches an Adverse Event Prioritization and Handling and further teaches, “In one embodiment, a group of servers each host an event engine with a respective set of interconnected tasks and queues that form a workflow. The group of servers may include a load balancer which routes the biometric measured by the IoT devices to one of the servers for processing. Because the data is processed using different tasks, the event engines can process multiple health events simultaneously. Stated differently, the event engines process the health events using a series of steps in the workflow where each step (or task) can process a respective health event in parallel.” (paragraph 0017). Therefore, it would have been obvious to one of ordinary skilled in the art at the time of filing to modify Wall, Bauman, and Vincent to include further comprising reporting a status of the workflow as an accumulation of a status of processing queues via an IoT reporting service as taught by Hutchins in order to track metrics or statistics associated with performance.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rahme et al. US Publication 20230154578 A1 Method and System for Asynchronous Medical Patient Data Communication and Management
Rahme discloses an asynchronous system for managing medical file protection and distribution. The system controls the distribution of sensitive patient records between different healthcare entities. The system includes a registration process for the healthcare institutions which creates a secure gateway between the system and the healthcare institution. Once registered, the system creates a content queue on the server for content designated to be sent to the institution. The client device of the healthcare institution will poll the queue and download the medical file content as it becomes available.
Brough et al. US Publication 20170140134 A1 Medical Device User Caching
Brough discloses an example medical device includes a physiological measurement device, a device management engine, a user caching engine, and a login engine. The device management engine is configured to receive data captured by the physiological measurement device. The user caching engine is configured to store cache records associated with users in a user cache. The login engine is configured to receive a user identifier associated with a user and determine whether the user identifier is associated with a cache record stored in the user cache. When determined that the user identifier is associated with a cache record stored in the user cache, the login engine is configured to log the user in. When not determined that the user identifier is associated with an unexpired cache record stored in the user cache, the login engine is configured to prompt the user for a credential.
Napora et al. US Publication 20090132586 A1 Management of Medical Workflow
Napora discloses various embodiments provide participants in a medical workflow with an integrated way to interact with a variety of medical information systems. Medical information can be collected from different medical information systems and/or data sources and presented to a user in one or more customized interfaces. Users can interact with the interface(s) and perform tasks associated with a medical workflow.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW L HAMILTON whose telephone number is (571)270-1837. The examiner can normally be reached Monday-Thursday 9:30-5:30 pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Fonya Long can be reached at (571)270-5096. 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.
/MATTHEW L HAMILTON/Primary Examiner, Art Unit 3682
Prosecution Insights