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 .
DETAILED ACTION
Status of the Claims
The following office action in response to the application filed on 5/10/2024.
Claims 1-20 were previously presented.
Therefore, claims 1-20 are pending and addressed below.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claims 1-20 are directed to a method, a system, and a non-transitory computer readable medium and thus a statutory category of invention (Step 1: YES).
Claim 1 is rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea without significantly more. The claim recites the limitations of “…retrieving …a plurality of odds feeds… of a plurality of sports betting operators; receiving … input indicative of a user’s interaction; and sending in accordance with the received input, at least one bet …to offload data processing of the at least one bet”. These recited limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of commercial or legal interactions (including business relation, i.e. processing data of a sports betting) and/or fundamental economic principles or practices (including mitigating risk, i.e. a sports betting method) but for the recitation of generic computer components. If a claim limitation, under its broadest reasonable interpretation, covers concepts of commercial or legal interactions and/or fundamental economic principles or practices but for the recitation of generic computer components, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
The additional limitations (besides those that recite the abstract idea) include the presence in the method claimed of a computer network, an aggregator application, a plurality of back-end transactional components and a graphical user interface (GUI) of the aggregator application that are all recited at a high level of generality to perform the functions of “retrieving… …a plurality of odds feeds…to show…a merged odds module…; receiving … input; and sending …at least one bet …to offload… data processing of the at least one bet”, such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, the additional elements do not integrate the abstract idea into a particular application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception or amount to an inventive concept. As discussed above with respect to integration of the abstract idea into a practical application, the additional limitations of the computer network, the aggregator application, the plurality of back-end transactional components and the graphical user interface (GUI) of the aggregator application that are all recited at a high level of generality to perform the functions of “retrieving… …a plurality of odds feeds…to show…a merged odds module…; receiving … input; and sending …at least one bet …to offload… data processing of the at least one bet”, above amounts to mere instructions to apply the exception using the generic computer component. When viewing the additional elements either individually or as an ordered combination, the claim as a whole does not amount to significantly more than the judicial exception because the claim does not include improvements to another technology or technical field, improvements to the function of the computer itself, and does not provide meaningful limitations beyond general linking the use of an abstract idea to a particular technological environment. In effect, the additional limitations add the words “apply it” (or an equivalent) to the judicial exception, or mere instructions to implement an abstract idea on a computer. Mere instructions to apply an exception using the generic computer component cannot provide an inventive concept. Thus, the claim is not patent eligible.
Independent claims 19 and 20 recite limitations substantially similar to claim 1. Thus, the claims are rejected based on the same reasoning as above in claim 1. Thus, the claims are not eligible.
Dependent claims 2-18 are dependent on claims 1, 19 and 20. Therefore, claims 2-18 are directed to the same abstract idea of claims 1, 19 and 20. Claims 2-18 further recite the limitations that merely refer back to further details of the abstract idea. In addition, the additional limitations (besides those that recite the abstract idea) of the aggregator application, the GUI of the aggregator application, the computer network, the at least one of the plurality of back-end transactional components, the webview link or the iframe link, the electronic wallet, the application programming interface (API), the first computing device, the second computing device, the web application and the native application included in the dependent claims 2-18 that are all recited at a high level of generality to perform the functions of “receiving… user data; and sending…the user data to offload …data processing of the user data…” (claim 2); “sent…the user data…” (claim 3); “generating …a user account…; and sending…account data…” (claim 4); “sent…the account data…” (claim 5); “generating… the at least one bet…” (claim 6 and claim 7); “receiving… at least one bet update; and updating…the at least one bet update received…” (claim 8); “requesting… the at least one bet update…” (claim 9); “executes… the application and the transactional components” (claim 10); “communicates … with the back-end transactional components” (claim 11); “receives …at least one of the plurality of odds feeds” (claim 12); “sends …the at least one bet” (claim 13); “tracks… the at least one bet” (claim 14); “communicates… with the back-end transactional components” (claim 15); “receives … odds feeds” (claim 16); “sends …the at least one bet” (claim 17); and “tracks …the at least one bet” (claim 18), such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
The dependent claims 2-18 does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception or amount to an inventive concept. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to nothing more than an instruction to “apply it” with the judicial exception. In addition, the additional limitations (besides those that recite the abstract idea) of the aggregator application, the GUI of the aggregator application, the computer network, the at least one of the plurality of back-end transactional components, the webview link or the iframe link, the electronic wallet, the application programming interface (API), the first computing device, the second computing device, the web application and the native application included in the dependent claims 2-18 that are all recited at a high level of generality to perform the functions of “receiving… user data; and sending…the user data to offload …data processing of the user data…” (claim 2); “sent…the user data…” (claim 3); “generating …a user account…; and sending…account data…” (claim 4); “sent…the account data…” (claim 5); “generating… the at least one bet…” (claim 6 and claim 7); “receiving… at least one bet update; and updating…the at least one bet update received…” (claim 8); “requesting… the at least one bet update…” (claim 9); “executes… the application and the transactional components” (claim 10); “communicates … with the back-end transactional components” (claim 11); “receives …at least one of the plurality of odds feeds” (claim 12); “sends …the at least one bet” (claim 13); “tracks… the at least one bet” (claim 14); “communicates… with the back-end transactional components” (claim 15); “receives … odds feeds” (claim 16); “sends …the at least one bet” (claim 17); and “tracks …the at least one bet” (claim 18), above amounts to mere instructions to apply the exception using the generic computer components. When viewing the additional elements either individually or as an ordered combination, the claim as a whole does not amount to significantly more than the judicial exception because the claim does not include improvements to another technology or technical field, improvements to the function of the computer itself, and does not provide meaningful limitations beyond general linking the use of an abstract idea to a particular technological environment. In effect, the additional limitations add the words “apply it” (or an equivalent) to the judicial exception, or mere instructions to implement an abstract idea on a computer. Mere instructions to apply an exception using the generic computer component cannot provide an inventive concept. Thus, when considering the combination of elements and the claimed as a whole, the dependent claims 2-18 are not patent eligible.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C.102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless --
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 6, 8, 10, 19 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated over JOAO (2019/0051116).
As per claim 1, JOAO teaches a method (see paragraphs 12-17 and Fig.1-Fig.2), comprising:
retrieving over a computer network, by an aggregator application of a sports betting affiliate, a plurality of odds feeds from a plurality of back-end transactional components of a plurality of sports betting operators in order to show a merged odds module in a graphical user interface (GUI) of the aggregator application (via obtain betting odds information regarding a sporting event, game, match, activity, competition, or tournament, and/or obtain data and/or information. The apparatus 100 can provide an electronic forum or chat room (not shown), or a webpage, which can provide an individual or user with a video screen via which he or she can watch and/or listen to a sporting event, game, match, activity, competition, or tournament. The apparatus 100, the electronic forum, the chat room, or the webpage can also provide the individual or user with sports betting and other data and/or information, which can be continuously updated, and allow the individual or user to place bets, communicate with others, and engage in a wide variety of activities. The individual or user can access the information/analytics provider computer 70 in order to obtain any data and/or information, or analytics data and/or information, which he or she may want to obtain and review in advance of placing any bet, see paragraphs 334, 340-344 and Fig.1-Fig.2);
receiving, by the aggregator application, input indicative of a user’s interaction with the GUI of the aggregator application (via the individual or user can place (input/user’s interaction) any bet while in, or via, the respective electronic forum, chat room, or webpage of the website, or via the central processing computer. Each time a bet is placed by the individual or user or by any other individual or user, information regarding the same can be stored in his or her respective sports betting account, gaming account, or gambling account, and information regarding same can also be transmitted to, stored, and/or maintained, at the central processing computer, the financial institution computer, and/or the escrow agent computer. The individual or user can place a bet on the selected sporting event, game, match, activity, competition, or tournament, and the individual or user can utilize a payment identifier, such as his or her sports betting account number, gaming account number, or gambling account number, in order to place and make payment for the bet. The individual or user can also provide a payment identifier such as, but not limited to, a credit account number, a credit card account number, a debit account number, a debit card account number, a charge account number, a charge card account number, a savings account number, a checking account number, or any other payment account number, see paragraphs 79, 95-101 and Fig.1-Fig.2); and
sending over the computer network, by the aggregator application, in accordance with the received input, at least one bet to at least one of the plurality of back-end transactional components to offload data processing of the at least one bet to the at least one of the plurality of back-end transactional components (via the individual or user can, at step 1304 or at any other time, place any bet while in, or via, the respective electronic forum, chat room, or webpage of the website, or via the central processing computer 10. When the individual or user places any bet, information regarding or pertaining to the bet can be transmitted from the user communication device 20 and can be received and processed by the central processing computer 10, see paragraphs 368 and Fig.1-Fig.2).
As per claim 6, JOAO teaches the limitations wherein generating, by the aggregator application, the at least one bet in accordance with the received input (via the individual or user can place (input/user’s interaction) any bet while in, or via, the respective electronic forum, chat room, or webpage of the website, or via the central processing computer. Each time a bet is placed by the individual or user or by any other individual or user, information regarding the same can be stored in his or her respective sports betting account, gaming account, or gambling account, and information regarding same can also be transmitted to, stored, and/or maintained, at the central processing computer, the financial institution computer, and/or the escrow agent computer. The individual or user can place a bet on the selected sporting event, game, match, activity, competition, or tournament, and the individual or user can utilize a payment identifier, such as his or her sports betting account number, gaming account number, or gambling account number, in order to place and make payment for the bet. The individual or user can also provide a payment identifier such as, but not limited to, a credit account number, a credit card account number, a debit account number, a debit card account number, a charge account number, a charge card account number, a savings account number, a checking account number, or any other payment account number, see paragraphs 79, 95-101 and Fig.1-Fig.2).
As per claim 8, JOAO teaches the limitations wherein receiving, by the aggregator application, at least one bet update from the at least one of the plurality of back-end transactional components (via the central processing computer 10 can also provide, via the electronic forum, chat room, or webpage of the website, and during the sporting event, game, match, activity, competition, or tournament, information regarding available new bets, betting odds for same, and/or any new or updated betting odds for bets corresponding to the sporting event, game, match, activity, competition, or tournament, as well as the availability of bets and/or betting odds for same which can provide the individual or user with an opportunity to increase his or her winnings, minimize his or her losses, or obtain any hedge position to protect his or her interests regarding any bets he or she has already placed, see paragraph 371); and updating, by the aggregator application, the GUI of the aggregator application to include the at least one bet update received from the at least one of the plurality of back-end transactional components (via the central processing computer can also provide, via the electronic forum, chat room, or webpage of the website, and during the sporting event, game, match, activity, competition, or tournament, information regarding any new available bets and/or any new or updated betting odds for bets corresponding to the sporting event, game, match, activity, competition, or tournament, as well as the availability of bets and/or betting odds for bets which can allow the individual or user to protect his or her betting position and/or to increase his or her potential winnings or minimize his or her potential losses. Any information regarding any bets placed by the individual or user can be displayed in an appropriate location or section of the electronic forum, chat room, or webpage of the website. Any information regarding any gaming insurance product(s) or gaming derivative product(s) can also be displayed in an appropriate location or section of the electronic forum, chat room, or webpage of the website, see paragraphs 104 and 105).
As per claim 10, JOAO teaches the limitations wherein a first computing device of the sports betting affiliate executes the affiliate application, and wherein a second computing device of the sports betting operator executes the back-end transactional component. (via the user communication device 20 can communicate with, and/or can be linked with, the central processing computer(s) 10 and/or any other computers or communication devices described herein, via a wired communication network, a wireless communication network, or via any combination of wired and/or wireless communication networks, see paragraph 167).
As per claim 19, JOAO teaches a non-transitory computer-readable storage medium tangibly encoded with computer-executable instructions, that when executed by a processor of a computing device, performs a method, the method comprising (see paragraphs 12-17 and Fig.1-Fig.2):
retrieving over a computer network, by an aggregator application of a sports betting affiliate, a plurality of odds feeds from a plurality of back-end transactional components of a plurality of sports betting operators in order to show a merged odds module in a graphical user interface (GUI) of the aggregator application (via obtain betting odds information regarding a sporting event, game, match, activity, competition, or tournament, and/or obtain data and/or information. The apparatus 100 can provide an electronic forum or chat room (not shown), or a webpage, which can provide an individual or user with a video screen via which he or she can watch and/or listen to a sporting event, game, match, activity, competition, or tournament. The apparatus 100, the electronic forum, the chat room, or the webpage can also provide the individual or user with sports betting and other data and/or information, which can be continuously updated, and allow the individual or user to place bets, communicate with others, and engage in a wide variety of activities. The individual or user can access the information/analytics provider computer 70 in order to obtain any data and/or information, or analytics data and/or information, which he or she may want to obtain and review in advance of placing any bet, see paragraphs 334, 340-344 and Fig.1-Fig.2);
receiving, by the aggregator application, input indicative of a user’s interaction with the GUI of the aggregator application (via the individual or user can place (input/user’s interaction) any bet while in, or via, the respective electronic forum, chat room, or webpage of the website, or via the central processing computer. Each time a bet is placed by the individual or user or by any other individual or user, information regarding the same can be stored in his or her respective sports betting account, gaming account, or gambling account, and information regarding same can also be transmitted to, stored, and/or maintained, at the central processing computer, the financial institution computer, and/or the escrow agent computer. The individual or user can place a bet on the selected sporting event, game, match, activity, competition, or tournament, and the individual or user can utilize a payment identifier, such as his or her sports betting account number, gaming account number, or gambling account number, in order to place and make payment for the bet. The individual or user can also provide a payment identifier such as, but not limited to, a credit account number, a credit card account number, a debit account number, a debit card account number, a charge account number, a charge card account number, a savings account number, a checking account number, or any other payment account number, see paragraphs 79, 95-101 and Fig.1-Fig.2); and
sending over the computer network, by the aggregator application, in accordance with the received input, at least one bet to at least one of the plurality of back-end transactional components to offload data processing of the at least one bet to the at least one of the plurality of back-end transactional components (via the individual or user can, at step 1304 or at any other time, place any bet while in, or via, the respective electronic forum, chat room, or webpage of the website, or via the central processing computer 10. When the individual or user places any bet, information regarding or pertaining to the bet can be transmitted from the user communication device 20 and can be received and processed by the central processing computer 10, see paragraphs 368 and Fig.1-Fig.2).
As per claim 20, JOAO teaches a system, comprising: a processor of a computing device; and a non-transitory computer-readable storage medium tangibly encoded with computer-executable instructions, that when executed by the processor of the computing device, performs a method, the method comprising (see paragraphs 12-17 and Fig.1-Fig.2):
retrieving over a computer network, by an aggregator application of a sports betting affiliate, a plurality of odds feeds from a plurality of back-end transactional components of a plurality of sports betting operators in order to show a merged odds module in a graphical user interface (GUI) of the aggregator application (via obtain betting odds information regarding a sporting event, game, match, activity, competition, or tournament, and/or obtain data and/or information. The apparatus 100 can provide an electronic forum or chat room (not shown), or a webpage, which can provide an individual or user with a video screen via which he or she can watch and/or listen to a sporting event, game, match, activity, competition, or tournament. The apparatus 100, the electronic forum, the chat room, or the webpage can also provide the individual or user with sports betting and other data and/or information, which can be continuously updated, and allow the individual or user to place bets, communicate with others, and engage in a wide variety of activities. The individual or user can access the information/analytics provider computer 70 in order to obtain any data and/or information, or analytics data and/or information, which he or she may want to obtain and review in advance of placing any bet, see paragraphs 334, 340-344 and Fig.1-Fig.2);
receiving, by the aggregator application, input indicative of a user’s interaction with the GUI of the aggregator application (via the individual or user can place (input/user’s interaction) any bet while in, or via, the respective electronic forum, chat room, or webpage of the website, or via the central processing computer. Each time a bet is placed by the individual or user or by any other individual or user, information regarding the same can be stored in his or her respective sports betting account, gaming account, or gambling account, and information regarding same can also be transmitted to, stored, and/or maintained, at the central processing computer, the financial institution computer, and/or the escrow agent computer. The individual or user can place a bet on the selected sporting event, game, match, activity, competition, or tournament, and the individual or user can utilize a payment identifier, such as his or her sports betting account number, gaming account number, or gambling account number, in order to place and make payment for the bet. The individual or user can also provide a payment identifier such as, but not limited to, a credit account number, a credit card account number, a debit account number, a debit card account number, a charge account number, a charge card account number, a savings account number, a checking account number, or any other payment account number, see paragraphs 79, 95-101 and Fig.1-Fig.2); and
sending over the computer network, by the aggregator application, in accordance with the received input, at least one bet to at least one of the plurality of back-end transactional components to offload data processing of the at least one bet to the at least one of the plurality of back-end transactional components (via the individual or user can, at step 1304 or at any other time, place any bet while in, or via, the respective electronic forum, chat room, or webpage of the website, or via the central processing computer 10. When the individual or user places any bet, information regarding or pertaining to the bet can be transmitted from the user communication device 20 and can be received and processed by the central processing computer 10, see paragraphs 368 and Fig.1-Fig.2).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C.102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of AIA 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2, 4, 7 and 9 are rejected under AIA 35 U.S.C. 103 as being unpatentable over JOAO (2019/0051116) and further in view of Purves et al. (2015/0154588).
As per claim 2, JOAO does not explicitly teach the limitations wherein receiving, by the aggregator application, user data via the GUI of the aggregator application; and sending, over the computer network, by the aggregator application, the user data to the at least one of the plurality of back-end transactional components to offload data processing of the user data to the at least one of the plurality of back-end transactional components.
However, Purves teaches these limitations wherein receiving, by the aggregator application, user data via the GUI of the aggregator application; and sending, over the computer network, by the aggregator application, the user data to the at least one of the plurality of back-end transactional components to offload data processing of the user data to the at least one of the plurality of back-end transactional components (via FIG. 21 is an example data and logic flow illustrating the enrollment of a consumer account in a virtual wallet service and the utilization of a pre-fill service to pre-populate information necessary for wallet enrollment. The user may then indicate that they desire to add a new payment account to their virtual wallet 2103. The RUAG may then request that the user consent to the retrieval of their payment account information from the payment account issuer 2104. The user may be asked to provide the account number of the payment account that the user wishes to link to their virtual wallet account 2105. The RUAG may then use the user's account number or other credential such as a username/password combination or the like to initiate a request for retrieval of pre- provisioned data associated with the payment account 2106, see paragraph 145).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of JOAO and Purves in order to provide a RUAG controller 3301 of Purves in JOAO to receive and sending the user data more efficiently.
As per claim 4, JOAO does not explicitly teach the limitations wherein generating, by the aggregator application, a user account according to user interaction with the GUI of the aggregator application; and sending, over the computer network, by the aggregator application, account data of the generated user account to the at least one of the plurality of back-end transactional components to offload data processing of the account data to the at least one of the plurality of back-end transactional components.
However, Purves teaches these limitations wherein generating, by the aggregator application, a user account according to user interaction with the GUI of the aggregator application; and sending, over the computer network, by the aggregator application, account data of the generated user account to the at least one of the plurality of back-end transactional components to offload data processing of the account data to the at least one of the plurality of back-end transactional components (via FIG. 21 is an example data and logic flow illustrating the enrollment of a consumer account in a virtual wallet service and the utilization of a pre-fill service to pre-populate information necessary for wallet enrollment. In some embodiments, the consumer is directed to the virtual wallet enrollment page by directly typing the enrollment URL in a web browser 2101. In some embodiments, the consumer is navigated to a wallet login page where they may log into a wallet or create a new wallet account 2101a. In other embodiments, the consumer may enroll in the virtual wallet through a link in their issuer's web site, credit card company, rewards online access account, and/or the like. In some embodiments, the user may then create a virtual wallet account 2102. In other embodiments, the user may log into their pre-existing virtual wallet account. The user may then activate the wallet account 2102a. The user may then indicate that they desire to add a new payment account to their virtual wallet 2103. The RUAG may then request that the user consent to the retrieval of their payment account information from the payment account issuer 2104. The user may be asked to provide the account number of the payment account that the user wishes to link to their virtual wallet account 2105. The RUAG may then use the user's account number or other credential such as a username/password combination or the like to initiate a request for retrieval of pre-provisioned data associated with the payment account 2106, see paragraph 145).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of JOAO and Purves in order to provide a RUAG controller 3301 of Purves in JOAO to generate and sending the account data more efficiently.
As per claim 7, JOAO teaches the limitations wherein generation of the at least one bet is further responsive to user interaction via the aggregator application (via the individual or user can place (input/user’s interaction) any bet while in, or via, the respective electronic forum, chat room, or webpage of the website, or via the central processing computer. Each time a bet is placed by the individual or user or by any other individual or user, information regarding the same can be stored in his or her respective sports betting account, gaming account, or gambling account, and information regarding same can also be transmitted to, stored, and/or maintained, at the central processing computer, the financial institution computer, and/or the escrow agent computer. The individual or user can place a bet on the selected sporting event, game, match, activity, competition, or tournament, and the individual or user can utilize a payment identifier, such as his or her sports betting account number, gaming account number, or gambling account number, in order to place and make payment for the bet. The individual or user can also provide a payment identifier such as, but not limited to, a credit account number, a credit card account number, a debit account number, a debit card account number, a charge account number, a charge card account number, a savings account number, a checking account number, or any other payment account number, see paragraphs 79, 95-101 and Fig.1-Fig.2).
JOAO does not explicitly teach an electronic wallet.
However, Purves teaches an electronic wallet (via the RUAG may be configured to facilitate the generation of merchant-based user accounts from a virtual wallet application, issuer website, and/or the like, see paragraph 52).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of JOAO and Purves in order to provide a virtual wallet application of Purves in JOAO to generate the bets more efficiently.
As per claim 9, JOAO does not explicitly teach the limitations wherein requesting, by the aggregator application, the at least one bet update from the at least one of the plurality of back-end transactional components via an application programming interface (API) of the at least one of the plurality of back-end transactional components.
However, Purves teaches the limitations wherein requesting, by the aggregator application, the at least one bet update from the at least one of the plurality of back-end transactional components via an application programming interface (API) of the at least one of the plurality of back-end transactional components (via each callback may include the customer ID that is unique to the customer-merchant relationship. The API calls to the RUAG may include one or more API keys such as a public key and/or a shared secret key. An API key may be a string value that identifies the general API access configuration and settings for the site, see paragraph 98).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of JOAO and Purves in order to provide the RUAG system and the API of Purves in JOAO to request the updated bet more quickly.
Claims 3, 5 and 11-18 are rejected under AIA 35 U.S.C. 103 as being unpatentable over JOAO (2019/0051116) and Purves et al. (2015/0154588), and further in view of Lee et al. (2015/0249872).
As per claim 3, the combination of JOAO and Purves teach the limitations wherein the user data is sent to the at least one of the plurality of back-end transactional components (via FIG. 21 is an example data and logic flow illustrating the enrollment of a consumer account in a virtual wallet service and the utilization of a pre-fill service to pre-populate information necessary for wallet enrollment. The user may then indicate that they desire to add a new payment account to their virtual wallet 2103. The RUAG may then request that the user consent to the retrieval of their payment account information from the payment account issuer 2104. The user may be asked to provide the account number of the payment account that the user wishes to link to their virtual wallet account 2105. The RUAG may then use the user's account number or other credential such as a username/password combination or the like to initiate a request for retrieval of pre- provisioned data associated with the payment account 2106, see in Purves paragraph 145).
However, the combination of JOAO and Purves does not explicitly teach the limitations wherein a webview link or an iframe link.
Lee teaches this limitation wherein a webview link or an iframe link (via with the query response return 213c (e.g., in the form of a web page), the asset composite component 214 may generate a contextual activity payload 214. The payload may generate a new UI pane, and/or inset a composite response UI via an iframe inset, see paragraph 47).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of JOAO, Purves and Lee in order to provide a composite response UI via an iframe inset of Lee so that the user data in the combination of JOAO and Purves would be sent more quickly.
As per claim 5, the combination of JOAO and Purves teach the limitations wherein the account data is sent to the at least one of the plurality of back-end transactional components (via FIG. 21 is an example data and logic flow illustrating the enrollment of a consumer account in a virtual wallet service and the utilization of a pre-fill service to pre-populate information necessary for wallet enrollment. The user may then indicate that they desire to add a new payment account to their virtual wallet 2103. The RUAG may then request that the user consent to the retrieval of their payment account information from the payment account issuer 2104. The user may be asked to provide the account number of the payment account that the user wishes to link to their virtual wallet account 2105. The RUAG may then use the user's account number or other credential such as a username/password combination or the like to initiate a request for retrieval of pre- provisioned data associated with the payment account 2106, see in Purves paragraph 145).
However, the combination of JOAO and Purves does not explicitly teach the limitations wherein a webview link or an iframe link.
Lee teaches this limitation wherein a webview link or an iframe link (via with the query response return 213c (e.g., in the form of a web page), the asset composite component 214 may generate a contextual activity payload 214. The payload may generate a new UI pane, and/or inset a composite response UI via an iframe inset, see paragraph 47).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of JOAO, Purves and Lee in order to provide a composite response UI via an iframe inset of Lee so that the account data in the combination of JOAO and Purves would be sent more quickly.
As per claim 11, JOAO teaches the limitations wherein the aggregator application comprises a web application that communicates with the at least one of the plurality of back-end transactional components (via at step 1302, central processing computer 10 can transmit the search results message to the user communication device 20. At step 1302, user communication device 20 can receive the search results message. At step 1302, the individual or user can review the information contained in the search results message and select the sporting event, game, match, activity, competition, or tournament, on or for which he or she desires to place a bet. In a preferred embodiment, the individual or user, at step 1302, can, but not need, access the information/analytics provider computer 70 in order to obtain any data and/or information, or analytics data and/or information, which he or she may want to obtain and review in advance of placing any bet, see in JOAO paragraph 344).
However, the combination of JOAO and Purves does not explicitly teach the limitation of an iframe link.
Lee teaches this limitation of an iframe link (via with the query response return 213c (e.g., in the form of a web page), the asset composite component 214 may generate a contextual activity payload 214. The payload may generate a new UI pane, and/or inset a composite response UI via an iframe inset, see paragraph 47).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of JOAO, Purves and Lee in order to provide a composite response UI via an iframe inset of Lee so that the applications in the combination of JOAO and Purves would be communicated more efficiently.
As per claim 12, JOAO teaches the limitations wherein the aggregator application receives at least one of the plurality of odds feeds from the at least one of the plurality of back-end transactional components (via at step 1302, the individual or user can also request that the information/analytics provider computer 70 transmit updated data and/or information, including, but not limited to, analytics data and/or information, information regarding betting odds or betting odds changes, information regarding new betting opportunities, and/or any other data and/or information regarding the sporting event, game, match, activity, competition, or tournament, for which the individual or user wants to place a bet, or data and/or information regarding any teams and/or players or participants in or of same, to the user communication device 20 before the start of, during, or after, the selected sporting event, game, match, activity, competition, or tournament, see in JOAO paragraph 345).
However, the combination of JOAO and Purves does not explicitly teach the limitation of an iframe link.
Lee teaches this limitation of an iframe link (via with the query response return 213c (e.g., in the form of a web page), the asset composite component 214 may generate a contextual activity payload 214. The payload may generate a new UI pane, and/or inset a composite response UI via an iframe inset, see paragraph 47).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of JOAO, Purves and Lee in order to provide a composite response UI via an iframe inset of Lee so that the odds feeds data in the combination of JOAO and Purves would be received more efficiently.
As per claim 13, JOAO teaches the limitations wherein the aggregator application sends the at least one bet to the at least one of the plurality of back-end transactional components (via the individual or user can, at step 1304 or at any other time, place any bet while in, or via, the respective electronic forum, chat room, or webpage of the website, or via the central processing computer 10. In all instances when the individual or user places any bet, information regarding or pertaining to the bet can be transmitted from the user communication device 20 and can be received and processed by the central processing computer 10, see in JOAO paragraph 368).
However, the combination of JOAO and Purves does not explicitly teach the limitation of an iframe link.
Lee teaches this limitation of an iframe link (via with the query response return 213c (e.g., in the form of a web page), the asset composite component 214 may generate a contextual activity payload 214. The payload may generate a new UI pane, and/or inset a composite response UI via an iframe inset, see paragraph 47).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of JOAO, Purves and Lee in order to provide a composite response UI via an iframe inset of Lee so that bet data in the combination of JOAO and Purves would be sent more efficiently.
As per claim 14, JOAO teaches the limitations wherein the aggregator application tracks the at least one bet (via for each individual, party, entity, or user, the database 10H can contain any and/or all data and/or information regarding the sports betting, or other betting, history and/or betting patterns. For each sports betting account, gaming account, or gambling account, serviced by the apparatus 100 of the present invention, the database 10H can contain data and/or information for each bet placed on the respective account, the data and time of the bet, the sporting event, game, match, activity, competition, or tournament, which was the subject of the bet, the position taken by the bet or the bet made, the amount of the bet, whether or not the bet was placed in escrow, whether suspected game fixing, match fixing, or cheating, activity was noted for the sporting event, game, match, activity, competition, or tournament, the outcome of the sporting event, game, match, activity, competition, or tournament, whether the bet was a winning bet or a losing bet, a link to a recording of the respective electronic forum, chat room, or webpage, activity for the respective electronic forum, chat room, or webpage, via which the sporting event, game, match, activity, competition, or tournament, was watched or listened to, and/or any other data and/or information pertaining to each bet placed on the respective sporting event, game, match, activity, competition, or tournament. A video and/or audio recording of the placement of, or the making of, the bet can also be stored in the database 10H for each bet for which such a recording was made, see in JOAO paragraph 216).
However, the combination of JOAO and Purves does not explicitly teach the limitation of an iframe link.
Lee teaches this limitation of an iframe link (via with the query response return 213c (e.g., in the form of a web page), the asset composite component 214 may generate a contextual activity payload 214. The payload may generate a new UI pane, and/or inset a composite response UI via an iframe inset, see paragraph 47).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of JOAO, Purves and Lee in order to provide a composite response UI via an iframe inset of Lee so that bet data in the combination of JOAO and Purves would be tracked more efficiently.
As per claim 15, JOAO teaches the limitations wherein the aggregator application comprises an application that communicates with the at least one of the plurality of back-end transactional components (via at step 1302, central processing computer 10 can transmit the search results message to the user communication device 20. At step 1302, user communication device 20 can receive the search results message. At step 1302, the individual or user can review the information contained in the search results message and select the sporting event, game, match, activity, competition, or tournament, on or for which he or she desires to place a bet. In a preferred embodiment, the individual or user, at step 1302, can, but not need, access the information/analytics provider computer 70 in order to obtain any data and/or information, or analytics data and/or information, which he or she may want to obtain and review in advance of placing any bet, see in JOAO paragraph 344).
However, the combination of JOAO and Purves does not explicitly teach the limitation wherein a webview link of the native application.
Lee teaches this limitation wherein a webview link of the native application (via the AC Browser may be developed using iOS and/or Apple Cocoa libraries that include a webview, and themselves may contain iframes with embed codes to house any digital asset type, see paragraph 64).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of JOAO, Purves and Lee in order to provide a webview of Lee in the combination of JOAO and Purves so that the applications would be communicated more efficiently.
As per claim 16, JOAO teaches the limitations wherein the aggregator application receives an odds feed, of the plurality of odds feeds, from the at least one of the plurality of back-end transactional components (via at step 1302, the individual or user can also request that the information/analytics provider computer 70 transmit updated data and/or information, including, but not limited to, analytics data and/or information, information regarding betting odds or betting odds changes, information regarding new betting opportunities, and/or any other data and/or information regarding the sporting event, game, match, activity, competition, or tournament, for which the individual or user wants to place a bet, or data and/or information regarding any teams and/or players or participants in or of same, to the user communication device 20, see in JOAO paragraph 345).
However, the combination of JOAO and Purves does not explicitly teach the limitation wherein a webview link.
Lee teaches this limitation wherein a webview link (via the AC Browser may be developed using iOS and/or Apple Cocoa libraries that include a webview, and themselves may contain iframes with embed codes to house any digital asset type, see paragraph 64).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of JOAO, Purves and Lee in order to provide a webview of Lee in the combination of JOAO and Purves so that the odds feed data would be received more efficiently.
As per claim 17, JOAO teaches the limitations wherein the aggregator application sends the at least one bet to the at least one of the plurality of back-end transactional components (via the individual or user can, at step 1304 or at any other time, place any bet while in, or via, the respective electronic forum, chat room, or webpage of the website, or via the central processing computer 10. In all instances when the individual or user places any bet, information regarding or pertaining to the bet can be transmitted from the user communication device 20 and can be received and processed by the central processing computer 10, see in JOAO paragraph 368).
However, the combination of JOAO and Purves does not explicitly teach the limitation wherein a webview link.
Lee teaches this limitation wherein a webview link (via the AC Browser may be developed using iOS and/or Apple Cocoa libraries that include a webview, and themselves may contain iframes with embed codes to house any digital asset type, see paragraph 64).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of JOAO, Purves and Lee in order to provide a webview of Lee in the combination of JOAO and Purves so that the odds feed data would be sent more efficiently.
As per claim 18, JOAO teaches the limitations wherein the aggregator application tracks the at least one bet (via for each individual, party, entity, or user, the database 10H can contain any and/or all data and/or information regarding the sports betting, or other betting, history and/or betting patterns. For each sports betting account, gaming account, or gambling account, serviced by the apparatus 100 of the present invention, the database 10H can contain data and/or information for each bet placed on the respective account, the data and time of the bet, the sporting event, game, match, activity, competition, or tournament, which was the subject of the bet, the position taken by the bet or the bet made, the amount of the bet, whether or not the bet was placed in escrow, whether suspected game fixing, match fixing, or cheating, activity was noted for the sporting event, game, match, activity, competition, or tournament, the outcome of the sporting event, game, match, activity, competition, or tournament, whether the bet was a winning bet or a losing bet, a link to a recording of the respective electronic forum, chat room, or webpage, activity for the respective electronic forum, chat room, or webpage, via which the sporting event, game, match, activity, competition, or tournament, was watched or listened to, and/or any other data and/or information pertaining to each bet placed on the respective sporting event, game, match, activity, competition, or tournament. A video and/or audio recording of the placement of, or the making of, the bet can also be stored in the database 10H for each bet for which such a recording was made, see in JOAO paragraph 216).
However, the combination of JOAO and Purves does not explicitly teach the limitation wherein a webview link.
Lee teaches this limitation wherein a webview link (via the AC Browser may be developed using iOS and/or Apple Cocoa libraries that include a webview, and themselves may contain iframes with embed codes to house any digital asset type, see paragraph 64).
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the application, to combine the teachings of JOAO, Purves and Lee in order to provide a webview of Lee in the combination of JOAO and Purves so that the odds feed data would be tracked more efficiently.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-20 of the instant application are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of co-pending U.S. Application No. 18/309,785 (filed on 1/02/2026). Both claims 1, 19 and 20 of the instant application and claims 1, 17 and 20 of U.S. Application No. 18/309,785 are directed to a method, a non-transitory computer-readable storage medium and a computing device related to processing a sports betting. Thus, claims 1, 17 and 20 of U.S. Application No. 18/309,785 teaches or suggests all of the limitations of claims 1, 19 and 20 of the instant application. However, claims 1, 17 and 20 of U.S. Application No. 18/309,785 also contains additional limitations not found in claims 1, 19 and 20 of the instant application, such as the limitations “displaying, by the affiliate application, an odds module in a graphical user interface (GUI) of the affiliate application displayed via the web browser”. Accordingly, claims 1, 17 and 20 of U.S. Application No. 18/309,785 are directed to a species of claims 1, 19 and 20 of the instant application (see MPEP § 804(II)(B)(2)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the additional limitations “displaying, by the affiliate application, an odds module in a graphical user interface (GUI) of the affiliate application displayed via the web browser” of claims 1, 17 and 20 of U.S. Application No. 18/309,785 so that retrieved odds feeds data in claims 1, 19 and 20 of the instant application would be displayed more efficiently.
Claims 1, 19 and 20 of the instant application are rejected as unpatentable on the ground of nonstatutory obviousness-type double patenting over claims 1 and 17 of U.S. Patent No. 11,651,467 (co-pending U.S. Application No. 16/728,010). Both claims 1, 19 and 20 of the instant application and claims 1 and 17 of U.S. Patent No. 11,651,467 (co-pending U.S. Application No. 16/728,010) are directed to a method, a non-transitory computer-readable storage medium and a computing device related to processing a sports betting. Thus, claims 1 and 17 of U.S. Patent No. 11,651,467 teaches or suggests all of the limitations of claims 1, 19 and 20 of the instant application. However, claims 1 and 17 of U.S. Patent No. 11,651,467 also contains additional limitations not found in claims 1, 19 and 20 of the instant application, such as the limitations “receiving, by the affiliate application, user data via the GUI of the affiliate application, the user data comprising user consent data and credentials of a user; sending over the computer network via the web browser, by the affiliate application, the user data and the account data of the generated user account to the back-end transactional component to offload data processing of the user data to the back-end transactional component; generating, by the affiliate application, a user account according to user interaction with the GUI of the affiliate application; and generating, by the affiliate application, a bet according to user interaction with an electronic wallet and the GUI of the affiliate application”. Accordingly, claims 1 and 17 of U.S. Patent No. 11,651,467 are directed to a species of claims 1, 19 and 20 of the instant application (see MPEP § 804(II)(B)(2)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the additional limitations of claims 1 and 17 of U.S. Patent No. 11,651,467 so that the bet data in claims 1, 19 and 20 of the instant application would be processed more accurately with the user account data and the electronic wallet.
Claims 1, 19 and 20 of the instant application are rejected as unpatentable on the ground of nonstatutory obviousness-type double patenting over claims 1, 19 and 20 of U.S. Patent No. 11,983,788 (co-pending U.S. Application No. 18/322,633). Both claims 1, 19 and 20 of the instant application and claims 1, 19 and 20 of U.S. Patent No. 11,983,788 (co-pending U.S. Application No. 18/322,633) are directed to a method, a non-transitory computer-readable storage medium and a computing device related to processing a sports betting. Thus, claims 1, 19 and 20 of U.S. Patent No. 11,983,788 teaches or suggests all of the limitations of claims 1, 19 and 20 of the instant application. However, claims 1, 19 and 20 of U.S. Patent No. 11,983,788 also contains additional limitations not found in claims 1, 19 and 20 of the instant application, such as the limitations “generating, by the aggregator application, a plurality of bets according to user interaction with an electronic wallet and the GUI of the aggregator application” and “via a web browser”. Accordingly, claims 1 and 17 of U.S. Patent No. 11,983,788 are directed to a species of claims 1, 19 and 20 of the instant application (see MPEP § 804(II)(B)(2)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the additional limitations “generating, by the aggregator application, a plurality of bets according to user interaction with an electronic wallet and the GUI of the aggregator application” and “via a web browser” of claims 1, 19 and 20 of U.S. Patent No. 11,983,788 so that the bet data in claims 1, 19 and 20 of the instant application would be processed more efficiently with the electronic wallet.
Claims 1, 19 and 20 of the instant application are rejected as unpatentable on the ground of nonstatutory obviousness-type double patenting over claims 1, 17 and 20 of U.S. Patent No. 11,676,237 (co-pending U.S. Application No. 16/728,035). Both claims 1, 19 and 20 of the instant application and claims 1, 17 and 20 of U.S. Patent No. 11,676,237 (co-pending U.S. Application No. 16/728,035) are directed to a method, a non-transitory computer-readable storage medium and a computing device related to processing a sports betting. Thus, claims 1, 17 and 20 of U.S. Patent No. 11,676,237 teaches or suggests all of the limitations of claims 1, 19 and 20 of the instant application. However, claims 1, 17 and 20 of U.S. Patent No. 11,676,237 also contains additional limitations not found in claims 1, 19 and 20 of the instant application, such as the limitations “receiving, by the aggregator application, user data via the GUI of the aggregator application, the user data comprising user consent data and credentials of a user; sending over the computer network via the web browser, by the aggregator application, the user data and the account data of the generated user account to the plurality of back-end transactional components to offload data processing of the user data to the plurality of back-end transactional components; generating, by the aggregator application, a user account according to user interaction with the GUI of the aggregator application; and generating, by the aggregator application, a plurality of bets according to user interaction with an electronic wallet and the GUI of the aggregator application”. Accordingly, claims 1, 17 and 20 of U.S. Patent No. 11,676,237 are directed to a species of claims 1, 19 and 20 of the instant application (see MPEP § 804(II)(B)(2)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the additional limitations of claims 1, 17 and 20 of U.S. Patent No. 11,676,237 so that the bet data in claims 1, 19 and 20 of the instant application would be processed more quickly with the user account data and the electronic wallet.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tien C. Nguyen whose telephone number is 571-270-5108. The examiner can normally be reached on Monday-Thursday (6am-2pm EST).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor,
Bennett Sigmond can be reached on 303-297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-270-6108.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/TIEN C NGUYEN/ Primary Examiner, Art Unit 3694
/BENNETT M SIGMOND/Supervisory Patent Examiner, Art Unit 3694