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 .
Priority
Acknowledgment is made of applicant’s claim of PCT/EP2023/065551 and for foreign priority EP22382561.3 under 35 U.S.C. 119 (a)-(d).
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 02/03/25. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 19 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.
Claim 19 recites the limitations "the common interest," in generating an agreement based on one or more of: the common interest, the regulator collaborator, the regulatory decision... . There is insufficient antecedent basis for these limitations in the 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.
Subject Matter eligibility Rejection 35 U.S.C 101
Claims 1-20 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 Analysis
The claims are directed to statutory subject matter, encompassing the following statutory categories:
Process (Claims 1-20): The independent claim recites a "method of digitally facilitating regulatory decision-making" comprising a series of specific acts, including "providing a digital environment," "obtaining... a central data structure," "receiving... a request," and "digitally documenting" feedback. These limitations describe a series of steps to be performed, which aligns with the definition of a Process in MPEP § 2106.03.
Having confirmed the claims are directed to statutory subject matter, the analysis proceeds to Step 2A Prong one.
Step 2A, Prong One: Judicial Exception Analysis
Step 2A, Prong One verifies whether a claim recites a specific judicial exception before determining if that exception is integrated into a practical application under Prong Two.
The whole invention is related to a collaborative digital framework for improving regulatory decision-making by leveraging previously approved standardized digital solutions and documenting feedback. Refer to Specification paragraphs [0002] and [0005] for further details.
More specifically, Claims 1-20 are directed to a judicial exception because they recite the abstract idea of collecting, organizing, and managing information through administrative human interactions. This overarching concept falls within the specified categories of Mental Processes (MPEP § 2106.04(a)(2)(III)) and Certain Methods of Organizing Human Activity (MPEP § 2106.04(a)(2)(II)). Under the Broadest Reasonable Interpretation (BRI), the claims recite a functional workflow for database management and collaborative communication.
Independent Claim 1 Recites:
Claim 1.
A method of digitally facilitating regulatory decision-making of at least a component of a standardized digital solution for characterizing a disease, the method comprising: providing a digital environment comprising a plurality of components of standardized digital solutions, wherein the digital environment is accessible by a plurality of collaborators; obtaining, at a processor, a central data structure, wherein the central data structure comprises compiled evidence of a plurality of components of one or more previously-approved standardized digital solutions; receiving, at the processor, a request for a new standardized digital solution; generating, at the processor, the new standardized digital solution by leveraging one or more components of the plurality of components of the one or more previously-approved standardized digital solutions in the central data structure; receiving, at the processor, additional data for the new standardized digital solution from a collaborator of the plurality of collaborators; updating, at the processor, the central data structure to incorporate the additional data; receiving, at the processor, feedback from a regulatory collaborator, wherein the received feedback comprises a regulatory acceptance of at least a component of the new standardized digital solution; and digitally documenting the received feedback from the regulatory collaborator.
Claim Abstract Classification Rationale
Under their Broadest Reasonable Interpretation (MPEP § 2111), independent claims 1-20 recite a workflow for collecting regulatory evidence, reorganizing that data to create a new solution, and facilitating communications between stakeholders to record regulatory approval. This process aligns with the following abstract idea categories:
Mental Process (MPEP § 2106.04(a)(2)(III)): The independent claims recite cognitive steps of "leveraging" components to "generate" a solution and "updating" a structure based on "feedback." These steps describe the analytical act of selecting relevant information to satisfy a request and refining a draft based on commentary, which can be performed in the human mind. MPEP § 2106.04(a)(2)(III) defines mental processes as those that can be performed in the mind, including "analyzing information." The specification supports this, stating: "The TSP is built by identifying the components and assets that are available for use... This ensures that components and assets that have previously been generated and/or validated can be easily repurposed" (Spec., para. [0026]). This confirms that the "leveraging" involves mathematical or logical operations on information to determine which data fits a specific need, which are hallmarks of mental processes.
Certain Method of Organizing Human Activity (MPEP § 2106.04(a)(2)(II)): The independent claims recite "providing a digital environment accessible by a plurality of collaborators" and "receiving... feedback from a regulatory collaborator." This describes a managed workflow of interaction, which falls under the sub-category of Managing Personal Behavior or Relationships. This fits the category because it organizes how various stakeholders (collaborators and regulators) interact to share data and feedback. The specification supports this, stating: "Generally, methods disclosed herein involve providing a collaborative platform that brings together various stakeholders for creating standardized digital solutions" (Spec., para. [0002]). This explicitly defines the invention as a framework for managing human organizational relationships by addressing administrative challenges and facilitating interaction among people, consistent with MPEP § 2106.04(a)(2)(II).
Manual Replication Scenario (Human Equivalence)
The abstract nature of the claims is reinforced because the entire process is analogous to fundamental human activities. Even though a computer may perform these steps with greater efficiency or speed, the underlying process remains a series of mental and organizational acts.
Providing an environment: A project manager provides a shared physical office space (equivalent to the digital environment) where researchers (collaborators) can work.
Obtaining a data structure: A researcher pulls a folder of case studies on previously approved medical devices (equivalent to the central data structure) from a file cabinet.
Receiving a request: The manager receives a letter asking for a new device proposal.
Leveraging components: The researcher looks through the old case studies and selects relevant diagrams and data to paste into the new proposal draft.
Receiving additional data/Updating: A colleague reads the draft and adds a handwritten note with new test results; the researcher incorporates these into the draft.
Receiving feedback/Documenting: A government inspector (regulatory collaborator) reads the proposal, says "I accept this component," and the researcher writes "Approved by Inspector" on the top of the page.
Dependent Claims Analysis
The dependent claims 2-20 are also directed to an abstract idea.
Claims 2–9, 15–16, 18: These claims recite under BRI specific types of data being processed (e.g., "measurement data," "acceptability categorization," or "clinical information"), which specifies the content of the information without adding a technical application, remaining a Mental Process.
Claims 10–14, 19: These claims recite under BRI organizational rules such as "establishing standardized roles" or "receiving agreement on criteria," which represent "legal or commercial interactions" or "managing personal behavior" sub-categories within the Certain Methods of Organizing Human Activity exception.
Claim 20: Recites "generating a dossier," which is a common administrative act of compiling a report, falling under a Method of Organizing Human Activity.
As the claims recite a judicial exception, the analysis proceeds to Step 2A, Prong Two to determine if the exception is integrated into a practical application.
Step 2A, Prong Two: Integration into a Practical Application
Step 2A, Prong Two evaluates whether the claim as a whole integrates the judicial exception into a practical application by applying additional elements that meaningfully limit the exception. The additional elements in the present claims do not integrate the abstract idea because they represent generic computer components and administrative limitations that do not transform the judicial exception into an eligible application.
Evaluation of Independent Claim 1 Additional Elements
Processor and Storage (Digital Environment/Central Data Structure): Under the Broadest Reasonable Interpretation (BRI) (MPEP § 2111), the recitation of a "processor" and a "central data structure" within a "digital environment" defines a general-purpose computer used as a tool for information management. These elements fail to integrate the abstract idea because:
The additional elements are mere instructions for a generic processor to perform the abstract organizational steps identified in Prong One. Under MPEP 2106.05(a), the claims fail to provide a technological improvement because they only optimize administrative record-keeping. Finally, the limitations merely link the process to a medical environment. Each additional element, even in combination, fails to transform the abstract idea because the arrangement describes a generic computer performing its standard function of data storage and retrieval.
When viewed as a whole, the combination of these elements does not integrate the abstract idea. The claim describes a generic arrangement performing the abstract analysis, which does not transform the abstract idea into an eligible application.
Dependent Claims Analysis
The dependent claims add further structural data limitations that remain directed to the judicial exceptions identified in Prong One and fail to provide integration.
Claims 2, 5–9, 15, 16, 18, 20: These claims narrow the abstract idea by specifying the content of the data or the administrative output.
Claim 2: Reciting that data is "collected via a medical device" is a mere linking of the exception to a particular environment (h). It identifies a specific data source but does not provide a technical solution or a technological application of the data.
Claim 8: The "diagnostic specific algorithm" identifies a specific computational process for the Mental Process of data transformation. Per MPEP 2106.05(a), this provides an improvement to the abstract idea (the accuracy or specificity of the result) rather than an improvement to computer functionality or a technical field.
Claims 15 and 16: The "instrumentation asset" configurations represent logical relationships between data and hardware. Reciting a configuration "specific for a device used to capture" (Claim 15) or making the asset "device technology agnostic" (Claim 16) are architectural choices for data formatting. Under BRI, these are functional descriptions of data structure and do not provide a technological transformation beyond the abstract organizational activity.
Claims 3, 4, 10–14, 17, 19: These claims recite limitations that remain directed to the Judicial Exceptions of Mental Processes and Methods of Organizing Human Activity. These elements specify "standardized roles" (Claim 10) and "layers" of data (Claim 4), which define administrative rules and logical organizational models. Because these limitations do not alter the technological operation of the computer or provide an improvement to a technical field, they fail to integrate the exception under MPEP 2106.05(a).
When viewed as a whole, the combination of these elements in the dependent and independent claims does not integrate the abstract idea because they only refine the administrative scope and organizational framework of the collaborative environment.
Because the claims are directed to an abstract idea without integrating it into a practical application, the analysis proceeds to Step 2B.
Step 2B: Inventive Concept Analysis
Step 2B evaluates whether the additional elements, considered individually and as an ordered combination, amount to significantly more than the judicial exception by reciting an inventive concept.
Evaluation of Independent Claim 1 Additional Elements
Processor and Storage (Digital Environment/Central Data Structure):
The generic hardware elements fail to provide an inventive concept as they merely automate the administrative "decision-making" process through standard architectural functions of a "computing device" (Spec. 0134). These additional limitations provide no technological transformation because the claimed automation of documenting and leveraging records is an improvement to the administrative workflow rather than the computer's underlying functionality, mirroring a high-level sequence of operations that adds no "significantly more" than the abstract idea itself (MPEP 2106.05(a), (f)). Refer to spec, 0134-0136
When viewed as a whole, the combination of these elements is not enough to provide an inventive concept because it represents the generic application of a generic computer to automate the abstract organizational and mental processes of regulatory documentation. Automating the steps of gathering, selecting, and documenting through a database follows a routine and generic sequence of operations that adds no inventive concept to the abstract idea.
Dependent Claims Analysis
(Claims 2, 8, 15, 16): These claims add specific data sources and algorithmic configurations, such as a "medical device" or "diagnostic specific algorithm," which are insignificant pre/post-solution activities (MPEP § 2106.05(g)). The specification confirms these are generic steps for gathering or refining data: "The GENEActiv Original watch captures the raw data... the algorithm... interprets device data" (Spec., para. 0158).
Group 2 (Claims 3, 4, 10–14, 17, 19, 20): These claims add administrative rules, such as "standardized roles" and "generating a dossier," which are Mere Instructions (MPEP § 2106.05(f)) that narrow the abstract idea to specific organizational parameters. The specification confirms this is a standard administrative framework step (Spec., para. 0009).
When viewed as a whole, the combination of dependent claims and additional elements is not enough to provide an inventive concept because they merely narrow the administrative scope of the abstract idea using well-understood computer techniques.
The claims are directed to an abstract idea and lack an inventive concept as they merely automate the organization of human activity using generic computer components. Therefore, Claims 1–20 are rejected under 35 U.S.C. § 101.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Arazy US20130198094A1
Claim 1.
Arazy teaches, A method of digitally facilitating regulatory decision-making of at
least a component of a standardized digital solution for characterizing a disease, the method
comprising: (Arazy, abstract, par. 0006,0013)
Arazy describes an online system (digitally facilitating) used to achieve regulatory compliance (regulatory decision-making) for medical devices and pharmaceuticals.
providing a digital environment comprising a plurality of components of standardized
digital solutions, wherein the digital environment is accessible by a plurality of collaborators; (Arazy, par. 0081, 0125)
Arazy discloses a platform (digital environment) that hosts various regulatory documents (components) and provides access to a wide range of stakeholders (collaborators) such as manufacturers and government agencies.
obtaining, at a processor, a central data structure, wherein the central data structure comprises compiled evidence of a plurality of components of one or more previously-approved standardized digital solutions; (Arazy, par. 0007, 0009, 0082)
Arazy maintains central databases that store regulatory documents and master files (compiled evidence) for products (standardized digital solutions) that have previously been processed or licensed.
receiving, at the processor, a request for a new standardized digital solution; (Arazy, par. 0088-0087)
Arazy describes a process where a client initiates a request by selecting a device type and the country where they seek registration.
generating, at the processor, the new standardized digital solution by leveraging one or
more components of the plurality of components of the one or more previously-approved
standardized digital solutions in the central data structure; (Arazy, par. 0092, 0082-0083, 0199, 0217)
The process of an "application generator" (Arazy, Para 0083) using "autofill" to pull "reoccurring fields" (Arazy, Para 0092) is a direct functional match for "leveraging components" to "generate" a new solution.
Arazy describe that the system specifically preserves the "application content... at the time approval was granted" (Arazy, Para 0217). This provides an explicit match for the "previously-approved" requirement. Furthermore, Arazy’s "Modules" (Para 0199) represent the structural components of the solution. The act of leveraging these verified modules from the central database to create a new application anticipates the claim.
receiving, at the processor, additional data for the new standardized digital solution from
a collaborator of the plurality of collaborators; (Arazy, par. 0081, 0090, 0125)
Arazy discloses that the "Client" (a collaborator) "uploads documents and information" (additional data) into the platform.
updating, at the processor, the central data structure to incorporate the additional data;(Arazy, par. 0082, 0090-0091, 0120, 0135)
Arazy discloses a "master regulatory file" (central data structure) that is "updated". When a collaborator uploads new documents, the system validates them and maintains them within this file under "version control". Furthermore, Arazy explicitly identifies "ongoing maintenance" that involves "updating device changes" (incorporating additional data) into the existing forms.
receiving, at the processor, feedback from a regulatory collaborator, wherein the received
feedback comprises a regulatory acceptance of at least a component of the new standardized
digital solution; (Arazy, par. 0095, 0140, 0143, 0146, 0229)
Arazy discloses a system where "regulatory agencies" (regulatory collaborators) interact with the application file to provide a "license" or "approval" (regulatory acceptance).
and
digitally documenting the received feedback from the regulatory collaborator. (Arazy, par. 0135, 0140, 0161)
Under the Broadest Reasonable Interpretation (MPEP 2111), "digitally documenting" is met by Arazy's disclosure of "maintaining records" and "archiving" review data within a "master file" database.
Claim 2.
Arazy teaches, The method of claim 1, wherein the one or more previously approved standardized digital solutions include measurement data collected via a medical device.(Arazy, 0006, 0013, 0070, 0087)
Arazy’s focus on the "Verification and Validation" of "medical devices" and the storage of those results in a "master file" database captures the entirety of the claimed limitation.
Claim 3.
Arazy teaches, The method of claim 1, wherein the processor is further
configured to generate a plurality of new standardized digital solutions for different patient
populations.(Arazy, par. 0071, 0073, 0191- 0097, 0192, 0203)
Under the Broadest Reasonable Interpretation (MPEP 2111), the ability to "repeat steps" to generate applications for "additional markets" encompasses the creation of solutions for different "patient populations."
Claim 4.
Arazy teaches, The method of claim 1, wherein the components of the one or
more previously-approved standardized digital solutions are included in one or more of a
validation layer, an instrumentation layer, or a definition layer of the central data structure. (Arazy, par.0177-0178, 0191, 0199 )
The prior art describes a data architecture composed of "thirteen basic blocks" (Para [0177]) used to manage the "Master Regulatory File." Under MPEP 2111, the term "layer" is interpreted broadly to include functional groupings of data objects. Arazy’s device and risk blocks categorize the identity of the solution (Definition Layer), its biocompatibility and safety modules categorize the technical performance (Instrumentation Layer), and its compliance forms categorize the evidence for approval (Validation Layer).
Claim 5.
Arazy teaches, The method of claim 1, wherein generating the new standardized
digital solution comprises analyzing evidence data of the one or more previously- approved
digital solutions and generating the new standardized digital solution based on at least an
acceptability categorization of the evidence data. (Arazy, par. 0091, 0098, 0138, 0203)
Under MPEP 2111, an "acceptability categorization" is broadly interpreted to include "quality ratings" or "integrity validations" used to filter data. Arazy's system assesses these ratings to determine the "maturity of the client's product information" and automatically generates the appropriate next steps for a new filing. (Arazy, Para [0121]). By utilizing these "document quality ratings" to guide the creation of new applications, Arazy performs the exact functional step recited in the claim.
Claim 6.
Arazy teaches, The method of claim 5, wherein the acceptability categorization is
determined according to one or more of:
a freshness of the evidence data, a quantity of the evidence data, a patient population of the evidence data, regulatory acceptance of the evidence data, clinical validation of the evidence data, or technical verification of the evidence data, a content validity of the evidence data, a construct validity of the evidence data, a sensitivity to change of the evidence data, or a
combination thereof. (Arazy, Para 0015, 0070, 0138).
Arazy utilizes an intelligent system to assign quality ratings to documents after they have undergone Verification and Validation to ensure they meet the requirements of each FDA. Furthermore, the system ensures continuously updated information (freshness) is used to maintain the master file. By rating the data based on its update status and its performance results, Arazy performs the exact functional determination required by the claim.
Claim 7.
Arazy teaches, The method of claim 1, wherein generating new standardized
digital solution is based on a medical condition or a diagnosis method. (Arazy, Para 0069, 0087)
Arazy’s system triggers the Application Preparation Process based on the user's selection of a medical device or an IVD (diagnostic) device. Because the resulting digital record is tailored to the specific module (e.g., angioplasty) or risk class associated with that medical condition, Arazy performs the exact functional generation recited in the claim.
Claim 8.
Arazy teaches, The method of claim 1, wherein the new standardized digital
solution includes a diagnostic specific algorithm. (Arazy, Para 0069, 0180, 0199).
Under the Broadest Reasonable Interpretation (MPEP 2111), "including an algorithm" encompasses the storage of Software validation data within the product’s digital record. Arazy’s system manages these software modules for IVD (diagnostic) and laser (therapeutic) devices, ensuring the logic used to perform the medical function is part of the central data structure. Since the diagnostic utility of an IVD device is driven by its internal calculations, Arazy’s documentation of the software validation for these devices anticipates the inclusion of a diagnostic specific algorithm.
Claim 9.
Arazy teaches, The method of claim 1, wherein the component of the new
standardized digital solution comprises any of:
a measurable concept of interest component;
a measurement method component;
a raw data component;
an algorithm component;
a dataset component;
a technical validation component;
an analytical validation component;
a clinical validation component; or
a regulatory component.
(Arazy, par. 0009, 0070, 0080, 0177, 0181, 0199)
Arazy’s system is structured around Thirteen basic blocks and multiple Modules that specifically include Software validation (algorithm component), clinical evidence (clinical validation), and regulatory compliance documents (regulatory component). Arazy also utilizes Verification and Validation testing to generate the test reports that function as the technical validation and datasets for the device.
Claim 10.
Arazy teaches, The method of claim 1, further comprising:
prior to receiving the request, generating a mission within a digital environment by
establishing standardized roles for two or more collaborators of the plurality of collaborators,
wherein each of the two or more collaborators is a discrete stakeholder in the mission. (Arazy, par. 0081, 0086, 0125, 0160, 0176, 0234; Figure 1)
Arazy describes a system where the "mission" (the regulatory process) is a pre-existing structural framework into which stakeholders are "integrated." In Arazy, the act of "generating the mission" environment is accomplished by the initial setup of standardized roles (Administrators, Experts, Clients) and the creation of an assignment matrix. Because the expert assignment matrix must exist as a functional prerequisite before a client can ever initiate a request for an application the temporal requirement of "prior to receiving the request" is satisfied. Arazy’s architecture ensures that the roles for the discrete stakeholders (manufacturer, expert, agency) are defined at the foundational level, thus anticipating the claim.
Claim 11.
Arazy teaches, The method of claim 10, wherein establishing roles for the two or
more collaborators comprises assigning a primary role to a first of the two or more collaborators and assigning a secondary role to the second of the two or more collaborators, and wherein the primary role possesses additional rights in comparison to the secondary role, wherein the rights comprise rights to access, view, and/or use results developed from the mission. (Arazy, par. 0125, 0234, 0244)
Under the Broadest Reasonable Interpretation (MPEP 2111), primary and secondary roles are met by the hierarchical relationship between a legal owner and a subject user. Arazy identifies the Client/Manufacturer as the legal owner who holds the ultimate authority to set permission levels for every document, folder, and product. In this mission environment, the primary role (the Client) possesses additional rights because it controls the access and viewing capabilities of the secondary roles (the Experts). By distinguishing between the actor who determines the permissions and the actor who is subject to them, Arazy teaches the exact role-based hierarchy and rights distribution required by the claim.
Claim 12.
Arazy teaches, The method of claim 10, wherein a collaborator of the
two or more collaborators is assigned to any one of the following roles: a funder, observer,
technology provider, or data partner. (Arazy, par. Abstract, 0081, 0083, 0101, 0176, 0192)
Arazy explicitly identifies the Device Manufacturer (Technology Provider) and the Regulatory Agency (Observer) as key participants in the digital environment. Furthermore, the Client who pays the license fees serves the functional role of a Funder, and the stakeholders who upload laboratory results are the Data Partners
Claim 13.
Arazy teaches, The method of claim 10, further
comprising:
prior to receiving input from one or more of the two or more collaborators to define at least the component of the standardized digital solution, receiving agreement from each of the two or more collaborators on one or more criteria of the mission. wherein the one or more criteria of the mission comprise terms and conditions of an agreement. (Arazy, par. 0099-0114, 0127, 0129, 0168, 0170, 0216)
Under the Broadest Reasonable Interpretation (MPEP 2111), receiving agreement is functionally met by the combination of a client selecting a service profile and an expert accepting a job offer under pre-set income sharing terms. Arazy describes a system where the rules of the mission specifically the Review level and Number of people to review are chosen by the client before the work commences.
These selections, paired with the standardized Income sharing rates, constitute the terms and conditions of an agreement. Because Arazy’s CRM platform manages these stakeholder relationships and requires the service scope to be defined before an expert can provide the professional review (technical input), the reference teaches the temporal and functional requirements of the claim.
Claim 14.
Arazy teaches, The method of claim 13, further comprising:
prior to receiving agreement from each of the two or more collaborators, generating a
pre-defined template identifying the one or more criteria of the mission; (Arazy, par. 0093, 0120, 0193, 0213, 0215)
Arazy discloses pre-defined templates sample forms, boilerplate text, and blank documents that define the mission by selecting forms based on client risk and country. Clients choose these templates, experts review them, and this selection occurs before the agreement is finalized.
and providing the predefined template to each of the two or more collaborators. (Arazy, 0081, 0161, 0244)
Arazy satisfies the “providing” requirement by digitally making the same predefined application document accessible to both collaborators within a shared mission environment.
Claim 15.
Arazy teaches, The method of claim 1, wherein the new
standardized digital solution is a digital measurement solution and wherein the digital
measurement solution comprises:
a measurement definition defining one or more concepts of interest relevant to a disease; (Arazy, par. 0177, 0181, 0184, 0199)
Arazy discloses that each regulatory file includes a measurement definition via the GMDN block and clinical evidence module, which specify the device’s medical purpose and measurable unit such as analytes measured by a centrifuge thereby satisfying the measurement definition requirement.
an instrumentation asset configured to transform a measurement of interest captured
according to the measurement definition to a dataset that is informative for characterizing the
disease, wherein the instrumentation asset of the digital measurement solution is specific for a
device used to capture the measurement of interest. (Arazy, par. 0082, 0185, 0191, 0199)
Arazy discloses an instrumentation asset through device-specific Software Validation and Technical modules stored in a master regulatory file for a single product. These modules, organized by device name, validate how the device converts test measurements into FDA-required performance reports, thereby satisfying the claimed limitation.
Claim 16.
Arazy teaches, The method of claim 1, wherein the new
standardized digital solution is a target solution profile representing a common class of digital
measurement solutions; (Arazy, par. 0075, 0178, 0247)
Arazy teaches a target solution profile representing a common class through its disclosure of modules representing a class of device. Arazy’s system utilizes these modules to create a unique category for similar devices, allowing the system to infer the regulatory and technical requirements for any product within that common class. This functional "category" acts as the template for all subsequent devices of that type, matching the claimed TSP.
and
wherein the target solution profile comprises:
a measurement definition defining one or more concepts of interest relevant to a disease; (Arazy, par. 0177, 0181, 0184)
Arazy teaches a measurement definition through the use of the GMDN block, which serves as a universal classification system. In Arazy’s system, the GMDN block defines what the device is and its clinical utility, such as measuring analytes in patient samples. By identifying the clinical metric (analytes) relevant to the health condition, Arazy’s system provides the measurement definition defining a concept of interest within the device class profile.
an instrumentation asset configured to transform data captured according to the measurement definition to a dataset, the instrumentation asset being device technology agnostic and is thereby interchangeable across different target solution profiles. (Arazy, par. 0080, 0178, 0199, 0247)
Arazy teaches an instrumentation asset through its generic master regulatory files and technical Modules (e.g., electrical safety, sterility, software validation). These assets are device technology agnostic because they are defined at the module level representing a class of device rather than a single specific hardware model. Arazy explicitly describes how these requirements are inferred and applied to later similar devices within a category. Because Arazy allows these modular technical requirements to be interchanged and applied across any new device entering that unique category, it fulfills the requirement of an interchangeable, technology-agnostic instrumentation asset.
Claim 17.
Arazy teaches, The method of claim 1, wherein the digital environment is a
collaborative platform built upon a measurement stack model. (Arazy, par. 0081, 0177, 0199)
Under the Broadest Reasonable Interpretation (MPEP 2111), the measurement stack model is functionally identical to Arazy’s Thirteen basic blocks and Modules that are logically connected to form a product record. Arazy’s system is a collaborative platform because it provides a centralized environment for users, experts, and auditors to interact with these data blocks. Because Arazy’s architecture relies on this tiered organization of technical and clinical "Modules" to facilitate collaborative regulatory work, it fulfills the structural requirements of the claim.
Claim 18.
Arazy teaches, The method of claim 1, wherein the received input comprises one
or more of the following types of information: technical feasibility information, patient
perspective information, and clinical information. (Arazy, Paras 0070, 0145, 0151, 0199).
Under the Broadest Reasonable Interpretation (MPEP 2111), "receiving input" includes the "upload" or "exchange" of any document required for regulatory compliance. Arazy explicitly lists clinical evidence (Clinical Information) as a primary module of the regulatory file. Furthermore, the Verification and Validation data (Technical Feasibility) and post-marketing feedback (Patient Perspective) are integral parts of the dossier managed by the Arazy system. Since Arazy is designed to ingest and validate all these specific categories of medical and technical data to meet FDA requirements, it fulfills every element of the claim.
Claim 19.
Arazy teaches, The method of claim 10, wherein the method further comprises:
generating an agreement based on one or more of:
the common interest, the regulator collaborator, the regulatory decision, and the established roles of the two or more collaborators, wherein the agreement comprises terms comprising one or more of mission rules and collaborator rights; (Arazy, 0129, 0168, 0216, 0234)
Arazy teaches the generation of an agreement through its CRM (Customer Relationship Management) platform, which manages the relationship and service profile between the client and the expert. This agreement is based on the established roles because the system generates specific actions and income sharing terms derived from whether the collaborator is an Expert or a Client. Because the CRM system creates these professional associations to facilitate a specific regulatory application.
providing, via the digital environment, each of the two or more collaborators with the agreement; (Arazy, par. 0106, 0125, 0129)
Arazy’s agreement contains collaborator rights through the disclosure of permission levels and legal ownership rights determined by the manufacturer. It also contains mission rules by defining the Review level (e.g., integrity vs. professional review) and the income sharing terms that govern the expert's participation.
and
providing, via the digital environment, a framework for one or more collaborators to edit
the terms. (Arazy, Para 0135, 0161).
Arazy teaches providing the agreement and a framework to edit the terms through the Client Portal and the version and document control system. The portal allows the expert and client to communicate and comment upon the mission requirements (the terms), while the version control provides the structural framework to track and incorporate those edits. Because this collaborative interface is used to finalize the "final version" of the document/agreement before it enters the master file, Arazy anticipates the provision of an editing framework.
Claim 20.
Arazy teaches, The method of claim 1, further
comprising: generating a dossier for seeking regulatory decision-making, the dossier being related to at least a component of the new standardized digital solution. (Arazy, 0082, 0092, 0094, 0199, 0217)
Under the Broadest Reasonable Interpretation (MPEP 2111), the dossier is functionally met by Arazy’s master regulatory file and regulatory application. Arazy’s system is configured to prepare these files by aggregating all product/client/country information required for a license application. This dossier incorporates the various technical and clinical Modules (components) that describe the device’s performance and safety.
Conclusion
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