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 .
DETAILED ACTION
In the response filed on 02 March 2026, the following has occurred: claim 1 has been amended; claims 6 and 7 have been canceled.
Now claims 1-2, 5, 8 and 11 are pending.
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-2, 5, 8 and 11 are rejected under 35 U.S.C. 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.
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites a system for sharing documents between organizations. The limitations of:
sharing document information between electronic health records of a plurality of organizations between which configurations of document categories, description items in the document categories, and formats of the description items do not necessarily match each other, wherein the plurality of organizations [… provide …] the electronic health records in a plurality of documents […] of a transmission-side electronic health records, […] define a versatile transmission/reception format that does not use document categories and that holds a plurality of unique description items and value pairs; […] extract content of the description items in the document categories of the transmission-side electronic health records based on a transmission-side map that defines the description items in the document categories of the transmission-side electronic health records to be entered into description items of the transmission/reception format, [… organize …] the extracted content into a format defined for the corresponding description items in the transmission/reception format, simultaneously enter, into each of the description items, the [… organized …] content and a date/time record indicating when a document containing the description item was created, and [… provide …] the transmission/reception format, the transmission-side map indicates a list of correspondence between (i) pairs of document categories of the transmission-side electronic health records and description items in the document categories, and (ii) description items in the transmission/reception format; on reception-side electronic health records, [… obtain …] the transmission/reception format, create a dated document in a specified reception-side document category based on a reception-side map, extract content of the description items in the transmission/reception format based on the reception-side map that defines description items in the transmission/reception format to be [… organized …] into description items in document categories of the reception-side electronic health records, [… organize …] the extracted content into a format defined for the corresponding description items in the reception-side electronic health records, and [… save …] the [… organized …] content in the corresponding description items in document categories in the created dated document of the reception-side electronic health records, and the reception-side map indicates a correspondence between (i) description items in the transmission/reception format, and (ii) pairs of document categories of the reception-side electronic health records and description items in the document categories.
, as drafted, is a system which under its broadest reasonable interpretation, covers a method of organizing human activity (i.e., managing personal behavior including following rules or instructions) but for recitation of generic computer components. That is, other than reciting a server and various processors, the claimed invention amounts to managing personal behavior or interaction between people, the Examiner notes as stated in 2106.04(a)(2), “certain activity between a person and a computer… may fall within the “certain methods of organizing human activity” grouping”. For example, but for a server and various processors, the claim encompasses allowing a user to define a format and share a document with another user in the defined format, to organize information between the various users in their care of their patients. If a claim limitation, under its broadest reasonable interpretation, covers managing personal behavior or interactions between people but for the recitation of generic computer components, then it falls within the “Certain method of organizing human activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claim recites the additional elements of a server and various processors, which implements the abstract idea. The server and various processors are recited at a high-level of generality (i.e., a general-purpose computers/ computer components implementing generic computer functions; see Applicant’s Specification Figure 1, paragraph [0033]) such that it amounts no more than mere instructions to apply the exception using generic computer components. Accordingly, these additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim recites the additional elements of “transmit… receive…”, “record the information” and “convert…”. The “transmit… receive…” steps are recited at a high-level of generality (i.e., as a general means of receiving/transmitting data) and amounts to the mere transmission and/or receipt of data, which is a form of extra-solution activity. The “record the information” is recited at a high-level of generality (i.e., as a general means of storing data) and amounts to the mere storage of data, which is a form of extra-solution activity. The “convert…” steps are recited at a high-level of generality (i.e., mapping data to a structure) and amounts to merely linking of the abstract idea to particular technological environment. Accordingly, these additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a server and various processors, to perform the noted steps amounts to no more than mere instructions to apply the exception using generic hardware components. Mere instructions to apply an exception using generic hardware components cannot provide an inventive concept ("significantly more").
Also, as discussed above with respect to integration of the abstract idea into a practical application, the additional elements of “transmit… receive…”, “record the information” and “convert…” were considered extra-solution activity and/or generally linking to a particular technological environment. The “transmit… receive…” steps have been re-evaluated under the "significantly more" analysis and determined to amount to be well-understood, routine, and conventional elements/functions. As described in MPEP 2106.0S(d)(II)(i) "Receiving or transmitting data over a network" is well-understood, routine, and conventional. The “record the information” has been re-evaluated under the “significantly more” analysis and determined to amount to be well-understood, routine, and conventional elements/functions. As described in MPEP 2106.05(d)(II)(iv) “Storing and retrieving information in memory” is well-understood, routine, and conventional. The “convert…” steps have been re-evaluated under the “significantly more” analysis and determined to amount to be well-understood, routine, and conventional elements/functions. As described in Chen (2013/0304510): see below but at least paragraph [0006]; Jain (20180089159): see below but at least paragraph [0106]; formatting of data is well-understood, routine and conventional. Well-understood, routine, and conventional elements/functions cannot provide "significantly more." As such the claim is not patent eligible.
Claims 2, 5, 8 and 11 are similarly rejected because either further define the abstract idea and/or do not further limit the claim to a practical application or provide as inventive concept such that the claims are subject matter eligible.
Claim 2 further describe using a list of tags, however does not recite any additional elements sufficient for practical application and/or significantly more.
Claims 5 describe various entry of information, however does not recite any additional elements sufficient for practical application and/or significantly more.
Claim 8 recites allowing a human user to define the format via interaction with generic computer components, however does not recite any additional elements sufficient for practical application and/or significantly more.
Claim 11 recites the additional element of a relay server, however these are recited at a high-level of generality (i.e., a general-purpose computers/ computer components implementing generic computer functions; see Applicant’s Specification Figure 1, paragraph [0033]) such that it amounts no more than mere instructions to apply the exception using generic computer components. Accordingly, these additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of a relay server, to perform the noted steps amounts to no more than mere instructions to apply the exception using generic hardware components. Mere instructions to apply an exception using generic hardware components cannot provide an inventive concept ("significantly more").
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-2, 5, 8 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Pub. No. 2013/0304510 (hereafter “Chen”), in view of U.S. Patent Pub. No. 2018/0089159 (hereafter “Jain”), in view of U.S. Patent Pub. No. 2019/0348159 (hereafter “Selvaggi”).
Regarding (Currently Amended) claim 1, Chen teaches an inter-organization document information sharing system for sharing document information between electronic health records of a plurality of organizations between which configurations of document categories, description items in the document categories, and formats of the description items do not necessarily match each other (Chen: paragraphs [0002]-[0003], “electronic health records… electronically storing and exchanging patient health files and medical data… the diversity and type of medical source data (e.g. X-rays, MRIs, lab results, photographs, videos, technician notes, etc.)… utilize different types of software and supported file formats”, paragraph [0005], “A Health information Exchange (HIE) system and related methods for sharing patient medical data among a plurality of users”, paragraph [0037], “HIE system 100 seeks to meet the long felt, but unmet need for an integrated web-based health platform that allows for the storage and exchange of patient records in virtually any format”),
wherein the plurality of organizations send the electronic health records in a plurality of documents to a server of a transmission-side electronic health records (Chen: Figure 4, paragraph [0005], “A Health information Exchange (HIE) system and related methods for sharing patient medical data among a plurality of users”, paragraph [0034], “the HIE API 112 includes communication protocols configured to allow a plurality of different user (source) software programs such as outside applications 118 to communicate with and use the software modules or services of the HIE system 100 to store, organize, and retrieve/exchange patient medical records”),
a processor on the server is configured to define a versatile transmission/reception format […] and that holds a plurality of unique description items […] (Chen: Figures 3-4, paragraphs [0029]-[0030], “the form of Medical Objects (MOBs), which are generic deconstructed non-descript data records not characterized by any particular known file type or format… MOBs may be considered as data containers which hold attributes, properties, and the actual medical data (Mobbits) extracted by deconstructing a source medical data file of a known type… MOBs are in turn defined by extensible data schemas called Medical Object Definitions (MODs). Medical data can be converted or manipulated into different electronic file formats using Moxy Exchange Definitions (MXDs)… Each object belonging to a class will generally have the same fields ("attributes") and the same methods; the methods being the procedures, functions, or routines used then to manipulate the object.”, paragraph [0041], “The Moxy Exchange Database 110 stores a plurality of tile conversion algorithms each configured to convert various user source file types into a Medical Object (MOB) for storage in the MOB Store Database 108… It is well within the ambit of those skilled in the art to write the file conversion algorithms needs for specific file type conversions without undue experimentation”, paragraphs [0044]-[0048], “the attributes of MOB which are extracted from the source medical data file may include creation date, creator, creating domain, MOBID, external IDs, size version, and others”, paragraphs [0052]-[0053], “HIE System Data Exchange Services 111 ("Moxy Exchange") establishes a framework allowing for the conversion and export of documents for different formats or content to communicate with one another”, paragraph [0059], “MXDs tell Moxy how to convert data from one format to another… A user-defined file format and implementation”, paragraphs [0076]-[0077], “The destination file type may be selected by the user in a GUI such as via drop down box listing all available download file types supported by HIE system 100, direct input, or other method for selecting the file type”. Also see, paragraph [0037]. The Examiner notes the medical object (MOB) is a versatile transmission/reception format that holds a plurality of unique description items (attribute and property fields), which teaches what is required of the claim under the broadest reasonable interpretation);
the processor is configured to extract content of the description items in the document categories of the transmission-side electronic health records based on a transmission-side [… definition …] that defines the description items in the document categories of the transmission-side electronic health records to be entered into description items of the transmission/reception format, convert the extracted content into a format defined for the corresponding description items in the transmission/reception format, simultaneously enter, into each of the description items, the converted content and a date/time record indicating when a document containing the description item was created, and transmit the transmission/reception format(Chen: Figure 3, paragraphs [0005]-[0006], “converting data uploaded to the HIE system by a first user regardless of the source file format or type into a destination format… converts and stores the medical data in a generic data record such as an object… the system retrieves and converts the Medical Object (MOB) containing the medical data into the specified destination file format, and sends the destination file to the second user… The source and destination file formats may be the same or different”, paragraph [0008], “converting the first medical data file into the medical object using the conversion algorithm to deconstruct the first file format and extract file information from the first medical data file, the extracted information then being reorganized into the medical object having a format different than the first file format; and the processor storing the medical object in a database”, paragraphs [0029]-[0030], “MOBs are in turn defined by extensible data schemas called Medical Object Definitions (MODs). Medical data can be converted or manipulated into different electronic file formats using Moxy Exchange Definitions (MXDs), which are also extensible”, paragraph [0041], “a plurality of tile conversion algorithms each configured to convert various user source file types into a Medical Object (MOB) for storage in the MOB Store Database 108 (reference FIG. 1), and in some embodiments to further convert the MOB into a known destination file type requested by a user looking to retrieve patient medical data in a form compatible with his or her system supported medical file types”, paragraph [0044], “the attributes of MOB which are extracted from the source medical data file may include creation date, creator, creating domain, MOBID, external IDs, size version, and others”, paragraph [0049], “MOB properties may also include additional useful search data including procedure code for the chest X-ray series, diagnostic code for indication, number of images taken, whether radiologist found any abnormality, and others”, paragraph [0072], “The downloaded medical data source file is then received by HIE Core Server 102 (step 310)… The HIE Core Server 102 executes a conversion routine or application using the supplied conversion algorithm to convert the medical data source file type into a MOB (step 325)… Finally, the HIE Core Server 102 transmits and stores the MOB in the MOB Store Database 108 (step 330) which holds a plurality of MOBs”, paragraph [0082], “the HIE system 100 may process a plurality of user medical data download requests simultaneously… the HIE system 100 may process a plurality of medical data upload submissions simultaneously”. The Examiner notes a transmission side definition is used to convert the medical data into an object (i.e., transmission/reception format), and provides the object for storage),
the transmission-side [… definition …] indicates a list of correspondence between (i) pairs of document categories of the transmission-side electronic health records and description items in the document categories, and (ii) description items in the transmission/reception format (Chen: Figure 3, paragraphs [0052]-[0060], “a framework allowing for the conversion and export of documents for different formats or content to communicate with one another… includes file conversion algorithms operable to implement the file conversions for storage and retrieval of medical data… Moxy File Exchange Definitions (MXDs): methods for converting data from one format to another… MXDs tell Moxy how to convert data from one format to another, whether MOB, data file, or display format… The file-to-object conversion algorithms deconstruct/disassemble the source file format and extract pertinent file information/data embedded in the source file (i.e. component parts) including file properties, attributes, and actual medical data (e.g. X-ray, lab results, etc.). This conversion algorithms further reorganizes and saves this information/data into the structure of the MOB shown in FIG. 3”, paragraphs [0074]-[0076], “list all associated MOBs stored in the HIE system… listing all available download file types supported by HIE system 100”. Also see, paragraphs [0048]-[0049]);
on reception-side electronic health records, another processor is configured to receive the transmission/reception format, create a dated document in a specified reception-side document category based on a reception-side [… definition …], extract content of the description items in the transmission/reception format based on the reception-side [… definition …] that defines description items in the transmission/reception format to be recorded into description items in document categories of the reception-side electronic health records, convert the extracted content into a format defined for the corresponding description items in the reception-side electronic health records, and record the converted content description items in the corresponding description document categories in the created dated document of the reception-side electronic health records (Chen: Figures 1, 4-5, paragraph [0009], “processor converting the source file into the medical object using a file-to-object conversion algorithm… the processor converting the medical object into a destination file using an object-to-file conversion algorithm, the destination file containing the requested medical data form the medical object in a second file format”, paragraphs [0029]-[0030], “MOBs are in turn defined by extensible data schemas called Medical Object Definitions (MODs). Medical data can be converted or manipulated into different electronic file formats using Moxy Exchange Definitions (MXDs), which are also extensible”, paragraph [0034], “the HIE API 112 includes communication protocols configured to allow a plurality of different user (source) software programs such as outside applications 118 to communicate with and use the software modules or services of the HIE system 100 to store, organize, and retrieve/exchange patient medical records”, paragraph [0041], “a plurality of tile conversion algorithms each configured to convert various user source file types into a Medical Object (MOB) for storage in the MOB Store Database 108 (reference FIG. 1), and in some embodiments to further convert the MOB into a known destination file type requested by a user looking to retrieve patient medical data in a form compatible with his or her system supported medical file types”, paragraph [0044], “the attributes of MOB which are extracted from the source medical data file may include creation date, creator, creating domain, MOBID, external IDs, size version, and others”, paragraph [0060], “object-to-file algorithms to reconstruct/reassemble MOBs back into a destination file type during a medical file upload process to a user or requestor of patient medical data”, paragraph [0081], “the HIE Core 101 runs a conversion routine or application using the supplied conversion algorithm to convert the requested medical data from a MOB into the specific destination file type requested by the user. Finally, the HIE Core 101 sends the fully converted destination medical file back to the user terminal 120 via the AP I 112”. Also see, paragraphs [0048]-[0049], [0052]. The Examiner notes the date the document was originally created is an attribute that is converted and provided on a reception side in a transmission/reception format, which teaches what is required of the claim under the broadest reasonable interpretation), and
the reception-side [… definition …] indicates a correspondence between (i) the description items in the transmission/reception format, and (ii) pairs of document categories of the reception-side electronic health records and description items in the document categories (Chen: Figure 3, paragraphs [0052]-[0060], “a framework allowing for the conversion and export of documents for different formats or content to communicate with one another… includes file conversion algorithms operable to implement the file conversions for storage and retrieval of medical data… Moxy File Exchange Definitions (MXDs): methods for converting data from one format to another… MXDs tell Moxy how to convert data from one format to another, whether MOB, data file, or display format… object-to-file algorithms to reconstruct/reassemble MOBs back into a destination file type during a medical file upload process to a user or requestor of patient medical data”. Also see, paragraphs [0048]-[0049]).
Chen may not explicitly teach (underlined below for clarity):
the processor is configured to extract content of the description items in the document categories of the transmission-side electronic health records based on a transmission-side map that defines the description items in the document categories of the transmission-side electronic health records to be entered into description items of the transmission/reception format, convert the extracted content into a format defined for the corresponding description items in the transmission/reception format, simultaneously enter, into each of the description items, the converted content and a date/time record indicating when a document containing the description item was created, and transmit the transmission/reception format, the transmission-side map indicates a list of correspondences between (i) pairs of document categories of the transmission-side electronic health records and description items in the document categories, and (ii) description items in the transmission/reception format; on reception-side electronic health records, another processor is configured to receive the transmission/reception format, create a dated document in a specified reception-side document category based on a reception-side map, extract content of the description items in the transmission/reception format based on the reception-side map that defines description items in the transmission/reception format to be recorded into description items in document categories in the created dated document of the reception-side electronic health records, convert the extracted content into a format defined for the corresponding description items in the reception-side electronic health records, and record the converted content in the corresponding description items in document categories of the reception-side electronic health records, and the reception-side map indicates a correspondence between (i) description items in the transmission/reception format, and (ii) pairs of document categories of the reception-side electronic health records and description items in the document categories.
Jain teaches the processor is configured to extract content of the description items in the document categories of the transmission-side electronic health records based on a transmission-side map that defines the description items in the document categories of the transmission-side electronic health records to be entered into description items of the transmission/reception format, convert the extracted content into a format defined for the corresponding description items in the transmission/reception format, simultaneously enter, into each of the description items, the converted content and a date/time record indicating when a document containing the description item was created, and transmit the transmission/reception format, the transmission-side map indicates a list of correspondences between (i) pairs of document categories of the transmission-side electronic health records and description items in the document categories, and (ii) description items in the transmission/reception format; on reception-side electronic health records, another processor is configured to receive the transmission/reception format, create a dated document in a specified reception-side document category based on a reception-side map, extract content of the description items in the transmission/reception format based on the reception-side map that defines description items in the transmission/reception format to be recorded into description items in document categories in the created dated document of the reception-side electronic health records, convert the extracted content into a format defined for the corresponding description items in the reception-side electronic health records, and record the converted content in the corresponding description items in document categories of the reception-side electronic health records, and the reception-side map indicates a correspondence between (i) description items in the transmission/reception format, and (ii) pairs of document categories of the reception-side electronic health records and description items in the document categories (Jain: Figures 1-4, 7, paragraphs [0006]-[0008], “form definition specifies characteristics of the electronic form such as display properties, interactive elements to be included, and/or rules that vary content of the electronic form for different users or user types. The form definition can also specify different data types to be collected on the user form… an administrator can create and update a form definition for an electronic form that is provided to the user through the application. The administrator can design the electronic form using a configuration interface that allows for customization of the electronic form by specifying data types to collect using the electronic form and/or layout parameters for displaying the electronic form on the application… rules specified within the form definition can be used to dynamically adjust the content provided on the electronic form”, paragraph [0024], “accessing data indicating a hierarchy of categories; identifying different categories in the hierarchy that correspond to the different data formats; and converting the information of the particular data type using relationships of the categories in the hierarchy that correspond to the different data formats”, paragraph [0059], “form definition 112 may indicate certain types of data to acquire, and the application may include data separate from the form definition 112 that specifies sources from which to acquire that data, such as a mapping between data types and data sources”, paragraphs [0078]-[0079], “the form data may specify a specific data type for a particular electronic form (e.g., numerical input, or input in a particular numerical range… acceptable input in a free-form text input area… collect user input data provided to the customized electronic forms (e.g., text submitted, user selections from a list of presented options, etc.) and other input data that is associated with the user's participation in the electronic form”, paragraph [0105], “information related to the user input (e.g., user and date)”).
One of ordinary skill in the art before the effective filing date would have found it obvious to include a map define form characteristics to be captured as taught by Jain within the definitions for linking data as taught by Chen with the motivation of “improve collection of information related to different user-specific factors… allow for precise control over the type of data collected… engagement between users and the application are improved” (Jain: paragraph [0005]).
Chen and Jain may not explicitly teach (underlined below for clarity):
a processor on the server is configured to define a versatile transmission/reception format that does not use document categories and that holds a plurality of unique description items and value pairs;
Selvaggi teaches a processor on the server is configured to define a versatile transmission/reception format that does not use document categories and that holds a plurality of unique description items and value pairs (Selvaggi: Figures 1-3, paragraphs [0010]-[0012], “an EHR interoperability tool… that provides interoperability between disparate EHR systems… provides a technique for breaking down EHR's into elementary data blocks that can then be easily imported into differently structured EHR systems… the disclosed unique interoperability tool labels elemental data blocks of the standard electronic health record… enables sharing of medical records between nonconnected and dissimilar EHR system… In order to create an efficient and standardized way of sharing patient data, an EHR is broken down into basic sets of data. To break the EHR into basic data sets, the standard medical record is divided into elemental parts… The electronic data representing the individual data within each elemental part of the medical record becomes one basic data set. Each basic data set is extracted, labeled with a unique identifier (defined in detail below), and saved as a unique basic data file. These unique files can be imported and reassembled into an EHR in a different system”, paragraph [0025], “extracting individual fields from an Electronic Health Record (EHR), and storing each of the individual fields as a separate unique file external to, and using a format independent of, the EHR system”, paragraphs [0029]-[0033], “Each extracted data field, in this illustrated embodiment, is composed of an A-I header 202 for the specific EHR/medical event, followed by the exemplary FIC code 203 corresponding to the source field of the extracted data 204 from that specific EHR… Each such extracted data field is thus used by the disclosed principles to create unique data files 201, with each having a uniquely created A-I tied to the specific medical event of the EHR, a FIC identifying the source field for the data in each data file 201, and the actual raw data from the source filed identified by the FIC… Each data field contains the A-I code 303 which identifies the specific original EHR 200, the FIC 304 which identifies the original EHR field, and each field data 305. The combination of the A-I 303 together with the FIC 304 in each data file 301 allows another EHR system 300 to import the data files and place each data field 305 into the correct field within the importing EHR system 300”);
One of ordinary skill in the art before the effective filing date would have found it obvious to include using a format that doesn’t use categories and only composes unique description items as value pairs in a single structured format as taught by Selvaggi within the EHR interoperability system using conversion of data and intermediary formats as taught by Chan and Jain with the motivation of “create an efficient and standardized way of sharing patient data” (Selvaggi: paragraph [0011]).
Regarding (Previously Presented) claim 2, Chen, Jain and Selvaggi teach the limitations of claim 1, and further teaches wherein the transmission/reception format defines a list of tags indicating description items that need to be shared (Chen: Figures 3-4, paragraph [0037], “use only specific file formats regardless of the diversity of the medical source data”, paragraph [0041], “The Moxy Exchange Database 110 stores a plurality of tile conversion algorithms each configured to convert various user source file types into a Medical Object (MOB) for storage in the MOB Store Database 108… It is well within the ambit of those skilled in the art to write the file conversion algorithms needs for specific file type conversions without undue experimentation”, paragraph [0059], “MXDs tell Moxy how to convert data from one format to another… A user-defined file format and implementation”, paragraphs [0076]-[0077], “The destination file type may be selected by the user in a GUI such as via drop down box listing all available download file types supported by HIE system 100, direct input, or other method for selecting the file type”; Jain: Figures 1-4, 7, paragraph [0003], “an interface for an administrator to create a form, and then remotely make adjustments to the form that take effect automatically and in real time on user devices”, paragraphs [0006]-[0007], “form definition specifies characteristics of the electronic form such as display properties, interactive elements to be included, and/or rules that vary content of the electronic form for different users or user types. The form definition can also specify different data types to be collected on the user form… an administrator can create and update a form definition for an electronic form that is provided to the user through the application. The administrator can design the electronic form using a configuration interface that allows for customization of the electronic form by specifying data types to collect using the electronic form and/or layout parameters for displaying the electronic form on the application”).
The motivation to combine is the same as in claim 1, incorporated herein.
Regarding (Previously Presented) claim 5, Chen, Jain and Selvaggi teach the limitations of claim 1, and further teaches wherein the processor is configured to allow a plurality of records to be entered into each of the description items of the transmission/reception format (Chen: Figure 1, paragraphs [0070]-[0072], “the HIE system 100 may operate to convert all downloaded patient medical data files regardless of source from the native source file format into a generic file format for storage and later retrieval from the system… process is repeated each time a user downloads a patient medical data source file”, paragraph [0082], “the HIE system 100 may process a plurality of user medical data download requests simultaneously… the HIE system 100 may process a plurality of medical data upload submissions simultaneously”. The system is capable of downloading multiple files (i.e., records) and teaches what is required of the broadest reasonable interpretation).
The motivation to combine is the same as in claim 1, incorporated herein.
Regarding (Previously Presented) claim 8, Chen, Jain and Selvaggi teach the limitations of claim 1, and further teach wherein the processor is configured to be able to set a format on a description item (Jain: Figures 3-5, paragraphs [0078]-[0079], “form data may define validation rules that specify requirements for user input to portions of the customized electronic forms. For instance, the form data may specify a specific data type for a particular electronic form (e.g., numerical input, or input in a particular numerical range)”, paragraph [0105], “information related to the user input (e.g., user and date)”, paragraphs [0086]-[0088], “a configuration interface 310 for customizing form definitions for electronic forms… allows an administrator to have fine-tuned control over various aspects of an electronic form… select a data type for the user input to be received on the electronic form… and a data source for the user input to be received on the electronic from”, paragraphs [0094]-[0095], “The configuration interface 410 enables the administrator to configure different precision levels of information shown on a customized electronic form”).
The motivation to combine is the same as in claim 1, incorporated herein.
Regarding (Previously Presented) claim 11, Chen, Jain and Selvaggiteach the limitations of claim 1, and further teaches wherein the processor configured to (i) directly transmit the transmission/reception format into which the information has been entered to the reception-side electronic health record or (ii) temporarily transmit the transmission/reception format into which the information has been entered to a relay server and transmit the transmission/reception format from the relay server to a reception-side electronic health record (Chen: Figure 4, paragraphs [0034]-[0035], “the HIE API 112 includes communication protocols configured to allow a plurality of different user (source) software programs such as outside applications 118 to communicate with and use the software modules or services of the HIE system 100 to store, organize, and retrieve/exchange patient medical records… health care provider uses the NHIN Direct Network to communicate through a Direct Project Gateway on the HIE system 100”, paragraph [0060], “object-to-file algorithms to reconstruct/reassemble MOBs back into a destination file type during a medical file upload process to a user or requestor of patient medical data”, paragraph [0081], “the HIE Core 101 runs a conversion routine or application using the supplied conversion algorithm to convert the requested medical data from a MOB into the specific destination file type requested by the user. Finally, the HIE Core 101 sends the fully converted destination medical file back to the user terminal 120 via the AP I 112”. Also see, paragraphs [0048]-[0049]).
The motivation to combine is the same as in claim 1, incorporated herein.
Response to Arguments
Applicant's arguments filed on 02 March 2026 have been fully considered but they are not persuasive. Applicant’s arguments will be addressed herein below in the order in which they appear in the response filed on 02 March 2026.
Rejections under 35 U.S.C. § 112
Regarding the rejection of claims 1-2 and 5-11, in view of the amendments to claim 1 canceling the new matter, the written description rejection has been removed.
Rejections under 35 U.S.C. § 101
Regarding the rejection of claims 1-2, 5-8 and11, the Examiner has considered the Applicant’s arguments but does not find them persuasive. The Examiner has attempted to address all of the arguments presented by the Applicant; however, any arguments inadvertently not addressed are not persuasive for at least the following reasons:
Applicant argues:
Addressing now the rejections under 35 U.S.C. § 101, Applicant respectfully traverses the rejection, as the claimed limitations, when viewed as a whole, are directed toward significantly more than the alleged abstract idea of organizing human activity… Firstly, the current invention as claimed (amended) corresponds to a "Specific Improvement in Computer Capabilities" based on MPEP 2106.04(a) and 2106.05(a)… Just as the specific table structure in Enfish improved the efficiency of computer data processing, claim 1 of the present application does not simply use a general-purpose computer for mere administrative processing. Claim 1 defines a specific rule: "dynamically creating a new data structure called a 'dated document' on memory based on a reception-side map using a date/time record as a key." This is a "manipulation of data structures by software" to maintain data integrity between different schemas, and it constitutes a technical improvement that enhances the computer's capability to manage and present information… Secondly, the Examiner asserts that the invention is "organization of human activity." However, the process of verifying massive amounts of unstructured data from different institutions against dates in real-time and automatically relocating and storing them into a document structure unique to the receiving side clearly exceeds the scope of human mental activity. As mentioned in McRO and cited in MPEP 2106.0S(a), the court relied on the specification's explanation of how the particular rules recited in the claim enabled the automation of specific animation tasks that previously could only be performed subjectively by humans, when determining that the claims were directed to improvements in computer animation instead of an abstract idea… As noted above, the problem solved by the present invention is not a mere business objective of inter-organizational information sharing. Rather, the present invention solves a specific technical problem in computer data processing: the inability to automatically reconstruct the "chronological context" inherent in data elements on a receiving system without loss when transferring between systems with different data schemas.
The Examiner respectfully disagrees.
It is respectfully submitted, that unlike the argued court cases, the instant case does not recite a technical solution to a technical problem recited in Applicant’s specification. Firstly, no portions of the specification are argued for recitation of technical problem, MPEP 2106.04(d)(1) states, that the specification “must describe the invention such that the improvement would be apparent to one of ordinary skill in the art”, Applicant’s specification must sufficiently describe any alleged technical problem and claimed technical solutions to said technical problems, as applicant does not argue any portions of their specification for recitations of a technical problem the argument is not persuasive. Secondly, organizing data between humans at different facilities is an abstract idea, organizing data between human users does not improve the performance of the computer nor does it recite a technical solution to a technical problem recited in Applicant’s specification. The generic hardware components are not particular specialized hardware, they are generic off-the-shelf computer components (see Applicant’s Specification Figure 1, paragraph [0033]), and which as stated in 2106.05(f)(2) “claiming the improved speed or efficiency inherent with applying the abstract idea on a computer” does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA).
Therefore, as the currently claimed additional elements do not recite a technical solution to a technical problem recited in Applicant’s specification and/or an improvement in the functionality of the computer, the argument is not persuasive.
Rejections under 35 U.S.C. § 103
Regarding the rejection of claims 1-2, 5-8 and 11, the Examiner has considered the applicant’s arguments; however, the arguments are not persuasive as addressed herein. Any arguments inadvertently not addressed are unpersuasive for at least the following reasons:
Applicant argues:
Claim 1 has been amended to overcome the rejection under 35 U.S.C. § 103… Chen does not teach using a transmission side map and hence does not teach updated the description items, rather Chen saves them into generic format… On the contrary, the independent claim explicitly recites, inter alia, "a versatile transmission/reception fo1mat that does not use document categories and that holds a plurality of unique description items and value pairs as a single structured data set"… The outstanding Office Action relies on another reference Jain to teach a mapping or forms… There is no teaching to have both a transmission-side map and also recreating on a reception side… Applicant respectfully submits that the critical difference between Selvaggi's "Fragmentation" approach and the instant invention's is the "Reconstruction" Process… Selvaggi merely teaches "disassembly and static storage" of data and does not even suggest the "active reconstruction of chronological structure on the receiving side" as in the present invention… Such a combination would be a "change for the worse" that significantly degrades system performance and constitutes a clear "Teaching Away" in U.S. patent practice… Without such motivation and absent improper hindsight reconstruction.
The Examiner respectfully disagrees.
It is respectfully submitted, Applicant has removed the language of “a singled structure data set”, yet continues to argue such limitation that is not claimed, with respect to the actually claimed language, it is taught by the combination of Selvaggi and Jain within teachings of Chen, in particular Chen explicitly teaches the use of a transmission/reception format that uses the date the data was created along with the data and additional attributes/properties (i.e., description items; see above but at least paragraph [0021], [0044], [0049] and [0059]), this date is used in creating the document in the specified reception-side format as well (see above but at least paragraphs [0041], [0044], [0060] and [0081]), while Chen may not use the word “map” for the conversion of data, one of ordinary skill in the art in view of additional teachings such as at least paragraph [0059] of Jain, would find it prima facie obvious that Chen in view of Jain teaches the argued mapping of data, however the combination of Chen and Jain may not explicitly recite use of a versatile transmission/reception format that does not use document categories and has value pairs, nevertheless Selvaggi, teaches use of a single set of structured data that does not use document categories and holds a plurality of unique description items and value pairs (see above but at least Figures 2-3, paragraphs [0025], [0030] and [0033]), Additionally, nothing would evidence any inoperability, such that one of ordinary skill in the art would find it prima facie obvious to include the format of Selvaggi within the EHR interoperability system using conversion of data as taught by Chan and Jain with the motivation of “create an efficient and standardized way of sharing patient data” (Selvaggi: paragraph [0011]).
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Andrew E Lee whose telephone number is (571)272-8323. The examiner can normally be reached M-Th 9-5:00 PM.
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 on 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.
/A.E.L./Examiner, Art Unit 3684
/Shahid Merchant/Supervisory Patent Examiner, Art Unit 3684
Prosecution Insights