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 .
Specification
The disclosure is objected to because of the following informalities:
In paragraph [0036], “read existing user data and electronically share it other entities” should read “read existing user data and electronically share it with other entities.”
In paragraph [0038], “such as one or more HCRs, that that belongs to” should read “such as one or more HCRs, that belongs to.”
In paragraph [0042], “authentication server 164” should read “authentication server 130.”
In paragraph [0042], “As shown by arrows 164 and 166” should read “As shown by arrows 165 and 166.”
In paragraph [0042], “either directly or vis confirmation” should read “either directly or via confirmation.”
In paragraph [0058], “whichever is operation g device 104” should read “whichever is operating device 104.”
In paragraph [0089], “location of the user data reverenced” should read “location of the user data referenced.”
In paragraph [0090], “decrypting the encrypted user data associated that is with the data claim 110 and stored the encrypted datastore” should read “decrypting the encrypted user data associated with the data claim 110 and stored in the encrypted datastore.”
In paragraph [0091], “how and/or where forward the decrypted user data” should read “how and/or where to forward the decrypted user data.”
In paragraph [0097], “location of the user data reverenced” should read “location of the user data referenced.”
In paragraph [0098], “stored the encrypted datastore” should read “stored in the encrypted datastore.”
In paragraph [0099], “how and/or where forward the second decrypted user data” should read “how and/or where to forward the second decrypted user data.”
Appropriate correction is required.
Claim Objections
Claim 1 is objected to because of the following informalities:
In claim 1, “to access and the share user data” should read “to access and share the user data.”
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1, 10, and 19, the claims recite “responsive to a user accessing the authentication server”. It is unclear if “a user” is the same “user” recited earlier in the claims, therefore, the claim is rendered indefinite. For the purpose of examination, the claim will be interpreted as “responsive to the user accessing the authentication server.” Claims 2-9, 11-18, and 20 inherit this rejection.
Regarding claims 1, 10, and 19, the claims recite “reconfirm with the user that it is still desired for the surrogate to act as a digital proxy for the user”. It is unclear if “a digital proxy” is the same digital proxy recited earlier in the claims, therefore, the claim is rendered indefinite. For the purpose of examination, the claim will be interpreted as “reconfirm with the user that it is still desired for the surrogate to act as the digital proxy for the user.” Claims 2-9, 11-18, and 20 inherit this rejection.
Regarding claims 1, 10, and 19, the claims recite “confirmed to approve acting a digital proxy for the user, and reconfirmed by the user to act as a digital proxy”. It is unclear if “a digital proxy” is the same digital proxy recited earlier in the claims, therefore, the claim is rendered indefinite. For the purpose of examination, the claim will be interpreted as “confirmed to approve acting as the digital proxy for the user, and reconfirmed by the user to act as the digital proxy.” Claims 2-9, 11-18, and 20 inherit this rejection.
Regarding claim 1, the claim recites “receive user data from the user after authentication”. It is unclear if “user data” is the same user data recited earlier in the claims. For the purpose of examination, the claim will be interpreted as “receive the user data from the user after authentication.” Claims 2-9, 11-18, and 20 inherit this rejection.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Number 12,430,463 B1 to Witchey et al. (Witchey) in view of US 20160308877 A1 to Kantor et al. (Kantor), and in further view of US 20180150650 A1 to Saunders et al. (Saunders).
Regarding claim 1, Witchey teaches a system for adding a surrogate as a digital proxy to user data associated with a user and sharing the user data by the surrogate, the system comprising: an authentication server (Witchey Col. 6, lines 24-53, e.g., private data exchange server 120) comprising memory, storage, and a processor (Witchey Col. 6, lines 24-53, e.g., Server 120 may operate between entity 102 and entity 104 to broker permissions via execution of software instructions 132 stored in at least one non-transitory, computer-readable memory 130 on at least one processor 122; Col. 47, lines 4-22, e.g., Computer systems 402, 404 and 406 may include clients and servers (e.g., device 103, requestor device 105, server 120, a computing node that provides record-keeping system functionalities, a computing node that hosts a database)…… Various aspects and functions may be implemented as specialized hardware or software executing in one or more computer systems including the computer system 402 shown in FIG. 4. As depicted, the computer system 402 includes a processor 410, a memory 420, a bus 430, an interface 450 and a storage system 440) configured to: responsive to a user accessing the authentication server via a user interface, authenticate the user to achieve an authenticated user (Witchey Col. 7, 8, lines 51-67, 1-6, e.g., Typically, entity 102 is represented in the system via one or more of authorization identifiers 112, by which the system can recognize entity 102. Authorization identifier 112 can be single valued or multivalued depending on the desired implementation…… authorization identifier 112 can also include other record-keeping system identifiers, usernames, passwords); [responsive to a receiving a surrogate add request via the user interface from the authenticated user, generate a single-use temporary link to the authentication server; responsive to the authentication server being accessed via the single-use temporary link: verify an identity of the surrogate; confirm that the surrogate approves acting as a digital proxy for the user; and reconfirm with the user that it is still desired for the surrogate to act as a digital proxy for the user; responsive to the surrogate being verified in identity, confirmed to approve acting a digital proxy for the user, and reconfirmed by the user to act as a digital proxy, add the surrogate to the authentication server as digital proxy authorized to access and the share user data associated with the user]; receive user data from the user after authentication of the user by the authentication server (Witchey Col. 7, lines 35-50, e.g., Generally, entity 102 can own, obtain, process, or manage private data related to entity 102 or to another entity (e.g., to a customer of entity 102, an end user of a service provided by entity 102, etc.), where this data is private and/or sensitive in nature and is to be secured against unauthorized access…… Thus, in some embodiments, entity 102 might not have direct access to the computing systems that house records 114 and thus require computer device 103 to control records 114); use a private key to store the user data in an encrypted state in an encrypted datastore (Witchey Col. 22, lines 52-67, e.g., Keys 272 represent any required cryptographic keys that may be necessary to access fields-values 216 or other private data values in embodiments where the private data is secured via encryption), wherein the private key is shared with the authentication server and associated with the user (Witchey Col. 23, lines 1-7, e.g., Some of the keys 272 may be an authentication key(s) of the authorized entity and/or a data access key of the owner of DAT 250; Col. 10, lines 46-67, e.g., server 120 constructs or otherwise instantiates data access token (DAT) 150 in memory 130; Fig. 2, e.g., Data Access Token 250, Key(s) 272); and responsive to the surrogate accessing the authentication server, being authenticated by the authentication server (Witchey Col. 33, lines 33-61, e.g., Authenticating the token owner may have varying degrees of complexity. In more simple cases, the token owner may be authenticated via a username-password pair to enable the token owner to log into the private data exchange server, which in turn has access to the DAT and its corresponding DAAPs via the record-keeping system), and providing a valid data claim from a third- party application (Witchey Col. 8, lines 7-41, e.g., In the example shown, entity 104 transmits request 124 over network 115 from a requestor device 105 to private data exchange server 120. Request 124 includes one or more fields of interest 126 related to the fields in records 114…… Entity 104 makes their request via one or more of requestor device 105, which is shown as a cell phone or mobile device. Still, requestor device 105 can comprise any practical computing device with suitable software including a dedicated appliance), generate, by the authentication server, a single-use datastore token (Witchey Col. 8, lines 7-27, e.g., In response, private data exchanges server 120 causes one or more data access tokens (DATs) 150 to be instantiated or otherwise generated, possibly upon any required authorization of entity 102; Col. 11, 12, lines 54-67, 1-2, e.g., DAT 150 represents a persistent permission or right that exists until DAT 150 is consumed, burned, or otherwise used by the owner of DAT 150), wherein the single-use datastore token: identifies the encrypted datastore from a plurality of encrypted datastores (Witchey Col. 23, lines 23-36, e.g., Crypto protocols 275 comprises a list of required or optional protocols for accessing the requested private data values. Protocols 275 are typically network protocols in view that private data may be located on a remote data source (see private database 110 in FIG. 1)…… Typical end points of such protocols may include… the remote private database); provides instructions for decrypting encrypted user data associated with the valid data claim and stored in the encrypted datastore to achieve decrypted user data (Witchey Col. 24 lines 48-62, e.g., DAAP 270 may further include other features beyond cryptographic capabilities that may also contribute to or facilitate accessing private data values. For example, instructions 278 can comprise one or more software suites or application programs that could be executed by the device of the token owner to operate on the values of the requested fields), wherein the decrypted user data is the same as the user data received from the user (Witchey Col. 22, 23, lines 52-67, 1-7, e.g., Keys 272 represent any required cryptographic keys that may be necessary to access fields-values 216 or other private data values in embodiments where the private data is secured via encryption…… Thus, the token owner can then use their own keys to access keys 272 and in turn use keys 272 to obtain access to the request private data values); and provides direction to the encrypted datastore for how to forward the decrypted user data to the third-party application (Witchey Col. 34, lines 26-41, e.g., Recall that the DAAP (the data access activation protocol) comprises necessary or sufficient instructions for one or more of the token owner's devices that enable the devices to gain access to the private data values from the requested private records; Col. 35, lines 1-17, e.g., Thus, through proper encryption, the data may be transferred securely to the token owner's devices or may be securely stored in the memory of the device, possibly in a secured memory; Also see Col. 34-36, lines 26-67, 1-67, and 1-36, for more examples of directions to access the private data); and a data storage server (Witchey Col. 47, lines 4-22, e.g., a computing node that hosts a database) comprising memory, storage, and a processor (Witchey Col. 47, lines 4-22, e.g., Computer systems 402, 404 and 406 may include clients and servers (e.g., device 103, requestor device 105, server 120, a computing node that provides record-keeping system functionalities, a computing node that hosts a database)…… Various aspects and functions may be implemented as specialized hardware or software executing in one or more computer systems including the computer system 402 shown in FIG. 4. As depicted, the computer system 402 includes a processor 410, a memory 420, a bus 430, an interface 450 and a storage system 440) and configured to: employ, by the encrypted datastore located on the data storage server (Witchey Col. 6, lines 54-67, e.g., System includes one or more of private database 110, which comprises a computing device configured to store private data, records 114 for example), the decryption instructions of the single-use datastore token to decrypt encrypted user data associated with the data claim and stored in the encrypted datastore to achieve the decrypted user data (Witchey Col. 34, lines 26-41, e.g., Recall that the DAAP (the data access activation protocol) comprises necessary or sufficient instructions for one or more of the token owner's devices that enable the devices to gain access to the private data values from the requested private records); and send, by the encrypted datastore located on the data storage server, the decrypted user data to the third-party application according to the direction of the single-use datastore token for how and where to forward decrypted user data (Witchey Col. 35, lines 1-17, e.g., Thus, through proper encryption, the data may be transferred securely to the token owner's devices or may be securely stored in the memory of the device, possibly in a secured memory; Also see Col. 34-36, lines 26-67, 1-67, and 1-36, for more examples of directions to access the private data).
Witchey does not explicitly teach, but Kantor teaches responsive to a receiving a surrogate add request via the user interface from the authenticated user, generate a single-use temporary link to the authentication server (Kantor Fig. 10, e.g., 1002 and 1004; [0086], e.g., Selected recipients are determined for a sharing link to an item maintained in online storage (block 1002). One way this may occur is through a user interface provided to enable sending of a link to one or more recipients. For example, the collaboration service 124 may output a user interface 122 accessible by a client device 102 over a network 110. The user interface 122 may be output in response to a selection of a send a link control to share a particular content item. The user interface 122 enables a user to select one or more recipients, input known contact info, and/or submit a request to send a link to the one or more recipients); responsive to the authentication server being accessed via the single-use temporary link (Kantor Fig. 11, e.g., 1102, 1110-1114; [0095], e.g., Selection of a one-time sharing link for a shared item is detected (block 1102). A determination is made regarding whether the link involves a sign-in to gain access to the shared item (block 1104)): verify an identity of the surrogate (Kantor [0097], e.g., Both when the link requires sign-in per block 1104 and when action requiring sign-in is detected per block 1108, a determination is made as to whether the user is already signed-in (block 1110). If the user is not already signed-in, the user is redirected to login (block 1112) and the user is authenticated to a selected account (block 1114). This may occur through the collaboration service 124 and/or an authentication service accessible via the service provider 102 using any suitable authentication techniques. In general, the user provides credentials (e.g., username and password) to access and account which are verified to ensure that the user is who they claim to be); confirm that the surrogate approves acting as a digital proxy for the user (Kantor Fig. 11, e.g., 1126; [0101], e.g., If the auto-redeem option is not set, though, an account selection dialog (e.g. redeem dialog) prompting the user to select an account is output (block 1128). Based on input obtained via the account selection dialog, a determination is made regarding whether to use the current account or select another account (block 1130); Fig. 13, e.g., Please confirm the account you would like to use to access the share item); [and reconfirm with the user that it is still desired for the surrogate to act as a digital proxy for the user;] responsive to the surrogate being verified in identity, confirmed to approve acting a digital proxy for the user, [and reconfirmed by the user to act as a digital proxy,] add the surrogate to the authentication server as digital proxy authorized to access and the share user data associated with the user (Kantor Fig. 11, e.g., 1120; [0098], e.g., If so, the one-time sharing link is redeemed (block 1118) and access to the shared item is provided with authenticated permissions (block 1120). In this case, an assumption may be made that the user prefers to use the current account that already has permissions on the shared item. As such, access is granted without prompting to select a different account. In an alternate approach, a switch account option may be provided to enable the user to switch accounts even if the user already has authenticated access per block 1116; [0039], e.g., The permissions designate access levels and corresponding actions for content items. For instance, different access levels may be established to control who is able to perform actions such as read-only, print, publish, view, edit, one-time access, move, and/or copy, to name a few examples).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the teachings of Witchey with the teachings of Kantor with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of flexibility and convenience (Kantor [0023], e.g., a user may have to manually attach items to messages and/or publish an item to multiple different services/sites…… Thus, traditional techniques for sharing items from online storage may be inconvenient; [0024], e.g., Techniques for sharing of items from online storage (e.g., cloud storage) are described herein. In one approach, distinct sharing links to an item can be generated for multiple different publish targets through a single publishing user interface exposed to a user. Through the publishing user interface, a user may submit a request having a selection of different social networks and/or other sites/targets to receive a sharing link for an item. In response to the request, a distinct sharing link is generated for each selected recipient and the generated sharing links are published to appropriate targets. Thus, a user is able to easily send links for a shared item to multiple targets through a single request and can separately manage permissions associated with each distinct sharing link).
Witchey and Kantor do not explicitly teach, but Saunders teaches to reconfirm with the user that it is still desired for the surrogate to act as a digital proxy for the user (Saunders [0380]-[0381], e.g., process 2200 determines if the invitation is accepted or rejected by the invitee…… Continuing at state 2265, process 2200 sends an acceptance notification to the original owner requestor via an electronic communication channel (e.g., email). Moving to state 2270, the owner requestor selects the URL corresponding to the invitee in the email and then as determined at a decision state 2275 either grants or confirms the acceptance by the invitee or cancels the invitation).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to have modified the combined teachings of Witchey and Kantor with the teachings of Saunders with reasonable expectation of success. One of ordinary skill in the art would have been motivated to make the modification for the benefit of preventing new invitation from being sent to users that have already been registered/invited (Saunders [0371], e.g., Process 1900 moves to a decision state 1915 to determine if there is an existing connection with the guest having the electronic address entered at state 1910. In certain embodiments, this check is always made. It prevents a new invitation being sent to someone who already has a connection or invite;
Regarding claim 2, most of the limitations of this claim have been noted in the rejection of claim 1. Witchey further teaches responsive to the surrogate of the user accessing the authentication server, being authenticated by the authentication server (Witchey Col. 33, lines 33-61, e.g., Authenticating the token owner may have varying degrees of complexity. In more simple cases, the token owner may be authenticated via a username-password pair to enable the token owner to log into the private data exchange server, which in turn has access to the DAT and its corresponding DAAPs via the record-keeping system), and providing a second valid data claim from a second third-party application (Witchey Col. 8, lines 7-41, e.g., In the example shown, entity 104 transmits request 124 over network 115 from a requestor device 105 to private data exchange server 120. Request 124 includes one or more fields of interest 126 related to the fields in records 114…… Entity 104 makes their request via one or more of requestor device 105, which is shown as a cell phone or mobile device. Still, requestor device 105 can comprise any practical computing device with suitable software including a dedicated appliance), the authentication server being further configured to generate a second single-use datastore token (Witchey Col. 8, lines 7-27, e.g., In response, private data exchanges server 120 causes one or more data access tokens (DATs) 150 to be instantiated or otherwise generated, possibly upon any required authorization of entity 102; Col. 11, 12, lines 54-67, 1-2, e.g., DAT 150 represents a persistent permission or right that exists until DAT 150 is consumed, burned, or otherwise used by the owner of DAT 150), wherein the second single-use datastore token: identifies the encrypted datastore from a plurality of encrypted datastores (Witchey Col. 23, lines 23-36, e.g., Crypto protocols 275 comprises a list of required or optional protocols for accessing the requested private data values. Protocols 275 are typically network protocols in view that private data may be located on a remote data source (see private database 110 in FIG. 1)…… Typical end points of such protocols may include… the remote private database); provides instructions for decrypting second encrypted user data associated with the second valid data claim and stored in the encrypted datastore to achieve second decrypted user data (Witchey Col. 24 lines 48-62, e.g., DAAP 270 may further include other features beyond cryptographic capabilities that may also contribute to or facilitate accessing private data values. For example, instructions 278 can comprise one or more software suites or application programs that could be executed by the device of the token owner to operate on the values of the requested fields); and provides direction to the encrypted datastore for how to forward the second decrypted user data to the second third-party application (Witchey Col. 34, lines 26-41, e.g., Recall that the DAAP (the data access activation protocol) comprises necessary or sufficient instructions for one or more of the token owner's devices that enable the devices to gain access to the private data values from the requested private records; Col. 35, lines 1-17, e.g., Thus, through proper encryption, the data may be transferred securely to the token owner's devices or may be securely stored in the memory of the device, possibly in a secured memory; Also see Col. 34-36, lines 26-67, 1-67, and 1-36, for more examples of directions to access the private data); the encrypted datastore (Witchey Col. 6, lines 54-67, e.g., System includes one or more of private database 110, which comprises a computing device configured to store private data, records 114 for example) being configured to employ the decryption instructions of the second single-use datastore token to decrypt second encrypted user data associated with the second valid data claim and stored in the encrypted datastore to achieve the second decrypted user data (Witchey Col. 34, lines 26-41, e.g., Recall that the DAAP (the data access activation protocol) comprises necessary or sufficient instructions for one or more of the token owner's devices that enable the devices to gain access to the private data values from the requested private records); and send the second decrypted user data to the second third-party application according to the direction of the second single-use datastore token for how and where to forward second decrypted user data (Witchey Col. 35, lines 1-17, e.g., Thus, through proper encryption, the data may be transferred securely to the token owner's devices or may be securely stored in the memory of the device, possibly in a secured memory; Also see Col. 34-36, lines 26-67, 1-67, and 1-36, for more examples of directions to access the private data).
Regarding claim 3, most of the limitations of this claim have been noted in the rejection of claim 2. Witchey further teaches wherein the third-party application is a healthcare application (Witchey Col. 43, lines 50-59, e.g., A token owner (e.g., entity 104 of FIG. 1) can be an entity having access rights, as specified in a DAT, to access or interact with one or more of a patient data record, where the access rights are permitted by the authorized entity. For instance, the token owner is a doctor who wishes to access a patient's medical data (i.e., records 114); Col. 8, lines 27-41, e.g., Entity 104 makes their request via one or more of requestor device 105, which is shown as a cell phone or mobile device. Still, requestor device 105 can comprise any practical computing device with suitable software including a dedicated appliance).
Regarding claim 4, most of the limitations of this claim have been noted in the rejection of claim 2. Witchey further teaches wherein the second third-party application is a healthcare application (Witchey Col. 43, lines 50-59, e.g., A token owner (e.g., entity 104 of FIG. 1) can be an entity having access rights, as specified in a DAT, to access or interact with one or more of a patient data record, where the access rights are permitted by the authorized entity. For instance, the token owner is a doctor who wishes to access a patient's medical data (i.e., records 114); Col. 8, lines 27-41, e.g., Entity 104 makes their request via one or more of requestor device 105, which is shown as a cell phone or mobile device. Still, requestor device 105 can comprise any practical computing device with suitable software including a dedicated appliance; Note multiple tokens can be created and each token can be owned by a different entity).
Regarding claim 5, most of the limitations of this claim have been noted in the rejection of claim 4. Witchey further teaches wherein the second third-party application is a second healthcare application which is different from the healthcare application (Witchey Col. 43, lines 50-59, e.g., A token owner (e.g., entity 104 of FIG. 1) can be an entity having access rights, as specified in a DAT, to access or interact with one or more of a patient data record, where the access rights are permitted by the authorized entity. For instance, the token owner is a doctor who wishes to access a patient's medical data (i.e., records 114); Col. 8, lines 27-41, e.g., Entity 104 makes their request via one or more of requestor device 105, which is shown as a cell phone or mobile device. Still, requestor device 105 can comprise any practical computing device with suitable software including a dedicated appliance; Note multiple tokens can be created and each token can be owned by a different entity).
Regarding claim 6, most of the limitations of this claim have been noted in the rejection of claim 2. Witchey further teaches wherein the second third-party application is an insurance application (Witchey Col. 43, lines 50-59, e.g., However, the token owner could be an insurance company; Col. 8, lines 27-41, e.g., Entity 104 makes their request via one or more of requestor device 105, which is shown as a cell phone or mobile device. Still, requestor device 105 can comprise any practical computing device with suitable software including a dedicated appliance).
Regarding claim 7, most of the limitations of this claim have been noted in the rejection of claim 2. Witchey further teaches wherein the second third-party application is a financial services application (Witchey Col. 43, lines 60-67, e.g., However, the inventive subject matter can also apply to other sectors beyond healthcare, including those sectors where retaining control over private data is also important. Additional example areas that would benefit from the use of tokens to manage private data include those involving military applications, financial applications).
Regarding claim 8, most of the limitations of this claim have been noted in the rejection of claim 1. Witchey further teaches wherein the single-use datastore token includes the private key provided for decryption of encrypted user data in the encrypted datastore (Witchey Fig. 2, e.g., Data Access Token (DAT) 250, Key(s) 272 and Col. 22, lines 52-67, e.g., Keys 272 represent any required cryptographic keys that may be necessary to access fields-values 216 or other private data values in embodiments where the private data is secured via encryption).
Regarding claim 9, most of the limitations of this claim have been noted in the rejection of claim 1. Witchey further teaches wherein the decrypted user data comprises personal health information of the user (Witchey Col. 43, lines 13-36, e.g., In the healthcare context, records (e.g., 114 described in FIG. 1 and electronic records 288 described in FIG. 2) can comprise patient data records, electronic medical records (EMRs), electronic health records (EHRs), clinical trial data, hospital data, insurance data, payor information, CPT codes, ICD codes, prescription data, histopathology data, outcome data, biometrics, genomic data, real-time telemetry, patient waveform data (e.g., ECG, EKG, ICP, ART, CVP, EtCO2, respiration, etc.), or other types of health or medical data).
Regarding claim 10, the claim recites a method of the system of claim 1, and is similarly analyzed.
Regarding claim 11, the claim recites a method of the system of claim 2, and is similarly analyzed.
Regarding claim 12, the claim recites a method of the system of claim 3, and is similarly analyzed.
Regarding claim 13, the claim recites a method of the system of claim 4, and is similarly analyzed.
Regarding claim 14, the claim recites a method of the system of claim 5, and is similarly analyzed.
Regarding claim 15, the claim recites a method of the system of claim 6, and is similarly analyzed.
Regarding claim 16, the claim recites a method of the system of claim 7, and is similarly analyzed.
Regarding claim 17, the claim recites a method of the system of claim 8, and is similarly analyzed.
Regarding claim 18, the claim recites a method of the system of claim 9, and is similarly analyzed.
Regarding claim 19, Witchey teaches a non-transitory computer-readable storage medium comprising instructions (Witchey Col. 2, 3, lines 64-67, 1-64, e.g., Such systems can include at least one non-transitory computer-readable memory (e.g., SSD, RAM, Flash, HDD, FPGA, PLA, ROM, etc.) storing a suite of one or more sets of software instructions) embodied thereon which, when executed by one or more processors (Witchey Col. 2, 3, lines 64-67, 1-64, e.g., Contemplated systems further include one or more processors) cause the one or more processors to perform a method (Witchey Col. 2, line 58-63, e.g., The inventive subject matter provides apparatus, systems and methods in which private digital data may be accessed or otherwise managed via one or more digital access tokens (DATs) via which data owners retain control over their private data while also permitting others to access the data owner's private data). The rest of the claim recites a non-transitory computer-readable storage medium performing the method of claim 10, and is similarly analyzed.
Regarding claim 20, the claim recite a non-transitory computer-readable storage medium performing the method of claim 11, and is similarly analyzed
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 20120185921 A1 to Wechsler et al. discloses a user authenticating into a system and an owner authenticating into a system. The user request for sensitive information from the owner. The owner receives an alert for access and either approves or denies the user request. Once the owner approves or denies the user request, the user is notified and subsequently allowed/denied access to the sensitive data.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAWRENCE TRUONG whose telephone number is (571)272-6973. The examiner can normally be reached Monday - Friday, 8:00 am - 4 pm ET.
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, Ali Shayanfar can be reached at (571) 270-1050. 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.
/LAWRENCE TRUONG/Examiner, Art Unit 2434
/ALI SHAYANFAR/Supervisory Patent Examiner, Art Unit 2434
Prosecution Insights