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 11/12/2025 has been entered.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claims 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mahaffey et al (2014/0189808) in view of Bennison (2023/0155812), Bhasin et al (2022/0271935) and Beck et al (WO 2022040441).
For claim 1, Mahaffey teaches a method (abstract) comprising: generating, by a processing device, a request for an authorization token by a plugin (Mahaffey teaches that the client may request authorization from server to login or perform action which authorizing client to ask for authorization, what form of authorization to engage in (e.g. push, phone call, SMS, email), how long to authorize for (e.g. ask for 30 minutes of authorization for all sites), If the user has multiple accounts, allow them to choose which to login as, the request will then contain information regarding which account to authorize login to, the options may also specify a challenge token provided by the service that will be responded to by server if authorization is successful (e.g. digitally signed, HMAC, etc. as Mahaffey teaches in par.50-51 and par.131); causing, by the processing device responsive to the request, display of a user interface (UI) output by an authorization provider module, the user interface configured to receive an input approving execution of the plugin (Mahaffey teaches that the server authenticates the user, then displays a confirmation of the request (e.g., to confirm whether or not user wants to allow the requestor to gain access). For example, a server may use a user's Facebook account as its source of authentication. For that reason, the client must prove that it can connect with a user's Facebook account in order to claim to have access to that user's account information as Mahaffey teaches in par.62); generating, by the processing device, a call to the target authorization system, the call including the authorization code (Mahaffey teaches that the server can issue a challenge that is encrypted with the shared secret (either as a key or content, such as in an HMAC scheme) and returned to the server as a response; a phone number that allows the server to call and ask the user to confirm (e.g., by pressing a touch tone key), by entering a PIN code over the phone previously associated with the user's account, or by providing the user a code they need to input into the client) so that it may be, in turn, supplied to the server to prove that the user of the client as Mahaffey teaches in par.63 and 65);
and executing, by the processing device, the plugin using the authorization token (Mahaffey teaches that once proper credentials are provided, an authorization is issued. An authorization from the server is an indication (e.g. yes/no, true/false) of whether the action is allowed. The authorization can also take the form of a token that grants access or is proof of allowance of an access, token can be provided to any system that needs proof that a given user is authorized for a particular action as Mahaffey teaches in par.65).
Mahaffey fails to teach that communicating, by the processing device, the input approving execution of the plugin for receipt by a target authorization system, the input configured to cause the target authorization system to generate an authorization code for communication to the plugin as redirected via the authorization provider module, the plugin, the authorization provider module, and the target authorization system implemented separately, one to another, via a network; receiving, by the processing device, the authorization code at the plugin as redirected via the authorization provider module from the target authorization system, and receiving, by the processing device, the authorization token from the target authorization system in response to the target authorization system receiving the : authorization code.
Bennison teaches, similar system, communicating, by the processing device, the input approving execution of the plugin or system for receipt by a target authorization system, the input configured to cause the target authorization system to generate an authorization code for communication to the plugin as redirected via the authorization provider module (Bennison teaches that when the remote authentication system's settlement process completes a payment authorization and e-mails the receipt with the transaction details along with the confirmation code as Bennison teaches in par.184). It would have been obvious to one ordinary skill in the art before effective filling date to modify Mahaffey to include input approving execution of the plugin or system for receipt by a target authorization system, the input configured to cause the target authorization system to generate an authorization code for communication to the authorization provider module as taught and suggested by Bennison for the purpose of providing automated, near real-time fraud detection and alerting in the event a fraudster launches an attack or somehow compromises other components of the e-commerce system (e.g., the merchant's system, the remote authentication system, the financial institution's system) and successfully counterfeits a transaction (Bennison, par.184). Mahaffey, as modified by Bennison, does not explicitly teach the plugin, the authorization provider module, and the target authorization system implemented separately, one to another, via a network; receiving, by the processing device, the authorization code at the plugin as redirected via the authorization provider module from the target authorization system, and receiving, by the processing device, the authorization token from the target authorization system in response to the target authorization system receiving the authorization code.
Beck teaches, similar system, the plugin, the authorization provider module, and the target authorization system implemented separately, one to another, via a network (Beck teaches that The authorizing domain 110 may comprise a user using a user computing device 1 , an access control server (ACS) 102, and an authorizing entity computer 112. In some embodiments, the ACS 102 may be part of authorizing entity computer 112. Authorizing entity computer 112 may be a server computing device that is programmed to authorize or decline interactions such as payment transactions or data requests and The processing network 129 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services, and may be in operative communication with entities in the authorizing domain 110 and transport domain 130 as Beck teaches in par.34-38); receiving, by the processing device, the authorization code at the plugin as redirected via the authorization provider module from the target authorization system (Beck teaches that a resource provider plug-in 134, a gateway 135, and transport computer 136. Transport computer 136 may be operated by a server computing device and may include a processing module. The processing module may comprise code to enable communication between the transport domain 130 and interoperability domain 120 for transaction processing as Beck teaches in par.37-38 and 48). It would have been obvious to one ordinary skill in the art before effective filling date to modify Mahaffey, as modified by Bennison, to include the plugin, the authorization provider module, and the target authorization system implemented separately, one to another as taught and suggested by Beck for the purpose of providing communication between the transport domain 130 and interoperability domain 120 for transaction processing and verify the authorizing entity’s digital signature that is in an authentication response message, and he plug-in 134 may be managed by a separate server computer (Beck, par.38). Mahaffey, as modified by Bennison and Beck, does not explicitly teach receiving, by the processing device, the authorization token from the target authorization system in response to the target authorization system receiving the authorization code.
Bhasin teaches, similar system, receiving, by the processing device, the authorization token from the target authorization system in response to the target authorization system receiving the authorization code (Bhasin teaches that receive, from the first system, a digitally signed authorization code generated by the first system based on the authorization code and a private key corresponding to the public key associated with the first system; verify the digitally signed authorization code based on the public key and the authorization code; and in response to verifying the digitally signed authorization code, transmit an access token to the first system, wherein the access token is configured to authorize a user with the first system as Bhasin teaches in par.8). It would have been obvious to one ordinary skill in the art before effective filling date to modify Mahaffey, as modified by Bennison and Beck, to include authorization token from the target authorization system in response to the target authorization system receiving the authorization code as taught and suggested by Bhasin for the purpose of providing enhanced security for actions committed by a first system through a second system on behalf of a user e.g. allowing a first system to make a payment on behalf of a user (Bhasin, par.50).
For claim 2, Mahaffey, in view of Bennison, Beck and Bhasin further teaches registering, by the processing device, the plugin (Mahaffey, par.53); and retrieving, by the processing device, a client identifier via a plugin application programming interface of the plugin (Mahaffey, par.88).
For claim 3, Mahaffey, in view of Bennison, Beck and Bhasin further teaches wherein the retrieving includes generating a user interface that is configured to receive an input authorizing execution of the plugin (Mahaffey, par.108).
For claim 4, Mahaffey, in view of Bennison, Beck and Bhasin further teaches wherein the request specifies at least one of a network address of a target authorization system, an authorization type, a client identifier, a response type, a scope, and a challenger code (Mahaffey, par.46).
For claims 5 and 16, Mahaffey, in view of Bennison, Beck and Bhasin further teaches wherein the generating of the request for the authorization token includes executing the plugin in a sandboxed iframe (Mahaffey, par.184).
For claim 6, Mahaffey, in view of Bennison, Beck and Bhasin further teaches wherein the request is configured to cause a provider application programming interface (API) to pass the request to an authorization provider module, which causes the authorization provider module to load the user interface from a target authorization system specified in the request (Mahaffey, par.53).
For claims 7 and 17, Mahaffey, in view of Bennison, Beck and Bhasin further teaches wherein the displaying of the UI includes displaying a pop-up window (Mahaffey, par.112).
For claims 8 and 18, Mahaffey, in view of Bennison, Beck and Bhasin further teaches wherein the input received authorizing execution of the plugin includes credentials associated with a client identifier (Mahaffey, par.52).
For claims 9 and 19, Mahaffey, in view of Bennison, Beck and Bhasin further teaches wherein the authorization code is received as a uniform resource locator parameter (Mahaffey, par.148).
For claim 10, Mahaffey, in view of Bennison, Beck and Bhasin further teaches storing the authorization token locally as permitting continued execution of the plugin (Mahaffey, par.101).
For claim 11, Mahaffey teaches system (abstract) comprising: a processing device; and a computer-readable storage medium storing instructions that, responsive to execution by the processing device (abstract), causes the processing device to perform operations including: receiving an input approving execution of a plugin, the input received via a user interface (UI) (Bennison teaches that when the remote authentication system's settlement process completes a payment authorization and e-mails the receipt with the transaction details along with the confirmation code as Bennison teaches in par.184), generating a call via network to the target authorization system, the call including the authorization code (Mahaffey teaches that the server can issue a challenge that is encrypted with the shared secret (either as a key or content, such as in an HMAC scheme) and returned to the server as a response; a phone number that allows the server to call and ask the user to confirm (e.g., by pressing a touch tone key), by entering a PIN code over the phone previously associated with the user's account, or by providing the user a code they need to input into the client) so that it may be, in turn, supplied to the server to prove that the user of the client as Mahaffey teaches in par.63 and 65
and executing the plugin based on the authorization token (Mahaffey teaches that once proper credentials are provided, an authorization is issued. An authorization from the server is an indication (e.g. yes/no, true/false) of whether the action is allowed. The authorization can also take the form of a token that grants access or is proof of allowance of an access, token can be provided to any system that needs proof that a given user is authorized for a particular action as Mahaffey teaches in par.65).
Mahaffey fails to teach that communicating the input via network for receipt by a target authorization system, the input configured to cause the target authorization system to generate an authorization code for communication to an authorization provider module, the plugin, the authorization provider module, and the target authorization system implemented separately, one to another, via a network; receiving the authorization code at the plugin via the network from as redirected via the authorization provider module from the target authorization system and receiving the authorization token from the target authorization system via network in response to the target authorization system receiving the authorization code.
Bennison teaches, similar system, communicating the input via network for receipt by a target authorization system, the input configured to cause the target authorization system to generate an authorization code for communication to an authorization provider module (Bennison teaches that when the remote authentication system's settlement process completes a payment authorization and e-mails the receipt with the transaction details along with the confirmation code as Bennison teaches in par.184). It would have been obvious to one ordinary skill in the art before effective filling date to modify Mahaffey to include input approving execution of the plugin or system for receipt by a target authorization system, the input configured to cause the target authorization system to generate an authorization code for communication to the authorization provider module as taught and suggested by Bennison for the purpose of providing automated, near real-time fraud detection and alerting in the event a fraudster launches an attack or somehow compromises other components of the e-commerce system (e.g., the merchant's system, the remote authentication system, the financial institution's system) and successfully counterfeits a transaction (Bennison, par.184). Mahaffey, as modified by Bennison, does not explicitly teach the plugin, the authorization provider module, and the target authorization system implemented separately, one to another, via a network; receiving the authorization code at the plugin via the network from as redirected via the authorization provider module from the target authorization system and receiving the authorization token from the target authorization system via network in response to the target authorization system receiving the authorization code.
Beck teaches, similar system, the plugin, the authorization provider module, and the target authorization system implemented separately, one to another, via a network (Beck teaches that The authorizing domain 110 may comprise a user using a user computing device 1 , an access control server (ACS) 102, and an authorizing entity computer 112. In some embodiments, the ACS 102 may be part of authorizing entity computer 112. Authorizing entity computer 112 may be a server computing device that is programmed to authorize or decline interactions such as payment transactions or data requests and The processing network 129 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services, and may be in operative communication with entities in the authorizing domain 110 and transport domain 130 as Beck teaches in par.34-38); receiving the authorization code at the plugin via the network from as redirected via the authorization provider module from the target authorization system (Beck teaches that a resource provider plug-in 134, a gateway 135, and transport computer 136. Transport computer 136 may be operated by a server computing device and may include a processing module. The processing module may comprise code to enable communication between the transport domain 130 and interoperability domain 120 for transaction processing as Beck teaches in par.37-38 and 48). It would have been obvious to one ordinary skill in the art before effective filling date to modify Mahaffey, as modified by Bennison, to include the plugin, the authorization provider module, and the target authorization system implemented separately, one to another as taught and suggested by Beck for the purpose of providing communication between the transport domain 130 and interoperability domain 120 for transaction processing and verify the authorizing entity’s digital signature that is in an authentication response message, and he plug-in 134 may be managed by a separate server computer (Beck, par.38). Mahaffey, as modified by Bennison and Beck, does not explicitly teach receiving, by the processing device, the authorization token from the target authorization system via network in response to the target authorization system receiving the authorization code.
Bhasin teaches, similar system, receiving the authorization token from the target authorization system via network in response to the target authorization system receiving the authorization code (Bhasin teaches that receive, from the first system, a digitally signed authorization code generated by the first system based on the authorization code and a private key corresponding to the public key associated with the first system; verify the digitally signed authorization code based on the public key and the authorization code; and in response to verifying the digitally signed authorization code, transmit an access token to the first system, wherein the access token is configured to authorize a user with the first system as Bhasin teaches in par.8). It would have been obvious to one ordinary skill in the art before effective filling date to modify Mahaffey, as modified by Bennison and Beck, to include authorization token from the target authorization system in response to the target authorization system receiving the authorization code as taught and suggested by Bhasin for the purpose of providing enhanced security for actions committed by a first system through a second system on behalf of a user e.g. allowing a first system to make a payment on behalf of a user (Bhasin, par.50).
For claim 12, Mahaffey, in view of Bennison, Beck and Bhasin further teaches wherein the operations further include determining whether a user identifier associated with the plugin is already authorized by checking secure local storage (Mahaffey, par.44).
For claim 13, Mahaffey, in view of Bennison, Beck and Bhasin further teaches wherein the operations further include generating a user interface that is configured to receive an input authorizing execution of the plugin (Mahaffey, par.108).
For claim 14, Mahaffey, in view of Bennison, Beck and Bhasin further teaches wherein the authorization provider module is implemented as part of a software development kit (Mahaffey, par.38)..
For claim 15, Mahaffey, in view of Bennison, Beck and Bhasin further teaches wherein the operations further the request specifying at least one of a network address of a target authorization system, an authorization type, a client identifier, a response type, a scope, and a challenger code (Mahaffey, par.46).
Mahaffey fails to teach include communicating a request for receipt by the target authorization system.
Bennison teaches that communicating a request for receipt by the target authorization system (par.184). It would have been obvious to one ordinary skill in the art before effective filling date to modify Mahaffey to include communicating a request for receipt by the target authorization system as taught and suggested by Bennison for the purpose of providing automated, near real-time fraud detection and alerting in the event a fraudster launches an attack or somehow compromises other components of the e-commerce system (e.g., the merchant's system, the remote authentication system, the financial institution's system) and successfully counterfeits a transaction (Bennison, par.184).
For claim 20, Mahaffey teaches non-transitory computer-readable storage medium storing executable instructions, which when executed by a processing device, cause the processing device to perform operations (par.38) comprising: registering, via network, a plugin associated with a target authorization system using an authorization redirect application (Mahaffey teaches that authentication/authorization mechanism or interacting with a service's existing mechanisms, a form detection and analysis component, web browser registration/login tools, mobile keyboard (e.g., a software keyboard module that can log in and register accounts) support, a mobile application authentication API (application program interface), mobile app authentication to a server, and credential transport security mechanisms as Mahaffey teaches in par.53); retrieving, via network, a client identifier via a plugin application programming interface of an authorization provider module (Mahaffey teaches of identiffer in par.44); receiving, by the authorization provider module, via network, a request for an authorization token by the plugin; causing, in response to the request, display of a user interface received from a target authorization system by the authorization provider module, the user interface configured to receive an input approving execution of the plugin (Mahaffey teaches that the server authenticates the user, then displays a confirmation of the request (e.g., to confirm whether or not user wants to allow the requestor to gain access). For example, a server may use a user's Facebook account as its source of authentication. For that reason, the client must prove that it can connect with a user's Facebook account in order to claim to have access to that user's account information as Mahaffey teaches in par.62).
Mahaffey fails to teach that communicating the input approving execution of the plugin for receipt by the target authorization system, the input configured to cause the target authorization system to generate an authorization code for communication to the authorization provider module; the plugin, the authorization provider module, and the target authorization system implemented separately via a network and sending the authorization code received from the target authorization system as redirected to the plugin by the authorization provider module, the authorization code configured to enable receipt of an authorization token from the target authorization system in response to the target authorization system receiving the authorization code.
Bennison teaches, similar system, communicating the input approving execution of the plugin for receipt by the target authorization system, the input configured to cause the target authorization system to generate an authorization code for communication to the authorization provider module (Bennison teaches that when the remote authentication system's settlement process completes a payment authorization and e-mails the receipt with the transaction details along with the confirmation code as Bennison teaches in par.184),. It would have been obvious to one ordinary skill in the art before effective filling date to modify Mahaffey to include input approving execution of the plugin or system for receipt by a target authorization system, the input configured to cause the target authorization system to generate an authorization code for communication to the authorization provider module as taught and suggested by Bennison for the purpose of providing automated, near real-time fraud detection and alerting in the event a fraudster launches an attack or somehow compromises other components of the e-commerce system (e.g., the merchant's system, the remote authentication system, the financial institution's system) and successfully counterfeits a transaction (Bennison, par.184). Mahaffey, as modified by Bennison, does not explicitly teach the plugin, the authorization provider module, and the target authorization system implemented separately via a network and sending the authorization code received from the target authorization system as redirected to the plugin by the authorization provider module, the authorization code configured to enable receipt of an authorization token from the target authorization system in response to the target authorization system receiving the authorization code.
Beck teaches, similar system, the plugin, the authorization provider module, and the target authorization system implemented separately, one to another, via a network (Beck teaches that The authorizing domain 110 may comprise a user using a user computing device 1 , an access control server (ACS) 102, and an authorizing entity computer 112. In some embodiments, the ACS 102 may be part of authorizing entity computer 112. Authorizing entity computer 112 may be a server computing device that is programmed to authorize or decline interactions such as payment transactions or data requests and The processing network 129 may include data processing subsystems, networks, and operations used to support and deliver authorization services, exception file services, and clearing and settlement services, and may be in operative communication with entities in the authorizing domain 110 and transport domain 130 as Beck teaches in par.34-38); sending the authorization code received from the target authorization system as redirected to the plugin by the authorization provider module (Beck teaches that a resource provider plug-in 134, a gateway 135, and transport computer 136. Transport computer 136 may be operated by a server computing device and may include a processing module. The processing module may comprise code to enable communication between the transport domain 130 and interoperability domain 120 for transaction processing as Beck teaches in par.37-38 and 48). It would have been obvious to one ordinary skill in the art before effective filling date to modify Mahaffey, as modified by Bennison, to include the plugin, the authorization provider module, and the target authorization system implemented separately, one to another as taught and suggested by Beck for the purpose of providing communication between the transport domain 130 and interoperability domain 120 for transaction processing and verify the authorizing entity’s digital signature that is in an authentication response message, and he plug-in 134 may be managed by a separate server computer (Beck, par.38). Mahaffey, as modified by Bennison and Beck, does not explicitly teach the authorization code configured to enable receipt of an authorization token from the target authorization system in response to the target authorization system receiving the authorization code.
Bhasin teaches, similar system, the authorization code configured to enable receipt of an authorization token from the target authorization system in response to the target authorization system receiving the authorization code (Bhasin teaches that receive, from the first system, a digitally signed authorization code generated by the first system based on the authorization code and a private key corresponding to the public key associated with the first system; verify the digitally signed authorization code based on the public key and the authorization code; and in response to verifying the digitally signed authorization code, transmit an access token to the first system, wherein the access token is configured to authorize a user with the first system as Bhasin teaches in par.8). It would have been obvious to one ordinary skill in the art before effective filling date to modify Mahaffey, as modified by Bennison and Beck, to include in response to the target authorization system receiving the authorization code as taught and suggested by Bhasin for the purpose of providing enhanced security for actions committed by a first system through a second system on behalf of a user e.g. allowing a first system to make a payment on behalf of a user (Bhasin, par.50).
Response to Amendments/Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
The applicant’s arguments regarding new in claims 1, 11, and 20 have been considered but is moot, because the examiner applied new art, Beck et al (WO 2022040441), that covers newly claimed limitation.
Regarding dependent claims arguments, said arguments are moot because the applied references are not considered to have alleged differences, and therefore are considered to properly show that for which they were cited.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AYUB A MAYE whose telephone number is (571)270-5037. The examiner can normally be reached Monday-Friday 9AM-5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SHEWAYE GELAGAY can be reached at 571-272-4219. 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.
/AYUB A MAYE/Examiner, Art Unit 2436 /SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436