DETAILED ACTION
This is office action on the merits in response to the application filed on 12/30/2025.
Claims 1-20 have been filed by the applicant.
Claims 4-5 and 7 are currently canceled.
Claims 1 and 20 are currently amended.
Claims 1-3, 6, and 8-20 are currently pending and have been examined.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/30/2025 has been entered.
Response to Argument
Rejection under 101:
The applicant argues that the claims does not recite abstract idea because the claims recite specific structured trusted computing system and non-trusted computing system and performing provider-suitability check. The examiner respectfully disagrees. Performing provider-suitability check is merely making determination, which embodies the abstract idea, the claim itself is merely a recitation of the abstract idea and an instruction to “apply it” on a computer (i.e., trusted computing system and non-trusted computing system). This is not enough to provide an inventive concept. The trusted and non-trusted computing system merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)).
The applicant further argues that the claims recite server-implemented verification improves computer security. The examiner respectfully disagrees. As stated above, the claim itself is merely a recitation of the abstract idea and an instruction to “apply it” on a computer.
The applicant further argues that the recitation of authentication token improves computer security. The examiner respectfully disagrees. The use of token generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)).
The applicant further argues that the claims recite isolated and separated systems (i.e., trusted computing system and non-trusted computing system) which ties to a particular technological implementation and cannot reasonably be characterized as a mere instruction to “apply” and abstract idea. The examiner respectfully disagrees. The instructions embody the abstract idea, although the claims recite multiple computing systems, the claim itself is merely a recitation of the abstract idea and an instruction to “apply it” on computers. therefore, this is not enough to provide an inventive concept.
Therefore, 101 rejection is maintained.
Rejection under 103:
The applicant argues that Reeves performing the selection by the client device instead of server. The applicant also argues that Reeves does not disclose server-side suitability checks The examiner agrees that Reeves does not discloses a server to perform the above functions. 103 rejection is updated to reflect the amendment. However, Reeves discloses a suitability checks by making determination and selection on provider.
The applicant further argues that Novack use score for user/device, not for selection of authentication module as recited in the claims. The examiner respectfully disagrees. Reeves and Novack both discloses an authentication system. Reeves further discloses selecting authentication provider based on reputation system. Reeves does not explicitly disclose how reputation is utilized to evaluate/filter authentication provider. Novack discloses the specific of scoring system for evaluate user/device. It would have been understood to modify Reeves and apply the scoring system of Novack to Reeves’s reputation system to evaluate and select a required authentication provider, as a result to improve authentication security.
The applicant further argues that Lu does not teach (i) score associated with authentication provider, (ii) required provider attribute tied to transaction type, or (iii) a division between trusted and non-trusted computing systems. The examiner respectfully disagrees. Lu discloses selecting service provider based on value of the compliance parameter or attributes, such parameter can be a score [0040]. Lu further discloses service type as one of the request parameters [0021], which reflects association of transaction type and other parameters and attributes. In addition, there claims does not specify and distinguish trusted and non-trusted computing system. The examiner, under BRI, interprets those as mere two separate systems. Lu discloses separated systems [Fig. 1: provider device 102, service arrangement system 100].
The applicant further argues that Smets’s token does not have the same information as recited in the claim and is not transmitted from external system to the server for purpose of verifying provider suitability. The examiner respectfully disagrees. Smets is cited only to teach a token, Reeves in view of Lu discloses the system arrangement and verifying provider suitability. See 103 rejection for detail.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-3, 6, and 8-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-3, 6, and 8-19 are directed to a method, and claim 20 is directed to a system. Therefore, these claims fall within the four statutory categories of invention.
The limitations of independent claim 1, which is representative of independent claims 20, have been denoted with letters by the Examiner for easy reference. The judicial exceptions recited in claim 1 are identified in bold below:
executing, by a first computing device within a trusted computing system, a transaction for the individual
determining, by the first computing device, a type of transaction being performed at the first computing device
responsive to said determining, transmitting, by the first computing device to a server of the trusted computing system, an authentication request for authenticating an identity of an individual at the first computing device, wherein the authentication request comprises: i) data indicative of a minimum required authentication provider score for the type of transaction and ii) data indicative of at least one required authentication provider attribute for the type of transaction;
receiving, by the server of the trusted computing system, the authentication request and performing, by the server, a provider-suitability check by determining whether authentication provider modules executing in a non-trusted computing system meet the minimum required authentication provider score and possess the at least one required authentication provider attribute
identifying, by the server, an authentication provider module that: i) meets the minimum required authentication provider score for the type of transaction and ii) has the at least one required authentication provider attribute;
selecting the identified authentication provider module;
responsive to selecting the identified authentication provider module, receiving, by the server, an authentication token transmitted from the identified authentication provider module, the authentication token comprising data indicative of a trust-level score of the authentication provider module and data indicative of at least one attribute of the authentication provider module
Limitations A through G under the broadest reasonable interpretation covers steps or functions that are following instructions. Other than reciting generic computer hardware in limitation A-F and G, nothing in the claim element differentiates the limitation from processes of following instructions. For example, the disclosure establishes the context of select an authentication provider based on criteria. Therefore, limitations A through G recite an abstract idea, as highlighted above, that is consistent with the following instruction aspects of certain method of organizing human activities.
Accordingly, claim 1, and by analogy similar claims 20, recite abstract ideas and the analysis proceed to Step 2A.2.
The judicial exception is not integrated into a practical application. In particular, claim 1 recites the additional elements in bold below:
executing, by a first computing device within a trusted computing system, a transaction for the individual
determining, by a first computing device of a trusted computing system, a type of transaction being performed at the first computing device
responsive to said determining, transmitting, by the first computing device to a server of the trusted computing system, an authentication request, for authenticating an identity of an individual at the first computing device, wherein the authentication request comprises: i) data indicative of a minimum required authentication provider score for the type of transaction and ii) data indicative of at least one required authentication provider attribute for the type of transaction;
receiving, by the server of the trusted computing system, the authentication request and performing, by the server, a provider-suitability check by determining whether authentication provider modules executing in a non-trusted computing system meet the minimum required authentication provider score and possess the at least one required authentication provider attribute
identifying, by the server, an authentication provider module that: i) meets the minimum required authentication provider score for the type of transaction and ii) has the at least one required authentication provider attribute;
selecting the identified authentication provider module;
responsive to selecting the identified authentication provider module, receiving, by the server, an authentication token transmitted from the identified authentication provider module, the authentication token comprising data indicative of a trust-level score of the authentication provider module and data indicative of at least one attribute of the authentication provider module
The additional element(s) in limitation A-F and G merely uses a computer as a tool to perform an abstract idea. Accordingly, the additional element(s) do not integrate the abstract idea into a practical application because they do not recite any additional elements indicative of integration into a practical application. Rather, the claim as whole generally links the judicial exception to a technological environment defined by high level recitations of a computer and the Internet. The additional element of authentication token generally link the use of the judicial exception to a particular technological environment (MPEP § 2106.05(h)). Therefore, the claim is directed to an abstract idea and the analysis proceeds to Step 2B.
The additional elements, both individually and as an ordered combination, do not amount to significantly more than the judicial exception because the outcome of the considerations at Step 2B will be the same when the considerations from Step 2A.2 are reevaluated. As discussed under Step 2A.2, the additional element(s) amount to no more than a computer as a tool to perform an abstract idea. This is not enough to provide an inventive concept. Therefore, claims 1 and 20 are not patent eligible.
Dependent claims 2 further recite authenticating the identity which is further recites the abstract idea as discussed above in the claim 1, which is following instructions.
Dependent claims 3 further recite transmitting authentication response to the server which is further recites the abstract idea as discussed above in the claim 1, which is following instructions.
Dependent claims 6 further recite queueing the authentication request and determine one authentication provider meets the criteria which is further recites the abstract idea as discussed above in the claim 1, which is following instructions.
Dependent claims 8 further recite identifying an authentication provider based on score meets minimum required score which is further recites the abstract idea as discussed above in the claim 1, which is following instructions.
Dependent claims 9 further recite provide criteria based on transaction type which is further recites the abstract idea as discussed above in the claim 1, which is following instructions.
Dependent claims 10 further recite provide criteria based on transaction type and device type which is further recites the abstract idea as discussed above in the claim 1, which is following instructions.
Dependent claims 11 further define the device type. The different device merely serving as a tool to perform the abstract idea (MPEP § 2106.05(f)).
Dependent claims 12 further determining minimum required score automatically or manually which is further recites the abstract idea as discussed above in the claim 1, which is following instructions. The use of first computing device merely using the device as a tool to perform the abstract idea.
Dependent claims 13 further defines transaction type which is further recites the abstract idea as discussed above in the claim 1, which is following instructions.
Dependent claims 14 further recite transmitting initial authentication request and receiving input which is further recites the abstract idea as discussed above in the claim 1, which is following instructions.
Dependent claims 15 further recite provide authentication provider score based on device type which is further recites the abstract idea as discussed above in the claim 1, which is following instructions.
Dependent claims 16 further recite generating authentication request which is further recites the abstract idea as discussed above in the claim 1, which is following instructions.
Dependent claims 17-18 further recite provide trust level score based on authentication provider attributes which is further recites the abstract idea as discussed above in the claim 1, which is following instructions.
Dependent claims 19 further recite provide trust level score based on weight of authentication provider attributes which is further recites the abstract idea as discussed above in the claim 1, which is following instructions.
In summary, the dependent claims considered both individually and as an ordered combination do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract idea itself. The claims do not recite an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or provide meaningful limitations beyond generally linking an abstract idea to a particular technological environment. Therefore, the claims are rejected under 35 U.S.C. § 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-3, 8-12 and 16-18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Lu (US 20180240128 A1), and further in view of Reeves, JR. et al. (US 20110307938 A1) and of Smets et al. (US 20240176857 A1).
With respect to claim 1 and 8:
Lu teaches (in italic):
executing, by a first computing device within a trusted computing system, a transaction for the individual. (Similarly, the requesters may correspond to individuals who make service requests 101 from the system 100 for service providers to perform the service of a particular type. In some examples, requester device 104 can make a service payment for a service received through system 100. [0015-0017])
determining, by the first computing device, a type of transaction being performed at the first computing device; responsive to said determining, transmitting, by the first computing device to a server of the trusted computing system, an […] request (On the requester device 104, the service application 106 can be implemented to enable the service requester to select a service type (e.g., type of transport service, type of vehicle) as well as one or more service request parameters 101A, in connection with a corresponding service request 101 that is communicated over the network connection 99A to the system 100. [0021])
wherein the […] request comprises i) data indicative of a minimum required […] provider score for the type of transaction; and ii) data indicative of at least one required […] provider attribute for the type of transaction. (The selection of the service provider for service requests may be based in part on the value of the compliance parameter, and an attribute of individual service requests which is related to the value of the compliance parameter. Based on the service provider's account data set 128, the account monitor 160 can determine a compliance state 155 of the service provider with respect to the set of compliance rules. In some examples, the compliance state 155 can be binary (e.g., the service provider is in compliance, or not in compliance), trinary (e.g., the service provider is in compliance, not in compliance, or not in compliance but in grace-period), or set within a numeric range to reflect a score or other measure of non-compliance [0006 0040])
receiving, by the server of the trusted computing system, the […] request and performing, by the server, a provider-suitability check by determining whether […]provider modules executing in a non-trusted computing system meet the minimum required […]provider score and possess the at least one required […]provider attribute. (The provider selection component 130 may utilize the service request parameters 101A to match a corresponding service request 101 with an available service provider. A system operates to determine value of a compliance parameter, where the value of the compliance parameter reflects a compliance state of the provider with respect to a set of compliance rules. The selection of the service provider for service requests may be based in part on the value of the compliance parameter, and an attribute of individual service requests which is related to the value of the compliance parameter. [0006 0022 0040])
identifying, by the server, an […] provider module that i) meets the minimum required […]provider score for the type of transaction and ii) has the at least one required […]provider attribute; selecting the identified […] provider module. (Based on the service provider's account data set 128, the account monitor 160 can determine a compliance state 155 of the service provider with respect to the set of compliance rules. In some examples, the compliance state 155 can be binary (e.g., the service provider is in compliance, or not in compliance), trinary (e.g., the service provider is in compliance, not in compliance, or not in compliance but in grace-period), or set within a numeric range to reflect a score or other measure of non-compliance [0040])
responsive to selecting the identified […] provider module, receiving, by the server, […] transmitted from the identified […] provider module, […] comprising data indicative of a trust-level score of the authentication provider module and data indicative of at least one attribute of the authentication provider module. (Based on the service provider's account data set 128, the account monitor 160 can determine a compliance state 155 of the service provider with respect to the set of compliance rules. In some examples, the compliance state 155 can be binary (e.g., the service provider is in compliance, or not in compliance), trinary (e.g., the service provider is in compliance, not in compliance, or not in compliance but in grace-period), or set within a numeric range to reflect a score or other measure of non-compliance [0040])
Lu does not explicitly teach the following limitations. However,
Reeves teaches:
transmitting, […] an authentication request for authenticating the identity of the individual at the first computing device; authentication provider module (The browser 106 (on a client 108) receiving the sign-in page 104 parses the content, and when it processes the object tag, invokes a browser extension 110 associated with the MIME-type (or the like) referenced in the object tag. An example object tag that includes authentication request parameters/constraints. When the user elects to sign in, the browser extension 110 invokes an account selector 112, passing the authentication request parameters (including constraints) in the object tag as arguments (the arrow labeled three (3)). The account selector 112 may categorize the information providers in any way, including for example as known or unknown, or some other category, such as classified based upon data of a reputation service (as described below). The reputation information, for example, may correspond to data provided from a whitelist, a blacklist, a filtering service, a set of extended validation certificates, and/or a set of government-certified entities. the account selector 112 may leverage stored information 116, such as account usage history to enable the user to make a more informed choice of which credentials will be used to authenticate to the identity provider website. The account selector 112 may categorize the information providers in any way, including for example as known or unknown, or some other category, such as classified based upon data of a reputation service (as described below). For example, if the user has previously used a given identity provider for a given relying party, based upon the previous user interaction the selector may automatically select that provider again and automatically create an authentication request, without needing further user interaction. [0009, 0020-0030])
Lu discloses a system for select a service provider. Reeves discloses a system for sleeting a service provider for authenticating user identity. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Lu to selecting provider for identity authentication with the technique as disclosed by Reeves to provide security as Reeves suggested [0038].
Lu in view of Reeves does not explicitly teach an authentication token. However,
Smets teaches an authentication token (generate a token based on the highest confidence score to authorize payment using the selected account from the plurality of payment accounts for completion of the payment transaction [0064])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Lu in view of Reeves to use token in authentication response with the technique as disclosed by Smets to securely handling information.
Claim 20, a system with the same scope as claim 1, is rejected.
With respect to claim 2:
Reeves further teaches a responsive to said selecting, authenticating, by the selected authentication provider module, the identity of the individual. (The account selector 112 also constructs the authentication request (arrow eleven (11)). Further, once an identity provider has been selected, the account selector 112 returns the selection and authentication request back to the extension 110 (arrow twelve (12)). the browser extension 110 redirects the browser 106 to the selected identity provider website 118 for authentication and completion of remaining portions of the passive protocol. [0031-0032])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Lu to authenticate user with the technique as disclosed by Reeves to provide security as Reeves suggested [0038].
With respect to claim 3:
Reeves further teaches a responsive to said selecting, authenticating, by the selected authentication provider module, the identity of the individual. (The account selector 112 also constructs the authentication request (arrow eleven (11)). Further, once an identity provider has been selected, the account selector 112 returns the selection and authentication request back to the extension 110 (arrow twelve (12)). the browser extension 110 redirects the browser 106 to the selected identity provider website 118 for authentication and completion of remaining portions of the passive protocol. [0031-0032])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Lu to authenticate user with the technique as disclosed by Reeves to provide security as Reeves suggested [0038].
With respect to claim 8:
Lu further teaches identifying that the selected authentication provider module meets the minimum required authentication provider score when a trust level score of the selected authentication provider module is equal to or greater than the minimum required authentication provider score. (Based on the service provider's account data set 128, the account monitor 160 can determine a compliance state 155 of the service provider with respect to the set of compliance rules. In some examples, the compliance state 155 can be binary (e.g., the service provider is in compliance, or not in compliance), trinary (e.g., the service provider is in compliance, not in compliance, or not in compliance but in grace-period), or set within a numeric range to reflect a score or other measure of non-compliance [0040])
With respect to claim 9:
Lu further teaches providing the minimum required authentication provider score and/or the at least one required authentication provider attribute based on the type of transaction. (Based on the service provider's account data set 128, the account monitor 160 can determine a compliance state 155 of the service provider with respect to the set of compliance rules. In some examples, the compliance state 155 can be binary (e.g., the service provider is in compliance, or not in compliance), trinary (e.g., the service provider is in compliance, not in compliance, or not in compliance but in grace-period), or set within a numeric range to reflect a score or other measure of non-compliance [0040])
With respect to claim 10:
Lu further teaches providing the minimum required authentication provider score and/or the at least one required authentication provider attribute based on the type of transaction and a type of the first computing device. (The selection of the service provider for service requests may be based in part on the value of the compliance parameter, and an attribute of individual service requests which is related to the value of the compliance parameter. Based on the service provider's account data set 128, the account monitor 160 can determine a compliance state 155 of the service provider with respect to the set of compliance rules. In some examples, the compliance state 155 can be binary (e.g., the service provider is in compliance, or not in compliance), trinary (e.g., the service provider is in compliance, not in compliance, or not in compliance but in grace-period), or set within a numeric range to reflect a score or other measure of non-compliance [0006 0040])
With respect to claim 11:
Reeves further teaches wherein the type of the first computing device is one of: an Automated Teller Machine or a desktop computer, laptop or mobile device operated by a bank teller. (Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to: personal computers [0040])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Lu to utilizing personal computer the technique as disclosed by Reeves to provide security as Reeves suggested [0038].
With respect to claim 12:
Lu further teaches further comprising: automatically determining the minimum required authentication score by the first computing device or manually determining the minimum required authentication score. (The selection of the service provider for service requests may be based in part on the value of the compliance parameter, and an attribute of individual service requests which is related to the value of the compliance parameter. Based on the service provider's account data set 128, the account monitor 160 can determine a compliance state 155 of the service provider with respect to the set of compliance rules. In some examples, the compliance state 155 can be binary (e.g., the service provider is in compliance, or not in compliance), trinary (e.g., the service provider is in compliance, not in compliance, or not in compliance but in grace-period), or set within a numeric range to reflect a score or other measure of non-compliance [0006 0040])
With respect to claim 16:
Lu further teaches prior to transmitting the authentication request, generating, by the first computing device, the authentication request. (On the requester device 104, the service application 106 can be implemented to enable the service requester to select a service type (e.g., type of transport service, type of vehicle) as well as one or more service request parameters 101A, in connection with a corresponding service request 101 that is communicated over the network connection 99A to the system 100. [0021])
With respect to claim 17:
Lu further teaches providing a trust level score for the selected authentication provider module based on at least one attribute of the selected authentication provider module. (The selection of the service provider for service requests may be based in part on the value of the compliance parameter, and an attribute of individual service requests which is related to the value of the compliance parameter. Based on the service provider's account data set 128, the account monitor 160 can determine a compliance state 155 of the service provider with respect to the set of compliance rules. In some examples, the compliance state 155 can be binary (e.g., the service provider is in compliance, or not in compliance), trinary (e.g., the service provider is in compliance, not in compliance, or not in compliance but in grace-period), or set within a numeric range to reflect a score or other measure of non-compliance [0006 0040])
With respect to claim 18:
Lu further teaches providing the trust level score based on a subset of at least one attribute of said at least one attribute. (The selection of the service provider for service requests may be based in part on the value of the compliance parameter, and an attribute of individual service requests which is related to the value of the compliance parameter. Based on the service provider's account data set 128, the account monitor 160 can determine a compliance state 155 of the service provider with respect to the set of compliance rules. In some examples, the compliance state 155 can be binary (e.g., the service provider is in compliance, or not in compliance), trinary (e.g., the service provider is in compliance, not in compliance, or not in compliance but in grace-period), or set within a numeric range to reflect a score or other measure of non-compliance [0006 0040])
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over "Lu" and "Reeves" and “Smets” as applied to claim 1 above, and further in view of Lumsden (US 20020076012 A1).
With respect to claim 6:
Lu in view of Reeves and Smets does not teach responsive to transmitting the authentication request to the server, providing the authentication request to an authentication request queue on the server. However,
Lumsden teaches responsive to transmitting the authentication request to the server, providing the authentication request to an authentication request queue on the server. (placing the call in an alert state and placing the call in said queue means until the appropriate resources become available [0013])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Lu in view of Reeves and Smets to put request in queue with the technique as disclosed by Lumsden to ease the system load as Lumsden suggested.
Claim(s) 13 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over "Lu" and "Reeves" and “Smets” as applied to claim 1 above, and further in view of Novack (US 20150089585 A1).
With respect to claim 13:
Lu in view of Reeves and Smets does not teach determining the type of transaction as one of: a cash withdrawal below a predetermined threshold; a cash withdrawal above the predetermined threshold; opening a new bank account; or closing an existing bank account. However,
Novack teaches determining the type of transaction as one of: a cash withdrawal below a predetermined threshold; a cash withdrawal above the predetermined threshold; opening a new bank account; or closing an existing bank account. (The transaction information can include, for example, a transaction definition, a transaction type, location information, information describing or defining the transaction and/or parameters thereof (e.g., amounts involved parties or entities, locations of involved entities, types of connections and/or networks used in the transactions, transaction histories, combinations thereof, or the like). [0085])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system to identify transaction type with the technique as disclosed by Novack to provide high level of security as Novack suggested [0010].
Note: In addition with respect to “type of transaction as one of: a cash withdrawal below a predetermined threshold; a cash withdrawal above the predetermined threshold; opening a new bank account; or closing an existing bank account” this is nonfunctional descriptive material as it only describes various types of transaction, while the specific type is not used to perform any of the recited method steps. Therefore, it has been held the nonfunctional descriptive material will not distinguish the invention from the prior art in term of patentability. (In re Gulack, 217 USPQ 401 (Fed. Cir. 1983), In re Ngai, 70 USPQ2d (Fed. Cir. 2004), In re Lowry, 32 USPQ2d 1031 (Fed. Cir. 1994); MPEP 2111.05), Ex parte Nehls 88 USPQ2d 1883 (BPAI 2008) (precedential).
With respect to claim 19:
Lu in view of Reeves and Smets does not teach providing a respective weighting for each attribute of the subset; and providing the trust level score as a summation of each respective weighting. However,
Novack further teaches providing a respective weighting for each attribute of the subset; and providing the trust level score as a summation of each respective weighting. (The authentication score also can define a combined weight or value of a combination of authentication factors. The authentication service can generate one or more combinations of authentication factors that meet the desired or determined authentication score. [0030])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system to provide weighted authentication provider score with the technique as disclosed by Novack to provide high level of security as Novack suggested [0010].
Claim(s) 14-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over "Lu" and "Reeves" and “Smets” as applied to claim 1 above, and further in view of Elenbaas et al. (US 20090204471 A1).
With respect to claim 14:
Lu further teaches […] receiving at least one input on the first computing device to thereby determine the type of transaction. (On the requester device 104, the service application 106 can be implemented to enable the service requester to select a service type (e.g., type of transport service, type of vehicle) as well as one or more service request parameters 101A, in connection with a corresponding service request 101 that is communicated over the network connection 99A to the system 100. [0021])
Lu in view of Reeves and Smets does not teach prior to determining the transaction type, transmitting, by the first computing device, an initial authentication request to the server, wherein the initial authentication request comprises data indicative of an initial minimum required authentication provider score that is less that said minimum required authentication provider score for the type of transaction; responsive to receiving a response, at the first computing device, to the initial authentication request […]. However,
Elenbaas teaches prior to determining the transaction type, transmitting, by the first computing device, an initial authentication request to the server, wherein the initial authentication request comprises data indicative of an initial minimum required authentication provider score that is less that said minimum required authentication provider score for the type of transaction; responsive to receiving a response, at the first computing device, to the initial authentication request […]. (In one embodiment, the reputation score manager 290 receive pre-existing reputation scores and metadata 1230 from the remote repository 148, pre-existing reputation scores and metadata 1240 from the local repository 240, reputation scores from the partner services 1010 and new reputation scores and metadata 1254 from the additional source 1250. Ranking based on the eight reputations scores may be recalculated according to the regression formulas every time new data is collected on the worker or job owner, or every time a new task is defined. [0163 0170])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system as disclosed by Lu in view of Reeves and Smets to receive initial scores and recalculate score based on more data with the technique as disclosed by Elenbaas to accurately determine reputation score.
With respect to claim 15:
Lu further teaches providing the authentication provider score for the initial authentication request based on a type of the first computing device. (The selection of the service provider for service requests may be based in part on the value of the compliance parameter, and an attribute of individual service requests which is related to the value of the compliance parameter. Based on the service provider's account data set 128, the account monitor 160 can determine a compliance state 155 of the service provider with respect to the set of compliance rules. In some examples, the compliance state 155 can be binary (e.g., the service provider is in compliance, or not in compliance), trinary (e.g., the service provider is in compliance, not in compliance, or not in compliance but in grace-period), or set within a numeric range to reflect a score or other measure of non-compliance [0006 0040])
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20140233855 A1: User interface 220 may also output the identity of the service provider queried by identity verifications service query controller 214, such that the user may determine a level of confidence to assign to the results based on the identity of the service provider or wherein a performance rating for the service provider can be accessed from a third party service that monitors the performance rating of identity verification services and the performance rating can also be displayed in user interface 220. In one example, a user may assign a greater level of confidence to an identity verification service provider that is well known or well rated and the user may assign a different level of confidence to an identity verification service provider that is hosted by the organization itself versus one that is hosted by a third party.
US 20200244645 A1: A service provider receives, from a subset of the plurality of identity providers, the user identity information and selects a subset of the received user identity information to be used in verifying an identity of a user based, at least in part, on a reputation score associated with each identity provider in the subset of identity providers. The service provider generates a composite user identity based on the selected subset of the received user identity information. The service provider takes one or more actions to enable use of a service based on the generated composite user identity.
US 20240372719 A1: a resource system 130 may select an identity provider system 150 based on the type or types of credentials 105 the identity provider system 150 can issue. A resource system 130 may additionally or alternatively select an identity provider system 150 based other information such as security protocols it has in place, third-party evaluation of its services and/or security, reputation in the industry, etc.
US 20090150252 A1: In general in one aspect, a request is received from a consumer of services in a first geographical location to consult with a service provider having a service provider profile that satisfies at least some attributes in a set of attributes that define a suitable service provider. A user interface that indicates available service providers and their respective geographic locations is rendered on a system. The consumer selects an available service provider in a second, different geographical location from the consumer and the available service provider satisfies at least some of the attributes in the set of attributes. A communication channel between the consumer of services and the selected service provider is established.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZESHENG XIAO whose telephone number is (571)272-6627. The examiner can normally be reached 10:00am-4:30pm M-F.
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, Patrick McAtee can be reached on (571) 272-7575. 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.
/Z.X./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698