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 Claims
This action is in reply to the present action filed on 12/08/2025.
Claims 1-20 have been amended.
Claims 1-20 are currently pending and have been examined.
This action is made final.
Claim Objections
Claim 13 is objected to for stating “associated wit the”, and it should state “with”. Appropriate correction is required.
Claim Rejections - 35 USC § 112(a)
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-19 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 1 and 12 recite “continuously synchronizing associated personalized therapy treatment schedule data”. There is no support for the synchronization of the data being continuous in the specification. Appropriate correction is required. Dependent Claims 2-11 and 13-19 are additionally rejected as being dependent on a rejected claim.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 USC § 101 because the claimed invention is directed to a judicial exception (i.e. a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Step 1 Analysis:
Independent Claims 1, 12, and 20 are within the four statutory categories. Claim 1 is directed to a system, Claim 12 is directed to a method, and Claim 20 is directed to a non-transitory computer-readable medium (i.e. a machine). Dependent Claims 2-11 and 13-19 are further directed to a system and method respectively and therefore also fall into one of the four statutory categories.
Step 2A Analysis – Prong One:
The substantially similar independent claims, taking Claim 1 as exemplary, recite the following:
An enterprise software platform for orchestrating a personalized therapy development and/or treatment order in a supply chain, the enterprise software platform comprising:
one or more processors; and one or more storage devices coupled to the one or more processors and configured to store instructions that, when executed by the one or more processors, cause the enterprise software platform to perform operations comprising:
transmitting data to and receiving data from one or more remote computing devices operating an external software system,
wherein the data transmitted to and received from the one or more remote computing devices is passed through a set of application program interfaces (APIs),
including a patient API that manages data transactions associated with patient data by mapping patient identifiers to chain-of-identity (COI),
an ordering API that manages data transactions associated with personalized therapy treatment order data by validating and creating a personalized therapy treatment order linked to a patient’s COI,
and a scheduling API that manages data transactions associated with personalized therapy treatment schedule data by synchronizing therapy workflow schedules in real-time;
wherein the set of APIs work together by linking the patient’s COI to the personalized therapy treatment schedule data across the external software system,
thereby eliminating miscommunication between different platforms, loss of traceability, scheduling conflicts, and/or manual errors.
The series of steps as shown in underline above, given the broadest reasonable interpretation, cover the abstract idea of certain methods of organizing human activity because they recite managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions- in this case, transmitting data, managing data transactions associated with personalized therapy treatment data, and synchronizing workflow schedules) e.g., see MPEP 2106.04(a)(2). Any limitations not identified as part of the abstract idea are deemed “additional elements” and will be discussed in further detail below.
Dependent Claims 3-5, 7-8, 11, 13-15, and 17-19 include other limitations directed toward the abstract idea. For example, Claims 3 and 13 narrow the abstract idea by specifying the creation of a new patient data record includes a patient identification, Claims 4 and 14 narrow the abstract idea by specifying the patient data includes the external system patient ID, ordering institution information associated with the external software system, and patient information, Claims 5 and 15 narrow the abstract idea by specifying the restriction of access to patient information to a user, Claims 7 and 17 narrow the abstract idea by specifying what the ordering data includes, Claims 8 and 18 narrow the abstract idea by specifying the workflow criteria includes attributes of the personalized therapy development or treatment order, Claims 10 and 19 narrows the abstract idea by specifying the creating, updating, or canceling of a schedule of milestones for the personalized therapy development and/or treatment order in the supply chain, Claim 11 narrows the abstract idea by detailing what the schedule data includes. The dependent claims only serve to narrow the abstract idea set forth in the independent claims, and a claim may not preempt abstract ideas, even if the judicial exception is narrow, see MPEP 2106.04. Hence, the dependent claims are further directed toward certain methods of organizing human activity.
Step 2A Analysis – Prong Two:
Claims 1, 12, and 20 are not integrated into a practical application because the additional elements (i.e. the non-underlined limitations above- in this case, the enterprise software platform, processors, storage device, software system, patient API, ordering API, and scheduling API of Claim 1, the server, remote computing device, enterprise software platform, software system, patient API, ordering API, and scheduling API of Claim 12, and the non-transitory computer-readable medium, processors, computing system, remote computing device, enterprise software platform, software system, patient API, ordering API, and scheduling API of Claim 12) are recited at a high level of generality (i.e. as a generic processor performing generic computer functions) such that they amount to no more than mere instructions to apply the exceptions using generic computer components. For example, Applicant’s specification explains that the computer devices 12, 14 of the enterprise software platform 100 can perform a range of operations related to data corresponding to the supply chain events, including but not limited to point-of-care collection…tracking supply chain events…, optimizing resource utilization… (Applicant’s specification, ¶ 0027). The data processing unit of the computer device 12, 14 includes one or more processors operable to process data, one or more memories in communication with the processor to store data, and an input/output unit (I/O) to interface the processor and/or memory to other software or hardware modules, units, or devices of the computer device 12, 14 or an external device [0087]. [T]he Patient API 311 parses the data from the external system(s) 150 to identify and links the unique ID of the external system(s) 150 to the unique identifier (and patient data) within the enterprise software platform 100. In implementations, for example, after a patient has been added to the enterprise software platform 100 with the patient data required by the external system organization, orders can be created for that patient using the external system 150 via the Ordering API 313 [0045]. The Scheduling API 315 interfaces between the enterprise software platform 100 and the external system 150 to enable creation, update, and reception of milestone dates from clients of the external system 150 by a schedule request [0054]. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into practical application because they do not impose any meaningful limits on practicing the idea. Therefore, Claims 1, 12, and 20 are directed to an abstract idea without practical application.
Dependent Claims 2-10 and 13-19 also recite additional elements. Claim 2 recites the previously recited elements of the patient API and enterprise software platform as well as new elements of a first and second data structure and specifies the patient API structures the patient data from a first data structure associated with the external software system to a second data structure readable by the enterprise software platform. Claim 3 recites the previously recited patient API and enterprise software program and specifies the patient API facilitates creation of a new patient data record in the enterprise software platform. Claims 4 and 14 recite the previously recited external software system and specifies the external system includes the external system patient ID, ordering institution information associated with the externa software system, and patient information. Claims 5 and 15 recite the previously recited enterprise software platform and the external software system and specify the enterprise software platform restricts access to the patient information to a user that does not have the ordering institution information of the external software system. Claims 6 and 16 recite the previously recited ordering API, external software system, and enterprise software platform as well as new additional elements of a third data structure and a fourth data structure and specify that the ordering API structures the personalized treatment order data from a third data structure associated with the external software system to a fourth data structure readable by the enterprise software platform. Claims 7 and 17 recite the previously recited ordering API, enterprise software platform, and external software system and specify the ordering API creates, modifies, or cancels the personalized therapy development and/or treatment order in ordering data in the enterprise software platform. Claims 8 and 18 narrow the previously recited ordering API and enterprise software platform by specifying the ordering API automates selection of a workflow of actions in the supply chain amount a plurality of workflows which are stored by the enterprise software platform. Claim 9 narrows the previously recited scheduling API and external software system and introduces a fifth and sixth data structure by specifying the scheduling API structures the schedule data from a fifth data structure associated with the external software system to a sixth data structure readable by the enterprise software platform. Claims 10 and 19 recite the previously recited scheduling API and specifies the scheduling API creates, updates, and/or cancels a schedule of milestones. Claim 13 recites the previously recited patient API and enterprise software program and specifies the patient API structures the patient data from a first data structure to a second data structure readable and processible by the enterprise software platform, and the patient API creates a new patient data record in the enterprise software platform that includes an internal patient identifier corresponding to an external system patient ID. However, these additional elements are described only at a high level of generality and are being used in their expected fashion, so these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on the abstract idea. The claims do not recite additional elements that integrate the judicial exception into a practical application when considered both individually and as an ordered combination.
Step 2B Analysis:
The claims, when considered individually or in combination, do not include any additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed with respect to step 2A prong two, the additional elements of the enterprise software platform, processors, storage device, software system, patient API, ordering API, and scheduling API of Claim 1, the server, remote computing device, enterprise software platform, software system, patient API, ordering API, and scheduling API of Claim 12, and the non-transitory computer-readable medium, processors, computing system, remote computing device, enterprise software platform, software system, patient API, ordering API, and scheduling API of Claim 12 amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept (“significantly more”). MPEP2106.05(I)(A) indicates that merely saying "apply it” or equivalent to the abstract idea cannot provide an inventive concept ("significantly more").
Dependent Claim 11 does not recite any additional elements and only serves to further narrow the abstract idea. Claim 11 narrows the abstract idea by detailing what the schedule data includes.
Claims 3-5, 7-8, 10, 13-15, and 17-19 recite previously cited additional elements, which are not eligible for the reasons stated above, and further narrows the abstract idea. Claim 3 recites the previously recited patient API and enterprise software program and specifies that the patient API facilitates creation of a new patient data record in the enterprise software platform. Claims 4 and 14 recite the previously recited external software system and specify the external system includes the external system patient ID, ordering institution information associated with the external software system, and patient information. Claims 5 and 15 recite the previously recited enterprise software platform and the external software system and specify the enterprise software platform restricts access to the patient information to a user that does not have the ordering institution information of the external software system. Claims 7 and 17 recite the previously recited ordering API, enterprise software platform, and external software system and specify the ordering API creates, modifies, or cancels the personalized therapy development and/or treatment order in ordering data in the enterprise software platform. Claims 8 and 18 narrow the previously recited ordering API and enterprise software platform by specifying the ordering API automates selection of a workflow of actions in the supply chain amount a plurality of workflows which are stored by the enterprise software platform. Claims 10 and 19 recite the previously recited scheduling API and specifies the scheduling API creates, updates, and/or cancels a schedule of milestones. Claim 13 recites the previously recited patient API and enterprise software program and specifies the patient API structures the patient data from a first data structure to a second data structure readable and processible by the enterprise software platform, and the patient API creates a new patient data record in the enterprise software platform that includes an internal patient identifier corresponding to an external system patient ID.
Claims 2, 6, 9, and 16 recite new additional elements. Claim 2 recites the previously recited elements of the patient API and enterprise software platform as well as new elements of a first and second data structure and specifies the patient API structures the patient data from a first data structure associated with the external software system to a second data structure readable by the enterprise software platform. Claims 6 and 16 recite the previously recited ordering API, external software system, and enterprise software platform as well as new additional elements of a third data structure and a fourth data structure and specify that the ordering API structures the personalized treatment order data from a third data structure associated with the external software system to a fourth data structure readable by the enterprise software platform. Claim 9 narrows the previously recited scheduling API and external software system and introduces a fifth and sixth data structure by specifying the scheduling API structures the schedule data from a fifth data structure associated with the external software system to a sixth data structure readable by the enterprise software platform.
Thus, taken alone, the additional elements do not amount to significantly more than the abstract idea identified above. Furthermore, looking at the limitations as an ordered combination does not add anything that is already present when looking at the elements taken individually, and there is no indication that the combination of elements improves the functioning of computer or improves any other technology, and their collective functions merely provide conventional computer implementation.
Therefore, Claims 1-20 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-9, 12-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Mahmood et al. (US 20200177386 A1) in view of Eguro et al. (K. Eguro, "SIRC: An Extensible Reconfigurable Computing Communication API," 2010 18th IEEE Annual International Symposium on Field-Programmable Custom Computing Machines, Charlotte, NC, USA, 2010) and Dunn et al. (US-20230113707-A1).
Regarding Claim 1, Mahmood discloses:
An enterprise software platform for orchestrating a personalized therapy development and/or treatment order in a supply chain, the enterprise software platform comprising: (Mahmood discloses individualized medicine platform module 106 can perform a range of operations related to data corresponding to individualized supply chain events such as point-of-care collection…, tracking supply chain events…, optimizing resources…, security and compliance…, supply chain orchestration events… [0023]. [A] combination of hardware, software, and/or firmware that are configurable to facilitate the exchange of information, such as images, addresses, audio, video, commands, queries, messaging, generation of analytics and other such information [0059].)
one or more processors; and one or more storage devices coupled to the one or more processors and configured to store instructions that, when executed by the one or more processors, cause the enterprise software platform to perform operations comprising: (Mahmood discloses processor 230 can comprise one or more processor configured to perform one or more operations (of at least one module of client individualized medicine module 180) using hardware [0101]. The computer-readable media 240 is illustrated as including memory storage 250. The memory storage 250 represents memory storage capacity associated with one or more computer-readable media [0102].)
transmitting data to and receiving data from one or more remote computing devices operating an external software system (Mahmood discloses server device(s) 102 can be configured as a cloud of one or more server computers that are connected to the multiple devices through a network (e.g., using network component 114), the Internet, or other data communication link capable of enabling functionality to be delivered across multiple devices [0103]. Individualized medicine platform module 106 can access blockchain services using blockchain service module 310 that can use remote procedure call conventions, service-oriented architectures, or other mechanisms that facilitate remote computer systems (e.g., individualized medicine platform module 106) [0111]. Figure 4B illustrated is an example, non-limiting system 400B that includes a personalized medicine supply chain system and one or more distributed external system(s) [0129, see also Fig. 4B which illustrates external systems on remote computing devices].)
wherein the data transmitted to and received from the one or more remote computing devices is passed through a set of application program interfaces (APIs), (Mahmood discloses identity management application 165 can be configured to execute development operations tasks such as creating customer realms, creating client configurations, creating user profiles, assigning groups to user profiles, generating default rules and policies, federating customer realms for customer success groups and development operations groups, creating administrative access tokens (e.g., for application processing interface (API) actions, and/or creating AuthN token [0071]. Individualized medicine platform module 106 can access blockchain services using blockchain service module 310 that can use remote procedure call conventions, service-oriented architectures, or other mechanisms that facilitate remote computer systems (e.g., individualized medicine platform module 106) [0111].)
including a patient [API] that manages data transactions associated with patient data, (Mahmood discloses identity management application 165 can be configured to execute development operations tasks such as creating customer realms, creating client configurations, creating user profiles, assigning groups to user profiles, generating default rules and policies, federating customer realms for customer success groups and development operations groups, creating administrative access tokens (e.g., for application processing interface (API) actions, and/or creating AuthN token [0071].)
an ordering [API] that manages data transactions associated with personalized therapy treatment order data, by validating and creating a personalized therapy treatment order… (Mahmood discloses individualized medicine platform module 106 can execute supply chain optimization module 110 to facilitate ordering one or more therapy for a patient [0025-26]. Server device 102 can include an ordering module 110 that acquires, processes and curates data associated with ordering activities in a personalized medicine supply chain [0063]. In an aspect, this non-limiting example of an ordering feature of individualized medicine platform module 106 illustrates how any suitable type of order data can be acquired, generated and/or stored by ordering module 110 and how modules can perform operations in combination with other modules [0065].)
and a scheduling [API] to manage data transactions associated with personalized therapy treatment schedule data by synchronizing therapy workflow schedules in real-time; (Mahmood discloses a personalized medicine supply chain…can include one or more server device(s) 102 and one or more computing device(s) 104 that can generate, curate, track, monitor and store data associated with transactional processes of an individualized medicine supply chain [0021]. Various system components such as the scheduler component and manufacturing capacity component can be used to satisfy requirement criteria to facilitate a system determination (e.g., date availabilities for manufacturing occur)…a capacity-based scheduling operations employed…can utilize scheduling rules that correspond to a number of manufacturing slots available per week, number of slots currently scheduled, additional bookings available for the week, and generate determinations (e.g., using supply chain optimization module 110) as to dates and times available for manufacturing [0044].)
Mahmood does not explicitly disclose the patient, ordering, and scheduling modules being executed with an API which is met by Eguro:
…API… (Eguro teaches we have presented SIRC, a software hardware communication and synchronization API specifically designed for reconfigurable computing platforms. The high-level, platform-agnostic design of the API allows us to completely separate the implementation details a given communication mechanism from all user generated application code (p. 4, ¶ 0007).)
wherein the set of APIs work together by…continuously synchronizing associated… data across the external software system, thereby eliminating miscommunication between different platforms, loss of traceability, scheduling conflicts, and/or data entry errors. (Eguro teaches multiple sets of API interfaces can be used simultaneously to allow overlapped I/O and streaming execution. For example, if the user creates two instances of the software-side API (in two different threads), each one will communicate independently with one of two hardware-side APIs. Each of these hardware APIs will have their own set of I/O buffers, parameter registers, and associated handshaking/execution control signals (p. 4, ¶ 0002).)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the system and methods for personalized therapy development including the transmitting and receiving of data from remote devices, using APIs and managing patient data transactions, treatment order data, and treatment schedule data as disclosed by Mahmood to incorporate the modules of Mahmood being carried out on APIs as taught by Eguro. This modification would create a system and method capable of eliminating miscommunication amongst the system (see Eguro, p. 1, ¶ 0002-3).
Mahmood and Eguro do not teach the following limitations met by Dunn:
…by mapping patient identifiers to chain-of-identity (COI), (Dunn teaches Chain of Identity is enabled by a COI Identifier (COI ID), a set of numbers and/or characters that is the overarching “ID badge” for each patient and key materials related to their product. The COI ID must link a therapy to the intended patient and protect patient privacy. The COI ID is used in multiple places on the patient journey, from medical records to in-process drug labels [0081].)
…a personalized treatment…linked to a patient's COI, (Dunn teaches the COI ID must link a therapy to the intended patient and protect patient privacy [0081]. A single COI ID that best meets the data needs of the patient, the site and the product that comprises three sub identifiers:… a treatment ID,…The treatment ID includes a continuous string of multiple alphanumeric characters that uniquely identifies a specific treatment order cycle for a therapy, which is distinct part of the treatment journey [0083].)
…linking the patient's COI to the personalized therapy treatment order and… (Dunn teaches Chain of Identity is enabled by a COI Identifier (COI ID), a set of numbers and/or characters that is the overarching “ID badge” for each patient and key materials related to their product. The COI ID must link a therapy to the intended patient and protect patient privacy. The COI ID is used in multiple places on the patient journey, from medical records to in-process drug labels [0081].)
It would have been obvious to a person having ordinary skill in the art prior to the effective filing date of the claimed invention to have modified the system and methods for personalized therapy development including the transmitting and receiving of data from remote devices, using APIs and managing patient data transactions, treatment order data, and treatment schedule data as disclosed by Mahmood to incorporate the use of COI data to link to the personalized therapy treatment order as taught by Dunn. This modification would create a system capable of solving challenges associated with personalized medicine supply that impede the ability to implement personalized medicine on a large or global scale (see Dunn, ¶ 0004).
Regarding Claim 12, this claim recites limitations that are substantially similar to those of Claim 1 above; thus the same rejection applies. Mahmood further discloses:
A method for orchestrating a personalized therapy development and/or treatment order in a supply chain, the method comprising: from a server, transmitting data to and receiving data from one or more remote computing devices operating a software system external to the enterprise software platform (Mahmood discloses a computer-implemented method is provided. In an aspect, the method can include accessing, by a user device, an individualized medicine system operatively coupled to a processor …the computer-implemented method can comprise transmitting, by the user device, a query request to the individualized analytics system [0007]. Server device(s) 102 can be configured as a cloud of one or more server computers that are connected to the multiple devices through a network [0103]. Service-oriented architectures, or other mechanisms that facilitate remote computer systems (e.g., individualized medicine platform module 106) to request services from remote resources (e.g., blockchain 320) [0111].)
Regarding Claim 20, this claim recites limitations that are substantially similar to those of Claim 1 above; thus the same rejection applies. Mahmood further discloses:
A non-transitory, computer-readable medium storing instructions thereon that, when executed by one or more processors of a computing system, (Mahmood discloses processor 230 can comprise one or more processor configured to perform one or more operations (of at least one module of client individualized medicine module 180) using hardware. The computer-readable media 240 is illustrated as including memory storage 250. The memory storage 250 represents memory storage capacity associated with one or more computer-readable media [0101-102].)
cause the computing system to perform operations for orchestrating a personalized therapy development and/or treatment order in a supply chain, the operations comprising: (Mahmood discloses individualized medicine platform module 106 can perform a range of operations related to data corresponding to individualized supply chain events such as point-of-care collection (e.g., collection of samples that meet threshold quality standard requirements), tracking supply chain events (e.g., as relates to manufacturing a personalized therapeutic for a patient) [0023]. Software, and/or firmware that are configurable to facilitate the exchange of information [0059].)
Regarding Claim 2, Mahmood, Eguro, and Dunn teach the limitations as seen in the rejection of Claim 1 above. Eguro teaches the use of APIs as seen in the rejection of Claim 1 above. Mahmood further discloses:
wherein the patient API is configured to structure the patient data from a first data structure associated with the external software system to a second data structure readable and processible by the enterprise software platform. (Mahmood discloses computing device 104 can employ display module 190 to transform the data to various types of output information (e.g., text, charts, video, audio, graphs, tables, and other such output) [0040]. The Examiner interprets the transformed data as the second data structure. By following these rules, a first entity can create and store a data structure such that a second entity can successfully access and interpret the data included in the data structure [0063].)
Regarding Claim 3, Mahmood, Eguro, and Dunn teach the limitations as seen in the rejection of Claim 2 above. Eguro teaches the use of APIs as seen in the rejection of Claim 1 above. Mahmood further discloses:
wherein the patient API is configured to facilitate creation of a new patient data record in the enterprise software platform that includes an internal patient identifier (ID) that corresponds to an external system patient ID included in the patient data. (Mahmood discloses computing device 104 can employ display module 190 to transform the data to various types of output information (e.g., text, charts, video, audio, graphs, tables, and other such output) that are based upon order data, …patient identification data,…[0040]. An identity provider (IDP) can refer to an entity configured to create, maintain, and manage identity information for user profiles and devices of individualized medicine platform module 106 while providing authentication services to integrated applications [0054]. Environment 100C can accommodate a multitude of scenarios to integrate external IDP's and internal IDP's (e.g., first identity management application 165) with individualized medicine platform module 106. In a non-limiting embodiment, one or more client (e.g., using computing device(s) 104) can integrate its own IDP system that authenticates internal…and external users… with individualized medicine platform module 106 [0091].)
Regarding Claim 4, Mahmood, Eguro, and Dunn teach the limitations as seen in the rejection of Claim 1 above. Mahmood further discloses:
wherein the patient data received from the external system includes the external software system patient ID, ordering institution information associated with the external software system, and patient information. (Mahmood discloses computing device 104 can employ display module 190 to transform the data to various types of output information (e.g., text, charts, video, audio, graphs, tables, and other such output) that are based upon order data, schedule data, capacity data, patient identification data [0040]. Environment 100C can accommodate a multitude of scenarios to integrate external IDP's and internal IDP's (e.g., first identity management application 165) with individualized medicine platform module 106 [0091].)
Regarding Claim 14, this claim recites limitations that are substantially similar to those recited in Claim 4 above; thus, the same rejection applies.
Regarding Claim 5, Mahmood, Eguro, and Dunn teach the limitations as seen in the rejection of Claim 4 above. Mahmood further discloses:
wherein the enterprise software platform is configured to restrict access to the patient information to a user that does not possess ordering institution information of the external software system. (Mahmood discloses a user can refer to a device accessing…the individualized medicine platform module 106 as a representative of an institute to execute various operations within a step of the individualized medicine supply chain for a therapy in a respective region. Furthermore, a user can be a member of a group in an identity provider (e.g., pharmaceutical company, hospital, infusion center, manufacturing facility, etc.) where such membership is mapped to a role (e.g., role 1 can access personal health identifier (PHI) information for therapy A, role 2 is restricted from accessing PHI for therapy A) within such identity provider corresponding to respective permissions (e.g., executable actions or operations permitted by user) on a therapy in a region [0053].)
Regarding Claim 15, this claim recites limitations that are substantially similar to those recited in Claim 5 above; thus, the same rejection applies.
Regarding Claim 6, Mahmood, Eguro, and Dunn teach the limitations as seen in the rejection of Claim 1 above. Eguro teaches the use of APIs as seen in the rejection of Claim 1 above. Mahmood further discloses:
wherein the ordering API is configured to structure the personalized therapy treatment order data from a third data structure associated with the external software system to a fourth data structure readable and processible by the enterprise software platform. (Mahmood discloses supply chain optimization module 110 can generate, receive, curate, and/or transform ordering data, scheduling data, and/or resource management data. In an aspect, ordering data can represent instructions to order raw materials, patient samples, intermediary materials, final products (e.g., therapeutic drugs), and other such items associated with the individualized medicine supply chain [0041]. The Examiner interprets this as converting the third data structure to the fourth. By following these rules, a first entity can create and store a data structure such that a second entity can successfully access and interpret the data included in the data structure [0063].)
Regarding Claim 16, this claim recites limitations that are substantially similar to those recited in Claim 6 above; thus, the same rejection applies.
Regarding Claim 7, Mahmood, Eguro, and Dunn teach the limitations as seen in the rejection of Claim 6 above. Eguro teaches the use of APIs as seen in the rejection of Claim 1 above. Mahmood further discloses:
the ordering API is configured to create, modify, and/or cancel the personalized therapy development and/or treatment order in the supply chain in ordering data in the enterprise software platform, (Mahmood discloses supply chain optimization module 110 can generate, receive, curate, and/or transform ordering data,…and/or resource management data. In an aspect, ordering data can represent instructions to order raw materials, patient samples, intermediary materials, final products (e.g., therapeutic drugs), and other such items associated with the individualized medicine supply chain [0041].)
wherein the ordering data includes one or more of (i) a patient reference, (ii) product information, (iii) ordering institution information associated with the external software system, (iv) regional information associated with location of the product or treatment, (v) indication data, (vi) milestone data, and (vii) configurable workflow criteria that are configurable by a user of the external software system. (Mahmood discloses ordering data can represent instructions to order raw materials, patient samples, intermediary materials, final products (e.g., therapeutic drugs), and other such items associated with the individualized medicine supply chain [0041]. )
Regarding Claim 17, this claim recites limitations that are substantially similar to those recited in Claim 7 above; thus, the same rejection applies.
Regarding Claim 8, Mahmood, Eguro, and Dunn teach the limitations as seen in the rejection of Claim 7 above. Eguro teaches the use of APIs as seen in the rejection of Claim 1 above. Mahmood further discloses:
wherein the ordering API is configured to automate selection of a workflow in the supply chain among a plurality of workflows, which are stored by the enterprise software platform, (Mahmood discloses supply chain optimization module 110 can acquire, curate, analyze, integrate, and/or generate data associated with a material workflow through various stages of a supply chain [0028].)
by utilizing the configurable workflow criteria to include attributes of the personalized therapy development and/or treatment order to select most appropriate workflow from the plurality of workflows. (Mahmood discloses non-limiting data stored on the blockchain or on data stores coupled to server device(s) 102 can include identity data, custody data, label data…, scheduling data (e.g., between supply chain stakeholders), workflow data, analytics feeder data, integration data, asset data, financial data, laboratory data, manufacturing data human resource data, inventory data, patient compliance data, patient enrollment data, patient information …[0131].)
Regarding Claim 18, this claim recites limitations that are substantially similar to those recited in Claim 8 above; thus, the same rejection applies.
Regarding Claim 9, Mahmood, Eguro, and Dunn teach the limitations as seen in the rejection of Claim 1 above. Eguro teaches the use of APIs as seen in the rejection of Claim 1 above. Mahmood further discloses:
wherein the scheduling API is configured to structure the personalized therapy treatment schedule data from a fifth data structure associated with the external software system to a sixth data structure readable and processible by the enterprise software platform. (Mahmood discloses supply chain orchestration events (e.g., scheduling couriers, raw material delivery, tracking kits and materials and raw materials), ordering and scheduling activities (e.g., scheduling of sample collections, manufacturing, administration of medicine, etc.), reporting tasks (e.g., reporting quality findings, compliance activities, chain of identity information, chain of custody information, etc.), and/or facilitating system integrations (e.g., data integrations, data modifications, insight procurement, etc.) [0023]. Computing device 104 can employ display module 190 to transform the data to various types of output information…that are based upon… milestone data [0040].)
Regarding Claim 10, Mahmood, Eguro, and Dunn teach the limitations as seen in the rejection of Claim 9 above. Mahmood further discloses:
wherein the scheduling API is configured to create, update, or cancel a schedule of milestones for the personalized therapy development and/or treatment order in the supply chain. (Mahmood discloses computing device 104 can employ display module 190 to transform the data to various types of output information (e.g., text, charts, video, audio, graphs, tables, and other such output) that are based upon order data, schedule data, capacity data, patient identification data, sample identification data, courier data, manufacturer data (e.g., batch number), electronic record data, milestone data [0040]. Supply chain optimization module 110 can execute scheduling operations…can employ a set of rules and requirements applied against intake data to determine a limited selection of options allowable for scheduling. For instance, one or more rules can correspond to…therapy-specific conditions for transportation and delivery time constraints, logistical restrictions… [0026, 0029]. The Examiner interprets the therapy-specific conditions as milestones which are created by the supply chain optimization module.)
Regarding Claim 11, Mahmood, Eguro, and Dunn teach the limitations as seen in the rejection of Claim 10 above. Mahmood further discloses:
wherein the personalized therapy treatment schedule data includes an order reference, external system patient ID, a treatment reference, and/or milestone data. (Mahmood discloses execution of scheduling transactions based on scheduling condition data [0114]. Supply chain optimization module 110 can receive scheduling data (e.g., representing instructions to execute a scheduling task) from client individualized medicine module 180 (e.g., receiving data from input module 192), where the scheduling data represents the event of collecting blood samples from a center of excellence (e.g., hospital qualified for a respective therapy) [0028]. The Examiner interprets the event of collecting blood samples as an order reference.)
Regarding Claim 13, Mahmood, Eguro, and Dunn teach the limitations as seen in the rejection of Claim 12 above. Eguro teaches the use of APIs as seen in the rejection of Claim 1 above. Mahmood further discloses:
the patient [API] is configured to structure the patient data from a first data structure associated with the external software system to a second data structure readable and processible by the enterprise software platform; (Mahmood discloses computing device 104 can employ display module 190 to transform the data to various types of output information (e.g., text, charts, video, audio, graphs, tables, and other such output) [0040]. The Examiner interprets the transformed data as the second data structure. By following these rules, a first entity can create and store a data structure such that a second entity can successfully access and interpret the data included in the data structure [0063].)
and wherein the patient [API] is configured to facilitate creation of a new patient data record in the enterprise software platform that includes an internal patient identifier (ID) that corresponds to an external system patient ID included in the patient data. (Mahmood discloses computing device 104 can employ display module 190 to transform the data to various types of output information (e.g., text, charts, video, audio, graphs, tables, and other such output) that are based upon… patient identification data,…[0040]. An identity provider (IDP) can refer to an entity configured to create, maintain, and manage identity information for user profiles and devices of individualized medicine platform module 106 while providing authentication services to integrated applications [0054]. Environment 100C can accommodate a multitude of scenarios to integrate external IDP's and internal IDP's (e.g., first identity management application 165) with individualized medicine platform module 106. In a non-limiting embodiment, one or more client …can integrate its own IDP system that authenticates internal …and external users… with individualized medicine platform module 106 [0091].)
Regarding Claim 19, Mahmood, Eguro, and Dunn teach the limitations as seen in the rejection of Claim 12 above. Eguro teaches the use of APIs as seen in the rejection of Claim 1 above. Mahmood further discloses:
the scheduling [API] is configured to structure the personalized therapy treatment schedule data from a fifth data structure associated with the external software system to a sixth data structure readable and processible by the enterprise software system; (Mahmood discloses computing device 104 can employ display module 190 to transform the data to various types of output information (e.g., text, charts, video, audio, graphs, tables, and other such output) [0040]. The Examiner interprets the transformed data as the sixth data structure. By following these rules, a first entity can create and store a data structure such that a second entity can successfully access and interpret the data included in the data structure [0063].)
and wherein the personalized therapy treatment schedule data includes an order reference, external system patient ID, a treatment reference, and/or milestone data; (Mahmood discloses execution of scheduling transactions based on scheduling condition data [0114]. Supply chain optimization module 110 can receive scheduling data (e.g., representing instructions to execute a scheduling task) from client individualized medicine module 180 (e.g., receiving data from input module 192), where the scheduling data represents the event of collecting blood samples from a center of excellence (e.g., hospital qualified for a respective therapy) [0028]. The Examiner interprets the event of collecting blood samples as an order reference.)
wherein the scheduling API is configured to create, update, or cancel a schedule of milestones for the personalized therapy development and/or treatment order in the supply chain. (Mahmood discloses computing device 104 can employ display module 190 to transform the data to various types of output information (e.g., text, charts, video, audio, graphs, tables, and other such output) that are based upon order data, schedule data, capacity data, patient identification data, sample identification data, courier data, manufacturer data (e.g., batch number), electronic record data, milestone data [0040]. Supply chain optimization module 110 can execute scheduling operations…can employ a set of rules and requirements applied against intake data to determine a limited selection of options allowable for scheduling. For instance, one or more rules can correspond to…therapy-specific conditions for transportation and delivery time constraints, logistical restrictions… [0026, 0029]. The Examiner interprets the therapy-specific conditions as milestones which are created by the supply chain optimization module.)
Relevant Art Made of Record Not Currently Being Applied
The following references are considered pertinent to Applicant’s disclosure but are not currently being applied:
Said et al. (US-20200234826-A1) teaches mechanisms for implementing an integrated platform that provides personalized health care information and treatment recommendations which includes the use of various APIs.
Hogue et al. (US-20180102190-A1) teaches personalized treatment plan generation which uses specific data structures to extract patient specific data, determine a patient-specific plan, and manage the treatment.
Tran et al. (US-20180264347-A1) teaches a system for supply chain tracking and management including a plurality of specialist knowledge modules such as a scheduler.
Mahmood et al. (US-20210280287-A1) teaches systems for executing operations related to executing a series of dependent scheduling operations associated with an individualized medicine supply chain and distributed scheduling systems.
Response to Arguments
Regarding objections to Claims 12 and 20, Applicant’s amendments have been considered, and the objections have been withdrawn. A new objection to Claim 13 has been made.
Regarding rejections under 35 USC 101 to Claims 1-20, Applicant’s arguments have been considered but are not persuasive. The rejection has been updated in light of the amendments above.
Applicant argues the claims as amended are not directed to an abstract idea. The claims recite a specific enterprise software comprising a patient API, an ordering API, and a scheduling API, wherein each performs a concrete, computer-implemented data-management function that cannot be performed mentally or by hand (see Applicant’s Remarks, p. 3).
Regarding (a), Examiner respectfully disagrees. The claims do recite additional elements, such as the various APIs, which are not a part of the abstract idea, but instead are listed as additional elements. Further, Examiner notes that the claims are listed as reciting certain methods of organizing human activity, not mental processes. The human interaction subgroup “managing personal behavior or relationships or interactions between people” would include a patient data management interaction. It is important to note that the text within the parentheses stating social activities, teaching, and following rules or instructions are provided as examples and not an exclusive listing and that the October 2019 Update: Subject Matter Eligibility on p. 5 stating certain activity between a person and a computer may fall within the “certain methods of organizing human activity” grouping.
Applicant argues the patient API is explicitly recited as "mapping patient identifiers to chain-of-identity (COI)." This limitation requires the platform to execute instructions that transform external patient identifiers into an internal COI identifier. This is a specific data-structure operation within a networked computing environment, not a mental process or a generic "receiving and storing" step (p. 3).
Regarding (b), Examiner respectfully disagrees. The recited limitation is directed to an abstract idea, which cannot provide a practical application under Step 2A Prong One or “significantly more” under Step 2B. An improvement to the abstract ideas of data mapping does not amount to an improvement to technology or a technical field (see MPEP § 2106.05(a)(III) stating “it is important to keep in mind that an improvement in the abstract idea itself (e.g. a recited fundamental economic concept) is not an improvement in technology. Further, Examiner notes that data mapping does not include data transformation. It is a pre-processing step before any data transformation involving matching fields from databases or systems to another. The specification does not provide any alternate definition to the term “mapping”, so Applicant is not acting as their own lexicographer and the commonly held/understood meaning of the term applies. The claims do not recite any specific way in which the data is mapped and only states the patient API “manages data transactions associated with patient data by mapping patient identifiers to chain-of-identity (COI)”. The patient API is therefore not claimed as transforming any data.
Applicant argues the ordering API is expressly recited as "validating and creating a personalized therapy treatment order linked to a patient's COI." This is a technical validation and creation process tied to the platform's internal data structures and workflows. The operation cannot be performed without the platform's processor executing stored instructions to confirm COI linkages and construct a machine-readable order object (p. 4).
Regarding (c), Examiner respectfully disagrees. The recited limitation is directed to an abstract idea, which cannot provide a practical application under Step 2A Prong One or “significantly more” under Step 2B. It is important to note that the text within the parentheses stating social activities, teaching, and following rules or instructions are provided as examples and not an exclusive listing and that the October 2019 Update: Subject Matter Eligibility on p. 5 stating certain activity between a person and a computer may fall within the “certain methods of organizing human activity” grouping. There are no details on how the “validating a creating a personalized therapy treatment order linked to a patient’s COI” is accomplished. This limitation can be done by hand and therefore cannot be a technical problem. Further, Examiner notes the processor is recited as a generic additional element, and the claims merely state “apply it” (or an equivalent) with the judicial exception, as discussed in MPEP § 2106.05(f). Further, the argued technical improvements of “the platforms internal data structures and workflows” and “to confirm COI linkages and construct a machine-readable order object” is not found in the claims, and therefore cannot provide an improvement.
Applicant argues the scheduling API is expressly recited as "synchronizing therapy workflow schedules in real-time," which is a real-time, computer-implemented synchronization function among distributed external systems. This requires the use of machine-executed timestamp reconciliation, propagation of updates, and cross-system state consistency. Such real-time inter-system synchronization is a technical operation, not an abstract idea (p. 4).
Regarding (d), Examiner respectfully disagrees. The synchronization of schedules is a problem that existed before computers, and is therefore not a technological problem. Further, a workflow is not a technological improvement, it is merely generic patterns of activity. The limitations of “timestamp reconciliation, propagation of updates, and cross-system state consistency” is not claimed and therefore cannot provide a practical application.
Applicant argues the USPTO Memorandum dated August 4, 2025, which clarifies that "a claim does not recite a mental process when it contains limitation(s) that cannot practically be performed in the human mind, for instance when the human mind is not equipped to perform the claim limitation(s)" on page 2, fifth paragraph [emphasis added]. Claims as amended herein clearly fall within that category (p. 4).
Regarding (e), Examiner respectfully disagrees. The claims do recite additional elements, such as the various APIs, which are not a part of the abstract idea, but instead are listed as additional elements. Further, Examiner notes that the claims are listed as reciting certain methods of organizing human activity, not mental processes. The human interaction subgroup “managing personal behavior or relationships or interactions between people” would include a patient data management interaction. It is important to note that the text within the parentheses stating social activities, teaching, and following rules or instructions are provided as examples and not an exclusive listing and that the October 2019 Update: Subject Matter Eligibility on p. 5 stating certain activity between a person and a computer may fall within the “certain methods of organizing human activity” grouping.
Applicant argues the claims now expressly recite that the patient, ordering, and scheduling APIs "work together by linking the patient's COI to the personalized therapy treatment order and continuously synchronizing associated personalized therapy treatment schedule data across the external software system." This is a specific architectural arrangement that improves traceability, reliability, and data consistency across the disparate systems. Each API performs a defined technical function: the patient API transforms external identifiers into a COI data structure; the ordering API validates and creates COI-linked therapy orders, altering the platform's internal machine state; and the scheduling API performs real-time, machine-implemented synchronization across distributed systems.
Regarding (f), Examiner respectfully disagrees. There is no detail to how the APIs of the system specifically work together. MPEP 2106.05(f) states when determining whether a claim simply recites a judicial exception with the words "apply it" (or an equivalent), such as mere instructions to implement an abstract idea on a computer, examiners may consider the following: (1) Whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished. The recitation of claim limitations that attempt to cover any solution to an identified problem with no restrictionon how the result is accomplished and no description of the mechanism for accomplishing the more because this type of recitation is equivalent to the words “apply it”. See Electric PowerGroup, LLC v. Alstom, S.A., 830 F.3d 1350, 1356, 119 USPQ2d 1739, 1743-44 (Fed. Cir.2016); Intellectual Ventures I v. Symantec, 838 F.3d 1307, 1327, 120 USPQ2d 1353, 1366 (Fed.Cir. 2016); Internet Patents Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d1414, 1417 (Fed. Cir. 2015). The claims appear to merely recite the solution with no details ofhow this solution is reached. There is no indication how the APIs “work together” or how they continuously synchronize other than the catch all limitation with no mechanisms for how the solution is being performed. In ¶ 0021 of the instant specification, it is stated that an API is a type of software interface that provides a connection between computer programs on the same or different computers. APIs are ubiquitous for accessing data, storing data, performing analysis on said data.
Additionally, Examiner notes that, as stated above in (b), the patient API does not “transform” data. The recitation of the APIs “altering the platform's internal machine state” is also not claimed.
Applicant argues the cooperative behavior of these APIs automatically resolves inconsistencies that previously required manual reconciliation, thereby improving the functioning of the underlying distributed computing environment (p. 5).
Regarding (g), Examiner respectfully disagrees. All of the patient APIs perform completely separate functions. For example, patient API does not resolve any inconsistences with scheduling or ordering. Further, the argument of these APIs automating a manual process is the definition of “apply it” using a computer.
Applicant argues there is no evidence in the record showing that it was conventional for enterprise therapy-orchestration platforms to include a patient API that performs identifier-to-COI mapping, an ordering API that validates and creates COI-linked therapy orders, and a scheduling API that performs real-time cross-system synchronization, nor that such APIs were conventionally arranged to link COI, orders, and schedules to eliminate miscommunication, loss of traceability, scheduling conflicts, and manual data-entry errors. This coordinated API architecture is a non-generic, non-routine configuration, and the industry lacked automated, COI-linked, real-time inter-system orchestration tools of this kind. As explained in paragraphs [0004] and [0017]-[0020] of the as-filed specification, prior systems relied on manual reconciliation or siloed software incapable of synchronizing patient identity, therapy order, and scheduling data (p. 6).
Regarding (h), Examiner respectfully disagrees. Applicants specification [0017]-[0020] indicates that Vineti has previously disclosed a software platform technology that addresses the problems with personalized therapy. These improvements have been utilized in the instant invention and are merely modified by adjusting the software from an individual to an enterprise software system, which is not enough to provide an improvement to technology.
Regarding rejections under 35 USC 103 to Claims 1-20, Applicant’s arguments have been considered and are persuasive; therefore, the rejection has been withdrawn. However, upon further consideration, a new rejection has been made in light of the amendments, rejecting Claim 1 over Mahmood in view of Eguro and Dunn.
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 OLIVIA R GEDRA whose telephone number is (571)270-0944. The examiner can normally be reached Monday - Friday 8:00am-5:00pm.
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, Peter H Choi can be reached at (469)295-9171. 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.
/OLIVIA R. GEDRA/Examiner, Art Unit 3681
/PETER H CHOI/Supervisory Patent Examiner, Art Unit 3681