DETAILED ACTION
Notice of Pre-AIA or AIA Status
1.The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
2. According to applicant’s arguments filed on 02/27/2026, independent claims 1 and 11 have been amended; and claims 3 and 13 have been cancelled hereby acknowledged.
3. Applicant’s arguments with respect to independent claim(s) 1 and 11 have been fully considered but are moot based on the new ground of rejection.
4. Applicant argues that the prior art of record do not discloses the amended feature of claim 1 and 11 which recites: “identify a corruption datum corresponding to the user health datum, wherein the corruption datum includes a degree to which a data structure associated with the user health datum is corrupted; delete the corrupted data structure associated with the user health datum as a function of the corruption datum; share a health record of the user health datum cleansed of the corrupted data structure using the secure communication channel interface”.
5. Examiner would like to point out that the new secondary reference Rosenberg (US Pub.No.2020/0152299) teaches the above claimed limitations (see the rejection below).
Double Patenting
6. The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper time wise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); Inre Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.821(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
7. Claims 1,2,6,10-12, and 20 of the instant application is rejected on the ground of non-statutory double patenting as being unpatentable over claims 1,8,11,18 and 20 of the patent nos. 11,968,189; and claims 1-2,5,10,11-13, 15 and 18 of the patent nos. 11,394,695. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of the current application encompass the same subject matter as the patent claims [such as generating a secure communication channel interface, the system including a computing device configured to transmit, to a user client device, a configuration packet uniquely identifying the computing device, receive, from the user client device, a confirmation authentication for the configuration packet, initiate a secure communication channel interface with the user client device, establish a security baseline parameter within the secure communication channel interface, wherein establishing a security baseline parameter includes capturing a baseline audiovisual measurement using an audiovisual capture device, detect a change in the security baseline parameter by detecting a change in relation to a baseline user environment landmark, and execute a mitigation action to prevent a security breach] , but with obvious wording variations . This is a non-statutory double patenting rejection.
Claim Rejections - 35 USC § 103
8. 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.
9. Claim(s) 1-2,4-12 and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lindemann (US Pub.No.2018/0191695) in view of Coney (US Pub.No.2015/0310173) and further in view of Rosenberg (US Pub.No.2020/0152299).
10. Regarding claim 1 Lindemann teaches a system for generating a secure communication channel interface, the system comprising a computing device configured to: transmit, to a user client device [client device, element.200 in fig.2], a configuration packet uniquely identifying the computing device [relying party, element.250 fig.2](Fig.2, Para: 0109 and Para: 0114-0115 teaches establishing a secure communication module between client device and relying party. Each authenticator 220-221, including the non-intrusive authenticator 230 (e.g., based on location, sensed user behavior, etc.) will exchange a relying-party-specific and attested key in a registration operation (preceding authentication). The assurance level returned in the authentication operation will be part of a message signed/encrypted [configuration packet herein] by the relying-party-specific authentication key. The message will also include nonce (e.g., a random challenge) generated by the relying party. The authentication keys associated with each of the authenticators are used by the secure communication module 213 to establish secure communication with the relying party);
receive, from the user client device, an authentication datum; initiate a secure communication channel interface with the user client device as a function of the authentication datum ((Figs.37-38, Para: 0396-0397 teaches the client devices includes a secure transaction application for communicating with the relying party. The secure transaction application will be a stand-alone application which interfaces with the authentication engine via a secure application programming interface (API). During user confirmation process, the secure transaction application ensures that the text displayed to the user is the actual text related to the transaction. For example, the application will display text within a secure window and ask the user to provide authentication to confirm the transaction. The application will initiate a timer and periodically verify the content of the current window being displayed to the user (e.g., by generating a signature on the content). The period of verification will be randomly chosen. Thus, the application continually ensures that the user sees the valid transaction details in the window (thereby ensuring that the transaction text has not been modified by a man in the middle attack). If the application detects that the content has been tampered with it prevents the confirmation of the transaction from being generated. Para: 0520-0525 and Para: 0398 teaches after the user provides valid authentication (e.g., swipes a finger on the fingerprint sensor), the client device identifies the user and generates a token (cryptographic signature) with the transaction details (e.g., the displayed text) and a random challenge provided from the relying party (e.g., the token will be a signature over the transaction details and a nonce). This allows the relying party ensure that the transaction details have not been modified between the server and the client);
establish a security baseline parameter, wherein establishing the security baseline parameter comprises: identifying a network parameter; identifying a baseline audiovisual measurement; identifying a biometric identifier of a user ((Para:0010 and Para:0140 teaches for user authentication the user will provide location data or other personal (e.g. face image, color of clothing, gait or typing characteristics) or environmental data (e.g. temperature, humidity, WLAN SSIDs) to the relying party. Figs.26A-B, Para: 0312 teaches the authentication engine 2610 includes a voice recognition module 2660 and a lip movement analysis module 2670 in addition to the facial recognition module 2604 and eye tracking module 2605. The user's voice is captured via a microphone 2680 and the analog voice signal is converted to a digital signal via an analog to digital (A/D) converter 2681. The voice recognition module 2660 compares the digital voice signal to a voice print of the user stored within a voice database 2665. The voice print is generated during a training/enrollment process in which the user is prompted to speak certain words or phrases. Upon receiving the digitized audio signal resulting from the spoken words/phrases, the voice recognition module 2660 generates the voice print by capturing specific characteristics of the user's voice (e.g., spectral characteristics, phonetic-based categorization, etc.), and storing the results within the voice database 2665. The voice recognition module 2660 will utilize various voice recognition techniques when generating the voice print and comparing the voice print to a captured voice signal. Para: 0303 teaches eye-tracking techniques are used to verify that the eyes are reacting to the screen layout in an expected manner. This information may then be combined with face recognition techniques to verify that the expected face is still present. Moreover, the eye tracking and facial recognition techniques will be combined with other techniques (e.g., location-based authentication, non-intrusive user presence detection, fingerprint scanning, etc.) to arrive at a sufficient level of assurance that the legitimate user is in possession of the device);
Lindemann teaches all the above claimed limitations, but does not expressly teach establishing the security baseline parameter further comprises identify a user health datum as a function of the security baseline parameter; share a health record of the user health datum using the secure communication channel interface; and transcribe audio information of the user health datum transmitted over the secure communication channel interface
Coney teaches establishing the security baseline parameter further comprises; and identifying a user environment landmark comprising a physical object (Para:0131-0132, para:0047-0048 teaches identifying objects); identify a user health datum as a function of the security baseline parameter; share a health record of the user health datum using the secure communication channel interface; and transcribe audio information of the user health datum transmitted over the secure communication channel interface (Para:00011-0012 and Para:0096-00098 teaches share a health record of the user over the secure communication channel).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the invention was filed to modify Lindemann to include establishing the security baseline parameter further comprises identify a user health datum as a function of the security baseline parameter; share a health record of the user health datum using the secure communication channel interface; and transcribe audio information of the user health datum transmitted over the secure communication channel interface as taught by Coney such a setup would protect the privacy of the user.
Both Lindemann in view of Coney teaches all the above claimed limitations but fails to teach identify a corruption datum corresponding to the user health datum, wherein the corruption datum includes a degree to which a data structure associated with the user health datum is corrupted; delete the corrupted data structure associated with the user health datum as a function of the corruption datum; share a health record of the user health datum cleansed of the corrupted data structure using the secure communication channel interface.
Rosenberg teaches identify a corruption datum corresponding to the user health datum, wherein the corruption datum includes a degree to which a data structure associated with the user health datum is corrupted; delete the corrupted data structure associated with the user health datum as a function of the corruption datum; share a health record of the user health datum cleansed of the corrupted data structure using the secure communication channel interface (Para:0082-0085 and Para:0108-0111 teaches the server 106 initiates the secure peer-to-peer communication channel directly between the external provider 128 and the diagnostic provider 114 so that the selected external medical record can be transmitted to the diagnostic provider 114.The server 106 can determine if the selected external medical record is corrupt, incomplete, or otherwise has any flaws or inconsistencies which would prevent the selected external medical record from being transmitted to, or accessed in its entirety by, the diagnostic provider 114. The external provider 128 can also remove or delete the selected external medical record, in the event the external provider 128 does not confirm the selection of the external medical record).
Therefore, it would have been obvious to one of the ordinary skills in the art before the effective filing date of the invention was filed to modify Lindemann in view of Coney to include identify a corruption datum corresponding to the user health datum, wherein the corruption datum includes a degree to which a data structure associated with the user health datum is corrupted; delete the corrupted data structure associated with the user health datum as a function of the corruption datum; share a health record of the user health datum cleansed of the corrupted data structure using the secure communication channel interface as taught by Rosenberg such a setup would improves data accuracy.
11. Regarding claim 2 Lindemann teaches the system, wherein establishing the security baseline parameter comprises receiving from the user client device a plurality of authentication factors (Para:0010 and Para:0140 teaches for user authentication the user will provide location data or other personal (e.g. face image, color of clothing, gait or typing characteristics) or environmental data (e.g. temperature, humidity, WLAN SSIDs) to the relying party. Figs.26A-B, Para: 0312 teaches the authentication engine 2610 includes a voice recognition module 2660 and a lip movement analysis module 2670 in addition to the facial recognition module 2604 and eye tracking module 2605. The user's voice is captured via a microphone 2680 and the analog voice signal is converted to a digital signal via an analog to digital (A/D) converter 2681. The voice recognition module 2660 compares the digital voice signal to a voice print of the user stored within a voice database 2665. The voice print is generated during a training/enrollment process in which the user is prompted to speak certain words or phrases. Upon receiving the digitized audio signal resulting from the spoken words/phrases, the voice recognition module 2660 generates the voice print by capturing specific characteristics of the user's voice (e.g., spectral characteristics, phonetic-based categorization, etc.), and storing the results within the voice database 2665. The voice recognition module 2660 will utilize various voice recognition techniques when generating the voice print and comparing the voice print to a captured voice signal. Para: 0303 teaches eye-tracking techniques are used to verify that the eyes are reacting to the screen layout in an expected manner. This information may then be combined with face recognition techniques to verify that the expected face is still present. Moreover, the eye tracking and facial recognition techniques will be combined with other techniques (e.g., location-based authentication, non-intrusive user presence detection, fingerprint scanning, etc.) to arrive at a sufficient level of assurance that the legitimate user is in possession of the device);
12. Regarding claim 4 Coney teaches the system, wherein the computing device is configured to delete the health record upon the secure communication channel interface terminating (Para:0034 teaches deleting the health record)
.
13. Regarding claim 5 Coney teaches the system, wherein the computing device is configured to receive from the user client device a recorded session datum (Para:0011-0012, 0014 teaches receiving the patent record).
14. Regarding claim 6 Lindemann teaches the system, wherein the computing device is configured to request from the user client device a plurality of authentication factors as a function of a change in the security baseline parameter (Para: 0550-0551 teaches after the server transmits a random challenge to the client, and if the client does not respond within a specified timeout period, the random challenge is no longer valid and the client will receive an error in response to a subsequent authentication attempt. The client will then request for a new challenge from the server. The server then generates a new random challenge and transmits it to the client which may then use it to establish a new secure communication with the server. Para: 0145 teaches the existing authentication systems do not allow new authenticators to be enabled using registered authenticators on trusted clients. For example, if a user has a fingerprint sensor on her phone which she has registered with number of websites and then she installs a voice authenticator on her phone, she has no way to automatically register her voice authenticator with all the websites she was using with fingerprint sensor. Rather, in this case, the user must step through the same enrollment and registration process to register the voice authenticator with the relying party. Similarly, if the user purchases a new device with a new set of authenticators, the user must re-enroll and reregister all of the new authenticators with the server).
15. Regarding claim 7 Coney teaches the system, wherein the computing device is configured to transmit the health record to a health record database (Para:0011-0012, 0014 teaches transmitting the health record).
16. Regarding claim 8 Coney teaches the system, wherein the computing device is configured to receive from the user client device a health record validation datum (claim 21 and Para:0011-0012 teaches receive a health record validation datum).
17. Regarding claim 9 Coney teaches the system, wherein the computing device is configured to receive from the user client device a health record validation datum as a function of user input (claim 21 and Para:0011-0012 teaches receive a health record validation datum as user input).
18. Regarding claim 10 Lindemann teaches the system, wherein the computing device is configured to alert a security professional as a function of a change in the security baseline parameter (Para:0010 and Para:0140 teaches for user authentication the user will provide location data or other personal (e.g. face image, color of clothing, gait or typing characteristics) or environmental data (e.g. temperature, humidity, WLAN SSIDs) to the relying party. Figs.26A-B, Para: 0312 teaches the authentication engine 2610 includes a voice recognition module 2660 and a lip movement analysis module 2670 in addition to the facial recognition module 2604 and eye tracking module 2605. The user's voice is captured via a microphone 2680 and the analog voice signal is converted to a digital signal via an analog to digital (A/D) converter 2681. The voice recognition module 2660 compares the digital voice signal to a voice print of the user stored within a voice database 2665. The voice print is generated during a training/enrollment process in which the user is prompted to speak certain words or phrases. Upon receiving the digitized audio signal resulting from the spoken words/phrases, the voice recognition module 2660 generates the voice print by capturing specific characteristics of the user's voice (e.g., spectral characteristics, phonetic-based categorization, etc.), and storing the results within the voice database 2665. The voice recognition module 2660 will utilize various voice recognition techniques when generating the voice print and comparing the voice print to a captured voice signal. Para: 0303 teaches eye-tracking techniques are used to verify that the eyes are reacting to the screen layout in an expected manner. This information may then be combined with face recognition techniques to verify that the expected face is still present. Moreover, the eye tracking and facial recognition techniques will be combined with other techniques (e.g., location-based authentication, non-intrusive user presence detection, fingerprint scanning, etc.) to arrive at a sufficient level of assurance that the legitimate user is in possession of the device.
Para: 0550-0551 teaches after the server transmits a random challenge to the client, and if the client does not respond within a specified timeout period, the random challenge is no longer valid and the client will receive an error in response to a subsequent authentication attempt. The client will then request for a new challenge from the server. The server then generates a new random challenge and transmits it to the client which may then use it to establish a new secure communication with the server. Para: 0389 and Para: 0393 teaches in response to a successful authentication or unsuccessful authentication by the user of client device, the notification generation logic at the relying party will sends a notification to the client device. The notification may be sent in a variety of ways. For example, the notification may be sent via email, text message (e.g., SMS), instant message, or any other technology capable of delivering a message to the client devices).
19. Regarding claim 11 Lindemann teaches a method of generating a secure communication channel interface, the method comprising: using at least a processor of a computing device, transmitting, to a user client device, a configuration packet uniquely identifying the computing device; using the at least a processor, receiving, from the user client device, an authentication datum; using the at least a processor, initiating a secure communication channel interface with the user client device as a function of the authentication datum; using the at least a processor, establishing a security baseline parameter, wherein establishing the security baseline parameter comprises: identifying a network parameter; identifying a baseline audiovisual measurement; identifying a biometric identifier of a user; and identifying a user environment landmark comprising a physical object; using the at least a processor, identifying a user health datum as a function of the security baseline parameter; using the at least a processor, identifying a corruption datum corresponding to the user health datum, wherein the corruption datum includes a degree to which a data structure associated with the user health datum is corrupted;
using the at least a processor, deleting the corrupted data structure associated with the user health datum as a function of the corruption datum; using the at least a processor, sharing a health record of the user health datum cleansed of the corrupted data structure using the secure communication channel interface; and using the at least a processor, transcribing audio information of the user health datum transmitted over the secure communication channel interface. (see, the rejection for claim 1)
20. Regarding claim 12 Lindemann teaches the method, wherein establishing the security baseline parameter comprises receiving from the user client device a plurality of authentication factors (see, the rejection for claim 2).
21. Regarding claim 14 Coney teaches method, wherein the method further comprises, using the at least a processor, deleting the health record upon the secure communication channel interface terminating (see, the rejection for claim 3).
22. Regarding claim 15 Coney teaches method, wherein the method further comprises, using the at least a processor, receiving from the user client device a recorded session datum (see, the rejection for claim 5).
23. Regarding claim 16 Lindemann teaches the method, wherein the method further comprises, using the at least a processor, requesting from the user client device a plurality of authentication factors as a function of a change in the security baseline parameter (see, the rejection for claim 6).
24. Regarding claim 17 Coney teaches method, wherein the method further comprises, using the at least a processor, transmitting the health record to a health record database (see, the rejection for claim 7).
25. Regarding claim 18 Coney teaches method, wherein the method further comprises, using the at least a processor, receiving from the user client device a health record validation datum (see, the rejection for claim 8)
26. Regarding claim 19 Coney teaches method, wherein the user client device a health record validation datum is received as a function of user input (see, the rejection for claim 9).
27. Regarding claim 20 Lindemann teaches the method, wherein the method further comprises, using the at least a processor, alerting a security professional as a function of a change in the security baseline parameter (see, the rejection for claim 10).
.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DEREENA T CATTUNGAL whose telephone number is (571)270-0506. The examiner can normally be reached Mon-Fri : 7:30 AM-5 PM EST.
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, Lynn Feild can be reached at 571-272-2092. 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.
/DEREENA T CATTUNGAL/Primary Examiner, Art Unit 2431