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 .
Response to Arguments
In response to 35 USC 103, to independent claims 1, 9, and 17 along with their respective dependent claims, applicant argues, filed 06/10/2026, that the references fails to teach “determining, at the device, a confidence assessment for the verified claim locally-stored on, and specific to, the device based on a comparison between the plural data fields in the verified claim locally stored on, and specific to, the device and corresponding data locally-stored on the device, the data locally-stored on the device being based at least in part on use of the device by the user prior to sending the request for the service and the data locally-stored on the device comprising information corresponding to the plural data fields including the at least one of the name or the physical address of the user of the device”.
During the interview, the possible amendment with user device appear to overcome [0075] of Miu due to fact that [0075] uses a server. However, under further review and consideration. Miu does teach wherein determining the confidence assessment comprises deriving, by the user device and from the data locally-stored on the user device, a value corresponding to the at least one of the name or physical address of the user of the user device, and comparing another value of the at least one of the name or the physical address in the verified claim with the value derived by the user device from the data locally-stored on the user device.
Miu teaches “wherein determining the confidence assessment comprises deriving, by the user device and from the data locally-stored on the user device, a value corresponding to the at least one of the name or physical address of the user of the user device, and comparing another value of the at least one of the name or the physical address in the verified claim with the value derived by the user device from the data locally-stored on the user device”. Miu recites “when a provider 112 arrives at a patient's house, the provider 112 can use a camera included in the provider device 110 to obtain one or more images of an identification document 134 of the patient 130. For example, the provider 112 may ask the patient 130 to present the patient's identification document (e.g., driver's license) and then use the camera of the provider device 110 to obtain an image of a front side and an image of a back side of the patient's driver's license. While a driver's license is used in this example and various examples below, other types of ID documents can similarly be used instead of a driver's license. The provider device 110 can use the images to determine a confidence of an identity of the patient 130. For example, the provider device 110 can determine a 33%, 66%, 100%, or some other confidence that the patient 130 is who they say they are [0043]. The provider device 110 can determine a confidence of an identity of the patient 130 through verifying (i) that an identification document 134 includes particular visual security features, (ii) that human-readable textual information on a front side of the identification document 134 matches information encoded in a machine-readable code on a back side of the identification document [0044]. A government-issued ID such as an ID or driver's license can be used to assert ones identity, and a biometric, e.g., facial, fingerprint, retina, etc., can be processed to ensure the proper assignment of the identity credential itself. In some implementations, the authenticity of the ID is also verified against a third party system (e.g., a system associated with the issuer of the ID). This identity data can be stored locally on a mobile phone of a provider or on a server, or split across both [0037]. the provider device 110 can output “Identity of patient John Doe sufficiently determined, please go ahead and provide service.” In another example, the provider device 110 can output on a display “Identity of patient John Doe insufficiently determined, please re-try verifying identity” [0050] [0055]. the patient 130 can be worried whether the provider 112 is actually who the provider 112 says they are and are qualified to provide a particular service, and use the patient device 132 to verify that the provider 112 can provide the particular service. Accordingly, the patient device 132 can function similarly to the provider device 110 but instead of scanning the patient's identification document 134, scan the provider's identification document 114 to determine a confidence of the provider's identity [0056]. The provider device 110 can have providers initially input information that identifies the childcare facility, and then scan the identification document of the parent. The provider device 110 can then provide the confidence of identity and facility information to the verification server 120 [0057] Fig. 2”. Miu shows confidence assessment comparing the name or address of the user from the verified claim and data locally stored. Miu does contain locally-stored data. Miu shows verifying the identity of the patient or provider.
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 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.
Claims 1, 2, 4-5, 9, 10, 12-13, 14, 17-18, 20 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (US 20160365984, hereinafter Lee) in view of Miu (US 20190042719), Hawes et al. (US 10754936, hereinafter Hawes), and in further view of Khalil et al. (US 20190044940, hereinafter Khalil).
Re. claim 1, Lee discloses a method comprising: sending, by a user associated with a user account and to a service provider, a request for a service provided by the service provider (Lee discloses the user device sends a request for service to the service module 88. The request for service preferably includes the SP-signed certificate received from the sign-up server 30 corresponding to the service provider server 32, i.e., that is part of the same service provider system 18 as the service provider server 32 to which the request is sent [0062]. User device contains sign-up module may provide user information, a username, a password, payment information (e.g., credit card or bank account information), indication of desired service, and/or length of desired subscription to the service, and/or other information [0030]. Fig. 3);
receiving, by the user device, from the service provider and in response to the sending the request for the service, a request for a verified claim that is locally-stored on the user device (Lee discloses the user can request service and the user device will send the SP-signed certificate to a service provider server [0021]. At stage 186, the sign-up module 84 sends the SP-signed certificate (or an indication of the denial of such a certificate) to the user device 12 [0060] (SP-signed certificate interpreted as verified claim)), the verified claim comprising plural data fields to identify a user of the device, the verified claim being specific to the user device, and the verified claim being locally-stored on the user device prior to sending the request for the service (Lee teaches the module 84 is preferably configured to use at least some of the user information to produce the SP certificate. The module 84 may produce the SP certificate to include content and/or formatting that is server specific, user specific, subscription specific, service -provider specific, and/or device specific. User-specific content is information pertaining to (e.g., identifying, associated with, provided by) the user of the user device 12. Device-specific content is information in addition to the device ID and the device public key that is associated with the user device 12 that is used to subscribe to the service (e.g., device manufacturer, device model, one or more device capabilities (e.g., quantity of display pixels), etc.) [0037]. The SP-signed certificate module 86 is configured to receive the signing request from the module 84, with the signing request including the SP certificate, sign the SP certificate to produce an SP-signed certificate, and send the SP-signed certificate to the sign-up module 84 [0038][0060][0010][0024][0029]).
Although Lee discloses verified claim to the service provider, Lee does not explicitly teach but Miu teaches the plural data fields including at least one of a name or a physical address of the user of the device, the data locally-stored on the device comprising information corresponding to the plural data fields including the at least one of the name or the physical address of the user of device (Miu teaches obtain the patient's address from the patient's identification document, the previous care records of the patient, insurance records, or a patient account [0075]. A government-issued ID such as an ID or driver's license can be used to assert ones identity, and a biometric, e.g., facial, fingerprint, retina, etc., can be processed to ensure the proper assignment of the identity credential itself. In some implementations, the authenticity of the ID is also verified against a third party system (e.g., a system associated with the issuer of the ID). This identity data can be stored locally on a mobile phone of a provider or on a server, or split across both [0037][0055][0056][0048][0043]); in response to the receiving, determining, at the user device, a confidence assessment for the verified claim locally- stored on, and specific to, the user device based on a comparison between the plural data fields in the verified claim locally-stored on and corresponding data locally-stored on the user device (Miu teaches the provider device 110 can use the images to determine a confidence of an identity of the patient 130. For example, the provider device 110 can determine a 33%, 66%, 100%, or some other confidence that the patient 130 is who they say they are [0043]. The provider device 110 can determine a confidence of an identity of the patient 130 through verifying (i) that an identification document 134 includes particular visual security features, (ii) that human-readable textual information on a front side of the identification document 134 matches information encoded in a machine-readable code on a back side of the identification document [0044]. The verification server 120 can authenticate the service provider's identity by comparing the service provider's biometric information with biometric information on the identification document 114 [0061] [0037][0051][0059][0080][0006][0024-0026] Fig. 2), wherein determining the confidence assessment comprises deriving, by the user device and from the data locally-stored on the user device, a value corresponding to the at least one of the name or physical address of the user of the user device, and comparing another value of the at least one of the name or the physical address in the verified claim with the value derived by the user device from the data locally-stored on the user device (Miu teaches when a provider 112 arrives at a patient's house, the provider 112 can use a camera included in the provider device 110 to obtain one or more images of an identification document 134 of the patient 130. For example, the provider 112 may ask the patient 130 to present the patient's identification document (e.g., driver's license) and then use the camera of the provider device 110 to obtain an image of a front side and an image of a back side of the patient's driver's license. While a driver's license is used in this example and various examples below, other types of ID documents can similarly be used instead of a driver's license. The provider device 110 can use the images to determine a confidence of an identity of the patient 130. For example, the provider device 110 can determine a 33%, 66%, 100%, or some other confidence that the patient 130 is who they say they are [0043]. The provider device 110 can determine a confidence of an identity of the patient 130 through verifying (i) that an identification document 134 includes particular visual security features, (ii) that human-readable textual information on a front side of the identification document 134 matches information encoded in a machine-readable code on a back side of the identification document [0044]. A government-issued ID such as an ID or driver's license can be used to assert ones identity, and a biometric, e.g., facial, fingerprint, retina, etc., can be processed to ensure the proper assignment of the identity credential itself. In some implementations, the authenticity of the ID is also verified against a third party system (e.g., a system associated with the issuer of the ID). This identity data can be stored locally on a mobile phone of a provider or on a server, or split across both [0037]. the provider device 110 can output “Identity of patient John Doe sufficiently determined, please go ahead and provide service.” In another example, the provider device 110 can output on a display “Identity of patient John Doe insufficiently determined, please re-try verifying identity” [0050] [0055]. the patient 130 can be worried whether the provider 112 is actually who the provider 112 says they are and are qualified to provide a particular service, and use the patient device 132 to verify that the provider 112 can provide the particular service. Accordingly, the patient device 132 can function similarly to the provider device 110 but instead of scanning the patient's identification document 134, scan the provider's identification document 114 to determine a confidence of the provider's identity [0056]. The provider device 110 can have providers initially input information that identifies the childcare facility, and then scan the identification document of the parent. The provider device 110 can then provide the confidence of identity and facility information to the verification server 120 [0057] Fig. 2, Miu shows confidence assessment comparing the name or address of the user from the verified claim and data locally stored), and sending, by the user device, the confidence assessment and the verified claim to the service provider (Miu teaches the provider device 110 can provide an indication of the confidence to the verification server 120 and, in response, receive an indication whether the provider 112 should provide service to the patient 130. The provider device can provide an indication to the verification server 120 that (i) an identification document does include particular visual security features [0046]); and accessing, by the user device, the service provided by the service provider based at least in part on the sending of the confidence assessment (Miu teaches the provider device 110 can provide an indication of the confidence to the verification server 120 and, in response, receive an indication whether the provider 112 should provide service to the patient 130. receive an indication that the patient 130 is eligible to receive a service from the provider 112 [0046]).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by Lee to include the plural data fields including at least one of a name or a physical address of the user of the device, the data locally-stored on the device comprising information corresponding to the plural data fields including the at least one of the name or the physical address of the user of device in response to the receiving, determining, at the device, a confidence assessment for the verified claim locally- stored on, and specific to, the device based on a comparison between the plural data fields in the verified claim and corresponding data locally-stored on the device, wherein determining the confidence assessment comprises deriving, by the user device and from the data locally-stored on the user device, a value corresponding to the at least one of the name or physical address of the user of the user device, and comparing another value of the at least one of the name or the physical address in the verified claim with the value derived by the user device from the data locally-stored on the user device, and sending, by the device, the confidence assessment and the verified claim to the service provider; and accessing, by the device, the service provided by the service provider based at least in part on the sending of the confidence assessment as disclosed by Miu. One of ordinary skill in the art would have been motivated for the purpose of determining how trustworthy the user is, improves security purposes such as id validation (Miu [0084]).
Although Miu discloses the device based on a comparison between the plural data fields in the verified claim and corresponding data locally-stored on the device, the combination of Lee-Miu do not explicitly teach but Hawes teaches the data locally-stored on the user device being based at least in part on use of the user device by the user prior to sending the request for the service (Hawes teaches comparing the user’s current behavioral characteristics against the stored behavioral characteristics may be utilized to generate a challenge level for the user to authenticate himself/herself[Col 7 lines 53-67][Col 8 lines 11-21][Col 8 lines 37-63][Col 9 lines 7-19] [Col 13 lines 38-57]).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by the combination of Lee-Miu to include the data locally-stored on the device being based at least in part on use of the device by the user as disclosed by Hawes. One of ordinary skill in the art would have been motivated for the purpose of gathering enough identifying information to provide enough confidence in a user’s identity (Hawes [Col 1 lines 26-35]).
Although the combination of Lee-Miu-Hawes discloses that digital certificate is signed by a server, the combination of Lee-Miu-Hawes do not explicitly teach but Khalil teaches the verified claim comprising a signature of a server that is separate from the service provider (Khalil teaches signing the authentication challenge and the digital certificate to the identity management service device [0019] Figs 1a and 1b, Fig. 1b shows a separate server and service provider).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by the combination of Lee-Miu-Hawes to include being a digital certificate signed by a server that is independent of the service provider as disclosed by Khalil. One of ordinary skill in the art would have been motivated for the purpose of to authenticate the identity of the user of the user device (Khalil [0019] [0021]).
Re. claim 2, the combination of Lee-Miu-Hawes-Khalil teach the method of claim 1, further comprising: receiving the verified claim from the server, wherein the verified claim is generated by the server based on verification of the plural data fields by an identity verification provider (Lee discloses the request for service preferably includes the SP-signed certificate received from the sign-up server 30 corresponding to the service provider server 32. the service module 88 authenticates the SP-signed certificate, determines whether the requested service is subscribed to (e.g., paid for), and if so, provides the subscribed-to service to the user device [0061]).
Re. claim 4, the combination of Lee-Miu-Hawes-Khalil teach the method of claim 1, Hawes further teaches prompting, prior to the determining, the user for authorization to access the data locally- stored on the user device; and receiving, in response to the prompting, user input authorizing access to the data locally- stored on the user device (Hawes teaches the user may be prompted to enter the mark prior to accessing sensitive information or carrying out certain activities during a session [Col 5 lines 1-10][Col 6 lines 9-32] [Col 13 lines 38-57]).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by the combination of Lee-Miu to include prompting, prior to the determining, the user for authorization to access the data locally- stored on the user device; and receiving, in response to the prompting, user input authorizing access to the data locally- stored on the user device as disclosed by Hawes. One of ordinary skill in the art would have been motivated for the purpose of gathering enough identifying information to provide enough confidence in a user’s identity (Hawes [Col 1 lines 26-35]).
Re. claim 5, the combination of Lee-Miu-Hawes-Khalil teach the method of claim 1, Lee do not explicitly teach but Miu teaches wherein the service provider is configured to authenticate the user for service based on the verified claim and the confidence assessment (Miu teaches the verification server 120 can send the image(s) of the service provider's identification document 114 to the third party verification server 122 to confirm the authenticity of the identification document. the third party verification server 122 can send data to the verification server 120 that indicates whether the identification document 114 is authentic [0060]. The verification server 120 can authenticate the service provider's identity by comparing the service provider's biometric information with biometric information on the identification document 114. For example, the verification server 120 can compare an image of the service provider (as included in the service provider ID verification information) to an image (e.g., a portrait) on the identification document 114. As another example, the verification server 120 can compare an image of the service provider's finger print (as included in the service provider ID verification information) to a fingerprint on the identification document [0061]. the verification server 120 provides the provider device 110 with access to a record of services to be provided to the patient 130 in response to authorizing the visit [0067][0052]).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by Lee to include the service provider is configured to authenticate the user for service based on the verified claim and the confidence assessment as disclosed by Miu. One of ordinary skill in the art would have been motivated for the purpose of determining how trustworthy the user is, improves security purposes such as id validation (Miu [0084]).
Re. claim 9, Lee discloses a user device, comprising: at least one processor (Lee discloses processor [0026]); and a memory including instructions that, when executed by the at least one processor (memory 42 is a processor-readable storage medium that may store the software 48 which is processor-readable, processor-executable software code containing instructions that are configured to, when executed, cause the processor 40 to perform various functions [0026]), cause the at least one processor to: send, to a service provider, a request for a service provided by the service provider (The user device sends a request for service to the service module 88. The request for service preferably includes the SP-signed certificate received from the sign-up server 30 corresponding to the service provider server 32, i.e., that is part of the same service provider system 18 as the service provider server 32 to which the request is sent [0062]);
receive, from the service provider and in response to the sending the request for the service, a request for a verified claim that is locally stored on the user device (The user can request service and the user device will send the SP-signed certificate to a service provider server [0021]. At stage 186, the sign-up module 84 sends the SP-signed certificate (or an indication of the denial of such a certificate) to the user device 12 [0060] (SP-signed certificate interpreted as verified claim)), the verified claim comprising plural data fields to identify a user of the user device, the verified claim being associated with to the user device, and the verified claim being locally-stored on the device prior to sending the request for the service (The module 84 is preferably configured to use at least some of the user information to produce the SP certificate. The module 84 may produce the SP certificate to include content and/or formatting that is server specific, user specific, subscription specific, service -provider specific, and/or device specific. User-specific content is information pertaining to (e.g., identifying, associated with, provided by) the user of the user device 12. Device-specific content is information in addition to the device ID and the device public key that is associated with the user device 12 that is used to subscribe to the service (e.g., device manufacturer, device model, one or more device capabilities (e.g., quantity of display pixels), etc.) [0037]. The SP-signed certificate module 86 is configured to receive the signing request from the module 84, with the signing request including the SP certificate, sign the SP certificate to produce an SP-signed certificate, and send the SP-signed certificate to the sign-up module 84 [0038][0060][0010][0024][0029]).
Although Lee discloses verified claim to the service provider, Lee does not explicitly teach but Miu teaches the plural data fields including at least one of a name or a physical address of the user of the device, the data locally-stored on the user device comprising information corresponding to the plural data fields including the at least one of the name or the physical address of the user of the user device (Miu teaches obtain the patient's address from the patient's identification document, the previous care records of the patient, insurance records, or a patient account [0075][0055][0056][0048][0043][0037]); in response to the receiving, determine a confidence assessment for the verified claim locally-stored on, and associated with, the device based on a comparison between the plural data fields in the verified claim locally-stored on the user device and corresponding data locally-stored on the user device (Miu teaches the provider device 110 can use the images to determine a confidence of an identity of the patient 130. For example, the provider device 110 can determine a 33%, 66%, 100%, or some other confidence that the patient 130 is who they say they are [0043]. The provider device 110 can determine a confidence of an identity of the patient 130 through verifying (i) that an identification document 134 includes particular visual security features, (ii) that human-readable textual information on a front side of the identification document 134 matches information encoded in a machine-readable code on a back side of the identification document [0044]. The verification server 120 can authenticate the service provider's identity by comparing the service provider's biometric information with biometric information on the identification document 114 [0061] [0037][0051][0059][0080][0006][0024-0026]. Fig. 2), wherein determining the confidence assessment comprises deriving, by the user device and from the data locally-stored on the user device, a value corresponding to the at least one of the name or physical address of the user of the user device, and comparing another value of the at least one of the name or the physical address in the verified claim with the value derived by the user device from the data locally-stored on the user device (Miu teaches when a provider 112 arrives at a patient's house, the provider 112 can use a camera included in the provider device 110 to obtain one or more images of an identification document 134 of the patient 130. For example, the provider 112 may ask the patient 130 to present the patient's identification document (e.g., driver's license) and then use the camera of the provider device 110 to obtain an image of a front side and an image of a back side of the patient's driver's license. While a driver's license is used in this example and various examples below, other types of ID documents can similarly be used instead of a driver's license. The provider device 110 can use the images to determine a confidence of an identity of the patient 130. For example, the provider device 110 can determine a 33%, 66%, 100%, or some other confidence that the patient 130 is who they say they are [0043]. The provider device 110 can determine a confidence of an identity of the patient 130 through verifying (i) that an identification document 134 includes particular visual security features, (ii) that human-readable textual information on a front side of the identification document 134 matches information encoded in a machine-readable code on a back side of the identification document [0044]. A government-issued ID such as an ID or driver's license can be used to assert ones identity, and a biometric, e.g., facial, fingerprint, retina, etc., can be processed to ensure the proper assignment of the identity credential itself. In some implementations, the authenticity of the ID is also verified against a third party system (e.g., a system associated with the issuer of the ID). This identity data can be stored locally on a mobile phone of a provider or on a server, or split across both [0037]. the provider device 110 can output “Identity of patient John Doe sufficiently determined, please go ahead and provide service.” In another example, the provider device 110 can output on a display “Identity of patient John Doe insufficiently determined, please re-try verifying identity” [0050] [0055]. the patient 130 can be worried whether the provider 112 is actually who the provider 112 says they are and are qualified to provide a particular service, and use the patient device 132 to verify that the provider 112 can provide the particular service. Accordingly, the patient device 132 can function similarly to the provider device 110 but instead of scanning the patient's identification document 134, scan the provider's identification document 114 to determine a confidence of the provider's identity [0056]. The provider device 110 can have providers initially input information that identifies the childcare facility, and then scan the identification document of the parent. The provider device 110 can then provide the confidence of identity and facility information to the verification server 120 [0057] Fig. 2, Miu shows confidence assessment comparing the name or address of the user from the verified claim and data locally stored), and send the confidence assessment and the verified claim to the service provider (Miu teaches the provider device 110 can provide an indication of the confidence to the verification server 120 and, in response, receive an indication whether the provider 112 should provide service to the patient 130. The provider device can provide an indication to the verification server 120 that (i) an identification document does include particular visual security features [0046]); and access, by the device, the service provided by the service provider based at least in part on the sending of the confidence assessment (Miu teaches the provider device 110 can provide an indication of the confidence to the verification server 120 and, in response, receive an indication whether the provider 112 should provide service to the patient 130. receive an indication that the patient 130 is eligible to receive a service from the provider 112 [0046]).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by Lee to include the plural data fields including at least one of a name or a physical address of the user of the user device, the data locally-stored on the device comprising information corresponding to the plural data fields including the at least one of the name or the physical address of the user of the user device; in response to the receiving, determining, at the user device, a confidence assessment for the verified claim locally- stored on, and specific to, the user device based on a comparison between the plural data fields in the verified claim and corresponding data locally-stored on the user device, wherein determining the confidence assessment comprises deriving, by the user device and from the data locally-stored on the user device, a value corresponding to the at least one of the name or physical address of the user of the user device, and comparing another value of the at least one of the name or the physical address in the verified claim with the value derived by the user device from the data locally-stored on the user device and sending, by the user device, the confidence assessment and the verified claim to the service provider; access, by the user device, the service provided by the service provider based at least in part on the sending of the confidence assessment as disclosed by Miu. One of ordinary skill in the art would have been motivated for the purpose of determining how trustworthy the user is, improves security purposes such as id validation (Miu [0084]).
Although Miu discloses the user device based on a comparison between the plural data fields in the verified claim and corresponding data locally-stored on the user device, the combination of Lee-Miu do not explicitly teach but Hawes teaches the data locally-stored on the user device being based at least in part on use of the user device by the user prior to sending the request for the service (Hawes teaches comparing the user’s current behavioral characteristics against the stored behavioral characteristics may be utilized to generate a challenge level for the user to authenticate himself/herself[Col 7 lines 53-67][Col 8 lines 11-21][Col 8 lines 37-63][Col 9 lines 7-19] [Col 13 lines 38-57]).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by the combination of Lee-Miu to include the data locally-stored on the device being based at least in part on use of the user device by the user as disclosed by Hawes. One of ordinary skill in the art would have been motivated for the purpose of gathering enough identifying information to provide enough confidence in a user’s identity (Hawes [Col 1 lines 26-35]).
Although the combination of Lee-Miu-Hawes discloses that digital certificate is signed by a server, the combination of Lee-Miu-Hawes do not explicitly teach but Khalil teaches the verified claim being a digital certificate comprising a signature of a server that is separate from the service provider (Khalil teaches signing the authentication challenge and the digital certificate to the identity management service device [0019] Figs 1a and 1b, Fig. 1b shows a separate server and service provider).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by the combination of Lee-Miu-Hawes to include being a digital certificate signed by a server that is independent of the service provider as disclosed by Khalil. One of ordinary skill in the art would have been motivated for the purpose of to authenticate the identity of the user of the user device (Khalil [0019] [0021]).
Re. claim 10, rejection of claim 9 is included and claim 10 is rejected with the same rationale as applied in claim 2.
Re. claim 12, rejection of claim 9 is included and claim 12 is rejected with the same rationale as applied in claim 4.
Re. claim 13, rejection of claim 9 is included and claim 13 is rejected with the same rationale as applied in claim 5.
Re. claim 14, rejection of claim 13 is included and claim 14 is rejected with the same rationale as applied in claim 6.
Re. claim 17, Lee discloses a computer program product comprising code stored in a tangible computer-readable storage medium (Lee discloses computer readable medium [0067]), the code comprising: code to send, by a user device associated with a user account and to a service provider, a request for a service provided by the service provider (The user device sends a request for service to the service module 88. The request for service preferably includes the SP-signed certificate received from the sign-up server 30 corresponding to the service provider server 32, i.e., that is part of the same service provider system 18 as the service provider server 32 to which the request is sent [0062]. User device contains sign-up module may provide user information, a username, a password, payment information (e.g., credit card or bank account information), indication of desired service, and/or length of desired subscription to the service, and/or other information [0030]. Fig. 3);
code to receive, by the user device, from the service provider and in response to the sending, a request for a verified claim that is locally stored on the user device (The user can request service and the user device will send the SP-signed certificate to a service provider server [0021]. At stage 186, the sign-up module 84 sends the SP-signed certificate (or an indication of the denial of such a certificate) to the user device 12 [0060] (SP-signed certificate interpreted as verified claim)), the verified claim comprising plural data fields to identify a user of the user device, the verified claim being a digital certificate comprising a signature of a server, the verified claim being associated with the user device, and the verified claim being locally-stored on the user device prior to sending the request for the service (The module 84 is preferably configured to use at least some of the user information to produce the SP certificate. The module 84 may produce the SP certificate to include content and/or formatting that is server specific, user specific, subscription specific, service -provider specific, and/or device specific. User-specific content is information pertaining to (e.g., identifying, associated with, provided by) the user of the user device 12. Device-specific content is information in addition to the device ID and the device public key that is associated with the user device 12 that is used to subscribe to the service (e.g., device manufacturer, device model, one or more device capabilities (e.g., quantity of display pixels), etc.) [0037]. The SP-signed certificate module 86 is configured to receive the signing request from the module 84, with the signing request including the SP certificate, sign the SP certificate to produce an SP-signed certificate, and send the SP-signed certificate to the sign-up module 84 [0038][0060][0010][0024][0029]).
Although Lee discloses verified claim to the service provider, Lee does not explicitly teach but Miu teaches code to, the plural data fields including at least one of a name or a physical address of the user of the user device, the data locally-stored on the device comprising information corresponding to the plural data fields including the at least one of the name or the physical address of the user of user device (Miu teaches obtain the patient's address from the patient's identification document, the previous care records of the patient, insurance records, or a patient account [0075][0055][0056][0048][0043][0037]); in response to the receiving, determine a confidence assessment for the verified claim locally- stored on, and associated with, the device based on a comparison between the plural data fields in the verified claim and corresponding data locally-stored on the user device (Miu teaches the provider device 110 can use the images to determine a confidence of an identity of the patient 130. For example, the provider device 110 can determine a 33%, 66%, 100%, or some other confidence that the patient 130 is who they say they are [0043]. The provider device 110 can determine a confidence of an identity of the patient 130 through verifying (i) that an identification document 134 includes particular visual security features, (ii) that human-readable textual information on a front side of the identification document 134 matches information encoded in a machine-readable code on a back side of the identification document [0044]. The verification server 120 can authenticate the service provider's identity by comparing the service provider's biometric information with biometric information on the identification document 114 [0061] [0037][0051][0059][0080][0006][0024-0026] Fig. 2), wherein determining the confidence assessment comprises deriving, by the user device and from the data locally-stored on the user device, a value corresponding to the at least one of the name or physical address of the user of the user device, and comparing another value of the at least one of the name or the physical address in the verified claim with the value derived by the user device from the data locally-stored on the user device (Miu teaches when a provider 112 arrives at a patient's house, the provider 112 can use a camera included in the provider device 110 to obtain one or more images of an identification document 134 of the patient 130. For example, the provider 112 may ask the patient 130 to present the patient's identification document (e.g., driver's license) and then use the camera of the provider device 110 to obtain an image of a front side and an image of a back side of the patient's driver's license. While a driver's license is used in this example and various examples below, other types of ID documents can similarly be used instead of a driver's license. The provider device 110 can use the images to determine a confidence of an identity of the patient 130. For example, the provider device 110 can determine a 33%, 66%, 100%, or some other confidence that the patient 130 is who they say they are [0043]. The provider device 110 can determine a confidence of an identity of the patient 130 through verifying (i) that an identification document 134 includes particular visual security features, (ii) that human-readable textual information on a front side of the identification document 134 matches information encoded in a machine-readable code on a back side of the identification document [0044]. A government-issued ID such as an ID or driver's license can be used to assert ones identity, and a biometric, e.g., facial, fingerprint, retina, etc., can be processed to ensure the proper assignment of the identity credential itself. In some implementations, the authenticity of the ID is also verified against a third party system (e.g., a system associated with the issuer of the ID). This identity data can be stored locally on a mobile phone of a provider or on a server, or split across both [0037]. the provider device 110 can output “Identity of patient John Doe sufficiently determined, please go ahead and provide service.” In another example, the provider device 110 can output on a display “Identity of patient John Doe insufficiently determined, please re-try verifying identity” [0050] [0055]. the patient 130 can be worried whether the provider 112 is actually who the provider 112 says they are and are qualified to provide a particular service, and use the patient device 132 to verify that the provider 112 can provide the particular service. Accordingly, the patient device 132 can function similarly to the provider device 110 but instead of scanning the patient's identification document 134, scan the provider's identification document 114 to determine a confidence of the provider's identity [0056]. The provider device 110 can have providers initially input information that identifies the childcare facility, and then scan the identification document of the parent. The provider device 110 can then provide the confidence of identity and facility information to the verification server 120 [0057] Fig. 2, Miu shows confidence assessment comparing the name or address of the user from the verified claim and data locally stored), and send the confidence assessment and the verified claim to the service provider (Miu teaches the provider device 110 can provide an indication of the confidence to the verification server 120 and, in response, receive an indication whether the provider 112 should provide service to the patient 130. The provider device can provide an indication to the verification server 120 that (i) an identification document does include particular visual security features [0046]); and access, by the user device, the service provided by the service provider based at least in part on the sending of the confidence assessment (Miu teaches the provider device 110 can provide an indication of the confidence to the verification server 120 and, in response, receive an indication whether the provider 112 should provide service to the patient 130. receive an indication that the patient 130 is eligible to receive a service from the provider 112 [0046]).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by Lee to include the plural data fields including at least one of a name or a physical address of the user of the user device, the data locally-stored on the device comprising information corresponding to the plural data fields including the at least one of the name or the physical address of the user of user device; in response to the receiving, determining, at the user device, a confidence assessment for the verified claim locally- stored on, and specific to, the device based on a comparison between the plural data fields in the verified claim and corresponding data locally-stored on the user device, wherein determining the confidence assessment comprises deriving, by the user device and from the data locally-stored on the user device, a value corresponding to the at least one of the name or physical address of the user of the user device, and comparing another value of the at least one of the name or the physical address in the verified claim with the value derived by the user device from the data locally-stored on the user device, and sending, by the device, the confidence assessment and the verified claim to the service provider; access, by the device, the service provided by the service provider based at least in part on the sending of the confidence assessment as disclosed by Miu. One of ordinary skill in the art would have been motivated for the purpose of determining how trustworthy the user is, improves security purposes such as id validation (Miu [0084]).
Although Miu discloses the user device based on a comparison between the plural data fields in the verified claim and corresponding data locally-stored on the user device, the combination of Lee-Miu do not explicitly teach but Hawes teaches the data locally-stored on the user device being based at least in part on use of the device by the user prior to sending the request for the service (Hawes teaches comparing the user’s current behavioral characteristics against the stored behavioral characteristics may be utilized to generate a challenge level for the user to authenticate himself/herself[Col 7 lines 53-67][Col 8 lines 11-21][Col 8 lines 37-63][Col 9 lines 7-19] [Col 13 lines 38-57]).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by the combination of Lee-Miu to include the data locally-stored on the user device being based at least in part on use of the user device by the user as disclosed by Hawes. One of ordinary skill in the art would have been motivated for the purpose of gathering enough identifying information to provide enough confidence in a user’s identity (Hawes [Col 1 lines 26-35]).
Although the combination of Lee-Miu-Hawes discloses that digital certificate is signed by a server, the combination of Lee-Miu-Hawes do not explicitly teach but Khalil teaches being a digital certificate signed by a server that is independent of the service provider (Khalil teaches signing the authentication challenge and the digital certificate to the identity management service device [0019] Figs 1a and 1b, Fig. 1b shows a separate server and service provider).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by the combination of Lee-Miu-Hawes to include being a digital certificate signed by a server that is independent of the service provider as disclosed by Khalil. One of ordinary skill in the art would have been motivated for the purpose of to authenticate the identity of the user of the user device (Khalil [0019] [0021]).
Re. claim 18, rejection of claim 17 is included and claim 18 is rejected with the same rationale as applied in claim 2.
Re. claim 20, rejection of claim 17 is included and claim 20 is rejected with the same rationale as applied in claim 4.
Re. claim 23, the combination of Lee-Miu-Hawes-Khalil teach the method of claim 1, wherein the user account of the user whose identity is verified by the verified claim (Miu [0037][0043-44][0050][0055-57][0075]Fig. 2).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by Lee to include wherein the user account of the user whose identity is verified by the verified claim as disclosed by Miu. One of ordinary skill in the art would have been motivated for the purpose of determining how trustworthy the user is, improves security purposes such as id validation (Miu [0084]).
Claims 3, 11 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (US 20160365984, hereinafter Lee) in view of Miu (US 20190042719), Hawes et al. (US 10754936, hereinafter Hawes), Khalil et al. (US 20190044940, hereinafter Khalil) and in further view of Kragh (US 9805213).
Re. claim 3, the combination of Lee-Miu-Hawes-Khalil teach the method of claim 1, Although the combination of Lee-Miu-Hawes-Khalil discloses locally-stored data and content, the combination of Lee-Miu-Hawes-Khalil do not explicitly teach but Kragh teaches wherein the locally-stored data comprises at least one of email content, message content, social networking content or third party application content corresponding to the plural data fields in the verified claim (Kragh teaches a unique secure email extension and address are generated (block 139) that function separately, for identity protection, and are separate and distinct from the current "user name," which is the email address used in the identity proofing process [Col 16-4-11]. Once a person has been authenticated with a credentialed identity, the teachings of the present invention fine tune an email feature, by way of example, with additional authenticated micro object attribute features, such as presented with an electronic time-date stamped post mark which is an embedded email-authenticated object attribute, issued by the United States Post Office, by way of example. A second attribute feature reinforces the validation of a user's demographic information using an "elink authentication" process by creating a unique email address incorporating USPS.Gov as text along with the user's address [Col 27 lines 50-65]).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by the combination of Lee-Miu-Hawes-Khalil to include wherein the locally-stored data comprises at least one of email content, message content, social networking content or third party application content corresponding to the plural data fields in the verified claim as disclosed by Kragh. One of ordinary skill in the art would have been motivated for the purpose of further enhancing the security of accessing data (Kragh [Col 4 lines 20-25]).
Re. claim 11, rejection of claim 9 is included and claim 11 is rejected with the same rationale as applied in claim 3.
Re. claim 19, rejection of claim 17 is included and claim 19 is rejected with the same rationale as applied in claim 3.
Claims 7-8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (US 20160365984, hereinafter Lee), Miu (US 20190042719), Hawes et al. (US 10754936, hereinafter Hawes), Khalil et al. (US 20190044940, hereinafter Khalil) and in further view of Uhr et al. (US 20180294977, hereinafter Uhr).
Re. claim 7, the combination of Lee-Miu-Hawes-Khalil teach the method of claim 1, the combination of Lee-Miu-Hawes-Khalil do not explicitly teach but Uhr teach wherein the verified claim corresponds to a Merkle tree with nodes storing the plural data fields to identify the user (Uhr teaches the DB part 310 may store sequentially and cumulatively, the personal information for each user, the public key, and the node hash information by user acquired by hashing the personal information and the public key, may include the DB 311 for registration information that stores identification information of the specific root hash value for registration which is a root hash value of a Merkle tree containing the stored node hash information [0126]).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by the combination of Lee-Miu-Hawes-Khalil to include wherein the verified claim corresponds to a Merkle tree with nodes storing the plural data fields to identify the user as disclosed by Uhr. One of ordinary skill in the art would have been motivated for the purpose of search the specific transaction information for monitoring forgery, and sending the specific transaction information for monitoring forgery to the blockchain (Uhr [0002]).
Re. claim 8, the combination of Lee-Miu-Hawes-Khalil-Uhr teach the method of claim 7, the combination of Lee-Miu-Hawes-Khalil do not explicitly teach but Uhr teach wherein the Merkle tree is configured for selective sharing of the plural data fields based on the nodes (Uhr teaches thereby acquire the node hash information, and may allow the node hash information of the specific user, who requested the revocation, to be included in the Merkle tree corresponding to the root hash value for registration which is also included in the transaction information for monitoring forgery transmitted to and registered in the distributed DB, i.e., the blockchain nodes [0198]).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by the combination of Lee-Miu-Hawes-Khalil to include wherein the Merkle tree is configured for selective sharing of the plural data fields based on the nodes as disclosed by Uhr. One of ordinary skill in the art would have been motivated for the purpose of search the specific transaction information for monitoring forgery, and sending the specific transaction information for monitoring forgery to the blockchain (Uhr [0002]).
Re. claim 15, rejection of claim 9 is included and claim 15 is rejected with the same rationale as applied in claim 7.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (US 20160365984, hereinafter Lee), Miu (US 20190042719), Hawes et al. (US 10754936, hereinafter Hawes), Khalil et al. (US 20190044940, hereinafter Khalil) and in further view of Mardikar et al. (US 20120060207, hereinafter Mardikar).
Re. claim 21, the combination of Lee-Miu-Hawes-Khalili teach the method of claim 2, the combination of Lee-Miu-Hawes-Khalili discloses sending confidence assessment and the verified claim, the combination of Lee-Miu-Hawes-Khalili do not explicitly teach but Mardikar teaches in response to sending, by the device, the confidence assessment and the verified claim to the service provider, receiving, from the service provider, a request for additional information to identify the user, the additional information being different than the confidence assessment and the verified claim, the request for the additional information being based on a determination by the service provider that the confidence assessment and verified claim are not sufficient to identify the user; and prior to accessing, by the device, the service provided by the service provider, sending, by the device, the additional information to the service provider (Mardikar teaches system request additional input from the user device [0011-0012]. The system may add additional decision around access granting based on the confidence level of system in both the identity and authentication mechanism. That additional user action needs to be taken prior to granting access. Establishing more identity trust by providing more information about the subject (e.g., SSN, tax, business information, or other identifying factors) or by presenting more security claims [0024-0025]. The service provider front end may communicate with the access device, for example, prompting the subject (e.g., user or customer) to retry or enter additional information such as additional credentials or claims [0031-0033][0018] Fig. 3).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by the combination of Lee-Miu-Hawes-Khalili to include in response to sending, by the device, the confidence assessment and the verified claim to the service provider, receiving, from the service provider, a request for additional information to identify the user, the additional information being different than the confidence assessment and the verified claim, the request for the additional information being based on a determination by the service provider that the confidence assessment and verified claim are not sufficient to identify the user; and prior to accessing, by the device, the service provided by the service provider, sending, by the device, the additional information to the service provider as disclosed by Mardikar. One of ordinary skill in the art would have been motivated for the purpose of accessing or denying different levels of access to various types of information (Mardikar [0005]).
Claim 22 is rejected under 35 U.S.C. 103 as being unpatentable over Lee et al. (US 20160365984, hereinafter Lee), Miu (US 20190042719), Hawes et al. (US 10754936, hereinafter Hawes), Khalil et al. (US 20190044940, hereinafter Khalil) and in further view of Tran (US 20110211746).
Re. claim 22, the combination of Lee-Miu-Hawes-Khalili teach the method of claim 1, the combination of Lee-Miu-Hawes-Khalili do not explicitly teach but Tran teaches wherein determining the confidence assessment comprises generating, by the user device, a response vector comprising, for each of at least two of the plural data fields of the verified claim, a respective confidence score indicating a likelihood that the corresponding data field is accurate, the respective confidence scores being based on the comparison (Tran teaches the determined first multivariate vector may be compared with a second multivariate vector associated with a second financial document. Based on the comparison, a confidence score for the first financial document may be determined. The confidence score may represent the degree to which the two documents are dissimilar, as if two documents are similar, one of them may be a fraudulent copy of the other [0003]. The system compares the individual vector components of the first multivariate vector with the corresponding individual vector components of the second multivariate vector, the system may calculate an amount of variance between each pair of corresponding vector components. the system may sum each of these amounts of variance, and the sum may represent the confidence score for the first financial document. The greater the amount of variance between the first multivariate vector and the second multivariate vector (and thus, the greater the amount of variance between the first financial document and the second financial document), the more confidence a financial institution may have in the legitimacy and validity of the first financial document (e.g., because the first financial document might not be a copy of the second financial document), and correspondingly, the greater the confidence score may be. On the other hand, the smaller the variance between the first multivariate vector and the second multivariate vector (and thus, the lesser the amount of variance between the first financial document and the second financial document), the less confidence a financial institution may have in the legitimacy and validity of the first financial document (e.g., because the first financial document might be a copy of the second financial document), and correspondingly, the lower the confidence score may be [0040]).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the claimed invention to modify the method, device and system disclosed by the combination of Lee-Miu-Hawes-Khalili to include wherein determining the confidence assessment comprises generating, by the user device, a response vector comprising, for each of at least two of the plural data fields of the verified claim, a respective confidence score indicating a likelihood that the corresponding data field is accurate, the respective confidence scores being based on the comparison as disclosed by Tran. One of ordinary skill in the art would have been motivated for the purpose of improving the legitimacy of the document (Tran [0040]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Wang (US 20200084211) discloses devices for an authentication of an identity of a user. The client device determines an authentication proxy associated with the service provider, and sends, to the associated authentication proxy, the identifier and a first request for an authentication of an identity of a user associated with the client device.
Shah et al. (US 20170374070) discloses MFAS is authenticated by a server side self-signed certificate by the MFAP.
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 KEVIN A AYALA whose telephone number is (571)270-3912. The examiner can normally be reached Monday-Thursday 8AM-5PM; Friday: Variable 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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/KEVIN AYALA/Primary Examiner, Art Unit 2496
Prosecution Insights