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 .
Claim Objections
Claim 20 is objected to because of the following informalities: “s identifying that the request includes sel3ections” (line 8) should presumably read “identifying that the request includes selections”. Appropriate correction is required.
Claim 20 is objected to because of the following informalities: “workflowand” (line 16) should read “workflow and”. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites “the first mobile device” (line 5). There is insufficient antecedent basis for this limitation in the claim. Independent claims 13 and 20 recite similar language and are similarly rejected. Dependent claims 2-12 and 14-19 inherit this discrepancy by nature of their dependencies. Appropriate correction is required.
Claim 1 recites “a plurality of different remote authorization services” (line 7) and “the plurality of remote authorization services” (line 11). Consistent usage of the same terms is much preferred over creatively describing the same elements using different language. Using similar, yet slightly different claim language creates confusion. It is unclear whether each term is intended to refer to the same claim element or whether each term refers to a different claim element. Appropriate correction is required. Independent claims 13 and 20 recite similar language and are similarly rejected. Dependent claims 2-12 and 14-19 inherit this discrepancy by nature of their dependencies. Appropriate correction is required.
Claim 1 recites “different amounts of gameplay” (lines 7-8) and “the selected amount of gameplay” (lines 19-20). Consistent usage of the same terms is much preferred over creatively describing the same elements using different language. Using similar, yet slightly different claim language creates confusion. It is unclear whether each term is intended to refer to the same claim element or whether each term refers to a different claim element. Appropriate correction is required. Independent claims 13 and 20 recite similar language and are similarly rejected. Dependent claims 2-12 and 14-19 inherit this discrepancy by nature of their dependencies. Appropriate correction is required.
Claim 1 recites “a first authentication information” (line 15) and “the authentication information” (line 17). Consistent usage of the same terms is much preferred over creatively describing the same elements using different language. Using similar, yet slightly different claim language creates confusion. It is unclear whether each term is intended to refer to the same claim element or whether each term refers to a different claim element. Appropriate correction is required. Independent claims 13 and 20 recite similar language and are similarly rejected. Dependent claims 2-12 and 14-19 inherit this discrepancy by nature of their dependencies. Appropriate correction is required.
Claim 3 recites “memory” (line 4) and “a unique device identifier” (line 5). Claim 2, upon which claim 3 depends, recites “memory” (line 2) and “a unique device identifier” (line 3). The first instance of a claim element should generally subsequently be followed by referring to the element using “the” or “said”. Using "a” or “an" (or using no indefinite article) for the subsequently recited claim elements creates confusion as to whether the first instance of the claim element is being referred to or whether a new claim element is being identified. Dependent claims 4-7 inherit this discrepancy by nature of their dependencies. Appropriate correction is required.
Claim 4 recites “a second request” (line 2) and “the request” (line 3). Claim 1, upon which claim 4 ultimately depends recites “a request” (line 2). It is unclear whether “the request” of claim 4 refers to the “second request” or the “request” of claim 1. Dependent claim 15 recites similar language and is similarly rejected. Dependent claims 5 and 16 inherit this discrepancy by nature of their dependencies. Appropriate correction is required.
Claim 4 recites “the first microsite” (line 5). There is insufficient antecedent basis for this limitation in the claim. Dependent claim 15 recites similar language and is similarly rejected. Dependent claims 5 and 16 inherit this discrepancy by nature of their dependencies. Appropriate correction is required.
Claim 4 recites “a display” (line 7). Claim 1, upon which claim 4 ultimately depends, recites “a display” (line 13). The first instance of a claim element should generally subsequently be followed by referring to the element using “the” or “said”. Using "a” or “an" (or using no indefinite article) for the subsequently recited claim elements creates confusion as to whether the first instance of the claim element is being referred to or whether a new claim element is being identified. Dependent claims 5 and 15-16 recite similar language and are similarly rejected. Appropriate correction is required.
Claim 5 recites “the stored unique identifier” (line 6). There is insufficient antecedent basis for this limitation in the claim. Dependent claim 16 recites similar language and is similarly rejected. Appropriate correction is required.
Claim 5 recites “the unique identifier” (line 5) and “the stored unique identifier” (line 6). Consistent usage of the same terms is much preferred over creatively describing the same elements using different language. Using similar, yet slightly different claim language creates confusion. It is unclear whether each term is intended to refer to the same claim element or whether each term refers to a different claim element. Appropriate correction is required. Dependent claim 16 recites similar language and is similarly rejected. Appropriate correction is required.
Claim 5 recites “the first virtual credential token” (lines 9-10) and “the stored first virtual credential token” (line 12). Consistent usage of the same terms is much preferred over creatively describing the same elements using different language. Using similar, yet slightly different claim language creates confusion. It is unclear whether each term is intended to refer to the same claim element or whether each term refers to a different claim element. Appropriate correction is required. Dependent claim 16 recites similar language and is similarly rejected. Appropriate correction is required.
Claim 7 recites “the generated display” (lines 8-9). There is insufficient antecedent basis for this limitation in the claim. Appropriate correction is required.
Claim 7 recites “the display” (line 10) and “the updated display” (line 11). Consistent usage of the same terms is much preferred over creatively describing the same elements using different language. Using similar, yet slightly different claim language creates confusion. It is unclear whether each term is intended to refer to the same claim element or whether each term refers to a different claim element. Appropriate correction is required.
Claim 7 recites “confirmation” (line 14). Claim 1, upon which claim 7 depends, recites “confirmation” (line 17). The first instance of a claim element should generally subsequently be followed by referring to the element using “the” or “said”. Using "a” or “an" (or using no indefinite article) for the subsequently recited claim elements creates confusion as to whether the first instance of the claim element is being referred to or whether a new claim element is being identified. Dependent claim 12 recites similar language and is similarly rejected. Appropriate correction is required.
Claim 8 recites “an account” (line 4). Claim 1, upon which claim 8 depends, recites “a user account” (line 15). Consistent usage of the same terms is much preferred over creatively describing the same elements using different language. Using similar, yet slightly different claim language creates confusion. It is unclear whether each term is intended to refer to the same claim element or whether each term refers to a different claim element. Dependent claim 17 recites similar language and is similarly rejected. Dependent claims 9-10 and 18-19 inherit this discrepancy by nature of their dependencies. Appropriate correction is required.
Claim 14 recites “a user account” (line 4). Claim 13, upon which claim 14 depends, recites “a user account” (lines 17-18). The first instance of a claim element should generally subsequently be followed by referring to the element using “the” or “said”. Using "a” or “an" (or using no indefinite article) for the subsequently recited claim elements creates confusion as to whether the first instance of the claim element is being referred to or whether a new claim element is being identified. Dependent claims 15-16 inherit this discrepancy by nature of their dependencies. Appropriate correction is required.
Claim 14 recites “memory” (line 4). Claim 13, upon which claim 14 depends, recites “memory” (line 6). The first instance of a claim element should generally subsequently be followed by referring to the element using “the” or “said”. Using "a” or “an" (or using no indefinite article) for the subsequently recited claim elements creates confusion as to whether the first instance of the claim element is being referred to or whether a new claim element is being identified. Dependent claims 15-16 inherit this discrepancy by nature of their dependencies. Appropriate correction is required.
Claim 15 recites “the mobile microsite server” (line 1). There is insufficient antecedent basis for this limitation in the claim. Appropriate correction is required.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-2, 8, 11-13, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Herman, US 2023/0121270 A1 (hereinafter Herman), in view of Aronowitz et al., US 2018/0034859 A1 (hereinafter Aronowitz), and further in view of Ellis et al., US 2023/0114727 A1 (hereinafter Ellis).
Regarding Claim 1: Herman discloses a method of integrated mobile microsites for remote authorization, the method comprising:
receiving a request sent over a communication network from a security server to a remote authorization server, the request including information received at a microsite associated with a uniform resource locator (URL) encoded within an image scanned by a camera of the first mobile device (Herman, the information from the respective account profile associated with the user includes a payment account number or an electronic money transfer request [0018]; the microsite 100 can transmit payment authorization requests on behalf of multiple merchants, for example, via a payment gateway to each merchant's particular payment processor in the payment network [0063]; initiating transactions from the vendor, for example using any number of means such as the user scanning a barcode (e.g., two-dimensional code such as QR code) at the merchant location [0064]; the authorization request for each mobile payment transaction therefore includes information about the consumer (i.e., information from the respective account profile for the user) and information about the particular vendor; the server and/or microsite acts as a surrogate for the first and second vendors in the first and second mobile payment transactions, respectively [0073]);
identifying that the request includes selections made from among one or more options corresponding to a plurality of different remote authorization services and different amounts (Herman, the user has selected “Pay for Fuel” and is presented with an option to select a pump; in FIG. 7C, fueling is authorized and the user is presented with instructions for completing the transaction [0086]; the information from the respective account profile associated with the user includes a token; optionally, the information from the respective account profile associated with the user includes a payment account number or an electronic money transfer request [0018]; the microsite initiates an authorization request, which includes the token and purchase information [0084]); and
sending an authorization confirmation to the security server based on confirmation of the authentication information from the selected remote authorization service (Herman, at 1094, the payment processor for the merchant of record transmits the authorization request to a financial institution; for example, the financial institution may be the issuing bank for the consumer's credit, charge or debit card; alternatively, the financial institution may be the consumer's bank (e.g., for person-to-person (P2P) or person-to-business (P2B) payments); at 1095, the financial institution processes the authorization request and either approves or rejects it; the financial institution then transmits the response (approve/reject) back to the payment network as shown in FIG. 10B; at 1096, the response (approve/reject) is transmitted to the particular payment processor for the merchant of record [0081]; the payment network can validate or decline the authorization request and such information can be transmitted back to the microsite via the payment gateway [0084]).
Herman fails to explicitly disclose
gameplay;
launching a first authorization workflow over the communication network between the first mobile device and the remote authorization server in accordance with the selected remote authorization service of the plurality of remote authorization services and the selected amount
updating a display presented to the first mobile device based on the first authorization workflow and the selected remote authorization service, wherein the updated display is configured to receive a first authentication information for a user account of the selected remote authorization service from the first mobile device; and
a risk assessment by a risk engine, wherein the authorization confirmation corresponds to the selected amount of gameplay in association with the user account.
Ellis teaches managing a wager gaming credit management system using a mobile device (Ellis, once credit has been extended to a player, any cash submitted by the player and any of the player's winnings may be selectively used to pay down the wager account, including in some embodiments at the direction of the casino based on, for example, certain automated rules, at the discretion of the player, or a combination thereof [0030]; one or more of a warrantor or third-party financer fund at least a percentage of the funds advanced over a game period 1625; this amount can be characterized as an initial purchase price; tt the time of settlement [0030]; tiered credit approval amount thresholds throttle the timing of credit approval decisions, which in some applications can allow for an increased ability for the casino to include additional activity, including gaming activity and selective pay down activity, and financial information in credit approval decisions for the extension of increased credit amount requests [0035]).
It would have been obvious to one of ordinary skill in the art to modify the system and methods for facilitating mobile payment transactions as disclosed by Herman with the game credits management taught by Ellis since doing so would securely manage gameplay credits.
Aronowitz teaches
launching a first authorization workflow over the communication network between the first mobile device and the remote authorization server in accordance with the selected remote authorization service of the plurality of remote authorization services and the selected amount (Aronowitz, a computer determines a risk associated with an operation that requires authentication of a user of a client device; the computer identifies a plurality of authentication methods, each respective authentication method associated with a level of security offsetting the risk and a computing cost associated with a respective authentication method; the computer selects one or more authentication methods from the plurality of authentication methods according to the risk and to minimize the computing cost associated with authenticating the operation [0004]; given a level of risk associated with a particular transaction, such as, for example, a dollar amount corresponding to a particular financial transaction [0054]; the requesting client device is, such as a mobile client device [0036]);
updating a display presented to the first mobile device based on the first authorization workflow and the selected remote authorization service, wherein the updated display is configured to receive a first authentication information for a user account of the selected remote authorization service from the first mobile device (Aronowitz, the server sends the one or more authentication methods to the client device via a network, such as network 102 in FIG. 1 (step 610) [0084]; display 214 provides a mechanism to display information to a user and may include touch screen capabilities to allow the user to make on-screen selections through user interfaces or input data [0044]; data processing system 200 stores challenge responses 230, along with level of confidence in user identity 232 and user authentication decision 234, in memory 206; challenge responses 230 represent a response to each challenge in the selected subset of challenges sent to the requesting client device; challenge responses 230 may include, for example, a username, a password, a set of one or more biometric samples, location data, and the like [0039]); and
a risk assessment by a risk engine, wherein the authorization confirmation corresponds to the selected amount in association with the user account (Aronowitz, contextual factors are to be collected from the requesting client device to achieve sufficient confidence in the user's identity to mitigate the risk associated with allowing access to a protected resource; for example, given a level of risk associated with a particular transaction, such as, for example, a dollar amount corresponding to a particular financial transaction and associated historical factors regarding other financial transactions performed by the same user; the user to use a particular authentication method, time for the client device to obtain the data, time for the authentication server to process the data including network delays [0054]).
It would have been obvious to one of ordinary skill in the art to combine the system and methods for facilitating mobile payment transactions disclosed by Herman with the authentication methods taught by Aronowitz since doing so would perform adaptive authentication to improve the security of the transaction.
Regarding Claim 2: Ellis further teaches storing a plurality of virtual credential tokens associated with different user accounts in memory, wherein each of the virtual credential tokens is associated with a personal identification number (PIN), a unique device identifier, and account information associated with one of the different remote authorization services (Ellis [0068]; ]0201]; [0234]; [0278]; [0280]; [0350]).
Regarding Claim 8: Ellis further teaches calling the risk engine to generate the risk assessment by:
evaluating whether a creditable amount associated with the first amount of gameplay is available in an account at the selected remote authorization service (Ellis [0190]; [0241]).
Aronowitz further teaches calling the risk engine to generate the risk assessment by:
determining, based on historical datapoints and whether there is the creditable amount, whether to authorize the selected amount of gameplay (Aronowitz [0061]; [0062]; [0085]).
Regarding Claim 11: Ellis further teaches wherein the authorized first amount of gameplay corresponds to a number of virtual tokens for gameplay (Ellis [0035]; [0058]-[0060]).
Regarding Claim 12: Ellis further teaches wherein confirmation is a sent to an electronic gaming machine over the communication network, wherein the confirmation authorizes the selected amount of gameplay at the electronic gaming machine (Ellis, [0033]; [0233]; [0308]).
Regarding Claim 13: Herman discloses a system of integrated mobile microsites for remote authorization, the system comprising:
a communication interface that communicates over a communication network to receive a request from a security server, the request including information received at a microsite associated with a uniform resource locator (URL) encoded within an image scanned by a camera of the first mobile device (Herman, initiating transactions from the vendor, for example using any number of means such as the user scanning a barcode (e.g., two-dimensional code such as QR code) at the merchant location [0064]; the microsite 100 can be hosted at a server (e.g., computing device 300 of FIG. 3); a user's device (e.g., computing device 300 of FIG. 3) can be operably coupled to the microsite 100 by one or more networks; the user's device is optionally a mobile computing device such as a smart phone, tablet computer, smart watch, etc.; in other implementations described herein, the user's device is optionally an Internet-connected device such as a television (e.g., “connected TV” in FIG. 1), an appliance, or a vehicle (e.g., “connected car” in FIG. 1). This disclosure contemplates that the networks are any suitable communication network; the networks can be similar to each other in one or more respects; alternatively or additionally, the networks can be different from each other in one or more respects; the networks can include a local area network (LAN), a wireless local area network (WLAN), a wide area network (WAN), a metropolitan area network (MAN), a virtual private network (VPN), etc., including portions or combinations of any of the above networks; the mobile computing device and the microsite 100 discussed above can be coupled to the networks through one or more communication links; this disclosure contemplates the communication links are any suitable communication link; for example, a communication link may be implemented by any medium that facilitates data exchange between the mobile computing device and the microsite 100 including, but not limited to, wired, wireless and optical links; example communication links include, but are not limited to, a LAN, a WAN, a MAN, Ethernet, the Internet, or any other wired or wireless link such as WiFi, WiMax, 3G, 4G, or 5G [0065]);
a processor that executes instructions stored in memory (Herman, the system includes a server comprising a processor and a memory in operable communication with the processor, the memory having computer-executable instructions stored thereon [0030]), wherein the processor executes the instructions to:
identify that the request includes selections made from among one or more options corresponding to a plurality of different remote authorization services and different amounts (Herman, the user has selected “Pay for Fuel” and is presented with an option to select a pump; in FIG. 7C, fueling is authorized and the user is presented with instructions for completing the transaction [0086]; the information from the respective account profile associated with the user includes a token; optionally, the information from the respective account profile associated with the user includes a payment account number or an electronic money transfer request [0018]; the microsite initiates an authorization request, which includes the token and purchase information [0084]);
wherein the communication interface sends an authorization confirmation to the security server based on confirmation of the authentication information from the selected remote authorization service (Herman, at 1094, the payment processor for the merchant of record transmits the authorization request to a financial institution; for example, the financial institution may be the issuing bank for the consumer's credit, charge or debit card; alternatively, the financial institution may be the consumer's bank (e.g., for person-to-person (P2P) or person-to-business (P2B) payments); at 1095, the financial institution processes the authorization request and either approves or rejects it; the financial institution then transmits the response (approve/reject) back to the payment network as shown in FIG. 10B; at 1096, the response (approve/reject) is transmitted to the particular payment processor for the merchant of record [0081]; the payment network can validate or decline the authorization request and such information can be transmitted back to the microsite via the payment gateway [0084]).
Herman fails to explicitly disclose
gameplay;
launch a first authorization workflow over the communication network between the first mobile device and the remote authorization server in accordance with the selected remote authorization service of the plurality of remote authorization services and the selected amount;
update a display presented to the first mobile device based on the first authorization workflow and the selected remote authorization service, wherein the updated display is configured to receive a first authentication information for a user account of the selected remote authorization service from the first mobile device; and
a risk assessment by a risk engine, wherein the authorization confirmation corresponds to the selected amount of gameplay in association with the user account.
Ellis teaches managing a wager gaming credit management system using a mobile device (Ellis, once credit has been extended to a player, any cash submitted by the player and any of the player's winnings may be selectively used to pay down the wager account, including in some embodiments at the direction of the casino based on, for example, certain automated rules, at the discretion of the player, or a combination thereof [0030]; one or more of a warrantor or third-party financer fund at least a percentage of the funds advanced over a game period 1625; this amount can be characterized as an initial purchase price; tt the time of settlement [0030]; tiered credit approval amount thresholds throttle the timing of credit approval decisions, which in some applications can allow for an increased ability for the casino to include additional activity, including gaming activity and selective pay down activity, and financial information in credit approval decisions for the extension of increased credit amount requests [0035])
As recited above with respect to claim 1, it would have been obvious to one of ordinary skill in the art to modify the system and methods for facilitating mobile payment transactions as disclosed by Herman with the game credits management taught by Ellis since doing so would securely manage gameplay credits.
Aronowitz teaches
launch a first authorization workflow over the communication network between the first mobile device and the remote authorization server in accordance with the selected remote authorization service of the plurality of remote authorization services and the selected amount (Aronowitz, a computer determines a risk associated with an operation that requires authentication of a user of a client device; the computer identifies a plurality of authentication methods, each respective authentication method associated with a level of security offsetting the risk and a computing cost associated with a respective authentication method; the computer selects one or more authentication methods from the plurality of authentication methods according to the risk and to minimize the computing cost associated with authenticating the operation [0004]; given a level of risk associated with a particular transaction, such as, for example, a dollar amount corresponding to a particular financial transaction [0054]; the requesting client device is, such as a mobile client device [0036]);
update a display presented to the first mobile device based on the first authorization workflow and the selected remote authorization service, wherein the updated display is configured to receive a first authentication information for a user account of the selected remote authorization service from the first mobile device (Aronowitz, the server sends the one or more authentication methods to the client device via a network, such as network 102 in FIG. 1 (step 610) [0084]; display 214 provides a mechanism to display information to a user and may include touch screen capabilities to allow the user to make on-screen selections through user interfaces or input data [0044]; data processing system 200 stores challenge responses 230, along with level of confidence in user identity 232 and user authentication decision 234, in memory 206; challenge responses 230 represent a response to each challenge in the selected subset of challenges sent to the requesting client device; challenge responses 230 may include, for example, a username, a password, a set of one or more biometric samples, location data, and the like [0039]); and
a risk assessment by a risk engine, wherein the authorization confirmation corresponds to the selected amount in association with the user account (Aronowitz, contextual factors are to be collected from the requesting client device to achieve sufficient confidence in the user's identity to mitigate the risk associated with allowing access to a protected resource; for example, given a level of risk associated with a particular transaction, such as, for example, a dollar amount corresponding to a particular financial transaction and associated historical factors regarding other financial transactions performed by the same user; the user to use a particular authentication method, time for the client device to obtain the data, time for the authentication server to process the data including network delays [0054]).
As recited above with respect to claim 1, it would have been obvious to one of ordinary skill in the art to combine the system and methods for facilitating mobile payment transactions disclosed by Herman with the authentication methods taught by Aronowitz since doing so would perform adaptive authentication to improve the security of the transaction.
Regarding Claim 17: Ellis further teaches wherein the security server is further configured to call the risk engine to generate the risk assessment by:
evaluating whether a creditable amount associated with the first amount of gameplay is available in an account at the selected remote authorization service (Ellis [0190]; [0241]).
Aronowitz further teaches:
determining, based on historical datapoints and whether there is the creditable amount, whether to authorize the selected amount of gameplay (Aronowitz [0061]; [0062]; [0085]).
Regarding Claim 20: Herman discloses a non-transitory, computer-readable storage medium comprising instructions embodied thereon, the instructions executable by a computing system to perform a method of integrated mobile microsites for gameplay authorization, the method comprising:
receiving a request over a communication network from a security server to a remote authorization server, the request including information received at a microsite associated with a uniform resource locator (URL) encoded within an image scanned by a camera of the first mobile device (Herman, the information from the respective account profile associated with the user includes a payment account number or an electronic money transfer request [0018]; the microsite 100 can transmit payment authorization requests on behalf of multiple merchants, for example, via a payment gateway to each merchant's particular payment processor in the payment network [0063]; initiating transactions from the vendor, for example using any number of means such as the user scanning a barcode (e.g., two-dimensional code such as QR code) at the merchant location [0064]; the authorization request for each mobile payment transaction therefore includes information about the consumer (i.e., information from the respective account profile for the user) and information about the particular vendor; the server and/or microsite acts as a surrogate for the first and second vendors in the first and second mobile payment transactions, respectively [0073]);
s identifying that the request includes sel3ections made from among one or more options corresponding to a plurality of different remote authorization services and different amounts (Herman, the user has selected “Pay for Fuel” and is presented with an option to select a pump; in FIG. 7C, fueling is authorized and the user is presented with instructions for completing the transaction [0086]; the information from the respective account profile associated with the user includes a token; optionally, the information from the respective account profile associated with the user includes a payment account number or an electronic money transfer request [0018]; the microsite initiates an authorization request, which includes the token and purchase information [0084]);
sending an authorization confirmation to the security server based on confirmation of the authentication information from the selected remote authorization service (Herman, at 1094, the payment processor for the merchant of record transmits the authorization request to a financial institution; for example, the financial institution may be the issuing bank for the consumer's credit, charge or debit card; alternatively, the financial institution may be the consumer's bank (e.g., for person-to-person (P2P) or person-to-business (P2B) payments); at 1095, the financial institution processes the authorization request and either approves or rejects it; the financial institution then transmits the response (approve/reject) back to the payment network as shown in FIG. 10B; at 1096, the response (approve/reject) is transmitted to the particular payment processor for the merchant of record [0081]; the payment network can validate or decline the authorization request and such information can be transmitted back to the microsite via the payment gateway [0084]).
Herman fails to explicitly disclose
gameplay;
launching a first authorization workflow over the communication network between the first mobile device and the remote authorization server in accordance with the selected remote authorization services of the plurality of remote authorization services and including a selection of one of the different amounts;
updating a display presented to the mobile device based on the first authorization workflow and the selected remote authorization service, wherein the updated display is configured to receive a first authentication information for a user account of the selected remote authorization service from the first mobile device; and
a risk assessment by a risk engine, wherein the authorization confirmation corresponds to the selected amount of gameplay in association with the user account.
Ellis teaches managing a wager gaming credit management system using a mobile device (Ellis, once credit has been extended to a player, any cash submitted by the player and any of the player's winnings may be selectively used to pay down the wager account, including in some embodiments at the direction of the casino based on, for example, certain automated rules, at the discretion of the player, or a combination thereof [0030]; one or more of a warrantor or third-party financer fund at least a percentage of the funds advanced over a game period 1625; this amount can be characterized as an initial purchase price; tt the time of settlement [0030]; tiered credit approval amount thresholds throttle the timing of credit approval decisions, which in some applications can allow for an increased ability for the casino to include additional activity, including gaming activity and selective pay down activity, and financial information in credit approval decisions for the extension of increased credit amount requests [0035])
As recited above with respect to claim 1, it would have been obvious to one of ordinary skill in the art to modify the system and methods for facilitating mobile payment transactions as disclosed by Herman with the game credits management taught by Ellis since doing so would securely manage gameplay credits.
Aronowitz teaches
launching a first authorization workflow over the communication network between the first mobile device and the remote authorization server in accordance with the selected remote authorization services of the plurality of remote authorization services and including a selection of one of the different amounts (Aronowitz, a computer determines a risk associated with an operation that requires authentication of a user of a client device; the computer identifies a plurality of authentication methods, each respective authentication method associated with a level of security offsetting the risk and a computing cost associated with a respective authentication method; the computer selects one or more authentication methods from the plurality of authentication methods according to the risk and to minimize the computing cost associated with authenticating the operation [0004]; given a level of risk associated with a particular transaction, such as, for example, a dollar amount corresponding to a particular financial transaction [0054]; the requesting client device is, such as a mobile client device [0036]);
updating a display presented to the mobile device based on the first authorization workflow and the selected remote authorization service, wherein the updated display is configured to receive a first authentication information for a user account of the selected remote authorization service from the first mobile device (Aronowitz, the server sends the one or more authentication methods to the client device via a network, such as network 102 in FIG. 1 (step 610) [0084]; display 214 provides a mechanism to display information to a user and may include touch screen capabilities to allow the user to make on-screen selections through user interfaces or input data [0044]; data processing system 200 stores challenge responses 230, along with level of confidence in user identity 232 and user authentication decision 234, in memory 206; challenge responses 230 represent a response to each challenge in the selected subset of challenges sent to the requesting client device; challenge responses 230 may include, for example, a username, a password, a set of one or more biometric samples, location data, and the like [0039]); and
a risk assessment by a risk engine, wherein the authorization confirmation corresponds to the selected amount in association with the user account (Aronowitz, contextual factors are to be collected from the requesting client device to achieve sufficient confidence in the user's identity to mitigate the risk associated with allowing access to a protected resource; for example, given a level of risk associated with a particular transaction, such as, for example, a dollar amount corresponding to a particular financial transaction and associated historical factors regarding other financial transactions performed by the same user; the user to use a particular authentication method, time for the client device to obtain the data, time for the authentication server to process the data including network delays [0054]).
As recited above with respect to claim 1, it would have been obvious to one of ordinary skill in the art to combine the system and methods for facilitating mobile payment transactions disclosed by Herman with the authentication methods taught by Aronowitz since doing so would perform adaptive authentication to improve the security of the transaction.
Claims 3-7 and 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Herman, in view of Aronowitz, in view of Ellis, and further in view of KODIMER, US 2023/0262048 A1 (hereinafter Kodimer).
Regarding Claims 3 and 14: Ellis further teaches:
generating a first virtual credential token for the first mobile device (Ellis [0068]; ]0201]; [0234]; [0278]; [0280]; [0350]); and
storing the first virtual credential token in memory in association with the user account of the selected remote authorization service (Ellis [0068]; ]0201]; [0234]; [0278]; [0280]; [0350]).
Herman, as modified, fails to explicitly disclose
receiving a PIN selection from the first mobile device;
the received PIN, a unique identifier of the first mobile device, and account information associated with the selected remote authorization service, the account information including the first authentication information.
Kodimer teaches:
receiving a PIN selection from the first mobile device (Kodimer, including a user interface (UI) and workflow, wherein an MFP user can use an MFP-supplied login encoded image, such as QR code or barcode, displayed on the MFP’s front panel to receive or create a new PIN code to be used at the MFP; while example embodiments herein refer to a QR code, it is to be understood that any scan-able indicia can be used; by scanning the QR code from the user’s phone camera, a user’s trusted device can invoke a SkyPrint web portal using phone/face login to gain secure PIN code issuance; as a result, the user experience is improved; a QR code is used to invoke a secure page from the user’s secure and trusted mobile device instead of using the MFP to register with web portal page for PIN code issuance [0017]);
the received PIN, a unique identifier of the first mobile device, and account information associated with the selected remote authorization service, the account information including the first authentication information (Kodimer, FIG. 5 is an enlarged view of sequence 500 comprised of screens 136, 140 and 144 on touchscreen display 148 of smartphone 116 of FIG. 1; screen 136 is generated after QR code scanning; a portal is opened with the print server and a PIN selection window 504 is displayed; a PIN can be selected via soft keypad 508; alternatively, a PIN can be automatically created when a user selects soft key 512; screen 140 shows PIN selection 516 in PIN selection window 504; a newly created PIN created and use verification is provided at block 520 of screen 144; the PIN is then associated with the user and stored on the print server [0030]; FIG. 7 is a flowchart 700 illustrating an example embodiment of a system for PIN authentication issuance from a MFP QR Code; the process begins at block 704 and proceeds to block 708 where a user is registered in a SkyPrint administration portal for device PIN authentication; next, at block 712, a user arrives at an MFP without having a PIN or having forgotten their PIN; the user proceeds to scan an MFP QR code on the MFP device authentication screen with their secure mobile device at block 716; next, the system presents an instruction to the user at block 720 to generate, or auto-generate a new PIN; a new PIN is then created and saved on the print server at block 724; the user is then able to authenticate to the MFP with their new PIN code in block 728 and the process ends at block 732 [0032]).
It would have been obvious to one of ordinary skill in the art to combine the system and methods for facilitating mobile payment transactions disclosed by Herman with the use of PINs as taught by Kodimer since doing so would securely manage users account.
Regarding Claims 4 and 15: Kodimer further teaches:
receiving a second request over the communication network from the first mobile device, the request including the URL encoded within another image scanned by the camera of the first mobile device (Kodimer [0017]; [0019]; [0030]-[0032]); and
launching a different version of the first microsite based on the second request including the unique identifier of the first mobile device, wherein the different version of the first microsite includes a display that presents a request for the PIN (Kodimer [0017]; [0019]; [0029]-[0030]).
Regarding Claims 5 and 16: Kodimer further teaches:
receiving the PIN from the first mobile device at the different version of the first microsite (Kodimer [0017]; [0019]; [0030]-[0032]).
Aronowitz further teaches:
automatically launching a second authorization workflow corresponding to the selected remote authorization service based on the unique identifier of the first mobile device and the received PIN matches the stored unique identifier of the first device and the stored PIN associated with the first virtual credential token (Aronowitz [0039]-[0040]; [0044]; [0084]-[0085]).
Ellis further teaches:
automatically populating a field within a display associated with the selected remote authorization service based on the first authentication information associated with the first virtual credential token (Ellis [0029]; [0035]; [0236]; [0300]-[0301]); and
authorizing a second amount of gameplay from the user account of the selected remote authorization service based on the stored first virtual credential token and an updated risk assessment by the risk engine concerning the second amount of gameplay (Ellis [0029]; [0035]; [0236]; [0300]-[0301]).
Regarding Claim 6: Herman further discloses providing an option to switch to a different user account (Herman [0008]).
Kodimer further teaches providing an option within a different version of the microsite to switch, and providing an option to save a different PIN associated with the different account (Kodimer [0017]; [0019]; [0030]-[0032]).
Regarding Claim 7: Herman further discloses:
receiving a second request over the communication network from the first mobile device, the second request including a second URL encoded within an image scanned by the camera of the first mobile device (Herman [0018]; [0063]-[0064]; [0073]).
Aronowitz further teaches
launching a second authorization workflow over the communication network corresponding to a second remote authorization service associated with a second selection of the second remote authorization service of the remote authorization services and a second selection of one of the different amounts of gameplay presented within the generated display (Aronowitz [0039]-[0040]; [0044]; [0084]-[0085]);
updating the display based on the second authorization workflow to the different remote authorization services, wherein the updated display is configured to receive a second authentication information for the different remote authorization service from the first mobile device (Aronowitz [0039]-[0040]; [0044]; [0084]-[0085]); and
authorizing the second selected amount of gameplay based on confirmation of the authentication information from the second remote authorization service and a second risk assessment by the risk engine (Aronowitz [0039]-[0040]; [0044]; [0084]-[0085]).
Claims 9-10 and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Herman, in view of Aronowitz, in view of Ellis, and further in view of Retna et al., US 2020/0202268 A1 (hereinafter Retna).
Regarding Claims 9 and 18: Herman, as modified, discloses the invention as recited above. Herman, as modified, fails to explicitly disclose wherein the historical datapoints are used to train a machine-learning model to correlate one or more conditions to one or more risk levels, and wherein determining whether to send the first confirmation includes applying the machine-learning model to a set of conditions associated with the request.
Retna teaches wherein the historical datapoints are used to train a machine-learning model to correlate one or more conditions to one or more risk levels, and wherein determining whether to send the first confirmation includes applying the machine-learning model to a set of conditions associated with the request (Retna, the server device may include a data source that stores historical risk data and historical compliance data associated with multiple entities; the intelligence platform may include a platform that utilizes machine learning models to predict risk and compliance data, remediation incidents, and remediation solutions, as described herein [0015]; as further shown in FIG. 1A, and by reference number 105, the intelligence platform may receive, from the server device, historical risk data identifying historical risks, and historical compliance data identifying historical compliance actions; the historical risks and/or the historical compliance actions may be associated with one or more entities (e.g., one or more corporations, one or more educational institutions, one or more government agencies, and/or the like); each of the one or more entities may monitor risk activities and/or compliance actions associated with each entity, and may store data associated with the monitored risk activities and/or the compliance actions (e.g., the historical risk data and/or the historical compliance data) in a data structure (e.g., a database, a table, a list, and/or the like) associated with the server device [0016]; process 400 may include receiving historical risk data identifying historical risks associated with entities (block 410) [0108]; process 400 may include training a machine learning model with the historical risk data and the historical compliance data to generate a structured semantic model (block 430); for example, the device (e.g., using computing resource 224, processor 320, memory 330, and/or the like) may train a machine learning model with the historical risk data and the historical compliance data to generate a structured semantic model, as described above [0110]).
It would have been obvious to one of ordinary skill in the art to combine the system and methods for facilitating mobile payment transactions disclosed by Herman with the use of historical datapoints and machine learning for risk management as taught by Retna since doing so would efficiently calculate the risk associated with the authorization request. .
Regarding Claims 10 and 19: Retna further teaches wherein the historical datapoints used train the machine-learning model are associated with authorizations corresponding to different users and respective creditable amounts (Retna [0015]-[0017]; [0107]-[0110]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WERNER G GARNER whose telephone number is (571)270-7147. The examiner can normally be reached M-F 7:30-15:30 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, DAVID LEWIS can be reached at (571) 272-7673. 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.
/WERNER G GARNER/Primary Examiner, Art Unit 3715