DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of the Claims
The status of the claims as of the response filed 08/25/2025, is as follows: Claims 1-7 and 10-13 are pending. Claims 8 and 9 are canceled. The applicant has amended Claims 1-6 and 10-12 are amended and have been considered below. (Claim 7 is an original claim and Claim 13 is a new claim).
Applicant Arguments Response
35 U.S.C. § 112(a)
Applicant’s arguments, see page 7, filed 11/25/2025, with respect to Claims 8 and 9 have been fully considered and are persuasive. The 35 U.S.C. § 112(a) rejection is withdrawn.
Applicant argues that “Claims 8 and 9 are canceled without prejudice” and therefore “the rejections of Claims 8 and 9 under 35 U.S.C. § 112(a) are rendered moot by the present cancellation of Claims 8 and 9.
The Examiner respectfully agrees and withdraws the rejection because a rejection cannot be maintained against canceled claims.
35 U.S.C 102/103 Arguments
Applicant’s arguments, see pages 8-10, filed November 25, 2025, with respect to Claims 1 and 11 have been fully considered and are not persuasive. The 35 U.S.C. § 103 rejection is submitted.
Applicant argues that Zhang “fails to disclose” the amended claim 1 arrangement, including the card-reader certification feature, the server exchange of certification information and patient information, and the display of “the patient information, the status confirmation results, and the recommended response measures.” Applicant also states that the prior rejection was “rendered moot by the present amendment.”
Examiner respectfully agreed and found persuasive that claim 1 is not anticipate by Zhang, however the present 103 rejection over Zhang was submitted in view of Mishra. Refer below for 35 U.S.C 103 rejection.
35 U.S.C 101 Subject Matter Eligibility Arguments:
Applicant’s arguments, see pages 10-12 of the reply filed in response to the 11- 25-2025, with respect to amended claims, have been fully considered and are not persuasive as to the current § 101 rejection.
Applicant argues that claim does not recite mental process and that “acquiring data” is not mental process.
Examiner respectfully disagrees because applicant argue only one part of the claim workflow, while the current rejection is grounded in the recommendation-generating limitation. Applicant is correct that data acquisition, by itself, is better characterized as data gathering rather than the mental process itself; MPEP 2106 treats mental processes as observations, evaluations, judgments, and opinions, and separately treats surrounding data gathering as extra-solution activity. However amended claim 1 still recites the hospital-side step of producing recommended response measures “based on” patient data and status data, which reasonably reads as a judgment or evaluation under BRI.
Applicant’s argue that the claim uses a card reader and communication interface in a concrete emergency setting to obtain patient information from a server, and that this is said to be a specific technical solution and an improvement over conventional systems.
Examiner respectfully disagrees because the claim recites a concrete machine environment, but not a technological improvement in the sense required by MPEP 2106.05(a). The specification says the problem is that merely providing emergency-worker input was inadequate for supporting prompt measures at the destination medical institution, and the solution is to obtain patient information and provide recommended response measures at the medical institution; that is an improvement in the information available for medical decision-making, not a disclosed improvement in how the card reader, communication interface, server, or processor itself operates. The specification par. 0022 also describes these components generically and with existing techniques: the IC card reader reads the My Number Card, the communication interface performs data communications, the Mynaportal-related retrieval can be realized using existing techniques, and the medical institution system outputs recommendations based on transmitted patient information and status confirmation results. On this record, applicant’s “specific technical solution” argument adds narrower that is not carried by the actual claim language or the disclosed technical details.
The applicant argues that the "additional elements recited in Claim 1 integrate any purported abstract idea into a practical application and recite an improvement over conventional technology" because "it is possible to acquire patient information from the server by reading certification information from the card owned by the patient using the claimed card reader and communication interface".
Examiner respectfully disagrees because the argued improvement is not a claimed improvement in technology, but an argued benefit of using conventional components in the claimed workflow. The card reader and communication interface are recited as tools to obtain and relay patient information, and the specification describes them at a functional level: the IC card reader is used to acquire patient information, and the communication interface performs data communications with an external device such as the cloud system. That evidence shows data acquisition and transmission, not a specific technical improvement in card-reading or communication technology. Accordingly, the additional elements do not integrate the abstract idea into a practical application under MPEP 2106.05(a), 2106.05(f), and 2106.05(g).
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 following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
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.
35 U.S.C 112(f) Rational:
Claims 1 and 11 each recite vital information acquiring means for acquiring vital information of the patient. This limitation uses the word means coupled with functional language - for acquiring vital information, without reciting sufficient structure to perform the entire function.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
Examiner Interpretation vital information acquiring means for acquiring vital information of the patient:
The specification discloses the corresponding structure as: a camera and an IC card reader of input interface 22 - see paragraph 0029; processing circuitry 25 executing acquiring function 251, which captures moving image data from the camera as vital information - see paragraphs 0032 through 0033; and a vital measuring device that provides respiratory rate, blood pressure, pulse rate, and body temperature - see paragraph 0034. This structure, and equivalents thereof, is the scope of vital information acquiring means for purposes of examination.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/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.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.-The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 13 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the applicant, regards as the invention.
Lack of Antecedent:
Claim 13 recites the destination candidate results. Because article “the” must point back to an element already introduced somewhere in the claim chain. Claim 13 depends from Claim 1. Claim 1 does not introduce any element called destination candidate results, nor does it introduce transport destination candidate determination results or any equivalent term that could serve as a proper antecedent. The first and only appearance of this phrase in the entire claim chain is here in Claim 13, yet the definite article the treats it as if it were already known. Because no such element exists earlier in the claim.
For the purpose of compact prosecution, the Examiner applies the broadest reasonable interpretation and reads the destination candidate results as transport destination candidate determination results output by the first processing circuitry.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-7, and 10-13 are rejected under 35 U.S.C. § 101 because the claimed subject matter is directed to a judicial exception, an abstract idea, without reciting elements that integrate the exception into a practical application or provide an inventive concept amounting to significantly more than the exception itself.
Step 1: Statutory Categories
The claims fall within recognized statutory categories under MPEP § 2106.03:
Machine, Claims 1-7, 10, and 13:. Each claim recites structural components including processing circuitry, a card reader, a communication interface, vital information acquiring means, and a display that together form a tangible system.
Process, Claims 11-12: The language reciting a series of acts or steps, aligning with the definition of a process.
Having confirmed the claims fall within statutory categories, the analysis proceeds to Step 2A, Prong One.
Step 2A, Prong One: Abstract Idea Identification
Prong One asks whether the claim recites a judicial exception, specifically whether the claim limitations under their broadest reasonable interpretation fall within an enumerated abstract idea category defined in MPEP § 2106.04(a)(2).
The invention relates to an emergency support system that collects patient information and vital signs in the field, relays that information to a destination hospital, and generates recommended response measures at the hospital based on the received data. The specification explains at paragraph 0004. The solution, described at paragraph 0049, is a medical institution system that outputs one or more recommended response measures for the patient based on the patient information and the status confirmation results. Refer to the specification at paragraphs 0020 and 0049 and Figures 1, 6, and 11 for further details.
Under BRI per MPEP § 2111, Claims 1-7, 10, and 13 recite a three-part emergency support system. The emergency terminal acquires patient identification data from a card and vital information from the patient, then sends that data through an emergency transport system to a medical institution system. The medical institution system evaluates the patient information and status confirmation results to produce recommended response measures and displays all of this information together on a screen. Claims 11-12 recite the same workflow as a method. The independent claims describe a managed information-relay workflow between emergency field personnel and hospital personnel, in which the core inventive step is evaluating patient data to form medical recommendations.
Representative Independent Claim
Claim 1.
An emergency support system, comprising:
an emergency terminal of an emergency service worker;
an emergency transport system configured to support emergency transport by the emergency service worker; and
a medical institution system provided in a medical institution that is a destination of transport,
wherein the emergency terminal includes:
a card reader configured to read certification information from a card carried by a patient;
a communication interface; and
vital information acquiring means for acquiring vital information of the patient; and
processing circuitry configured to transmit the certification information to a server via the communication interface;
receive patient information from the server via the communication interface;
and transmit the patient information and status confirmation results of the patient, including the vital information, to the emergency transport system via the communication interface,
the emergency transport system includes first processing circuitry configured to transmit, to the medical institution system to which the patient is to be transported, the patient information acquired from the emergency terminal, and the status confirmation results acquired from the emergency terminal,
the medical institution system includes second processing circuitry configured to output one or more recommended response measures for the patient based on the patient information and the status confirmation results, and
the second processing circuitry is configured to cause a display to display a display screen including the patient information, the status confirmation results, and the recommended response measures.
Note: The non-bolded portions represent the abstract idea. The bolded portions represent additional elements evaluated in Prong Two and Step 2B.
Independent Claims Abstract Classification Rational
Under their broadest reasonable interpretation, independent claims 1 and 11 recite a medical-evaluation process in which patient-related information is used to produce treatment-related output. Claim 1 recites that the medical institution system is configured to “output one or more recommended response measures for the patient based on the patient information and the status confirmation results,” and claim 11 recites the same evaluative step in method form. That language matters because it ties the claimed result to a review of patient inputs and condition inputs, not to any stated improvement in how the computer itself operates.
That evaluative content places the independent claims in the mental-process category. MPEP 2106 explains that mental processes include observations, evaluations, judgments, and opinions. Consistent with MPEP 2111, the phrase “output one or more recommended response measures for the patient based on the patient information and the status confirmation results” reasonably requires reviewing at least two categories of patient-related information and forming a recommendation from that review. In substance, the claims recite a judgment about what response should be taken for the patient. The claim focuses on the result of the evaluation, not on a particular technological way of performing that evaluation. A physician could review a patient chart, current vital signs, and condition notes, then decide what response measures should be prepared before the patient arrives. Writing those response measures on paper would mirror the same evaluative content recited in independent claims 1 and 11.
Dependent Claims: Abstract Idea Analysis
The dependent claims are also directed to an abstract idea:
Claims 2-3:
Because taking patient data as input and producing or updating medical recommendations as output, remains the abstract idea (Mental Process: evaluation and judgment).
Claim 4:
Because ranking and sequentially presenting evaluation results narrows the abstract idea by specifying how the recommendations are organized and displayed, remains a Mental Process (presenting the results of the evaluation in ranked order).
Claims 5-6:
Because underlying transport-destination determination and disease prediction are abstract evaluations and judgments (Mental Process). A person reviewing patient data, hospital availability, and geographic proximity can determine which hospital is the best candidate and can predict a likely disease based on symptoms.
Claim 7:
Because triage is a medical assessment judgment: classifying patient severity and urgency. This is a Mental Process (judgment).
Claim 10:
Because generating recommendations within a range of actions an emergency worker can perform is a narrowing of the abstract evaluation and judgment.
Claim 12:
Because acquiring electrocardiographic information is a data-gathering step extending the observation aspect of the abstract idea. The electrocardiograph device (implied by the measurement) is a new additional element.
Claim 13:
Because the determination of destination candidates and triage results is an abstract evaluation and judgment (Mental Process).
Having identified the judicial exception, the analysis proceeds to Step 2A, Prong Two to determine whether the claims integrate the exception into a practical application.
Step 2A, Prong Two: Practical Application
Step 2A, Prong Two asks whether the additional elements, alone and in combination, apply the judicial exception in a manner that imposes a meaningful limit on it, rather than merely using generic technology to carry out, communicate, or display the abstract result. Here, the additional elements do not overcome Prong Two because the claims recite ordinary system components that gather patient information, move that information through the recited environment, and display the resulting recommendations and classifications, but do not recite a specific technical mechanism that improves how the underlying technology itself operates.
Independent Claims: Additional Element Evaluation
Claims 1 and 11 recite, beyond the mental process identified in Prong One, the following elements: emergency terminal, emergency transport system, medical institution system, card reader, communication interface, vital-information acquiring means, transmitting certification information to a server, receiving patient information from the server, transmission steps, processing circuitry, first processing circuitry, second processing circuitry, and display. Those are the additional elements analyzed below, first individually and then as an ordered combination.
The recited emergency terminal, emergency transport system, and medical institution system do not integrate the exception into a practical application. In claims 1 and 11, those elements identify the emergency-care setting in which the evaluation is carried out, but the claims do not recite any change in how those systems themselves operate. Under MPEP 2106.05(h), limiting an abstract idea to a particular technological environment does not, by itself, integrate the exception into a practical application.
The card reader, communication interface, vital-information acquiring means, transmitting certification information to a server, receiving patient information from the server, and transmission steps likewise do not integrate the exception into a practical application. In claims 1 and 11, those limitations obtain patient-related information and move it from the emergency terminal to the emergency transport system and then to the medical institution system. The claims do not recite any specific improvement in card reading, sensing, or communication technology; instead, those elements are used to gather and relay information for the evaluation. Under MPEP 2106.05(g) and (f), that use of technology remains data gathering, data transmission, or use of technology as a tool.
The recited processing circuitry, first processing circuitry, and second processing circuitry also do not integrate the exception into a practical application. Claims 1 and 11 assign functions to those components, but do not recite a specific improvement in processor operation, computer capability, or system architecture. Under MPEP 2106.05(a), the claims therefore do not reflect an improvement in computer functionality or other technology.
The display limitation also does not integrate the exception into a practical application. Causing a display to show the patient information, the status confirmation results, and the recommended response measures presents the result of the evaluation, but the claims do not recite any improvement in display technology itself.
Viewed as a whole, these additional elements do not integrate the mental-process exception into a practical application. Claims 1 and 11 recite a sequence in which the card reader reads certification information, the communication interface and recited transmission steps send and receive patient-related information, the recited system components route that information through the emergency terminal, emergency transport system, and medical institution system, the recited circuitries support generation of the recommendation, and the display presents the resulting information and recommended response measures. Read together, that combination applies the abstract evaluation in an emergency-care setting, but it still applies the evaluation by using the recited technology as tools for input, transfer, processing, and output. Under MPEP 2106.05(a), the claims do not recite any improvement in computer functionality or other technology, and under MPEP 2106.05(h), they do not do more than link the evaluation to a particular technological environment. The claim language therefore does not show that the combination changes how the terminal, card reader, communication path, processor, or display operates; instead, it shows an ordered use of those components to carry out and communicate the evaluation. For that reason, the additional elements, viewed as a whole, do not overcome Prong Two.
Dependent Claims: Prong Two
The dependent claims do not pass Prong Two.
Claims 2-3:
These claims add a trained model as the mechanism for generating and updating the recommended response measures. Under MPEP § 2106.05(f), reciting a trained model to perform the abstract evaluation amounts to mere instructions to apply the exception using a machine-learning tool when the claim does not specify a particular model architecture, training methodology, or technical mechanism that improves computing technology. The claims recite executing a trained model at a functional level: take patient data as input, produce medical recommendations as output. The specification at paragraph 0041 lists a neural network, deep learning, ChatGPT, Random Forest, etc. as possible algorithms and states that other machine learning algorithms such as support vector machines and kernel regression may also be used, confirming the model is any general-purpose ML tool. Paragraph 0099 further confirms that the first trained model Md1, the second trained model Md2, and the third trained model Md3 may be respectively replaced with predetermined logic determinations, demonstrating the advance lies in the medical-assessment content, not in a specific machine-learning technique.
Claim 4:
Does not have new additional elements refer to prong one.
Claims 5-6:
These claims add a trained model for transport determination with inputs including medical institution vacancy information and position information of the emergency service worker. The trained model for transport determination is an additional element evaluated under MPEP § 2106.05(f) for the same reasons as Claims 2-3: the model is recited at a functional level without specifying a particular architecture or technical improvement. The additional data inputs (vacancy information, position information) are field-of-use limitations per MPEP § 2106.05(h) that specify the type of data the abstract evaluation processes without changing the nature of the evaluation itself.
Claim 7:
Does not have new additional elements refer to prong one.
Claim 10:
This claim adds a trained model for the emergency service worker that generates recommendations falling within a range executable by the emergency service worker. The trained model is an additional element evaluated under MPEP § 2106.05(f) as above. The range limitation narrows the abstract recommendation to a subset of actions, which is a field-of-use narrowing per MPEP § 2106.05(h).
Claim 12:
This claim adds acquiring electrocardiographic information related to an electrocardiographic waveform measured from the patient. This is pre-solution data gathering per MPEP § 2106.05(g). The specification at paragraph 0024 describes the electrocardiograph as transmitting data by email to which a PDF file of the electrocardiographic information is attached, confirming the data acquisition uses a general-purpose transmission method without technical specificity.
Claim 13:
This claim adds a trained machine-learning model with electrocardiographic information as an additional input for determining destination candidates and triage results. The trained machine-learning model is an additional element under MPEP § 2106.05(f) as above. The electrocardiographic information input is pre-solution data gathering per MPEP § 2106.05(g).
Whole-Claim Determination
When viewed as a whole, the combination of elements in the independent and dependent claims does not integrate the judicial exception into a practical application. The additional elements serve as generic tools for data acquisition, data routing, data processing, and results display, each performing its ordinary function in a standard input-process-output sequence. No claim recites a specific technical architecture, a non-conventional hardware integration, or a particular improvement to computing technology that would impose a meaningful limit on the abstract idea.
The claims do not integrate the judicial exception into a practical application. The analysis proceeds to Step 2B.
Step 2B: Inventive Concept Analysis
Step 2B asks whether the claims add significantly more than the abstract idea itself by reciting an inventive concept in the additional elements identified in Prong Two. Here, they do not. For the reasons below, the additional elements, considered alone and in combination, amount to implementation of the mental-process exception with recited system components, data-gathering and transmission steps, and model-based tools, but do not add a technological feature or arrangement that makes the claims more than the abstract idea carried out in the claimed environment.
Consistent with Prong Two, the additional elements recited in independent claims 1 and 11 are: emergency terminal, emergency transport system, medical institution system, card reader, communication interface, vital-information acquiring means, transmitting certification information to a server, receiving patient information from the server, transmission steps, processing circuitry, first processing circuitry, second processing circuitry, and display.
System environment
The recited emergency terminal, emergency transport system, and medical institution system do not supply an inventive concept. These elements place the abstract evaluation in an emergency-care setting, but claims 1 and 11 do not recite any non-ordinary configuration or specific technological arrangement for those systems. MPEP 2106.05(h) explains that merely linking an abstract idea to a particular technological environment does not make the claim eligible, and that is what these system-level elements do here. The specification is consistent with that reading. It states that “an emergency support system 1 includes an emergency transport system 30” and “a medical institution system 50 provided in a medical institution that is a transport destination,” and further states that it is possible “to integrate the emergency transport system 30 into the medical institution system 50” (Spec. 0089). Those passages describe the claimed systems as the operating setting of the workflow, not as a technically improved architecture.
Data acquisition and communication
The recited card reader, communication interface, vital-information acquiring means, transmitting certification information to a server, receiving patient information from the server, and transmission steps do not supply an inventive concept. In claims 1 and 11, those limitations obtain patient-related information and move it through the claimed system before and after the evaluation. MPEP 2106.05(g) explains that data gathering or output activity surrounding an abstract idea does not add significantly more, and MPEP 2106.05(f) explains that merely using technology as a tool to perform the idea is not enough. The specification supports that characterization. It explains that the IC card reader “is used to acquire patient information from the patient information card carried by a patient,” that the communication interface “performs data communications with an external device such as the cloud system 31,” and that the communicating function “transmits ... the patient information, the vital information, and results of observation and consultation ... to the cloud system 31” and “receives ... information such as a transport destination medical institution or candidates for the transport destination medical institution, results of triage, and the like” (Spec. 0029, 0031, 0035). Those passages show acquisition and relay of information, not a recited improvement in card reading, sensing, or communication technology.
Processing components
The recited processing circuitry, first processing circuitry, and second processing circuitry do not supply an inventive concept. Claims 1 and 11 assign functions to those components, but do not recite a specific processor architecture, memory arrangement, or other technical implementation that improves computer operation. MPEP 2106.05(a) supports that conclusion because it looks for an improvement in the functioning of the computer or other technology, and the claims here recite functional use of processors without reciting such an improvement. The specification is consistent with that reading. It states that “the processing circuitry 25 is a processor that functions as a core of the emergency terminal 20” and that the processing circuitry “executes a program stored in the memory 21 ... to realize a function corresponding to the program” (Spec. 0032). It likewise states that “the processing circuitry 65 of the medical information processing apparatus 60 takes, as an input, at least the patient information and the status confirmation results to execute a second trained model Md2” and “causes the display 63 to display” the generated measures (Spec. 0077-0078). Those passages describe processors performing assigned functions in the workflow, not an improvement to computing technology itself.
Display
The recited display also does not supply an inventive concept. Claims 1 and 11 use the display to present patient information, status confirmation results, and recommended response measures after the evaluation is performed. MPEP 2106.05(g) explains that post-solution output of results does not add significantly more, and the claim language does not recite any display-specific mechanism or interface technique that improves display technology itself. The specification supports that reading. It states that “the display 23 displays various types of information in accordance with instructions from the processing circuitry 25” and that “any display such as a cathode-ray tube (CRT) display, a liquid crystal display, an organic electroluminescent (EL) display, a light-emitting diode (LED) display, and a plasma display may be suitably employed” (Spec. 0030). It also states that the display control function “causes the display 23 to display a display screen including information received from the cloud system 31” and that the processing circuitry 65 “causes the display 63 to display a display screen including the generated recommended response measures” (Spec. 0036, 0078). Those passages describe presentation of results on broadly described display devices, not an improved display technology.
Viewed as a whole, the additional elements in claims 1 and 11 still do not amount to significantly more than the abstract idea. The claim language recites an ordered sequence in which patient-related information is read, received, transmitted, evaluated, and displayed through the identified system components, but that sequence still uses the recited technology as tools for input, transfer, processing, and output. The specification reflects the same sequence: patient information is acquired and communicated to the cloud system (Spec. 0033, 0035), the emergency transport system transmits the patient information and status confirmation results to the medical institution system (Spec. 0037), the medical information processing apparatus executes the model to generate recommended response measures (Spec. 0077), and the display presents those measures (Spec. 0078). Nothing in those passages describes a non-ordinary technological arrangement or a specific technical mechanism that transforms the mental-process exception into an inventive application.
Dependent Claims Analysis
Consistent with Prong One and Prong Two, only dependent claims that newly recite an additional element require separate Step 2B analysis. Claims 4, and 7 do not newly add an additional element here. Claim 3 further specifies updating the recommendation evaluation already identified as abstract in Prong One, claim 4 adds ranking display of that same evaluative result using the display already recited in claim 1, and claim 7 further specifies triage output from the same transport-determination evaluation already addressed in Prong One.
Claims 2-3 include a trained model introduced by claim 2 and carried forward by claim 3. That limitation does not supply an inventive concept. MPEP 2106.05(f) applies because the claims invoke the model as a tool for generating or updating recommended response measures, but do not recite a specific model architecture, training methodology, feature-processing technique, or other technical mechanism that improves computing technology itself. The specification is consistent with that reading: it states that the second trained model Md2 may use a neural network, deep learning, ChatGPT, Random Forest, etc. (Spec., para. 0041) and that other machine learning algorithms such as support vector machines and kernel regression may also be used (Spec., para. 0041). Those disclosures show that the claimed advance is not a particular machine-learning technique, but the recommendation-focused evaluation already identified in Prong One.
Claim 4 does not add a new additional element for Step 2B. It uses the display already recited in claim 1 to show a ranking of a plurality of recommended response measures, which is still presentation of the evaluative result rather than a new technological feature. For that reason, claim 4 only further specifies the abstract idea already identified in Prong One and does not separately change the Step 2B analysis.
Claims 5-7 include a trained model for transport determination introduced by claim 5 and carried forward by claims 6 and 7, together with medical institution vacancy information in claim 5 and position information of the emergency service worker in claim 6. These limitations do not supply an inventive concept. MPEP 2106.05(f) applies to the trained model for the same reason discussed above: the claim uses the model to produce destination-related, disease-related, and triage-related evaluation, but does not recite a specific model architecture or technical improvement. MPEP 2106.05(h) applies to the added vacancy information and position information because those limitations merely specify additional information considered within the transport-determination evaluation, rather than improving the underlying technology.
Claim 10 introduces a trained model for the emergency service worker. That limitation does not supply an inventive concept. MPEP 2106.05(f) applies because the model is again used as a tool for generating recommended response measures, without any recited technical improvement in model design or computing operation. MPEP 2106.05(h) also applies because limiting the generated recommendations to those falling within a range executable by the emergency service worker narrows the recommendation content to a particular use context, but does not add a technological feature that makes the claim significantly more than the abstract idea.
Claim 12 introduces electrocardiographic information as an additional data input in the method chain stemming from claim 11. That limitation does not supply an inventive concept. MPEP 2106.05(g) applies because acquiring additional medical data for use in the evaluation is pre-solution data gathering. The specification is consistent with that reading. It states that the electrocardiograph is capable of obtaining an electrocardiographic waveform of a patient and transmitting electrocardiographic information (Spec., para. 0024) to the cloud system and, more specifically, transmits, for example, an email to which a PDF file of the electrocardiographic information is attached (Spec., para. 0024). That disclosure describes obtaining and sending the ECG information as input data for later evaluation, not as a technological improvement in ECG acquisition or signal processing.
Claim 13 introduces a trained machine-learning model for determining destination-candidate results and triage results from electrocardiographic information, vital information, and patient information. That limitation does not supply an inventive concept. MPEP 2106.05(f) applies because the claim invokes the model as a tool for the same kind of destination-and-triage evaluation identified in Prong One, but does not recite a specific model design, training process, feature-processing technique, or other technical mechanism that improves machine-learning technology itself. To the extent claim 13 also uses electrocardiographic information as an input, that additional input remains data gathered for the evaluation and does not change the Step 2B result.
Viewed as a whole, the full claim set still lacks an inventive concept. The independent claims recite the emergency-care setting, data-acquisition and communication steps, processing components, and display, and the dependent claims add trained models and additional input data such as medical institution vacancy information, position information, and electrocardiographic information. Read together, the claims still follow the same sequence identified throughout Step 2B: patient-related information is gathered, transmitted, evaluated, and displayed, with the trained models used only as tools for the same recommendation, destination, disease-prediction, and triage evaluations identified in Prong One. Under MPEP 2106.05(f), (g), and (h), those added models and data inputs do not supply significantly more because they do not improve the underlying technology; they only support or further limit the abstract evaluation. The specification (par. 0040-0041, 0024, 0099) is consistent with that reading because it describes the models broadly and as replaceable with predetermined logic, and describes the vacancy, position, and electrocardiographic information as additional inputs to those same evaluations.
Therefore, the claims 1-13 are rejected because do not recite a non-ordinary technical arrangement or a specific technological improvement that changes Step 2B result and are directed to judicial exception.
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.
Claim(s) 1, and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang – CN- 103312782, and further in view of MISHRA- US20160103963A1.
Claim 1.
An emergency support system, comprising:
an emergency terminal of an emergency service worker; (Zhang, ambulance vehicle sub system further comprises a user operation terminal… par. 0022, the remote intelligent emergency system comprises a data centre, an ambulance vehicle subsystem… par. 0041)
an emergency transport system configured to support emergency transport by the emergency service worker; (Zhang, the data centre are vehicular subsystem with the ambulance, the emergency command centre system… par. 0041-0042)
and
a medical institution system provided in a medical institution that is a destination of
transport, (Zhang, par. 0003, 0014, 0017-0018, 0026, 0042)
Zhang 's emergency support system integrates an ambulance terminal and an emergency command center via TD-SCDMA to transmit vital patient and ambulance location data to a data center, enabling the hospital scheduling sub-system to assign patients to the nearest suitable hospital with available resources based on the ambulance's geographic position.
wherein the emergency terminal includes:
a card reader configured to read (Zhang, automatic retrieval health record of the patient through an identity card scanning patients, before rescue…par.0034)
a communication interface: (Zhang, par. 0041-0042, connection communication supports)
and vital information acquiring means for acquiring vital information of the patient; (Zhang, monitoring device, used for real time collecting the vital sign data of the patient, par. 0044; video collecting device for instantly collecting process of the emergency ambulance in the video data, par. 0046; audio collecting device for instantly collecting in ambulance aid process of audio data, par. 0047)
and processing circuitry configured to transmit the
server via the communication interface; (Zhang, position data is compressed and transmitted to the data centre…par.0055; par. 0059; par. 0061, an ambulance vehicle subsystem through WCDMA network; par. 0042; par. 0055, …a gateway comprises a data gateway…; …ambulance ID, vital sign data and the geographic position data is compressed and transmitted to the data center…par.0076; )
Zhang describe an ambulance-side gateway processes ambulance ID, patient vitals, and location data and transmits that data to a data center, reading on the claimed processing circuitry and server transmission.
Zhang also discloses the claimed communication path by sending the collected data from the ambulance subsystem to the data center over a WCDMA wireless network.Together, Zhang’s express description of transmitting ambulance data to the data center.
receive patient information from the server via the communication interface: (Zhang, … inquiring the patient to the data centre of the electronic record…par.0033; 0048; par. 0057)
Zhang describe the ambulance-side terminal “inquiring the patient to the data centre of the electronic record” reads on obtaining patient information from the server, and the same disclosure explains the electronic medical record contains the patient’s “medical history” and “health record data.”
Because that inquiry is made between the ambulance subsystem and the data center over the system communication link.
and transmit the patient information and status confirmation results of the patient, including the vital information, to the emergency transport system via the communication interface, (Zhang, See at least, "the data gateway for ambulance ID, vital sign data and the geographic position data is compressed and transmitted to the data centre, audio/video gateway is used for transmitting the video and audio data in the rescuing process is compressed and transmitted to the data center" (par. 0055); "the emergency-related data comprises the real-time GPS data of ambulance idle time of each hospital resource data, the patient medical history, patient health record data, an ambulance on audio data, an ambulance on video data, an ambulance recording on the first-aid patient, ambulance on vital sign data" (par. 0057); "each ambulance is need to provide network terminal for conveniently inputting patient basic information, record information and emergency site, for viewing a patient health record" (par. 0053); "an ambulance vehicle subsystem through WCDMA network, internet, private and other access technology, through various sensors and information collecting device for collecting blood pressure, temperature, heart rate, electrocardiogram, body position and so on various vital sign parameters, converging the geographical position information and video image information, is transmitted to the data centre" (par. 0061); "doctors know disease, medical history, health record of the patient, real time patient vital sign parameter and its variation" (par. 0061), par. 0093.)
Zhang teaches transmitting patient-related information, including vital-status information, through gateway and wireless communication to the data centre in the emergency system, and it also discloses patient basic information, record information, medical history, and health record data as patient information within that same system.
the emergency transport system includes first processing circuitry configured to transmit, to the medical institution system to which the patient is to be transported, the patient information acquired from the emergency terminal, and the status confirmation results acquired from the emergency terminal, (Zhang, see at least, par. 0081, 0027, 0049, 0083, 0028, 0086, 0051)
Zhang does show transport-side forwarding toward the receiving hospital side. stored and forwarded and the hospital workstation query of ambulance-side data read on forwarding of patient-status data into the medical institution side.
the medical institution system includes second processing circuitry configured to output one or more recommended response measures for the patient based on the patient information and the status confirmation results, (Zhang, par. 0018-0021, 0051-0052, 0057, 0061, 0085, 0087-0088, 0090, 0093)
Zhang teaches a hospital-side system including a doctor client with a guidance subsystem that provides emergency guidance information using patient-condition and patient-record information, which reads on second processing circuitry configured to output one or more recommended response measures for the patient based on patient information and status confirmation results.
and
the second processing circuitry is configured to
(Zhang, par.0053, for viewing a patient health record and for communicating with other related party; )
35 USC 103 Rationales:
Primary references teaches all limitations as explained above, excepts the following:
wherein the emergency terminal includes: a card reader configured to read certification information from a card carried by a patient.
The limitation requires a card reader that reads card-stored patient verification information used to confirm identity or authorize access to patient information. Zhang teaches identity document scanning device for automatic retrieval health record of the patient through an identity card scanning patients, before rescue at paragraph 0023 and paragraph 0034 and paragraph 0064. This reads on a card reader reading patient card information because Zhang uses a patient-carried identity card at the emergency stage to retrieve the patient health record before rescue. However, Zhang does not teach reading certification information used for verification or authorization.
Mishra teaches that missing feature, as shown by patient identity verification information, for instance Personal Identification Numbers PINs at paragraph 0051 and the smart healthcare card may comprise a regular PIN and the distress PIN and facilitating Authentication, Authorization and Accounting AAA at paragraph 0053 and users may be capable of availing the emergency healthcare facilities provided by one or more healthcare service providers via at least one of swiping the smart healthcare card through feeding into and exposing the same before or in proximity of the at least one of contact and contactless smart healthcare card reader at paragraph 0054. This reads on certification information because Mishra stores card-based verification data on the patient card and uses that data through a card reader for authenticated emergency access.
A person of ordinary skill in the art would have combined Zhang with Mishra to improve patient verification during pre-rescue card-based record access, by modifying Zhang’s identity-card scanning workflow so the emergency terminal reads not only identity data for record retrieval but also PIN-based verification data from the same patient-carried card, because Zhang already retrieves patient records from a scanned patient card before rescue and Mishra teaches that smart healthcare cards provide secure access to emergency medical information and facilitate identification, authentication, authorization at paragraph 0047. Doing so would have predictably provided authenticated card-based access to the patient record during Zhang’s existing emergency workflow. Accordingly, the combination of Zhang and Mishra renders a card reader configured to read certification information from a card carried by a patient obvious.
the second processing circuitry is configured to cause a display to display a display screen including the patient information, the status confirmation results, and the recommended response measures.
The limitation requires hospital-side display control that presents all three recited information categories on a display screen together.
ZHANG teaches the hospital-side base system, including a hospital work station and doctor client that receive patient-related pre-arrival data from the data centre and provide emergency guidance information. Zhang teaches that the triage subsystem queries patient-related ambulance data from the data centre and assigns the patient to the doctor client, and that the doctor client guidance subsystem receives patient vital-sign, video, and audio data and provides emergency guidance information for patient admittance preparation. Zhang 0085-0088, par. 0093. However, Zhang does not clearly teach causing a display to present all three claimed categories together on one display screen.
MISHRA teaches that missing display feature. Mishra teaches a provider-facing summary form that may be presented in a single view, window and/or screen to allow a physician to access desired information in one place, with a minimum of required navigation and that this single screen display can be generated on the fly Mishra 0152. Mishra further teaches that downloaded EHR information may be reformatted into a clinically prioritized single-view presentation, while the host computing unit analyzes retrieved patient information and recommends healthcare solutions, services, or therapeutic regimens Mishra 0009, 0152, 0155-0156. These disclosures read on presenting aggregated patient information together with generated recommendation content on one physician-facing screen.
A person of ordinary skill in the art at the time of the invention would have had at least ordinary education and experience in networked medical information systems, emergency-response data systems, or provider-facing clinical interfaces, and would have looked to MISHRA because both references are directed to giving a clinician fast access to patient information needed for treatment decisions. Zhang places the doctor client at the hospital side to receive patient data and output guidance information before patient admittance preparation, including vital sign data, video and audio data in the rescuing process, and emergency guidance information, and teaches that the doctor can know the patient’s disease, medical history, health record and real time patient vital sign parameter and its variation. Mishra addresses the same presentation problem from the physician side by teaching a single view, window and/or screen that allows a physician to access desired information in one place, with a minimum of required navigation, while also teaching analysis of patient information to recommend healthcare solutions Mishra. Because Mishra provides a known physician-facing screen arrangement for consolidating clinically relevant patient data and recommendation content in one place, a POSITA would have recognized it as a fitting interface improvement for Zhang’s hospital-side doctor client.
Note: Claim 11 it is rejected with the same analysis of claim 1 for being very similar.
Claim 12.
Zhang in combination with MIshra teaches, The emergency support method according to claim 11, further comprising: acquiring, from the emergency terminal, electrocardiographic information related to an electrocardiographic waveform measured from the patient by the emergency transport system, prior to the transmitting,
wherein the status confirmation results further include the electrocardiographic
information acquired from the emergency terminal. (Zhang , par. 0057, 0061, 0090)
Claim(s) 2-7 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhang – CN- 103312782, in combination with Zhang in combination with MISHRA- US20160103963A1 and further in view of Makram-US 20190180868 A1.
Claim 2.
Zhang in combination with Mishra teaches, The emergency support system according to claim 1,
wherein the second processing circuitry is further configured to generate the one or more
recommended response measures by taking, as an input, at least the patient information and the status confirmation results to execute a trained model, (Zhang , par. 0014, 0021-0022, 0032, 0035, 0061)
and output the one or more recommended response measures. (Zhang , par. 0014, 0021-0022, 0032, 0035, 0061)
Zhang describe the use of different inputs (patient information and status confirmation result) to recommended guidance. However, does not explicitly said that the guidance are executed by a trained model.
However, Makram in fig. 1, paragraphs 0044- 0046, 0014-0016, describe a system functionally assesses patient biometrics, medical history, and nurse input to calculate a triage assessment, which is then used by a resource prediction machine (uses supervised machine learning techniques) to sort patients by acuity and assign appropriate resources like teams or specialists. In fig.6 describe the uses machine learning to receive patient parameters, analyze them to determine an acuity score and predict resource needs, and then use these predictions to assign tasks and manage work queues.
Markram and Zhang describe a functional process aims to improve hospital emergency (Markram paragraphs 0002-0005 and Zhang , paragraphs 0002-0004) therefore it is obvious for a PHOSITA look in Markram because are in the same topic of hospital emergency.
A PHOSITA would be motivated to include machine learning in Zhang to solve the flow through the complex assessment and treatment process and to sorting and resource allocation using machine learning, in comparison with potential variability in assessment accuracy due to reliance on human intuition in hospital emergency to improve the different patient data management and output process. Markram, par. 0004, 0039, 0044.
Claim 3.
Zhang in combination with Mishra and further view of Markram teaches, The emergency support system according to claim 2, wherein the second processing circuitry is further configured to update the one or more recommended response measures by taking, as an input, the patient information, the status confirmation results, examination information of the patient, and vital data collected in real time from the patient to execute the trained model. (Zhang , 0057, 0090-0094)
The system ambulance real-time recording and updating the multimedia medical record in an ambulance on patient vital sign data for remote guidance.
Claim 4.
Zhang in combination with Mishra and further view of Markram teaches, The emergency support system according to claim 3, wherein the second processing circuitry is further configured to cause the display to display a ranking of a plurality of recommended response measures sequentially obtained by the updating of the one or more recommended response measures. (Zhang , 0057, 0090-0094)
Zhang describe a data center utilizes various servers to process and manage diverse emergency-related information, including real-time ambulance data, patient medical records, and vital signs, to facilitate remote guidance and optimize emergency services. However does not exactly describe a ranking for obtained a sequentially recommendations.
However Markram describe a system that tracks real-time collection of data (par.0048, 0053-0059) and including timestamps for various events like study assigned bed, surgery etc. (par. 0014, 0018, 0020, 0069-0076, 0081, 0088), this represent a ranking plurality of recommendation sequentially by timestamps in the work queues.
Markram and Zhang describe a functional process aims to improve hospital emergency (Markram paragraphs 0002-0005 and Zhang , paragraphs 0002-0004) therefore it is obvious for a PHOSITA look in Markram because are in the same topic of hospital emergency.
A PHOSITA would be motivated to include a sequential recommended process from Markram to resolve unplanned nature of patient attendance and needs can lead to the inefficient management of medical resources and patient flows. Markram, par. 0003
Claim 5.
Zhang in combination with Mishra teaches, The emergency support system according to claim 1, wherein the first processing circuitry is further configured to output transport destination determination results or transport destination candidate determination results, and the status confirmation results, which include information on a predicted disease of the patient, by taking, as an input, the patient information, the vital information, and medical institution vacancy information to execute a trained model for transport determination. (Zhang , par. 0003, 0063)
Zhang describe the ambulance emergency intelligent auxiliary system collects patient physiological data via an ambulance terminal, transmits it in real-time to a rescue center, and utilizes an emergency command center for remote diagnosis, management, and deployment, including expert-guided cure plans by utilization rate, capacity and so on principle the patient assigned to the appropriate hospital.
However, does not explicitly said that are executed by a trained model.
However, Makram in fig. 1, paragraphs 0044- 0046, 0014-0016, describe a system functionally assesses patient biometrics, medical history, and nurse input to calculate a triage assessment, which is then used by a resource prediction machine (uses supervised machine learning techniques) to sort patients by acuity and assign appropriate resources like teams or specialists. In fig.6 describe the uses machine learning to receive patient parameters, analyze them to determine an acuity score and predict resource needs, and then use these predictions to assign tasks and manage work queues.
Markram and Zhang describe a functional process aims to improve hospital emergency (Markram paragraphs 0002-0005 and Zhang , paragraphs 0002-0004) therefore it is obvious for a PHOSITA look in Markram because are in the same topic of hospital emergency.
A PHOSITA would be motivated to include machine learning in Zhang to solve the flow through the complex assessment and treatment process and to sorting and resource allocation using machine learning, in comparison with potential variability in assessment accuracy due to reliance on human intuition in hospital emergency to improve the different patient data management and output process. Markram, par. 0004, 0039, 0044.
Claim 6.
Zhang in combination with Mishra and further view Markram teaches, The emergency support system according to claim 5, wherein the first processing circuitry is further configured to take, as an input, the patient information, the vital information, position information of the emergency service worker, and the medical institution vacancy information to execute the trained model for transport determination. (Zhang , par. 0003, 0061-0063)
Zhang use geographical position information and video image information, is transmitted to the data center, for the expert-guided cure plans by utilization rate, capacity and so on principle the patient assigned to the appropriate hospital.
Claim 7.
Zhang in combination with Mishra and further view of Markram teaches, The emergency support system according to claim 5, wherein the first processing circuitry is further configured to output results of triage of the patient by executing the trained model for transport determination.
(Zhang , par. 0003, 0031-0032, 0051-0052)
The triage subsystem of the hospital work station inquires about recorded patient vital signs, video, and audio data from the ambulance vehicle subsystem. This information, along with geographic location data of the ambulance, is then used to assign the patient to a specific doctor client. The doctor client's pneumology subsystem receives this data, including vital signs, video, and audio, along with emergency guidance information, to facilitate remote diagnosis and direct the ambulance vehicle subsystem for transport.
Claim 10.
Zhang in combination with Mishra teaches, The emergency support system according to claim 1, wherein the first processing circuitry is further configured to generate recommended response measures falling within a range executable by the emergency service worker by taking, as an input, at least the patient information and the vital information to execute a trained model for the emergency service worker, and output the recommended response measures falling within the range executable by the emergency service worker. (Zhang , par. 0021, 0052, 0057, 0090-0094, 0014, 0021-0022, 0032, 0035, 0061, 0063)
Examiner interpret “range” according to par. 0098 of the applicant as recommended actions are within the scope of practice and capabilities of the emergency service worker. Zhang system provided guidance according to adjusting from said data center taking video and audio data in the vital sign data and the rescuing process of patient in for patient hospitalization treatment as preparation work, for providing emergency guidance. Also guidance it is provide according to the resource utilization rate, capacity and so on principle the patient assigned to the appropriate hospital.
However, does not explicitly said that are executed by a trained model.
However, Makram in fig. 1, paragraphs 0044- 0046, 0014-0016, describe a system functionally assesses patient biometrics, medical history, and nurse input to calculate a triage assessment, which is then used by a resource prediction machine (uses supervised machine learning techniques) to sort patients by acuity and assign appropriate resources like teams or specialists. In fig.6 describe the uses machine learning to receive patient parameters, analyze them to determine an acuity score and predict resource needs, and then use these predictions to assign tasks and manage work queues.
Markram and Zhang describe a functional process aims to improve hospital emergency (Markram paragraphs 0002-0005 and Zhang , paragraphs 0002-0004) therefore it is obvious for a PHOSITA look in Markram because are in the same topic of hospital emergency.
A PHOSITA would be motivated to include machine learning in Zhang to solve the flow through the complex assessment and treatment process and to sorting and resource allocation using machine learning, in comparison with potential variability in assessment accuracy due to reliance on human intuition in hospital emergency to improve the different patient data management and output process. Markram, par. 0004, 0039, 0044.
Claim(s) 13 are rejected under 35 U.S.C. 103 as being unpatentable over Zhang – CN- 103312782, and MISHRA- US20160103963A1 and further in view of Shields- US11763949.
Claim 13.
Zhang in combination of Mishra and further view of Shields teaches, The emergency support system of claim 1, wherein the first processing circuitry is further configured to determine the destination candidate results and results of
triage by inputting, to a trained machine-leaming model, electrocardiographic information,
the vital information, and the patient information.
The claim 13 limitation requires the same first processing circuitry to input ECG information, vital information, and patient information to a trained machine-learning model and, from that model execution, determine both destination candidate results and triage results.
Zhang teaches several pieces of this limitation in part. Zhang teaches patient basic information, record information and collecting blood pressure, temperature, heart rate, electrocardiogram at paragraphs 0053 and 0061, which read on patient information, vital information, and electrocardiographic information.
Zhang teaches patient basic information, record information and collecting blood pressure, temperature, heart rate, electrocardiogram at paragraphs 0053 and 0061, which read on patient information, vital information, and electrocardiographic information.
Zhang also teaches destination-selection activity and triage-type output with direct record support.
For destination selection, Zhang teaches that the emergency command centre sub-system comprises a hospital scheduling subsystem, wherein said hospital scheduling sub-system for the patient assigned to the appropriate hospital Zhang [0016], and further explains that the hospital scheduling subsystem inquires the current geographic position of the ambulance and, within a designated distance, considers the salvation ability and free rescue resource of hospital and selected from the hospital nearest to ambulance hospital as the appropriate hospital Zhang [0017]; see also Zhang [0028], [0082]-[0083].
For triage-type output, Zhang teaches that the hospital work station comprises a triage subsystem and that the triage subsystem is used for inquiring patient vital sign data, video and audio data, and geographic location data of the ambulance, and then the patient assigned to the specific doctor Zhang [0018]; see also Zhang [0085]-[0086]. Zhang further describes embedded intelligent triage and nursing function and states This is secondary triage of emergency command centre Zhang [0063].
However, Zhang does not teach the missing feature of inputting the claimed data set to a trained machine-learning model.
Shields teaches that ML-based algorithms can be used to process and make decisions with a high volume of information surrounding a patient including, for example and without limitation: continuous physiological vitals data, HL7 FHIR data e.g. historical patient data Shields, col. 10, ll. 20-50, col. 4, ll. 20-40, fig. 12. Shields teaches the exact relationship Zhang is missing: ECG/vital/patient data go into a machine-learning decision process, and destination and triage results come out.
A POSITA would have made that modification because Shields teaches that machine-learning processing of patient vitals and historical patient data improves emergency decision making for effectively collect, transfer, analyze, and process data for patients in need of health care. Shield, Col 1. ll. 50-60. Using Shields’s known technique in Zhang’s similar system would have predictably produced a more data-driven and more consistent destination and triage determination process.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 JOSHUA DAMIAN RUIZ whose telephone number is (571)272-0409. The examiner can normally be reached 0800-1800.
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, Shahid Merchant can be reached at (571) 270-1360. 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.
/JOSHUA DAMIAN RUIZ/Examiner, Art Unit 3684
/Shahid Merchant/Supervisory Patent Examiner, Art Unit 3684