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 .
Claims Status
This Office-Action is in response to claims filed on 12/08/2025
Claims 1-3 and 7-20 are pending and rejected; claims 1, and 20 are independent claims
The terminal disclaimer filed on 12/08/2025 is entered, accordingly the double patenting rejection is withdrawn; Claims 4-6 are canceled.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/20/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant's arguments filed on 12/08/2025 have been fully considered but they are not persuasive.
With respect to applicant’s argument: The Doran and Romanychev reference, alone and in combination, fail to disclose the limitation “collect usage data related to the filtered user data, wherein the usage data comprises data indicative of use of the user data by the computing system; and generate at least one quick response code embedded with at least one of the usage data related to the filtered user data and a link to the usage data related to the filtered user data.” As claimed in claims 1 and 20.
Examiner respectfully disagree with applicant argument for the following reasons: Romanychev discloses (see Romanychev Fig. 11 and ¶72, the medical data provided by the patient may be filtered, by the health care platform 108, as a protected shareable medical data 204, and an unprotected medical data 208; ¶¶84 169-170, data collection module 304 may be configured to store the verified data collected from the patient and/or the individual [i.e. filtered data], or user in a database, such as, the EHR database 111; ¶85, the data collection module 304 may be configured to categorize the medical data based on factors, such as, but not limited to, personal data, medical data, level of sharing defined by the patient and/or HIPAA rules and regulations [i.e. usage data], and so forth.); ¶72, the patient and/or an individual may define a level of sharing 202 for each data form stored in the EHR database 111, in an embodiment of the present invention. The level of sharing may include, but not limited to, allow to all, allow to emergency only, including National Provider Identifier (NPI) list, excluding NPI list, an authorization code in compliance with Health Insurance Portability and Accountability Act (HIPAA), which may grant access to a user for a specific patient only, and so forth [i.e. HIPPA authorization code is usage data that is contained in QR code] )
With respect to applicant’s argument: The Doran and Romanychev reference, alone and in combination, fail to disclose the limitation, “generate at least one quick response code embedded with at least one of the usage data related to the filtered user data and a link to the usage data related to the filtered user data”
Examiner respectfully disagree with applicant’s argument for the following reasons: Romanychev teaches (see Romanychev ¶73, medical data and their level of sharing, defined by the patient may be embedded in a medical identifier 206…, the identification data may be embedded in an identification code 206…, the medical identifier 206 may be, but not limited to, a Quick Response (QR) code, a Bar code, a unique identifier, such as a biometric, and so forth), disclosing the recited claim limitation.
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.
Claim(s) 1-3 and 7-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Romanychev et al. US Pub. No.: 2022/0139510 A1 (hereinafter Romanychev) in view of Doran et al. US Pub. No.: 2021/0125297 A1 (hereinafter Doran)
Romanychev discloses:
As to claim 1. A system for network data privacy, comprising:
a computing system including at least one processor and at least one memory device, wherein the computing system executes computer-readable instructions (see Romanychev ¶170 Fig. 11 a computer system that can be used to implement an embodiment of the present invention);
a network connection operatively connecting the computing system to at least one user device (see Romanychev Fig. 1 and ¶57, a health care system 100 for communicating medical data of a patient to a user, according to an embodiment of the present invention);
wherein, upon execution of the computer-readable instructions, the at least one processor is configured to:
provide, to the at least one user device, a user software application to a user for installation on the at least one user device (see Romanychev ¶76, user interface module 302 may be configured to provide a user interface of the medical application 106 on the patient device 102 and/or the user device 104. First, the patient and/or an individual may install the medical application 106 in the patient device 102; ¶160, At step 908, the health care platform 108 may install the medical application 106 on the user device 104, in an embodiment of the present invention) , wherein the at least one user device is configured to wirelessly communicate with the computing system via the user software application (see Romany ¶65, sharing of the identification data and/or the medical data from the health care platform 108 to the patient device 102, the user device 104 and/or the scanning device 105, or vice versa may be done through a communication network 110.. include a wireless network);
receive, from the user software application installed on the at least one user device, user data comprising personal information data of the user (see Romanychev ¶76, the user interface module 302 may function in conjunction with the data collection module 304 in order to collect information from the patient and/or an individual..., the information may include, but not limited to, a name, an age, a date of birth, a residential address, an office address, medical data, medical reports, prescriptions, a blood type, an emergency note, an emergency contact, biometric data, and so forth);
store the user data in at least one database (see Romanychev ¶67, the identification data and/or the medical data shared by the patient and/or the user may be stored in a database. In an embodiment of the present invention, the database may be an Electronic Health Record (EHR) database 111);
filter the user data to allow for certain variables in the user data to be determined private (see Romanychev ¶72, the medical data provided by the patient may be filtered, by the health care platform 108, as a protected shareable medical data 204, and an unprotected medical data 208) ;
collect usage data related to the filtered user data wherein the usage data comprises data indicative of use of the user data by the computing system (see Romanychev Fig. 11 and ¶72, the patient and/or an individual may define a level of sharing 202 for each data form stored in the EHR database 111, in an embodiment of the present invention. The level of sharing may include, but not limited to, allow to all, allow to emergency only, including National Provider Identifier (NPI) list, excluding NPI list, an authorization code in compliance with Health Insurance Portability and Accountability Act (HIPAA), which may grant access to a user for a specific patient only, and so forth ¶84, data collection module 304 may be configured to store the verified data collected from the patient and/or the individual [i.e. filtered data], or user in a database, such as, the EHR database 111; ¶85, the data collection module 304 may be configured to categorize the medical data based on factors, such as, but not limited to, personal data, medical data, level of sharing defined by the patient and/or HIPAA rules and regulations [i.e. usage data], and so forth.);
generate at least one quick response code embedded with at least one of the usage data related to the filtered user data and a link to the usage data related to the filtered user data (see Romanychev ¶73, medical data and their level of sharing, defined by the patient may be embedded in a medical identifier 206…, the identification data may be embedded in an identification code 206…, the medical identifier 206 may be, but not limited to, a Quick Response (QR) code, a Bar code, a unique identifier, such as a biometric, and so forth) ; and
transmit the quick response code embedded with the at least one of the usage data and the link to the usage data to the at least one user device (see Romanychev FIGS. 1 4A-4G and ¶99, a medical identifier(QR code)is provided in a dynamic form (e.g., electronic/computer storable/readable form). A dynamic medical identifier may be downloaded(transmitted) to a smart user device (e.g., a mobile telephone and/or a wearable device), such as user device 104)
Romanychev does not explicitly disclose but the related art Doran discloses:
receive, from a user-specific dashboard of the user software application, at least one communication request related to usage of the user data transmitted from the at least one user device (see Doran Fig. 5, user specific dash board, ¶¶70-71, collect a user profile and privacy preferences as the user accepts or rejects particular contracts. As seen from the dashboard, data column 502 provides the user an opportunity to see exactly which data the user is sharing with the associated company [i.e. usage data transmitted/shared] …, provide the user with an option to consent to all PII data collection of an entity);
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the system and method for communication medical data disclosed by Romanychev to include the system of intelligent contract analysis and data organization disclosed by Doran, a person with ordinary skill in the art would have been motivation to prevent unauthorized proliferation of personal data and provide the option for consent for specific data usage (see Doran Par. 2) .
As to claim 2, Romanychev in view of Doran discloses the system of claim 1, wherein the at least one processor is configured to receive identification of the user via an application accessible by the at least one user device (see Romanychev ¶¶49 60, patient and/or individual person may update the patient profile by providing identification data and/or medical data that may include, Personal Identifiable Information (PII) and/or Protected Health Information (PHI) on the medical application 106, as shown in FIG. 10)
As to claim 3, Romanychev in view of Doran discloses the system of claim 1, wherein the at least one processor is configured to verify identification of the user of an application accessible by the at least one user device (see Romanychev ¶78, user may log-in the medical application 106 by using the log-in credentials, such as, but not limited to, a sign-in ID and a password, and/or a unique identifier, for example, a fingerprint, a face recognition, retina, etc.) .
As to claim 4, (canceled).
As to claim 5, (canceled).
As to claim 6, (canceled).
As to claim 7, Romanychev in view of Doran discloses the system of claim 1, wherein the at least one processor is configured to display the at least one communication request on a graphical user interface of the at least one user device (see Romanychev Figs. 4A-4G, graphical user interface of user device).
As to claim 8, Romanychev in view of Doran discloses the system of claim 1, wherein the at least one processor is configured to host the at least one quick response code embedded with the usage data on an application accessible by the at least one user device (see Romanychev FIGS. 1 4A-4G and ¶99, a medical identifier(QR code)is provided in a dynamic form (e.g., electronic/computer storable/readable form). A dynamic medical identifier may be downloaded(transmitted) to a smart user device (e.g., a mobile telephone and/or a wearable device), such as user device 104).
As to claim 9, Romanychev in view of Doran discloses the system of claim 1, wherein the at least one processor is configured to display the at least one quick response code on a graphical user interface of the at least one user device (see Romanychev Fig. 4C, the QR code 406 being displayed on the graphical user interface of a user device).
As to claim 10, Romanychev in view of Doran discloses the system of claim 1, wherein the at least one processor is configured to translate the at least one quick response code into human-readable data upon tactile engagement of the at least one quick response code displayed on a graphical user interface of the at least one user device (see Romanychev ¶112, once the QR code 406 is scanned, an unprotected PII data, a protected PII data, a basic PHI data, or a combination thereof, associated with the patient is displayed on the user device 104, which may include, a first name, a last name, an emergency contact, a date of birth, a gender, and so forth).
As to claim 11, Romanychev in view of Doran discloses the system of claim 10, wherein the at least one processor is configured to display the human-readable data on the graphical user interface of the at least one user device (see Romanychev ¶112, an unprotected PII data, a protected PII data, a basic PHI data, or a combination thereof, associated with the patient is displayed on the user device 104, which may include, a first name, a last name, an emergency contact, a date of birth, a gender, and so forth. Therefore, the user may then be able to access a set of medical data in a readable format as per the level of authorization).
As to claim 12, Romanychev in view of Doran discloses the system of claim 1, wherein the at least one processor is configured to require authentication to access and/or view the embedded data (see Romanychev Fig. 4D and ¶113, an unprotected PII data, a protected PII data, a basic PHI data, or a combination thereof, associated with the patient is displayed on the user device 104, which may include, a first name, a last name, an emergency contact, a date of birth, a gender, and so forth. Therefore, the user may then be able to access a set of medical data in a readable format as per the level of authorization).
As to 13, Romanychev in view of Doran discloses the system of claim 12, wherein the authentication has multiple levels of authentication (see Romanychev ¶¶7 and 45-47, a data access module configured to enable the at least one personnel to access the medical data of the at least one individual based on a level of authorization for the at least one personnel defined by the at least one individual when the identity of the individual is valid) .
As to claim 14, Romanychev in view of Doran discloses the system of claim 12, wherein the authentication includes at least one of a username, a password, a pin, biometric information, and a security token (see Romanychev ¶78, user may log-in the medical application 106 by using the log-in credentials, such as, but not limited to, a sign-in ID and a password, and/or a unique identifier).
As to claim 15, Romanychev in view of Doran discloses the system of claim 12, wherein the authentication is inputted into a graphical user interface of the at least one user device (see Romanychev Fig. 4D, graphical user interface for user authentication).
As to claim Romanychev in view of Doran discloses 16, the system of claim 1, wherein the at least one quick response code includes at least one an identifier of the enterprise system (see Romanychev Fig. 5 and ¶73, the medical identifier 206 may be, but not limited to, a Quick Response (QR) code, a Bar code, a unique identifier, such as a biometric, and so forth. In an embodiment of the present invention, the medical identifier 206 may include data such as, but not limited to, a PII open code, a PII encoded code, a second medical identifier (e.g., a URL to the EHR database 111 that stores the protected medical data 204) [i.e. identifier of enterprise system], an authorization code, a patient code, and so forth)
As to claim 17, Romanychev in view of Doran discloses the system of claim 1, wherein the source of the usage data is the enterprise system (see Romanychev ¶85, personal data, medical data, level of sharing defined by the patient and/or HIPAA rules and regulations).
As to claim 18, Romanychev in view of Doran discloses the system of claim 1, wherein the source of the usage data is a third-party entity (see Romanychev ¶105, he predetermined order may be defined by the service provider of the health care platform 108, or is based on laws in compliance with HIPAA [i.e. third-party]).
As to claim 19, Romanychev in view of Doran discloses the system of claim 1, wherein the at least one quick response code is embedded with information related to product and/or service offerings (see Romanychev ¶73, the identification data may be embedded in an identification code 206…, the medical identifier 206 may be, but not limited to, a Quick Response (QR) code, a Bar code, a unique identifier, such as a biometric, and so forth).
Romanychev discloses:
As to claim 20, a system for network data privacy, comprising:
a computing system including at least one processor and at least one memory device, wherein the computing system executes computer-readable instructions (see Romanychev ¶170 Fig. 11 a computer system that can be used to implement an embodiment of the present invention);
a network connection operatively connecting the computing system to at least one user device (see Romanychev Fig. 1 and ¶57, a health care system 100 for communicating medical data of a patient to a user, according to an embodiment of the present invention);
provide, to the at least one user device, a user software application to a user for installation on the at least one user device (see Romanychev ¶76, user interface module 302 may be configured to provide a user interface of the medical application 106 on the patient device 102 and/or the user device 104. First, the patient and/or an individual may install the medical application 106 in the patient device 102; ¶160, At step 908, the health care platform 108 may install the medical application 106 on the user device 104, in an embodiment of the present invention) , wherein the at least one user device is configured to wirelessly communicate with the computing system via the user software application (see Romany ¶65, sharing of the identification data and/or the medical data from the health care platform 108 to the patient device 102, the user device 104 and/or the scanning device 105, or vice versa may be done through a communication network 110.. include a wireless network);
receive, from the user software application installed on the at least one user device, user data comprising personal information data of the user (see Romanychev ¶76, the user interface module 302 may function in conjunction with the data collection module 304 in order to collect information from the patient and/or an individual..., the information may include, but not limited to, a name, an age, a date of birth, a residential address, an office address, medical data, medical reports, prescriptions, a blood type, an emergency note, an emergency contact, biometric data, and so forth);
store the user data in at least one database (see Romanychev ¶67, the identification data and/or the medical data shared by the patient and/or the user may be stored in a database. In an embodiment of the present invention, the database may be an Electronic Health Record (EHR) database 111);
filter the user data to allow for certain variables in the user data to be determined private (see Romanychev ¶72, the medical data provided by the patient may be filtered, by the health care platform 108, as a protected shareable medical data 204, and an unprotected medical data 208) ;
collect usage data related to the filtered user data wherein the usage data comprises data indicative of use of the user data by the computing system (see Romanychev Fig. 11 and ¶72, the patient and/or an individual may define a level of sharing 202 for each data form stored in the EHR database 111, in an embodiment of the present invention. The level of sharing may include, but not limited to, allow to all, allow to emergency only, including National Provider Identifier (NPI) list, excluding NPI list, an authorization code in compliance with Health Insurance Portability and Accountability Act (HIPAA), which may grant access to a user for a specific patient only, and so forth;¶84, data collection module 304 may be configured to store the verified data collected from the patient and/or the individual [i.e. filtered data], or user in a database, such as, the EHR database 111; ¶85, the data collection module 304 may be configured to categorize the medical data based on factors, such as, but not limited to, personal data, medical data, level of sharing defined by the patient and/or HIPAA rules and regulations [i.e. usage data], and so forth.);
generate a quick response code embedded with at least one of the usage data related to the filtered user data and a link to the usage data related to the filtered user data (see Romanychev ¶73, medical data and their level of sharing, defined by the patient may be embedded in a medical identifier 206…, the identification data may be embedded in an identification code 206…, the medical identifier 206 may be, but not limited to, a Quick Response (QR) code, a Bar code, a unique identifier, such as a biometric, and so forth) ; and
transmit the quick response code embedded with the at least one of the usage data and the link to the usage data to the at least one user device (see Romanychev FIGS. 1 4A-4G and ¶99, a medical identifier(QR code)is provided in a dynamic form (e.g., electronic/computer storable/readable form). A dynamic medical identifier may be downloaded(transmitted) to a smart user device (e.g., a mobile telephone and/or a wearable device), such as user device 104)
Romanychev does not explicitly disclose but the related art Doran discloses:
receive, from a user-specific dashboard of the user software application, at least one communication request related to usage of the user data transmitted from the at least one user device (see Doran Fig. 5, user specific dash board, ¶¶70-71, collect a user profile and privacy preferences as the user accepts or rejects particular contracts. As seen from the dashboard, data column 502 provides the user an opportunity to see exactly which data the user is sharing with the associated company [i.e. usage data transmitted/shared] …, provide the user with an option to consent to all PII data collection of an entity);
generate a predictive model during training of a machine learning program including a neural network of the machine learning program, wherein a training data set utilized during the training of the machine learning program comprises a personal data set of at least one user, and wherein the personal data set of the at least one user includes at least one data entry related to at least one data portability measure with respect to the at least one user (see Doran ¶45, if a user has preferences/values that make privacy of personal information a high priority, then certain contract provisions (e.g., allowing a business to use personal data with third-party advertisers) are going to repeatedly be rejected. The pattern that may be established by the user in rejecting certain contract provisions combined with a user's overall privacy profile (indicating a user's preferences as to how his/her PII is shared or distributed among third parties) may be used to train at least one machine-learning model);
predict, by the predictive model, at least one predicted data portability measure of the at least one user associated with the at least one user device based upon the personal data set of the at least one user (see Doran 46, the machine learning model may use the data from the Democrat voter in her 30's living in Colorado to make similar consent/no consent recommendations to a user who demonstrates similar political preferences, age, and location. In some example aspects, individual historical data may be coupled with broader population-based data to train the machine-learning model(s));
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the system and method for communication medical data disclosed by Romanychev to include the system of intelligent contract analysis and data organization disclosed by Doran, a person with ordinary skill in the art would have been motivation to prevent unauthorized proliferation of personal data and provide the option for consent for specific data usage (see Doran Par. 2) .
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NEGA WOLDEMARIAM whose telephone number is (571)270-7478. The examiner can normally be reached Monday to Friday, 8am-5pm.
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, Cathy Thiaw can be reached at 5712701138. 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.
NEGA . WOLDEMARIAM
Examiner
Art Unit 2407
/N.W/Examiner, Art Unit 2407
/Catherine Thiaw/Supervisory Patent Examiner, Art Unit 2407 2/17/2026